The twelve stages
For every stage: its purpose, the core question it answers, what to document, a common mistake to avoid, an illustrative example, the output of the stage, and what must be true before moving forward.
01
Customer Segments
Force clarity about who the product should create the most value for, before any solution is discussed.
Core question: Who are we trying to create the most value for?
What to document - Core customer — the primary focus of the product
- Secondary customer — important but not dominant
- Population / indirect beneficiary — may benefit without dedicated design effort
Common mistake Designing for 'everyone' so that the product ends up weak for everyone, or letting the loudest secondary stakeholder set priority over the core customer.
Example For an AI meeting assistant, the core customer is busy account managers, not sales leadership or IT — even though both groups will also use the tool.
02
Customer Needs, Pains & Outcomes
Move from a vague complaint to a specific, evidenced problem and a clearly stated desired outcome.
Core question: What problem matters most, and what change does the customer actually want?
What to document - Problem statement and why it matters
- Problem strength: frequency, severity, urgency, cost of inaction, willingness to change
- The Outcome Chain: Immediate Outcome → Behavior Change → User Success → Long-Term Impact
Common mistake Treating a complaint as automatically high priority, or jumping straight from a pain point to a long-term impact claim without describing the behavior change in between.
Example The problem isn't 'meeting notes are messy' — it's 'important follow-up commitments from customer meetings are being missed,' which is frequent, costly, and painful enough to justify investment.
03
Assumptions & Evidence
Separate what the team actually knows from what it is currently guessing.
Core question: What do we know, what are we assuming, and what is the riskiest assumption?
What to document - Known facts — supported by evidence
- Assumptions — believed likely but not yet validated
- Hypotheses — testable statements
- Unknowns — important information the team doesn't have
- For each key assumption: confidence, evidence source, validation action, consequence if wrong
Common mistake Writing an assumption into a strategy document and then treating it as settled fact simply because it is written down.
Example 'Account managers will trust AI-suggested follow-ups' is an assumption, not a fact, until it has been tested with real users doing real follow-ups.
04
Minimum Viable Output
Identify the smallest focused output capable of creating or testing the priority outcome — not a miniature version of the eventual product.
Core question: What is the smallest useful output capable of producing or testing the desired outcome?
What to document - Must Have Now — essential to create or test the outcome
- Can Wait Until Later — useful, not needed for the first evidence cycle
- Will Not Build Now — deliberately excluded to protect focus
- Key Dependencies — people, data, systems, approvals, partners, content
Common mistake Confusing 'minimum viable output' with 'cheapest possible version of the full product,' which usually reintroduces most of the original scope through the back door.
Example Instead of a full AI meeting assistant, the minimum viable output is a short list of suggested follow-up actions generated automatically after each meeting.
05
Measurement & Guardrails
Define how the team will know whether the outcome actually happened, and what damage is unacceptable even if it does.
Core question: What metric proves the outcome occurred, and what must not get worse while it does?
What to document - Outcome, adoption, engagement, efficiency, and quality metrics
- One Primary Outcome Metric
- Guardrail metrics: complaints, safety, cost, error rate, privacy, exclusion, support burden
- For each metric: baseline, target, data source, review period, owner
Common mistake Measuring only activity (logins, downloads, releases shipped) instead of the customer change the product was built to create.
Example Primary outcome metric: percentage of important follow-up actions completed within 24 hours. Guardrail: incorrect AI suggestions must stay below an acceptable threshold.
06
Experiment Planning
Design the smallest reliable test for the riskiest assumption before committing further investment.
Core question: What is the smallest test that would meaningfully change our confidence?
What to document - Hypothesis: 'We believe [customer] will achieve [outcome] by using [solution]. We will consider this supported when [evidence] reaches [threshold] within [period].'
- Riskiest assumption, target participants, method, procedure, timeline
- Data to collect, pass threshold, fail threshold, decision rule
Common mistake Running an experiment that produces interesting data but was never designed to end in a decision.
Example Pilot the follow-up suggestion feature with 10 account managers for 3 weeks; consider it supported if 24-hour follow-up completion improves meaningfully without excessive correction burden.
07
Review, Learn & Iterate
Turn experiment results into an explicit decision rather than simply a report.
Core question: What did we learn, and what should we do next?
What to document - What happened vs. what was expected
- Which assumptions were confirmed or rejected
- What remains uncertain
- Decision: Continue, Improve, Pivot, Pause, or Stop
Common mistake Reviewing results without updating the underlying assumption register, so the same untested belief resurfaces in the next planning cycle.
Example Follow-up completion improved from 41% to 68% with a low correction rate — continue, and begin scoping the next minimum output increment.
08
Product Logic & Iteration Loop
Compress the full chain of reasoning into one sentence a stakeholder can understand in seconds.
Core question: Can we state, in one sentence, who this is for, what we're building, and why?
What to document - Product logic sentence: 'For [core customer], this [minimum output] will address [priority problem] and help achieve [desired outcome], measured by [evidence].'
- The Learn → Decide → Change → Retest loop as it applies to this product
Common mistake Letting the product logic drift into vague language ('improve the experience') that no longer names a customer, a problem, or a measurable outcome.
Example 'For busy account managers, this automated follow-up suggestion list will address missed commitments and help achieve on-time follow-up, measured by 24-hour completion rate.'
09
Implementation & Action Plan
Translate product logic into accountable, trackable action rather than intention.
Core question: What has to happen, by whom, and how will we know it's done?
What to document - Action / deliverable
- Outcome supported
- Accountable owner, start date, due date
- Dependency and completion evidence
Common mistake Building a task list disconnected from any outcome, so activity continues even after it stops mattering.
Example Ship the follow-up suggestion feature to the pilot group by a fixed date, owned by the engineering lead, with completion evidence defined as a working feature in production for all 10 pilot accounts.
10
Product Readiness & Final Decision
Check readiness honestly before committing to a major new stage of investment.
Core question: Is there sufficient evidence and clarity to continue investing?
What to document - Customer clarity, problem validation, outcome measurability
- Assumption evidence, output focus, metrics, guardrails, risks, ownership
- Readiness decision: Ready, Ready with conditions, or Not ready
Common mistake Treating 'we shipped something' as equivalent to 'we are ready to scale it.'
Example Ready with conditions: pilot results are strong, but the correction workflow needs one more iteration before wider rollout.
11
Scaling & Sustainability
Confirm the customer outcome is repeatable before treating scale as the obvious next step.
Core question: Is the value repeatable, and can the organization sustain it at scale?
What to document - Repeatable customer outcome and current capacity
- Operational bottlenecks, quality consistency, process standardization
- Funding/revenue, people and skills, technology, data, infrastructure, partnerships, compliance, scaling risks
Common mistake Scaling output (more users, more markets, more automation) before confirming the outcome holds up outside the pilot group.
Example Before rolling out company-wide, confirm the follow-up completion improvement holds across account managers with different meeting volumes and CRM setups.
12
Product Lifecycle & Exit Strategy
Plan for renewal, transition, or retirement as a deliberate part of product strategy, not an afterthought.
Core question: What is this product's current lifecycle stage, and what would responsible retirement require?
What to document - Lifecycle stage: Launch, Growth, Maturity, Decline, Transition
- Current customer value, operating cost, reliability, support burden, relevance
- If exiting: customer transition, communication, alternatives, migration, data handling, contracts, knowledge transfer
Common mistake Letting a product continue by default long after its customer value and its operating cost have crossed, with no retirement plan in place.
Example A legacy manual follow-up tracker is retired only after account managers are fully transitioned to the automated workflow and historical data has been exported.