STACEY
McCALMON PMP

The UXD Quality Improvement Program was one of my personal Focus Areas within the Executive Initiatives program, a portfolio of high-priority CEO-level initiatives tied directly to company revenue and business metrics. I owned the program infrastructure and launch. The UXD Quality focus area was co-owned with the UXD VP as executive sponsor. UXD Quality emerged from ongoing Co-CEO concerns about design quality across the product portfolio.

There was no existing process for identifying, triaging, or resolving design issues at scale. Bugs and quality gaps were being handled ad hoc, with no clear ownership and no system for tracking resolution. This was a net-new program, built from scratch, under direct executive pressure.

Five core product lines. Each with a .com and international portal. All of them in scope from day one.

I designed an end-to-end process for identifying, triaging, resolving, and scaling the resolution of UX quality issues across all product lines. The program needed to launch immediately, no runway for a phased rollout.

Fortunately, a prior failed initiative had surfaced a scaling technique that hadn't worked in its original context but turned out to be exactly what this program needed. I pulled it from the ashes and adapted it. The program processed approximately 400 issues across the portfolio during its active phase.

PRD creation at scale was the biggest bottleneck. PRDs traditionally took hours, sometimes days, to complete. With 400 issues across five product lines, that wasn't viable.

I worked cross-functionally with UX Design, Product, Engineering, and UX Writing to develop and refine an AI prompt that could generate PRDs within our team's standards. Once dialed in, anyone on the team could use it, not just PMs. What used to take hours now took minutes.

The product org ran as an A/B testing, experimental organization, every initiative is tied to revenue, and leadership needs to know which tests win and which lose. When I joined, there was a reporting template and a standing weekly meeting: 90 minutes, Co-CEOs, full C-suite (CPO, CTO, CMO), VPs, and the broader product org, over 200 on the guest list, 125–140 joining per session.

In my first few meetings, I noticed a pattern: the CEOs kept asking the same questions. The template wasn't answering what leadership actually needed to know.

I didn't rush to suggest improvements. I took note, acted on pressing changes as needed, and used the team's continuous improvement plan as the framework for longer-term refinement. Over time, I owned the template, cadence, and scheduling entirely, translating complex program status into executive-ready insights.

A new CPO joined, creating a natural inflection point. We redesigned the entire program around his needs:

• Co-CEOs transitioned out of the live meeting, new CPO owned reporting up to them directly
• Split into two meetings: .com and international product lines
• Reduced from 90 minutes to 60 minutes per session
• Reports distributed 24 hours before each meeting, CPO arrived with informed questions
• Revamped templates to reflect new leadership priorities

The reports became something more than meeting prep, leadership and PMs began using them as a test repository, referencing how specific experiments had performed over time. What started as a recurring deliverable became institutional memory and a bigger asset than anyone anticipated.

The Revenue Experience Team was actually three teams: eCommerce, Retention, and a proprietary product line. Prior to my ownership, eCommerce operated separately while Retention and the proprietary product line sat outside the product org entirely. A merger brought them together, but merging an org chart doesn't merge a culture.

I stepped in as program manager for the combined team of approximately 80 people across Product, Engineering, Design, UX Writing, Research, and Analytics, dispersed across the US, Poland, and India.

Three teams. Three sets of tools, templates, meeting formats, and operating norms. The risk wasn't conflict, it was fragmentation: three groups running in parallel, duplicating effort, misaligned on priorities, unable to collaborate when it counted.

I didn't try to flatten the teams into one. Each had its own character, product domain, and working rhythm, and that was appropriate. The goal was coherence without uniformity.

• Shared tooling and templates where it mattered for cross-team visibility
• Standardized meeting formats at the program level, roadmap planning, offsites, all-hands, retros, while preserving each team's internal rhythms
• Cross-functional collaboration frameworks that brought in Marketing, Legal, and Customer Care when major initiatives required it