Milestone map
Milestone map
3 milestones
Run a Discovery and Prioritisation Process
4 weeks
Conduct a structured discovery process to build the evidence base for a product roadmap. This must include: at least five customer interviews (30+ minutes each) with documented pain points and quotes, competitive analysis of at least three alternatives, a review of usage data or support ticket patterns to surface the highest-frequency problems, and a stakeholder alignment session with product, engineering, and business leadership. Produce a discovery synthesis document.
Proof required
Submit the discovery synthesis document (min 900 words) including customer interview summaries (noting at least 5 named participants), competitive analysis of at least 3 alternatives, and documented outcomes of the stakeholder alignment session.
What gets checked
- Customer interview summaries include verbatim quotes — not just the submitter's interpretations
- Competitive analysis names at least three alternatives with specific differentiators
- Stakeholder alignment session is documented — who attended, what was agreed, what was unresolved
Common mistakes
- Discovery is skipped — roadmap is built from stakeholder requests and gut feel
- Customer interviews are too few or too short to surface genuine pain patterns
- Stakeholder alignment is not run — product, engineering, and business have misaligned assumptions going into roadmap planning
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to share the most surprising customer insight from the interviews — what would they have guessed wrong without talking to customers?
- Verify at least five customers were interviewed and that notes include verbatim quotes
- Confirm the stakeholder alignment session involved all three functions — product, engineering, and business
Build and Present the Roadmap
3 weeks
Produce a product roadmap covering at least two quarters: a near-term committed lane (this quarter, specific deliverables), a medium-term direction lane (next quarter, problem/opportunity areas), and a long-term vision lane (6-12 months, strategic bets). The roadmap must be grounded in the discovery synthesis and include explicit prioritisation criteria (e.g. RICE, opportunity scoring, or a documented custom framework). Present the roadmap to engineering leadership, business leadership, and at least one customer (or customer advisory group), and document the feedback and revisions.
Proof required
Submit the roadmap document or deck (covering all three lanes), the prioritisation criteria document, and documented feedback from engineering, business, and at least one customer, plus the revisions made based on feedback.
What gets checked
- All three lanes are present and clearly distinguished in the roadmap
- Prioritisation criteria are documented and applied — the roadmap is not a list of everything
- Customer feedback is documented — not just internal stakeholder feedback
Common mistakes
- Roadmap is a feature list — no near/medium/long distinction, no prioritisation criteria
- Roadmap is built without grounding in the discovery synthesis — it reflects stakeholder preferences
- Customer feedback is not sought — the roadmap is validated only internally
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter why a specific item is in the near-term lane and not the medium-term — the prioritisation criteria should answer this
- Confirm at least one customer (not just internal stakeholders) provided documented feedback
- Check that the revisions are documented — what changed from the initial version and why?
Run a Roadmap Review After First Quarter
2 weeks
After completing the first quarter of the roadmap, run a structured retrospective covering: what shipped versus what was planned (and why any gaps exist), whether the discovery-grounded bets were validated or invalidated by user behaviour, and how the medium-term lane should be updated based on what was learned. Update the roadmap for the next quarter and run a stakeholder alignment session to confirm the updates.
Proof required
Submit the quarterly retrospective document (min 600 words covering shipped vs planned, bet validation, and lane updates), the updated roadmap, and notes from the stakeholder alignment session confirming the updates. A product or business leader must sign off on the updated roadmap.
What gets checked
- Retrospective covers all three dimensions — shipped vs planned, bet validation, lane updates
- At least one original bet is explicitly validated or invalidated by evidence — not assumed correct
- Updated roadmap reflects the retrospective findings — it has changed meaningfully
Common mistakes
- Retrospective only covers what shipped — misses the learning about whether the bets were right
- Roadmap is updated without stakeholder alignment — updates introduce new misalignment
- Retrospective is held but findings are not incorporated into the roadmap
Resources
Foundationstart here
What a verifier looks for
- Ask the submitter which bet from the original roadmap was most definitively validated or invalidated — what was the evidence?
- Confirm the stakeholder alignment session ran before the updated roadmap was communicated broadly
- Check the retrospective covers all three dimensions — many stop at shipped vs planned
Part of