The cost of building first, designing second
Two years to change how a company builds products
Context
The organization ran Scaled Agile in a way that treated design as a downstream finishing function. Product managers and engineers drove the backlog. Design was brought in to make things look good after the fundamental decisions had already been made, sometimes after delivery had already shipped. The cost was structural: when design flagged serious usability problems after the fact, rework consumed multiple sprint cycles. API dependencies and service architecture had been built without a UX foundation, which meant the experience had to fit within parameters the design team had no hand in defining. That pattern repeated itself across product teams, compounding over time.
Company
Enterprise analytics SaaS
My role
Sr. Manager, User Experience and Design Operations (later Director, Product Experience)
Team
40-50 person multidisciplinary design org
Timeline
2021 to 2023 (steady state); transformation sustained through 2025
Working backwards from what engineering actually needed
Approach
I served as the design organization's representative in a cross-functional SDLC redesign led by product operations, partnering with leaders from engineering, product management, and dev ops. While product operations owned the program, I owned everything on the design side: how design should engage in product discovery, what inputs designers needed to be successful before engineering began, and how design reviews fit into the broader lifecycle gate structure.
The core artifact I built was an Epic Readiness ritual, a checkpoint requiring validated discovery and design work before engineering could start. I worked backwards from what engineering needed as inputs, then defined what design and product management had to produce to get there. Design was responsible for desirability: do we understand the problem, the user, and a defensible approach to solving it? Product management was responsible for viability: do we understand what we're building and why?
The ritual evolved through quarterly retrospectives with product teams. Over time I added success criteria and OKR alignment as readiness requirements, so teams understood what "good" looked like before a single component was built. At the end of the transformation period, Epic Readiness was connected to the organization's design principles scorecard, meaning work entering engineering had been evaluated for design quality as a gate condition, not an afterthought.
I was also one of the design leadership voices in Epic Readiness reviews themselves, with equal standing in determining whether work was ready to move forward.
Champions at the top and a gap in the middle
Challenges
The transformation had real executive sponsorship: the SVP of Product Management, SVP of Engineering, and the CPO as executive sponsor. What it lacked was enough champions in the middle layer. Engineering managers and lead engineers were often handed work to build knowing design hadn't been involved. Many of them wanted the change; they just didn't feel empowered to push back on timelines or escalate the gap. That made adoption slower and more uneven than it needed to be.
In early 2024, a significant reduction in force gutted many of the original sponsors and champions. Momentum stalled. The response was to lean into the new hire onboarding infrastructure that had already been built: role-specific SDLC training for every product org member covering the full lifecycle and their specific responsibilities within it. It was a structural substitute for the advocacy network that had been lost, and it created a floor that prevented full regression.
The initial training rollout, a cohort-based program run over several weeks with select product teams, generated real enthusiasm but didn't sustain behavior change. Without ongoing investment in follow-up cohorts and reinforcement, many teams merged old habits with the new framework in ways that diluted both. That was the clearest failure in execution.
What got built differently
The results
Embedded design into the product development lifecycle across 20 product areas and 25-40 epics per quarter, shifting design's role from downstream finisher to upstream shaper
Eliminated the pattern of design being brought in after delivery; late-stage rework that had previously consumed multiple sprint cycles was no longer the default resolution path
Built an Epic Readiness ritual that evolved from basic input/output requirements to a full readiness standard including success criteria and OKR alignment, establishing a shared definition of "ready to build" across design, PM, and engineering
Connected Epic Readiness to the organization's design principles scorecard, so design quality was assessed as a gate condition before engineering began
Sustained the transformation through near-complete executive leadership turnover and a significant reduction in force by embedding process knowledge into onboarding infrastructure rather than individual champions
One rollout is not a program
What I learned
The training strategy is what I would change. The initial cohort was strong and generated real momentum. We did not follow it with ongoing training investment, and behavior change at organizational scale requires repetition. The new hire onboarding tracks were the right instinct; the gap was applying that same rigor to people who had already been through the one-time rollout. Sustained transformation needs a program, not an event.