Branch · 2025 to 2026
Redesigning a product development lifecycle.
A four-phase operating model with named DACI ownership, paired briefs, mandatory success metrics before Build, and post-launch decision loops. Adopted across product, design, engineering, and PMM.
Role
Sr. Director, Product Experience
Duration
Multi-quarter rollout
Team
Product, Design, Eng, PMM
Outcome
Adopted org-wide
The problem we kept paying for
Define was a black hole. Measurement was never the spine.
The company was shipping product, but problems got framed by PM alone. Designers entered at ticket assignment instead of problem framing. Engineers reacted to scoped solutions instead of shaping them. Analytics arrived after launch instead of before.
The cost wasn't just velocity. Teams shipped features without success metrics, those features accumulated into a heavier and heavier system, and nothing got deprecated because nothing had been measured. The system got heavier every quarter.
The approach
You can't fix a process by writing a process doc in isolation.
The work had to be grounded in how teams were actually working, where they were experiencing friction, and where expectations were misaligned. So instead of starting with a top-down framework, I designed a participatory workshop that asked each discipline to define its current reality first.
Each discipline named what their role was ultimately responsible for. Not titles. Not tasks. The actual outcomes the role exists to create. This surfaced where role definitions had drifted from how teams described their own work.
The unedited version. What work actually consumed time. This surfaced the gap between the role's stated purpose and its lived reality. Designers logging hours on ticket triage. PMs spending weeks on docs instead of discovery. Engineers reverse-engineering missing context.
"The gap is the work."
Pain points named without filter. Late design involvement. Unclear exit criteria. PMM brought in after positioning had hardened. No success metrics before build. The honesty of this prompt did more for buy-in than any framework I could have presented.
The method
Sticky notes, by discipline, mapped to the lifecycle.
Step 01
Capture role-level input
Participants used color-coded sticky notes by discipline (Product, Design, Engineering, PMM, Leadership). Each answered the three prompts individually before any group discussion. No solutions. No debate. Just current reality.
Step 02
Cluster the themes
Related notes were clustered into themes. Patterns emerged fast: discovery expectations varied widely, ownership was unclear, exit criteria were inconsistent, research and customer signal weren't integrated early enough, measurement wasn't defined before build.
Step 03
Map work to the lifecycle
Themes were mapped to lifecycle phases. Some pain points lived in one phase. Others showed up across multiple phases, revealing which parts of the process needed the most clarity. The map made the invisible rules of product development visible.
Step 04
Define artifacts and exit criteria
Once the current state was mapped, the group shifted from pain points to operating expectations. For each phase: what needs to be true before work moves forward, what decisions get made here, what artifacts exist, who owns them. This became the foundation for the four-phase model.
The workshop in action
Setup. Current state. Future state. Three boards, one arc.
Step 01 · Setup
Role purpose, work that fills the week, and pain points. Each discipline maps its current reality first.
Step 02 · Current state
Map every sticky to the lifecycle phase where it happens. The concentration of work shows where the process actually breaks.
Step 03 · Future state
For each phase: outcomes that must be true and artifacts that support them. Teal for outcomes. Orange for artifacts.
Click any board to view full size. Three boards. Same room. Built by the people who had to do the work afterward.
The shift
From sequential handoffs to a shared operating model.
The workshop surfaced what was actually breaking. The four-phase model is the response. Two side-by-side pictures, before the deep dive.
Before
Sequential handoff
The symptoms
- ·No success metrics before Build
- ·Designers enter at ticket assignment
- ·Engineers reverse-engineer context
- ·Nothing deprecated, system gets heavier
- ·Define is a black hole
After
Shared operating model
What changed
- ·Triad in the room from Discover
- ·Success metrics required before Build
- ·Standing threads, not one-time gates
- ·Invest, iterate, or deprecate decision
- ·Dashboards at launch, not after
The framework
The four-phase model.
Initiative-level work · SDLC runs inside Build · Design and customer proximity span all phases
01
Discover
Problem framing with the cross-functional triad in the room from the start. Exit: a signed problem brief.
02
Plan
Paired problem brief and technical solution brief. Defined success metrics. Dashboard plan committed before Build.
03
Build
SDLC runs inside this phase. Design active in hi-fi and QA. Customer partners engaged on significant initiatives.
04
Measure
Post-launch reviews against Plan metrics. Triad reconvenes. Invest, Iterate, or Deprecate decision documented.
Design and customer proximity run through all four phases as standing threads, not one-time gates. Design is never "started" at ticket assignment Customer contact is a calendar commitment with defined minimums per phase. The PDLC governs initiative-level work; SDLC runs inside Build.
The non-negotiables
Three things named non-negotiable from day one.
Technical feasibility and design implications shape the problem brief itself. Loops back from Measure re-engage the triad before returning to Build. The single change that did the most to fix Define as a black hole.
Every initiative entering Plan has defined success metrics, a dashboard plan, and a post-launch review scheduled. Dashboards exist at launch. Analytics is engaged at Plan, not at launch.
"Close the loop."
Every significant initiative gets a formal Invest, Iterate, or Deprecate decision. Features without decisions don't accumulate silently into maintenance burden. The loop closes with a real call.
The infrastructure
Four commitments leadership had to make.
A single source of truth for specs.
Designate one system as authoritative. Migration-forward policy. New initiatives use it from day one.
A functioning deprecation process.
Quarterly feature health reviews. Defined approval path for Reinvest, Maintain, or Deprecate decisions. Customer notice and migration paths for sunset.
Research access infrastructure.
Weekly customer touchpoint cadence as a calendar commitment. Named research coordinator per team. A searchable, accessible repository of insights.
A standing health review.
A regular leadership forum on whether gates are being respected, measurement is happening, teams are stuck. Not a status meeting. The mechanism that keeps the framework from ossifying.
The meta-point
Operating model design isn't about choosing a process framework.
It's about making the invisible rules of product development visible enough for teams to align around them.
This work was not about adding process. It was about reducing ambiguity. The participatory workshop wasn't facilitation theater. It was the mechanism that turned a process redesign into shared ownership across Product, Design, Engineering, and PMM. That's the difference between an operating model that gets adopted and one that gets ignored.