The one document a team or facilitator follows through an engagement. It walks the five phases in order — Strategy → Discovery → Shape → Build → Scale — and for each one gives you five things: why the phase exists, what you walk in with, the step-by-step (the activities and methods, each with what it produces), what you walk out with, and the Stake (the gate decision that ends the phase).

A single worked example runs through the entire guide: one HR team takes one problem from a cascaded company strategy all the way to a scaled solution, shown step by step. Read the steps, then read how the example team actually did that step — the point is to see exactly what each step produces before you try it on your own work. Full method how-tos live in the Methods Handbook; term definitions live in the Glossary. This guide is the sequence that ties them together.

The worked example we'll follow

Watch for the ▶ Worked example blocks under each step — that's the case in motion.

How the process works — read first

Five phases sit around one hub. Strategy is the hub: it holds the why, the North Star, and the kill criteria, and it never really "finishes." The four phases orbit it in order — Discovery → Shape → Build → Scale — and each launches from Strategy and reports back to it.

It moves in loops, not a line. You go out from Strategy to one phase, do the work, then return through a gate to re-align and update Strategy with what you learned — then aim the next loop better. Each loop removes a chunk of risk; you're not trying to know the whole answer on day one. After Scale you return to Strategy and the next problem re-enters Discovery. "Done" isn't a phase.

It's a thinking aid, not a rigid sequence. You can be in Build on one problem and Discovery on another; Discovery never fully stops.

The Stake — how every gate works

Each phase ends at an exit gate, and a gate is not a checkbox — it's a decision (a "Stake"). Every gate has the same shape.

Three outcomes, never just "done": Proceed → next phase · Iterate → stay, the evidence isn't there yet · Pivot / Kill → return to Strategy (stopping on a pre-set rule is a win).

