A guide for the whole journey
Process model matrix.
Eight phases. One central hypothesis. Follow how an idea is framed, challenged, built, and measured, with the questions, people, and artifacts that help at every step.
This is a learning loop: evidence can send you back to an earlier phase. When a timebox ends, make the next decision with the evidence you have.
Scroll sideways to explore all eight phases. Select a phase for details, or an artifact or role for an explanation. Highlighted roles lead the phase.
| EmbarkDecide whether and what to build | BuildSpecify, build, and accept | LandDeliver and measure | ||||||
|---|---|---|---|---|---|---|---|---|
| Phase | ||||||||
| Core question | Is the problem worth solving, and what do we believe? | What is the case against building it? | Which solution, and how small can the first release be? | Can Build start without unresolved questions? | Is every increment testable? | Does it work, hold up, and stay secure? | Does the product reach its users? | Did we solve the problem? |
| Hypothesis | Formulate Write the hypothesis before building: We believe … for … will lead to … We will know we are right when … Add the assumptions, ranked by risk. | Try to falsify Give every phase 0 assumption an experiment: an interview, data analysis, landing page, or presale. Mark each result confirmed, rejected, or unclear. Rewrite or discard the hypothesis accordingly. | Refine Turn the validated problem hypothesis into a solution hypothesis. What is the smallest slice that can test it? Use the clickable prototype to challenge the solution, beyond checking usability alone. | Make measurable Translate the phase 0 success signal into specific metrics and events in the test strategy and user stories. What is not measured cannot later be validated. | Instrument Build tracking, events, and dashboards alongside the product, as dedicated stories rather than an afterthought. | Check Usability testing on the real product provides the first qualitative signal for the solution hypothesis. Also verify that instrumentation produces correct data. | Start measuring Launch begins the measurement period. Record the baseline and agree on the period and thresholds before reviewing results. | Validate Compare the central hypothesis with the phase 0 success signal: confirmed, partially confirmed, or rejected. The result and new hypotheses begin the next cycle. |
| Goal | Describe the problem and formulate the hypothesis behind the project. | Confirm or overturn the assumptions from phase 0. | Move from an understood problem to a chosen solution, before detailed pixels or code. | Describe the work clearly enough for Build to begin. | Deliver incrementally, with every increment testable. | Demonstrate that the product works, withstands load, and is secure. | Get the product into users’ hands, beyond simply deploying it. | Answer the question from phase 0 with real data. |
| Timebox | 1 week One week, two at most. Taking longer can be a sign that the team is justifying a preferred solution rather than defining a problem. | 2–4 weeks Two weeks for an existing product with analytics; up to four for a new product. Then decide using the evidence available. | 2 weeks Two weeks including a clickable prototype and first usability test. The domain model may evolve afterwards; the phase must stay timeboxed. | 2–3 weeks Two to three weeks for the first release slice. Specify later stories during Build, staying at least one sprint ahead. | 2-week sprints Two-week sprints; an MVP typically takes three to six. Estimate the number in phase 3 and revisit it at each sprint’s end. | 1–2 weeks One to two weeks for acceptance, load, and security testing. Regression and unit tests already run during Build and are not included in this allowance. | 1 week One week from acceptance to launch if training and communication were prepared during Build. Otherwise, allow two. | 4–8 weeks of data Agree in advance on four to eight weeks of measurement after launch, then one week of analysis and reflection. Extending the period because results are disappointing undermines the original hypothesis. |
| Roles | ||||||||
| Decision maker | Sponsor Decides Gate A on the Product Owner’s recommendation. Finance confirms the budget envelope. | Sponsor Decides Gate B. UX Research and the Product Owner recommend jointly. The Tech Lead can veto technical infeasibility. | Product Owner Decides MVP scope. The Sponsor approves the solution design and scope. The Tech Lead decides build vs. buy. | Product Owner and Tech Lead Jointly confirm the Definition of Ready. QA confirms the test strategy. | Product Owner Accepts each story. The Tech Lead owns the Definition of Done and technical decisions within the ADRs. | Sponsor Signs acceptance on QA’s recommendation. Security can veto critical findings. The Product Owner decides which remaining defects are acceptable. | Sponsor Approves launch. The Tech Lead gives technical approval and Support confirms readiness. Any of them can stop the launch. | Sponsor Decides whether to continue, improve, pivot, or stop. The Product Owner recommends based on the evidence. |
| Artifacts | ||||||||
| Exit | Gate A Is the problem large enough? Are budget and benefits plausible? If yes, hold the kickoff. If no, end the project here. That is a successful decision, too. | Gate B Go, no-go, or return to phase 0 if the problem differs from the original assumption. Always ask: what argues against building, and why does that reason not prevail? | Acceptance Stakeholders have approved the solution and scope. The clickable prototype has passed the first usability test or been revised based on its findings. | Definition of Ready The backlog is estimated and each story meets the Definition of Ready. The team can start its first sprint without unresolved foundational questions. | Definition of Done Every story meets the Definition of Done. The release is feature-complete and ready for acceptance. | Acceptance No open blockers. The acceptance report is signed. Remaining known defects are documented and accepted. | Live The product is in production, users are trained, and support is running. Instrumentation for phase 7 is active. | Back to the start The new hypotheses become the next project charter. The model is a cycle, not a waterfall. |