The product management process: six stages and the handoffs that break them
A product management process framework that survives contact with a real company — what each stage owes the next, where processes actually break, and how much of it you need at your stage.
Most published product management processes are drawn as a loop with five or six boxes, and every one of them is roughly correct. They’re also useless in the same way, because the boxes are never where anything goes wrong.
Processes don’t fail in the stages. They fail in the handoffs. Research that reaches nobody, a decision nobody can trace, a spec engineering has to reinterpret — all of those are gaps between boxes, and drawing more boxes doesn’t close them.
What a product management process framework actually is
A repeatable sequence for turning signals about users into shipped changes, where each stage produces a specific artefact that the next stage can act on without going back to the person who made it.
That last clause is the whole test. If your discovery output needs the researcher in the room to be usable, discovery hasn’t produced an artefact, it’s produced a memory.
The six stages, and what each owes the next
1. Sense — collect signals continuously
Support tickets, sales calls, usage data, churn interviews, your own search logs. The job is a standing habit, not a phase.
Owes the next stage: a live list of observed problems, not a backlog of requested features. The translation matters: “customers want bulk export” is a request; “customers re-key data into a spreadsheet every Monday” is a problem, and only one of them leaves room for a better answer.
Where it breaks: signals land in five places and nobody owns the pile.
2. Frame — turn a signal into a problem statement
One paragraph: who is stuck, in what circumstance, what it costs them, and how you’d know it was fixed.
Owes the next stage: something you could rank against other problems. Unframed problems can’t be prioritised, so teams end up prioritising solutions — which is the single most common structural defect I see.
Where it breaks: the framing arrives already containing the solution.
3. Decide — prioritise, out loud
Owes the next stage: a decision with a reason and a named owner. The bar: someone who wasn’t in the room can read why this and not that.
Where it breaks: the decision is made in the meeting and never written down, so it gets relitigated every time a stakeholder pushes. A scoring framework helps here, but only if someone is allowed to act on the output — and RICE has a specific failure mode worth knowing before you install it.
4. Shape — turn a decision into something buildable
Solution options, the one you chose, the trade-offs, the edge cases.
Owes the next stage: a document an engineer can start from without a meeting. If the first sprint begins with an argument about intent, shaping didn’t finish.
Where it breaks: shaping is done in a doc when it should have been done in a prototype. A clickable slice settles in one meeting what a twelve-page spec argues about for two weeks — which is the case for sending the prototype instead.
5. Ship — deliver in slices that can be evaluated
Owes the next stage: instrumentation that exists before launch. The most common reason teams can’t tell whether something worked is that the events were added afterwards.
Where it breaks: scope grows quietly, and the thing that ships isn’t the thing that was decided — so the learning stage measures an experiment nobody designed.
6. Learn — decide what the result means, and act on it
Owes the first stage: a written verdict. Kept, killed, or iterated, with the number and the date.
Where it breaks: this stage doesn’t happen. It is by far the most commonly skipped, and skipping it is what makes every earlier stage cheaper to fake — if nothing is ever evaluated, the quality of the decision never surfaces.
The three artefacts worth mandating
Don’t mandate the process. Mandate the outputs, and let teams reach them however they like:
- A framed problem before anything is prioritised.
- A written decision with the reason and what was given up.
- A verdict within a fixed window after launch — six weeks is a reasonable default.
Three documents. Everything else — ceremonies, templates, tools — is a local choice, and treating it as a local choice is what stops the process being resented.
How much process you actually need
| Stage | What’s enough | What’s over-engineering |
|---|---|---|
| Pre-fit, under 10 people | Founder talks to users weekly; decisions in a shared doc | Anything with a template |
| 10–40, first PMs | The three artefacts above, one owner per area | Stage gates, formal reviews |
| 40–150, multiple teams | Add a quarterly planning rhythm and one shared prioritisation method | A PMO |
| 150+ | Add explicit interfaces between teams | Uniformity for its own sake |
The failure at the small end is process theatre. At the large end it’s the opposite: every team invents its own vocabulary and nobody can compare two roadmaps.
If you’re installing this
Don’t roll out all six stages. Pick the handoff that’s most obviously broken and fix only that one, for one quarter.
In practice it’s nearly always stage 6. Teams that start evaluating outcomes begin, within two quarters, to frame problems better and decide more carefully — because for the first time somebody is going to look. Installing the front of the process before the back of it produces beautiful discovery documents and no change in what gets built.
And if the honest blocker is that nobody is allowed to act on any of these outputs, no process will fix it. That’s an ownership problem wearing a process costume — the most expensive misdiagnosis in this whole area, and the one I’d check for before designing anything. Telling the two apart usually takes one conversation, which is where an interim or consulting engagement tends to start rather than end.