Four checks: Evidence sufficient? (enough, and good enough, to decide) · Commitment secured? (does the sponsor back the next phase's resources) · Risk acceptable? (are the remaining unknowns manageable next phase) · Kill criteria triggered? (check the "Stop if…" conditions set at Strategy).

Two rules keep it honest. Judge the quality of evidence, not just its presence — rate it on source (opinion → observation → data → experiment), strength, recency, relevance, sufficiency; a confident opinion is not evidence. And kill criteria are set in advance, at Strategy. Scale the rigor to the stakes — a quick chat for low-risk work, scored evidence for big bets, a formal sign-off for compliance-bound work. Every gate ends by returning to Strategy and updating the roadmap.

Running through every phase

These conditions sit under the whole process; if a phase breaks one, the checklist is theatre: trust (no micromanagement), space for failure (a killed bet is a lesson), intellectual honesty (report what the data says), collaboration (not hand-offs), tolerance for iteration (not perfectionism).

How to read this guide — canon, options, and specs

Everything in the numbered steps of each phase is the canon — the House of Product process and its core methods. It's the spine; follow it as written. Under each phase you'll then find a Going deeper layer with three things:

1. Fuller explanations of each canonical method — written for People & Culture, but at a product-practitioner's depth, so you understand not just what to do but why it works and where it breaks.
2. A diagram build spec for each method — an ASCII sketch plus a description, ready to hand to Claude Code to render as a polished visual. These are specs, not finished images.
3. Clearly tagged extras drawn from canonical product sources:

• OPTIONAL — a method worth adding when the context calls for more rigor (a bigger bet, higher scrutiny, a compliance-bound rollout). Skip it for small, low-risk work.
• ALTERNATIVE — a different, usually more formal instrument for a canonical step (e.g., a scored prioritization in place of a 2×2). Use it instead of the canonical tool when the situation warrants; otherwise the canonical tool is enough.

Nothing in the Going-deeper layer replaces the canon — it equips it. When in doubt, run the canon.

Phase 1 — Strategy

Know what we're aiming at before we pick problems, so effort compounds instead of scattering.

Why this phase exists. Without a shared direction, HR runs on whoever shouted loudest this quarter. Strategy lets the team say no to good ideas to protect the great ones — and it's where People & Culture stops being a silo and lines up with the business as one team.

You walk in with. A reason to set direction (a new cycle, a company strategy to align to) and a willingness to choose.

Step by step

Step 1 — Cascade the company strategy into a P&C strategy. Cascading does not mean copying the company goal onto an HR slide. It means asking: given what the business is trying to do, what has to be true about our people for it to work — and which of those is most at risk? That at-risk thing becomes your focus.

1. Write the company strategy in one sentence.
2. List what that strategy demands of the workforce (skills, headcount, capabilities, retention).
3. Find the binding constraint — the people-side thing most likely to break the company plan if ignored.
4. State your P&C strategy as a response to that constraint, in one sentence that ladders visibly up to the company goal.

Step 2 — Define the North Star. Pick the single metric that represents the core value you deliver against that strategy. It should be an outcome (a change in the world), nameable by everyone, and hard to game.

Step 3 — Place the year's bets. You can't fix everything; choose the few things you'll back. (Full method: Placing Bets in the handbook.) For each bet write the belief, the bet, what success looks like, the budget, and the stop line.

Step 4 — Build the 6-month roadmap. Turn the bets into themes and outcomes — problems to solve, not pre-decided features — sequenced Now / Next / Later, visible to everyone.

Step 5 — Stress-test viability. Check leadership actually sees the return before you spend a cycle.

You walk out with. A named North Star, the year's bets, an outcome-framed roadmap, the specific problem to take into Discovery ("new hires take too long to become productive"), a sponsor, and the kill criteria for this cycle.

The Stake — ready to start? (the kickoff gate). Do we have enough alignment and a clear problem to enter Discovery?

• Evidence: Can everyone state the North Star and top bets unprompted? Is the problem named — not a solution handed down?
• Commitment: Sponsor and real resource for a Discovery effort?
• Risk: Fuzzy enough to need discovery — or a known task that's just a project?
• Kill criteria: Have we written the "Stop if…" conditions?
• Decide: Proceed → Discovery · Iterate → tighten the strategy first · Pivot/Kill → not worth a cycle.

Going deeper — Strategy

The canon above is the spine. Below is the depth, the diagram specs, and the clearly-tagged options.

Stakeholder mapping has two altitudes — this is the first

The canon maps stakeholders in Discovery, as concentric circles around a single problem (Phase 2, Step 1). That's the problem altitude. But there's an earlier, higher-altitude map worth doing here in Strategy, and it answers a different question.

• Strategy altitude (here): Who can fund, block, or redirect this bet — and whose own strategy does it touch? The unit is the bet/portfolio. You're managing power and politics.
• Problem altitude (Discovery): Who needs to be in the room, and how often, to solve this specific problem? The unit is one problem. You're managing involvement and collaboration.

Same skill, two heights. Teams that only do the Discovery circles walk into Strategy without a sponsor and get their bet killed by someone they never mapped; teams that only do the strategy map fill a discovery room with powerful people who have nothing to contribute to the actual problem. Do both.

How to run the strategy-altitude map.

1. List everyone with a stake in the bet: the sponsor, budget holders (Finance), decision-makers (the exec or steering group), influencers (senior leaders, and for HR specifically: Legal, Works Council / employee reps, IT/HRIS), and the management chain of the people the bet will affect.
2. Score each on power (formal authority + control of resources) and interest (how much they care about this outcome).
3. Plot them on a power/interest grid and set an engagement cadence per quadrant (below).
4. Add a sponsor map: name the one executive sponsor, then the coalition around them, annotating each with their real motivation — the stated reason usually sits on top of an unstated incentive.
5. Add a RACI for the specific decisions in this cycle (who is Responsible, Accountable, Consulted, Informed) so decision rights are explicit, not assumed.
6. Re-run it at every gate — the map is alive, not a one-off.

This is the canonical Power/Interest grid (often called Mendelow's matrix). The four quadrants tell you how to spend your attention:

Cascade — a fuller frame

The canon's four cascade steps are the essential move. If you want a more complete scaffold for a large or contested strategy, the strategy stack (Perri) makes the ladder explicit across four levels: Vision (where the company is going, 5–10 yrs) → Strategic Intent (the one or two business challenges in the way right now) → Initiatives (the problems a team will solve to meet that intent) → Options (the specific experiments that might solve an initiative). Your P&C strategy is an initiative serving the company's strategic intent; the bets you place are options. Best practice: review each level on its own cadence (company quarterly, initiatives quarterly-staggered, options every cycle). Pitfall: cascading by copying the company goal down a level instead of translating it into the people-side constraint — the canon's Step 1 exists precisely to stop that.

North Star — a fuller frame

A North Star (the term and the framework come from Amplitude and John Cutler) is the one metric that captures the value you create, decomposed into a few inputs the team can actually move week to week. Three properties separate a real North Star from a vanity number:

• It's a leading indicator of value, not a lagging financial. Attrition or cost-per-hire are lagging — they tell you what already happened. Time-to-productivity is leading — move it and the financials follow.
• It sits one level out of reach. You can't push it directly; it's a composite that several teams move together. If you can move it with one lever, it's a KPI, not a North Star.
• It's hard to game. "Onboarding sessions delivered" is gameable (run more sessions, learn nothing). "Days to first independent contribution" is not.

Underneath it sit 3–5 inputs — the leading behaviours that produce it — each defined precisely: the [count / %] of [who] who [action] within [time window].

Placing bets — a fuller frame, with two optional tools

The canon's Placing Bets method (belief / bet / success / budget / stop line) is the core, and the full how-to is in the handbook. Two optional tools add rigor when the stakes justify it:

• OPTIONALDIBB — Data → Insight → Belief → Bet (Spotify). Use when you need to show the evidence chain behind a bet to a sceptical sponsor. It forces you to name the data you saw, the insight you drew, the belief that follows, and only then the bet you're making — so a bet can be challenged at any link. It pairs cleanly with the canon: the "belief" and "bet" are the same words the canon already uses.
• OPTIONALThree Horizons portfolio balance (McKinsey). Use when you're placing several bets at once and want to avoid a portfolio that's all safe, near-term work. Sort bets into Horizon 1 (optimise what exists), Horizon 2 (build an emerging capability), Horizon 3 (seed a future option). A common split is roughly 70/20/10. Caveat (Steve Blank): horizon means ambition, not time — a Horizon-3 idea can ship fast; don't treat H3 as "the someday pile."

Roadmap — a fuller frame

The canon builds a Now / Next / Later roadmap of outcomes. That format (Bastow / ProdPad) is deliberately not a timeline: Now = validated work in motion (dates visible), Next = validated problems queued (no locked dates), Later = problem areas still needing discovery (outcomes only). It encodes the "cone of uncertainty" — the further out, the less you pretend to know. The cards are problems and outcomes, never features, which is why the roadmap survives when Discovery reframes a problem.

Phase 2 — Discovery

Understand the real problem before committing budget. "Discovery prevents HR from solving the wrong problem beautifully."

Why this phase exists. HR's classic failure is designing for people instead of with them. Discovery moves the learning to the cheap end — before you've spent — by replacing assumptions with evidence.

You walk in with. A named problem (not a solution), a sponsor, and the kill criteria from Strategy.

Step by step

Step 1 — Set up the team and map stakeholders. Name a problem owner, a user advocate, a tech/delivery partner, and the sponsor. Then sort everyone into the circles — core / contributing / consulted / informed / users — so you involve each correctly. (Method: Stakeholder Mapping.) Kick off from real signals, not just execs: user feedback, an honest look at your own current work, data anomalies.

Step 2 — Map and rank assumptions. List every belief the idea rests on (user / problem / solution / viability) and rank by impact × uncertainty; the top-left ones get tested first. (Method: Assumption Mapping.)

Step 3 — Run dual discovery + research, and define the success measure. Research both sides in parallel — B2C needs/friction and B2B constraints — via interviews, observation, surveys, and data, watching the say-vs-do gap. Then define how you'll measure "solved," in behaviour, before designing. (Methods: Dual Discovery; research.)

Step 4 — Explore the problem with 5W1H. Answer who has it, where/when it occurs, why (root cause, not symptom — push the "why" several times), and how you'll know it's solved. (Method: 5W1H.) If you can't answer all four, you're not ready to design.

Step 5 — Build personas + JTBD (both layers). Segment users into the few distinct types whose needs differ, build a research-grounded persona for each, and write a job-to-be-done line (functional / emotional / social). Keep the B2C and B2B layers. (Method: Personas + JTBD.)

Step 6 — Map the journey. Lay out the experience step by step with actions, touchpoints, pain points, and emotion; the emotional dips are your breakpoints. (Method: Journey Mapping.)

Step 7 — Frame the problem. Turn the signals into one sentence the whole team agrees on, separating symptom from cause and bounding the scope. (Method: Problem Framing.)

You walk out with. A framed problem statement, both persona layers + JTBD, a journey map, a risk-ranked assumption map, primary research insights from both sides, and the success metric with a baseline.

The Stake 1 — is this worth shaping? Do we understand the problem well enough to frame it and pick a direction?

• Evidence: Assumptions risk-ranked? Primary (not desk) research? Friction clear? Outcome metric defined?
• Commitment: Team/sponsor agree it's worth continued investment, with resources for Shape?
• Risk: Are the remaining unknowns something Shape can resolve?
• Kill criteria: Any showstopper? Check the "Stop if…" conditions.
• Decide: Proceed → Shape · Iterate → more Discovery · Pivot/Kill → Strategy (a win).

Going deeper — Discovery

The circles are the *second* altitude of stakeholder mapping

In Strategy you mapped who can fund or block the bet (power/interest). Here, the canon's circles map something different: who needs to be in the room for this specific problem, and how often. Don't sort by power — sort by involvement intensity:

• Core — the trio who live this problem daily (problem owner + user advocate + delivery partner); in every activity.
• Contributing — people whose help you need at synthesis and ideation, but it isn't their main job (a data analyst, a subject expert, an IT engineer).
• Consulted — domain gatekeepers engaged at named moments, not standing meetings (Legal, Accessibility, Works Council).
• Informed — people who need to know but don't decide (leadership, adjacent teams); they get showcases.
• Users — the people whose work the solution will change; the outermost ring (and the ones you actually interview).

The trap is putting a powerful stakeholder in the Core ring because they're senior, when they have nothing to add to the problem. Power belongs on the Strategy map; the room belongs to whoever moves the problem.

5W1H — a fuller frame

The value of 5W1H is that it forces root cause before design. The "why" is where it earns its keep: push it ~5 times (the "five whys") until you hit something you can actually change. Stop at the first answer and you'll design for a symptom. The "how will we know" is your success measure in disguise — if you can't state it in observable behaviour, you don't yet understand the problem.

Personas + JTBD — a fuller frame, with one alternative

Two distinctions matter. First, a segment is not a persona. A segment is a slice of people by attribute (role, tenure, location); a persona is a behavioural archetype built from research. The test for whether a persona deserves to exist is distinctness: would you make a different decision for it than for your other personas? If not, collapse it. Second, Jobs-to-Be-Done is a third lens on top of personas — the idea (from Christensen) that people "hire" a solution to make progress, and that progress has three dimensions:

• Functional — the practical task ("get my first task done").
• Emotional — how they want to feel ("confident, not lost").
• Social — how they want to be seen ("a strong hire, not the person who keeps asking dumb questions").

Miss the emotional and social jobs and you build something that works on paper but no one adopts. The JTBD line also bridges to engineering: it rewrites cleanly as a user story — "As a [persona], I want to [functional job], so that [emotional/social outcome]" — which is the shared language between People teams and the people who build the tooling.

• ALTERNATIVEThe switch interview (Moesta / "forces" school). Use instead of a generic interview when you're trying to understand why people adopt or abandon something. You reconstruct the story of a real switch: the push (what made the old way unbearable), the pull (what attracted them to the new), the anxiety (what worried them about switching), and the habit (the inertia holding them back). Push and pull drive change; anxiety and habit resist it. Interview recent switchers, not long-tenured users who've rationalised. A standing risk in all interviews is the say–do gap — people misreport their own behaviour — so triangulate stories with observation and data, and trust an A/B result over an interview quote when they disagree.

Journey mapping — a fuller frame

A journey map is a narrative of the experience across stages, with the emotional curve as its most useful row — the dips are your opportunities. Best practice: draw a rough map from each interview, then synthesise one canonical map, rather than inventing an idealised journey in a room. Walk it end-to-end during prototype reviews to catch assumptions at each step.

Assumption mapping — a fuller frame

The canon ranks assumptions by impact × uncertainty. The canonical instrument (Bland & Osterwalder) plots them on a 2×2 of importance × evidence, and gives the dangerous quadrant a name: leap-of-faith assumptions — high importance, low evidence. Those are what you test first, because they're the beliefs that, if wrong, sink everything, and you currently have nothing but hope behind them. Assumptions come in four flavours — desirability (do they want it?), feasibility (can we build it?), viability (does it work for the business / Legal / budget?), and adaptability (does it survive a changing environment?) — colour-code them so you can see if you've ignored a whole category.

[Optional] Opportunity Solution Tree — structure the whole discovery

Use when an outcome has many possible opportunities and solutions and you need to keep the team honest about how a solution connects to the goal. The Opportunity Solution Tree (Torres) is a living map: a single outcome at the root → opportunities (real unmet needs, taken only from actual interviews) → solutions (each must attach to an opportunity, or it's a distraction) → assumption tests under each solution. Its quiet power is reframing debate from "should we build X — yes or no?" into "which of these solutions best serves this opportunity?" — compare-and-contrast instead of up-or-down.

[Optional] Continuous discovery

Use when this is an ongoing product, not a one-off project. Rather than a single discovery push, the trio talks to users every week and updates the tree continuously (Torres). The hard part is recruiting; automate it (in-product prompts, a standing panel) so the cadence survives. For a one-time intervention the canon's focused discovery is enough; for a product you'll run for years, continuous discovery is what keeps it from drifting.

Phase 3 — Shape

Pick the bet — then build the smallest thing that proves it.

Why this phase exists. Not every validated problem deserves resources now. Shape is where you prioritize ruthlessly and de-risk cheaply — before the expensive build — so you commit to one defensible direction, not three half-bets.

You walk in with. A framed, researched problem, the success metric with a baseline, and a recommended direction from Discovery.

Step by step

Step 1 — Prioritize and pick one bet. Compare candidate directions with Impact/Effort, ICE, or an Opportunity-Solution Tree, and choose one you can defend ("this, not that"). (Methods: Prioritization, Opportunity-Solution Tree.)

Step 2 — Assess the four risks. Check Value (will they use it?), Usability (can they?), Feasibility (can we build it?), Viability (does it work for the business, incl. legal?), and name the biggest honestly. (Method: Four-Risk Assessment.)

Step 3 — Name the riskiest assumption and design its test. Write it as a falsifiable hypothesis and pick the cheapest test that could disprove it, with pass/fail set in advance. (Method: Experiments.)

Step 4 — Build to learn: run the smallest test. Use the lightest test that fits the risk — pretotype → prototype → POC → MVP, or a fake-door / A/B / concierge / Wizard-of-Oz. The aim is evidence, not a finished product. (Method: Experiments and its types.)

Step 5 — Test honestly with real users. Gather feedback looking for disconfirming evidence, not applause.

You walk out with. A validated problem, one selected solution + rationale, the four-risk assessment, evidence on the riskiest assumption, and updated kill criteria.

The Stake 2 — a prioritized solution worth building? Is the problem validated, and have we committed to one defensible direction?

• Evidence: Problem validated? Options assessed across value/usability/feasibility/viability? Did the test move the riskiest assumption from hope to evidence?
• Commitment: Aligned on ONE direction (not three half-bets)? Resources for Build?
• Risk: Remaining unknowns within Build's reach? Appetite realistic?
• Kill criteria: Any showstopper? "We like it" is not validation.
• Decide: Proceed → Build · Iterate → more Shape · Pivot/Kill → back to Strategy.

Going deeper — Shape

Prioritization — the canon tool and two more formal options

The canon uses Impact/Effort (and ICE, and the tree). That 2×2 is the right first cut: plot each option by impact and effort, do the quick wins (high impact / low effort) first, plan the big bets (high/high), defer the maybes (low/low), and drop the money pits (low impact / high effort).

• OPTIONALRICE (Intercom). Use when you must defend a ranking to stakeholders with a number. Score = (Reach × Impact × Confidence) ÷ Effort, where Reach = people affected in a time window, Impact is tiered (3 / 2 / 1 / 0.5 / 0.25), Confidence is a % (100 / 80 / 50), Effort is person-months. Caveat: the precision is partly illusory — Reach and Impact are estimates — so use RICE to structure the argument, not to end it. Best run after you've shortlisted, not on every raw idea.

• OPTIONALOpportunity scoring (Ulwick / ODI). Use when you have survey data on what users need. Score = Importance + max(Importance − Satisfaction, 0), on 0–10 scales. High importance + low satisfaction = underserved = where the opportunity is. It's the most data-hungry option; reserve it for big investments.

The four risks — a fuller frame

Cagan's four risks are the checklist that stops you de-risking the wrong thing. In order of how often teams get them wrong:

• Value risk — will they use/choose it? Usually the hardest and most-skipped risk. Most failed internal tools were usable, feasible, and viable — and simply unwanted.
• Usability risk — can they figure it out?
• Feasibility risk — can we build it with what we have, in time? The risk teams over-test, because engineers are comfortable here.
• Viability risk — does it work for the business? For HR this is where Legal, Works Council, data privacy, and budget live — and a viability "no" here is fatal no matter how loved the product is.

Inside the trio, ownership splits naturally: the product owner carries value + viability, the designer carries usability, the delivery partner carries feasibility — but the assessment is done together.

The build-to-learn ladder — a fuller frame

The canon lists the test types; here's the ladder by cost and fidelity, lowest first, with the rule: pick the cheapest rung that can falsify your riskiest assumption.

1. Pretotype (Savoia) — test demand before building anything. Fake-door (an ad/link/sign-up for a thing that doesn't exist yet, measuring clicks), Wizard-of-Oz / Mechanical Turk (a human does manually what software eventually will), Pinocchio (a non-working mock). Answers: do they even want it?
2. Prototype — paper → clickable → high-fidelity. Answers usability and desirability of a specific design.
3. Proof of concept (POC) — an engineering spike to answer one feasibility question; usually thrown away.
4. Concierge — deliver the real value fully manually, one person at a time (the canon's worked example uses this). Answers value + viability with real users and almost no build.
5. MVP (Ries) — the smallest real release that completes one Build-Measure-Learn loop. Not "version one with fewer features" — the smallest thing that tests the riskiest hypothesis.
6. A/B test — randomised variants, compared on one primary metric; needs volume.

Designing the experiment — a fuller frame

Whatever rung you pick, write it as an experiment before you run it (the Strategyzer experiment-card discipline): state the hypothesis (falsifiable), the metric, the pass/fail threshold set in advance, the cost/time, and what each result triggers (Proceed / Iterate / Pivot-Kill). Setting the threshold after you see the data is how teams talk themselves into a dead idea.

Phase 4 — Build

Build it properly — and keep measuring the outcome, not just the launch.

Why this phase exists. This is where most teams think the work is. In product thinking it's the back half — you only earn it once Discovery and Shape have done their job. The discipline: keep measuring outcomes (behaviour change), not just celebrate shipping.

You walk in with. A validated solution, one committed direction, Build resources, and the outcome metric (with a baseline) from Discovery.

Step by step

Step 1 — Run a Lean Inception to scope the MVP. A Lean Inception is a short, structured kickoff (often a few days) that gets the whole cross-functional team owning the same outcome and agreeing the smallest thing to build, before anyone builds. Steps: (1) align on the vision/North Star; (2) agree the users and the single outcome the MVP must move; (3) brainstorm the features/increments; (4) sequence them — what's in the first slice; (5) write down explicitly what is not in the MVP; (6) leave with a shared MVP scope and build sequence.

Step 2 — Build the validated version in small increments. Build what Shape validated — guard hard against scope creep (the portal and gamification stay out).

Step 3 — Instrument it. Instrumentation means deciding, before you build, exactly what you'll measure, and wiring the solution so the data is captured automatically as it runs — not reconstructed from memory afterwards. Without it you'll "launch" and never know if it worked. Steps:

1. Restate the outcome metric (lagging indicator) from Discovery — the thing that defines success.
2. Add leading indicators — earlier signals that predict the outcome, so you learn before the lagging metric confirms.
3. Define each metric precisely — what event starts and stops the clock, who's counted (the denominator), how often it's measured.
4. Choose the capture method — where each number comes from; automate it so it's collected as the process runs, not dug up later.
5. Set the baseline before launch — you can't show change without a "before."
6. Tie thresholds to the kill criteria — the leading-indicator level that means stop/pivot.
7. Stand up the readout before the cohort starts, so day-one data flows.

Step 4 — Release to a pilot cohort. Ship to a bounded, representative group first — big enough to learn from, small enough to support and reverse — including the hard case. Set a time window; brief the cohort and their managers; keep a manual support line open.

Step 5 — Run evaluative research during the build. Usability tests, pilot feedback, and adoption tracking while it runs — not only after. (Method: evaluative research.)

You walk out with. The validated solution running with a real pilot cohort, outcome + adoption signals against the baseline, and an honest rollout-readiness read — including where it underperformed.

The Stake 3 — is the solution validated? Has it been tested with real users, and do the signals justify scaling?

• Evidence: Tested with real users (not colleagues)? Did it move the outcome metric for the cohort? Adoption/behaviour signals present?
• Commitment: Resources for org-wide rollout? Owners lined up?
• Risk: Remaining product/operational risks manageable? Foundation sound to scale?
• Kill criteria: Do the signals meet the minimum threshold set at Strategy?
• Decide: Proceed → Scale · Iterate → more build/test · Pivot/Kill → back to Strategy (don't scale on sunk cost).

Going deeper — Build

Lean Inception — a fuller frame

The canon runs a Lean Inception to scope the MVP. The full method (Caroli) is a structured week that ends with two artifacts — an MVP Canvas and a Sequencer. The canonical agenda:

• Day 1 — kickoff (sponsor sets context); write the product vision; "Is / Is-not / Does / Does-not"; product goals.
• Day 2 — describe the personas; map the user journeys.
• Day 3 — brainstorm features; review each through business, UX, and technical lenses.
• Day 4 — sequence the features into MVP → increment 2 → increment 3.
• Day 5 — build the MVP Canvas; showcase to stakeholders.

Run it with active members (business + UX + delivery, all week) and stakeholders (kickoff and showcase only). It compresses to 2–3 days for smaller efforts; below two days you lose the sequencing, which is the part that stops you shipping one giant blob.

Instrumentation — a fuller frame

The canon's seven steps are the method; three product habits make them robust:

• Leading vs lagging. A lagging metric reports the past (6-month attrition); a leading metric predicts the future and can move this cycle (day-7 "I know what to do" pulse). Instrument both, but steer by the leading ones.
• Name events Object–Action ("OnboardingPlan–Completed", "Buddy–Paired"), version the schema, and tag every release so you can compare cohorts. Sloppy event names make dashboards lie within a quarter.
• Three tiers of metric: a primary metric (the outcome), guardrail metrics you must not push backwards (e.g., manager workload), and counter-metrics that catch gaming (e.g., "buddies assigned" rising while "buddy interactions" flatlines). Always set a baseline before launch.

Releasing to a cohort — a fuller frame

"Release to a pilot cohort" has a canonical ramp that controls blast radius:

• Beta — 5–50 hand-picked users, high-touch support; goal is qualitative + behavioural learning.
• Canary — a small slice (1–5%, or one team / office / role) with fast rollback; goal is production safety and an early metric signal.
• General availability — staged ramp (5% → 25% → 50% → 100%) with the guardrail metrics checked at each step.

For an internal People product, "canary" means a sympathetic pilot org with stakes proportional to the risk. During the build, run moderated usability tests with ~5 users per persona per major flow (Nielsen's rule: five users surface ~85% of usability problems) and track task-success rate, time-on-task, and error rate.

Phase 5 — Scale

Roll out what works — and fold it into continuous improvement.

Why this phase exists. Premature scaling is a classic killer: rolling out org-wide what worked for ten volunteers, then watching it fail at ten thousand. In product thinking, scale isn't an end — it's a handoff into ongoing discovery. For HR especially, scaling is organizational change, so the rollout itself needs a method, not just a launch date.

You walk in with. A validated solution, pilot signals against the baseline, a rollout-readiness assessment, and owners lined up.

Step by step

Step 1 — Scale the rollout in phases (this is change management). Don't big-bang. Phase the rollout by readiness, build the lightweight version of anything the pilot did by hand, communicate to the people affected, enable the people who'll run it, and keep a checkpoint after each phase so you can halt or adjust. Steps: (1) sequence the rollout (which group, in what order, by readiness); (2) build the minimal tooling the pilot proved necessary; (3) communicate the change to users and managers (what, why, what's expected); (4) enable the local owners who'll run it; (5) checkpoint after each phase before continuing.

Step 2 — Operationalize ("run" mode). Assign ongoing ownership and set up monitoring — name who runs it day-to-day and who's accountable for improving it.

Step 3 — Evaluate at scale. Re-measure — the pilot metric can behave differently at scale — and check it holds across segments (equity), not just on average.

Step 4 — Stand up health monitoring. Track a composite signal (usage + satisfaction + engagement), not a vanity number, on a regular cadence.

Step 5 — Run a retrospective. Capture what you learned about the problem, the solution, and your way of working.

Step 6 — Feed the learnings back to Strategy. Update the roadmap and North Star — close the loop.

You walk out with. A live, owned, monitored solution; a confirmed outcome at scale (with the equity gap caught and fixed); and learnings fed back into Strategy and Discovery.

The gate — closing the loop. Scale's checklist is its gate: are you scaling something validated (not promising)? Phased plan with checkpoints? Assigned owner? Health monitoring? Re-measured at scale? Learnings fed back? When those hold, you return to Strategy — and the next problem re-enters Discovery.

Going deeper — Scale

Health monitoring — a fuller frame, two optional composites

The canon tracks a composite, not a vanity number. Two canonical composites give you a ready-made structure:

• OPTIONALHEART (Google). Five lenses on experience health: Happiness (attitude — pulse/CSAT), Engagement (depth of use), Adoption (new uptake), Retention (continued use), Task success (completion, errors, time). You don't track all five — pick the 2–3 that fit the product's stage, and for each run Goals → Signals → Metrics (what does good look like → what behaviour signals it → what number measures it).

• OPTIONALAARRR "pirate metrics" (McClure). A funnel view: Acquisition → Activation → Retention → Referral → Revenue. For an internal People product, read "Revenue" as business value (time saved, attrition avoided, productivity gained) and "Acquisition" as "made aware / enrolled." Useful when adoption itself is the thing you're trying to grow.

Change management & adoption — a fuller frame (this matters most for HR)

For an internal People product, the rollout is a change-management problem, so the canon's "phased rollout" deserves a real model.

• [Optional — recommended for HR] ADKAR (Prosci / Hiatt). People adopt a change in a sequence: Awareness (why this is changing) → Desire (what's in it for me) → Knowledge (how to do it) → Ability (actually doing it) → Reinforcement (it sticks). The key principle is the barrier point: progress is blocked by the first element that's missing. If a team lacks Desire, more Knowledge (training) won't help — you have to fix Desire first. Diagnose each segment, find its barrier, and sequence interventions accordingly; re-diagnose at 30/60/90 days.

• Adoption curve (Rogers) + the chasm (Moore). Adopters arrive in a sequence — innovators (~2.5%) → early adopters (~13.5%) → early majority (~34%) → late majority (~34%) → laggards (~16%). Pilot with innovators and early adopters; the hard part is crossing the chasm into the early majority, who are pragmatists and need proof, references, and support — not novelty. This is why the canon rolls out by readiness, department by department.

Run mode & retros — a fuller frame

"Operationalize" means standing up product-ops habits: an owner and a support route, a release cadence (not ad hoc), and a metric-review rhythm (weekly health, monthly business review, quarterly portfolio review). Build a "voice of the user" intake so support tickets become opportunities that re-enter the tree. And make the retrospective dual: a qualitative retro (Start/Stop/Continue or Mad/Sad/Glad) and a quantitative outcome review (did we move the metric?) — both feeding back into Strategy, which is what makes the whole thing a loop rather than a line.

After Scale — close the loop

Scale is not the finish line; "done" isn't a phase. The team returns to the hub with what scaling taught them, updates the North Star and roadmap, and the next problem re-enters Discovery. Each full lap leaves the strategy sharper and the next loop better aimed.

What to notice across the worked example. One problem ran the whole way through — from a cascaded growth strategy to a scaled, monitored onboarding system. At no point did the team bet big before they had evidence: a concierge test (ten manual matches) de-risked the idea before a line of tooling was built; a pilot cohort proved it on 20 real hires before the org-wide rollout; and instrumentation set up in advance meant they could actually tell it worked (45 → 33 → 34 days) rather than just declaring victory at launch. Every gate could have ended in Pivot/Kill — and that possibility, not the eventual success, is what made each step honest.

Appendix — cross-cutting tools (gates, evidence, pre-mortems, kill criteria)

These run across every phase. The canon's "Stake" already embeds them; this appendix gives the product-practitioner depth and the source frameworks, all OPTIONAL rigor you scale to the stakes.

Gates: keep the vocabulary, not the waterfall

The Stake borrows the vocabulary of Stage-Gate (Cooper) — a sequence of stages separated by Go/Kill decision gates. That vocabulary is useful; the classic practice is not, and it's worth knowing why. In a traditional stage-gate, all the risk lands at the end: you write a business case at an early gate (when revenue and cost are pure guesswork), build for months, and only meet the customer at launch. The fix this guide uses is to keep the gate as a real Proceed / Iterate / Pivot-Kill decision, but feed it continuous-discovery evidence and assumption tests instead of a fictional up-front business case — so risk is burned down early and continuously. (Cooper himself now argues stage-gate can nest sprints inside stages; the point is that gates must gate evidence, not paperwork.)

Evidence quality — what "sufficient evidence" means at a gate

When a gate asks "is the evidence sufficient?", weigh it by strength, not volume. Roughly weakest → strongest:

1. Opinions from non-target people / surveys with no behaviour behind them.
2. Stated preferences and intentions from target users in interviews ("I would use this").
3. Behavioural signals in cheap tests — fake-door clicks, landing-page sign-ups.
4. Real usage in a concierge / Wizard-of-Oz run.
5. A/B-test results with a real consequence and statistical significance.
6. Multi-cohort, multi-period retention and value-delivered data.

A confident opinion (level 1–2) is the most common thing mistaken for evidence. Push every gate toward levels 3+.

Pre-mortem — surface failure *before* it happens (Klein)

Run a pre-mortem at the entry to each phase, not just at kickoff. The method (Klein, HBR 2007):

1. Brief the team on the plan as it stands.
2. Say: "It's [end date]. This has failed completely." — speak as if failure is certain.
3. Everyone writes, silently, for ~2 minutes: every reason it failed — especially the ones they'd normally be too polite to raise.
4. Round-robin: each person reads one reason, no repeats, all recorded.
5. Revise the plan to mitigate the top reasons; assign owners.

It works because imagining a certain failure ("prospective hindsight") unlocks ~30% more reasons than asking "what might go wrong?" — and because it gives quiet sceptics permission to speak.

Kill criteria — decide how you'll stop, in advance (Duke)

Kill criteria are the "Stop if…" conditions the canon sets at Strategy. The most usable form (Duke) is "states and dates": "If by [date] we have/haven't [observable state], we stop." Make them concrete and instrumented, and — crucially — name an independent "quit owner" who has the authority to call it, because the person who fell in love with the bet is the last person who can kill it. Hold the kill review on a fixed cadence, separate from the cheerful status meeting.

Examples for People products:

• "Unless ≥30% of pilot managers complete a calibrated 1:1 within 30 days, we stop the rollout."
• "Unless day-7 onboarding-confidence hits 70% by end of Q2, we re-shape the product."
• "Unless support tickets per user fall below 0.1/month after enablement, we don't expand past the pilot unit."

Stopping on a pre-set criterion is a win — it's capital reallocated to a better bet, not a failure. (Pair this with the worked example's stop line: "if a tested onboarding change doesn't move the day-7 pulse, stop.")

Diagram spec index

Every build spec in this guide, for handoff to Claude Code as a visual library. Render dark-theme with a single accent; keep them schematic, not decorative.

Strategy — Power/Interest grid · North Star tree · Three Horizons S-curves · Now-Next-Later board.

Discovery — Stakeholder circles · Forces of progress (switch) · Journey map · Assumption map (importance × evidence) · Opportunity Solution Tree.

Shape — Impact/Effort 2×2 · RICE table · Opportunity landscape · Four risks · Build-to-learn ladder · Experiment card.

Build — MVP Canvas · Sequencer · Metric tiers (primary/guardrail/counter) · Release ramp.

Scale — HEART × Goals-Signals-Metrics table · AARRR funnel · ADKAR bar · Adoption curve + chasm.

Cross-cutting — Gate flow (five phases, three exits).