Milestone map
Milestone map
3 milestones
Build the Launch Plan
3 weeks
Produce a complete launch plan for a significant product or feature release. The plan must include: launch objectives (what success looks like in measurable terms), target audience definition, go-to-market strategy (channels, positioning, messaging), launch timeline with milestones and owners, pre-launch readiness checklist (engineering, legal, support, marketing gates), and a risk register with contingency plans for the top three launch risks. Review the plan with product, marketing, and engineering leadership before execution.
Proof required
Submit the launch plan document (min 1000 words covering all six elements), plus documentation of the review meeting with product, marketing, and engineering leadership showing any revisions requested and made.
What gets checked
- Launch objectives are measurable — specific KPIs with targets, not qualitative aspirations
- Pre-launch readiness checklist covers at least four functions — not just engineering
- Risk register identifies specific risks with specific contingencies — not generic 'monitor and respond'
Common mistakes
- Launch objectives are qualitative — 'increase awareness' without a measurement criterion
- Pre-launch checklist is engineering-only — support, legal, and marketing readiness are not gated
- Plan is built without cross-functional leadership review — critical gaps are discovered at launch
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to state the launch objectives in measurable terms — what numbers define success?
- Confirm the plan was reviewed by all three functions — product, marketing, and engineering
- Check the risk register has specific contingencies — ask the submitter what happens if the top risk materialises
Execute the Launch and Monitor in Real Time
1 week
Execute the product launch according to the plan. During launch week, run daily standups with all launch owners, monitor launch metrics in real time (document the metrics tracked and the monitoring setup), activate at least one contingency plan if any risk materialises, and run a 48-hour post-launch incident review if any significant issue is encountered. Document all decisions made during the launch window and their rationale.
Proof required
Submit launch week daily standup notes (all meeting records), metrics monitoring log showing what was tracked and results, documentation of any contingency activation or incident review, and a launch decision log covering significant decisions made during the launch window.
What gets checked
- Daily standup notes exist for every launch day — not just a summary at the end
- Metrics monitoring log shows specific numbers, not just 'we watched the dashboard'
- Decision log covers significant decisions with their rationale — not only outcomes
Common mistakes
- Launch is executed but not monitored in real time — issues are discovered after the window closes
- Daily standups are run but not documented — decisions and blockers are not tracked
- Contingency plans are written but not activated when risks materialise — team defaults to ad-hoc response
Resources
Foundationstart here
What a verifier looks for
- Ask the submitter to describe one decision made during the launch window — what was the situation and what was decided?
- Confirm daily standup notes exist for every day of the launch window
- Check the metrics monitoring log shows actual numbers — not just a description of what was tracked
Run the Launch Retrospective and Measure Against Objectives
2 weeks
Within two weeks of launch, run a cross-functional launch retrospective and measure results against the launch objectives. The retrospective must cover: what the metrics show versus targets (with data), what went well in execution, what failed or nearly failed, and three specific changes to the launch process for next time. Present the retrospective to the product and marketing leadership team and document their response.
Proof required
Submit the launch results report (objectives versus actuals with data), cross-functional retrospective notes (covering all four required sections), and notes from the leadership presentation showing their response and any follow-up actions.
What gets checked
- Objectives versus actuals are compared with actual numbers — not qualitative assessments
- Retrospective covers all four sections — results, what worked, what failed, and three process changes
- Leadership presentation response is documented — their assessment of the launch and follow-up actions
Common mistakes
- Retrospective is run without metrics — what worked is assessed qualitatively without data
- Retrospective only covers what went well — failures and near-failures are not addressed
- Three process changes are written but not reviewed by leadership — they are never implemented
Resources
Foundationstart here
What a verifier looks for
- Ask the submitter to state two launch objectives and the actual numbers achieved
- Confirm the retrospective involved cross-functional participants — not just the product team
- Check that three specific process changes are named — not 'improve communication' but what specifically changes