Most teams get stuck not because they have bad ideas, but because the path from idea to decision is invisible. Anyone can raise an opportunity. Few know what happens next, who decides, and when.
This workflow makes that path explicit. Ten stages. Clear owners. Defined inputs and outputs. It's the rails that let a product team move ideas through the system without heroics.
The principle Every stage has an owner, an input, and an output. If you can't name all three, it's not a real stage. It's a meeting.
The process at a glance
The ten stages
Each stage answers four questions: Who owns it? What's the input? What's the output? How long does it take?
01
Opportunity Statement
Anyone can propose. A user complaint, a contract clause, a compliance deadline, a market signal, if it deserves attention, it deserves a written statement.
02
Solution Approval
The Product Manager convenes a short meeting with tech leadership and team champions. Decision: No / Now / Later, and Build / Buy / Partner.
03
Shaping Team Assignment
The Lead Engineer pulls together the people who will actually shape the solution, a lead architect, product, UX, and tech.
04
Shaping
The team translates the approved objective into a concrete solution and a ballpark estimate. Recommended two weeks, no more than is needed.
05
Shaping Review
A meeting with the shaping team, product champions and users. Three outcomes only: Approved, Approved with Feedback, or Rework.
06
Prioritisation
PM and tech leadership rank the approved solution against the current backlog. Use the scorecard. If it can't be defended, it doesn't ship.
07
Scheduling
Land the work on the roadmap with a tentative schedule. Tentative is the key word, everything before launch is an estimate.
08
Implementation
The dev team executes. The PM protects the team from scope creep and resolves blockers. Jira is the source of truth.
09
Launch
Documentation written, feedback channels open, support handed over, marketing briefed where needed. Launch is not a date. It's a checklist.
10
Validation
The stage most teams skip. Did it work? What did we learn? Without this step, the cycle never compounds.
Full reference table
For when you want the whole picture on one screen, hand this to a new team member on day one.
| Stage | Owner | Input | Output | Timeframe |
|---|---|---|---|---|
| 1. Opportunity Statement | Anyone | Written opportunity | Ongoing | |
| 2. Solution Approval | Product Manager | Solution Document, Objective | No / Now / Later · Build / Buy / Partner | 1 week from discovery |
| 3. Shaping Team Assignment | Lead Engineer | Approved Objective | Dev team assigned | 2 days |
| 4. Shaping | Shaping Team | Approved Objective | Solution · Ballpark Estimate | ~2 weeks |
| 5. Shaping Review | Shaping Team | Solution Document | Approved / Feedback / Rework | Meeting |
| 6. Prioritisation | Product Manager | Solution · Ballpark | Prioritisation | 1 week from shaping |
| 7. Scheduling | Product Manager | Ballpark · Prioritisation | Tentative schedule | 1 week from shaping |
| 8. Implementation | Development Team | Solution | Product Value | When scheduled |
| 9. Launch | Product Manager | Product Value | Docs · Feedback · Comms · Support · Marketing | When dev completes |
| 10. Validation | Product Manager | Product Value | Analysis · Learning | When released |
Three patterns to watch for
Pattern 1 · Skipped approval Work starts in Shaping without a real No / Now / Later decision. The team spends weeks shaping something that was never going to ship.
Pattern 2 · Infinite rework loop A shaping review produces Rework three or more times. The problem isn't the solution, it's that the opportunity was never clear. Go back to stage 1.
Pattern 3 · Missing validation Launch happens, the team moves on, no one ever asks if it worked. The cycle never learns. Put validation on the calendar before the launch.
What to read next
The Solution Document is the artefact that travels with an idea through stages 2 through 5. It's what the approval meeting reads, what shaping fills out, and what the review approves.