Placing Bets

What it is

You almost never know in advance whether a big initiative will work. Placing bets just means being honest about that. Instead of dressing a plan up as a sure thing, you treat it as a bet — a sensible wager based on the best evidence you have right now. It's the same logic as an investor with a bit of money: you don't bet on a certainty (there isn't one), you make a smart wager, decide how much you're willing to risk, and know what would make you walk away.

Every bet has five plain parts: what you believe (your best read of the situation, from your research), what you'll try, what success looks like, the budget (how much time and people you'll spend before you judge it), and the stop line (the result that tells you to pull out). Two habits make betting work. You place several bets, not one — like spreading money across a few stocks, because some will lose. And you judge a bet by whether it was a smart call at the time, not only by whether it happened to win: a well-reasoned bet that didn't pay off was still a good bet, and you treat it as a lesson, not a failure. That's the difference between a team that keeps trying smart new things and one that only ever plays it safe.

When to use it

Strategy (Phase 1), when you turn your goals into the few things you'll actually back this year. And again at every review, to decide which bets to keep, change, or stop. Your bets become the themes on your Roadmap.

The four moves

Place — write each bet on one page.

• Belief: what you think is true, and why (from your research).
• Bet: what you'll do about it.
• Success looks like: the measure that says it worked (linked to your North Star).
• Budget: how much time and people you'll spend before you decide — a limit you set up front, not a guess at how long it'll take.
• Stop line: the result that means you walk away (your kill criteria).

Prioritize — you can't back everything. Rank your bets by how much they'd move your North Star, and keep a healthy mix: some safe near-term wins, some bigger long shots. Only start as many as you can actually staff — a list of twenty "active" bets is a wish list, not a plan.

Track — keep them visible. Put your bets on a simple Now / Next / Later board and check them on a regular rhythm. As evidence comes in, update how confident you are. If a bet runs past its budget, it doesn't quietly carry on — it comes back to the table to be re-decided.

Validate — judge honestly. At each review, look at the evidence (is it real, recent, and enough?) and choose one of three things: keep going, adjust, or stop. Stopping a bet because it hit the stop line you set is a success — the system working as designed — not an embarrassment.

Pitfalls & how to run it well

Expecting every bet to win (then you only ever pick safe ones and never learn anything new); not setting a budget (the project drags on forever); not setting a stop line (nobody's willing to end it); and judging a bet only by whether it won rather than whether it was a smart call. Run it well by writing each bet on one page, setting the budget and stop line before you start, keeping the board visible, and treating a well-reasoned bet that lost as a lesson.

Connects to

Your beliefs come from Discovery and Assumption mapping; your placed bets become the themes on the Roadmap; you check them at the Exit gates using Evidence rating and Kill criteria.

Roadmapping

What it is

A roadmap is the bridge between the Strategy hub and the actual work. It takes the year's few bets and the North Star and turns them into a rolling ~6-month plan expressed as outcomes and themes — problems to solve — rather than a locked list of features with delivery dates. That distinction is the whole point, and it's the place product and project cultures most visibly collide. A project plan commits to outputs ("ship A in Q1, B in Q2") and treats any deviation as failure. A product roadmap commits to outcomes ("cut time-to-productivity this half") and treats new evidence as a reason to re-aim — because the team doesn't yet know exactly which features will move the outcome. The roadmap is "living" because every exit gate (Stake) returns to Strategy and updates it; a roadmap that hasn't changed in six months is a sign the team stopped learning, not a sign of discipline.

When to use it

Strategy (Phase 1), after you've cascaded company strategy into your function's strategy and named the North Star and the year's bets. Re-touch it at every cycle as gates feed learnings back. Don't use a roadmap as a delivery contract or a Gantt chart of features — that's project thinking wearing a product label.

Process

1. Anchor on the North Star and the year's bets — the roadmap exists to serve them, not to list everything anyone wants.
2. Express every item as an outcome or a problem to solve, not a solution ("improve onboarding completion," not "build an onboarding portal").
3. Group items into a few themes over a ~6-month horizon; sequence by priority and dependency, not by how confident you are of a delivery date.
4. Attach a success measure to each theme (the outcome metric you'll judge it by), and ideally the kill criteria that would stop it.
5. Make it visible to the whole team and key stakeholders — transparency is what turns a roadmap into shared commitment rather than a private plan.
6. Stress-test it against viability — does leadership see the ROI?
7. Revisit every cycle. As gates return learnings to Strategy, re-sequence, drop, or add. Expect it to change; that responsiveness is the feature.

Pitfalls & how to run it well

The dominant failure is listing projects-with-dates and calling it a roadmap. Others: over-specifying the Later column (it's the most uncertain — keep it loose); attaching no success measure to a theme; and never revisiting it. Run it well by keeping it visible, reviewing it at every Strategy return, and cutting ruthlessly to protect focus — if everything is on the roadmap, nothing is.

Connects to

Upstream: the Strategy cascade and North Star definition feed it; Prioritization decides what's Now versus Later. Downstream: each theme enters Discovery as a framed problem, and exit-gate learnings flow back to revise it.

Stakeholder Mapping (the circles / RACI)

What it is

Stakeholder mapping places everyone touched by or touching an initiative into rings by their actual role in the decision. The circles model uses five: Core (the working team that decides and builds), Contributing (part-time SMEs, HRIS, IT), Consulted (e.g. managers, finance, legal — they give input, not control), Informed (kept in the loop), and Users (both B2C end users and B2B internal clients). It maps directly onto RACI — "consulted" and "informed" are literally RACI's C and I — and the underlying job is the same: separate who decides, who advises, and who is merely told. It's also where you name the product trio + sponsor explicitly inside the core: a problem owner (often the HRBP), a user advocate, a build/tech lead (People Ops / HRIS), and a sponsor for vision, resources, and air cover.

When to use it

At Discovery kickoff, before you plan research, and again whenever scope shifts. The cost of skipping it is role confusion that surfaces later as stalled decisions and blindsided stakeholders.

Process

1. List everyone the initiative touches or who could touch it.
2. Place each into a ring: core / contributing / consulted / informed / users.
3. Make decision rights explicit — core decides, consulted advises, informed is told. Write it down so a "consulted" voice doesn't quietly behave like an approver.
4. Name the trio + sponsor within the core.
5. Make sure users are represented on both sides (B2C and B2B), not just executives.
6. Agree how and how often each ring is engaged.

Pitfalls & how to run it well

Putting everyone in "core" so every decision needs everyone (paralysis); forgetting users are stakeholders (you design for execs and lose adoption); letting a consulted stakeholder act as an approver. Run it well by keeping the center small, naming decision rights out loud, and re-mapping when scope changes.

Connects to

Feeds Dual discovery (it tells you who to research on each side) and clarifies the trio. It's the social map that the rest of Discovery runs on.

5W1H

What it is

5W1H forces you to answer, for any problem: Who has it (which segments, personas), Where / When does it occur (the moment of friction), Why does it happen (the root cause, not the symptom), and How will we know it's solved (the success metric, defined now). It's the lightweight front end to problem framing — the answers become the raw material for the problem statement. Two of the questions do most of the work. "Why," pushed several layers deep, guards against the most common product error: fixing a symptom while the cause persists. "How will we know it's solved" forces you to commit to an outcome measure before you fall in love with a solution, so you can later tell whether you actually changed anything.

When to use it

Early in Discovery, the moment a problem lands on the table — especially when it arrives pre-solutioned ("we need an X"). Pairs immediately with problem framing.

Process

1. Who: name the specific segment or persona that feels it — not "employees" in general.
2. Where / when: pin the moment of friction (which step, which context). Problems are rarely universal.
3. Why: ask "why" repeatedly (the five-whys move) to get past the symptom to a root cause — which is itself a hypothesis to check, not a fact.
4. How will we know: define the metric or behaviour that would tell you it's solved, in outcome terms ("productive in five days"), not completion terms ("form shipped").
5. If you can't answer all of them, stop — you're not ready to design; you're ready to do more discovery.

Pitfalls & how to run it well

Stopping at the first "why" (you fix a symptom); skipping "how will we know" (you ship with no way to judge success); treating it as bureaucracy rather than a ten-minute sharpening tool. Run it fast and out loud, and let the "why" get uncomfortable.

Connects to

Feeds Problem framing directly (its answers populate the problem statement) and Assumption mapping (the root-cause "why" is usually an assumption to test). Upstream of everything in Discovery.

Personas + JTBD

What it is

A persona is a visualization of a segment — a composite, research-based portrait of one distinct type of user, built so the team designs for a specific person instead of a faceless "user." The operative word is distinct: a persona is only worth having if it's different enough to justify its existence. Personas come out of segmentation — dividing your users by a dimension that genuinely changes how you'd serve them (behaviour, needs, the job they're doing, their context) — not by demographics for their own sake. The test of a real persona is decision-relevance: would you make different product decisions for this persona than for that one? If two "personas" would lead to the same design, they're one segment wearing two faces — collapse them. A useful set is small (2–4) and sharply different.

Jobs-to-Be-Done (JTBD) captures the progress a persona is trying to make — the "job" they hire a solution to do — across three dimensions: functional (the practical task), emotional (how they want to feel), and social (how they want to be seen). JTBD is solution-agnostic and stable: features and demographics churn, but the job ("get up to speed in a new role") holds, which is what makes it a reliable target. It also has a direct line into delivery — a JTBD translates almost one-to-one into a user story, the format engineers use to describe backlog items, which is how a product-thinking HR team starts speaking the same language as its tech and product partners.

For internal functions you keep two layers (the B2C / B2B dual lens): end-user personas (employees, managers, new hires) and internal-stakeholder personas (HRBPs, leaders), each a distinct segment with its own jobs. Success means both — user adoption and operational alignment.

When to use it

Discovery, after the problem is framed and you have real research, to ground design in specific people. Always built from research (interviews, observation, data) — an invented persona just launders assumptions and is worse than none.

Process

1. Segment first. Look across your research for the dimension that splits users into groups who need different things — behaviour, needs, jobs, context (demographics rarely do this alone).
2. Test distinctness. For each candidate segment ask "would we design differently for this group?" If not, merge it. Keep the 2–4 that pass.
3. Build the persona anatomy for each (below), grounded in what real people said and did — include a verbatim quote.
4. Write the JTBD across functional, emotional, and social dimensions.
5. Repeat for the stakeholder layer (B2B) — same anatomy, but the needs and jobs are governance and operational.
6. Translate each JTBD into a user story so the work is ready to hand to delivery (see the bridge below).
7. Name them, keep them few, and revisit as research deepens.

Persona anatomy

What a good persona contains:

• Segment & distinctness — the dimension this persona represents, and why it's different enough to need its own card.
• Demographics — role, tenure, team, location, and the few demographic facts that are actually relevant (not decoration).
• Context / environment — where and how they work (remote, deskless, on the floor), which shapes everything else.
• Needs — what they require to succeed.
• Problems & frictions — what gets in their way today; the pain points (ties straight to the journey map).
• Motivations — what drives them; why they'd care enough to change behaviour.
• Habits & rituals — their routines and recurring behaviours; a solution has to fit these or it won't be adopted.
• Current process / workarounds — how they solve this today, including the tools and hacks they already use. You're rarely competing with nothing — you're competing with the spreadsheet, the DM to a friend, the "I just wing it."
• JTBD — functional / emotional / social (below).
• Success metric — what "this worked" looks like for them.
• Triggers — the event that kicks off the job (the "when" of the JTBD): first day, a reorg, a failed review.
• Desired outcome — the gain they're after, in their words (the positive mirror of problems & frictions).
• Influences & who they trust — whose opinion moves them; often decisive for B2B stakeholders.
• Tech comfort — adoption-relevant: a low-comfort persona will quietly reject a clever-but-fiddly solution.
• A verbatim quote — one real line from research; it anchors the persona in evidence and is the fastest tell of a grounded vs invented persona.
• Frequency / volume — how often they hit this and how many of them exist (how much the segment matters).

JTBD — functional, emotional, social

• Functional — the practical task: "get up to speed on my role and start contributing."
• Emotional — how they want to feel: "feel confident and settled, not lost or anxious."
• Social — how they want to be perceived: "be seen as competent and a good hire by my new team." A complete JTBD names all three, because solutions that nail the functional job but ignore the emotional and social ones get quietly rejected.

The bridge to delivery: a JTBD maps almost directly onto a user story — the one-line format engineers use to describe a backlog item.

• JTBD: "When I start a new role, I want to know what's expected of me, so I can feel confident."
• User story: "As a new hire, I want a clear week-one plan, so that I feel confident about what's expected." The "so that…" clause is the outcome, which keeps the backlog item tied to value rather than to a feature. This translation is how a product-thinking HR team hands work to product and engineering in the language they already use — instead of throwing a finished solution over the wall.

Pitfalls & how to run it well

The big one: personas that aren't distinct — if two would drive the same decisions, you've got one segment and wasted effort, so collapse them. Others: demographics-only personas (age and location rarely change the design — behaviour and jobs do); inventing personas instead of grounding them in research; too many personas (4 is plenty); and writing JTBD as features ("wants an app") rather than progress ("wants to feel confident"). Run it well by segmenting on what actually changes the design, basing every line on real research, and naming all three JTBD dimensions.

Connects to

Built from Dual discovery research; feeds Journey mapping (whose journey?), Assumption mapping (each persona carries user assumptions to test), and the opportunities in the Opportunity-Solution Tree. Downstream, the JTBD → user story translation is the handoff into delivery backlogs — the shared language with product and engineering.

Journey Mapping

What it is

A journey map visualises a user's experience of a process as a sequence of steps, and for each step captures four things: what the person does, the tools and touchpoints they use, the pain points they hit, and the emotion they feel — usually split across before / during / after. It turns a vague sense that "onboarding is rough" into a specific map of which moments fail and why. It builds directly on a persona (whose journey is this?) and is grounded in dual discovery research, not imagination. The layer teams skip is emotion, and it's the one that most often matters: a step that's functionally fine but emotionally awful — the anxious first day, the silent wait for an approval — is frequently where the real problem lives, and a purely functional map misses it. The output is a ranked set of moments of friction — the breakpoints worth solving.

When to use it

Discovery, after you have personas and some real research, to locate the highest-leverage moments to attack. Don't map an idealised "designed" journey; map the lived one.

Process

1. Pick one persona and bound the scope — which journey, from where to where.
2. Lay out the steps in sequence across before / during / after.
3. For each step, capture actions, touchpoints/tools, pain points, and emotion.
4. Draw the emotion as a line across the steps; the dips are your breakpoints.
5. Ground every step in something a real person reported — not the official process diagram.
6. Use the breakpoints to generate opportunities (this feeds ideation and the Opportunity-Solution Tree).

Pitfalls & how to run it well

Drawing the process as designed rather than as lived; dropping the emotion layer; mapping too broad a scope so nothing is specific. Run it well with one persona and a bounded scope, built from real stories, and pick one synthesis tool per project rather than over-documenting.

Connects to

Built on Personas + JTBD and Dual discovery. Its breakpoints feed the Opportunity-Solution Tree and surface user assumptions to map. Often the single most persuasive artifact for stakeholders, because the emotional dips are visceral.

Problem Framing

What it is

Problem framing turns raw, messy signals — complaints, requests, dashboards, anecdotes, the answers from 5W1H — into a single clear, testable problem, separating symptom from root cause and bounding the scope. Its output is a problem statement, written to a template: "[User group] struggles with [problem] when [context] because [reason], which leads to [impact]." The core skill is resisting the pull toward solutions: requests almost always arrive pre-solutioned ("we need a new LMS"), which smuggles in an unexamined assumption about both the problem and its fix. A well-framed problem aligns the team on one target, makes discovery measurable, and keeps later ideation focused — which is why getting it right saves months that would otherwise be spent building the wrong thing beautifully.

When to use it

Discovery, right after 5W1H exploration. The resulting problem statement is exactly what the Discovery exit gate checks ("a framed problem the team agrees on, one sentence").

Process

1. Gather the raw signals and the 5W1H answers.
2. Strip the pre-loaded solution out of the request — turn "we need X" back into "what is X supposed to fix?"
3. Separate symptom from root cause (the "why" from 5W1H).
4. Bound the scope — a specific user group, context, and moment, not "everyone, everywhere, always."
5. Write the statement using the template.
6. Get the team to literally agree on the one sentence — agreement is part of the deliverable.

Pitfalls & how to run it well

Framing the solution as the problem ("the problem is we don't have an LMS"); leaving it unbounded and universal; ending with three competing statements and no agreement. Run it well by forcing exactly one sentence, keeping the reason falsifiable, and re-framing without ego if discovery proves the first cut wrong.

Connects to

Built from 5W1H; the statement anchors Assumption mapping, the Opportunity-Solution Tree, and the entire solution search. It's the gate condition for leaving Discovery.

Assumption Mapping

What it is

Every plan rests on assumptions — beliefs treated as true without proof, "invisible decisions waiting to be tested." Assumption mapping pulls them into the open and plots each on two axes — importance (how badly the idea breaks if it's false) and certainty (how much evidence you already have) — so the team aims its scarce research at the beliefs that are both load-bearing and unproven. Assumptions come in four types worth forcing: user, problem, solution, and viability — and the riskiest are usually the viability ones ("leadership will fund this," "managers will allow the time"). The map is the bridge from believing to knowing: the dangerous assumptions become hypotheses, each handed to an experiment that designs the cheapest test that could disprove it. It also connects to the gate mechanics — a top-left assumption that fails becomes a kill criterion, and how confidently you can move it depends on evidence rating.

When to use it

Discovery, once the problem is framed and you have a candidate direction, before committing real research or build effort. Re-map as evidence arrives and new assumptions appear; it's a living artifact. Skip it only when the work is genuinely known and low-risk — then it's a project, not a discovery.

Process

1. Brain-dump every assumption with the team, forced across the four types: user, problem, solution, viability. Phrase each as "We believe that…"
2. Make each atomic and falsifiable — split compound beliefs, reword vague ones so they could be proven wrong.
3. Rate each on importance and certainty.
4. Plot them on the 2×2.
5. Act by quadrant: high-importance + low-certainty → test first; high-importance + high-certainty → confirm cheaply with evidence you have; low-importance → park or ignore.
6. Turn the top-left assumptions into hypotheses and hand them to Experiments.
7. Re-map as you learn — tested assumptions move right, new ones appear.

Pitfalls & how to run it well

Mapping only solution assumptions and skipping viability (usually the real killers); rating importance by how much you like the assumption rather than how much the idea depends on it; treating the map as a one-time artifact. Run it as a team (diverse views expose hidden assumptions), time-box 30–45 minutes, and force-rank if everything lands "high importance" — the point is to choose.

Connects to

Upstream: Problem framing, 5W1H, Personas/JTBD, and Journey mapping all surface assumptions. Downstream: each top-left assumption becomes a hypothesis for Experiments; the risk-ranked map is what the Discovery exit gate checks.

Dual Discovery

What it is

Dual discovery is the operational execution of the B2C / B2B dual lens. You run end-user research (needs, friction, motivation) and stakeholder research (constraints, goals, success criteria) in parallel, then reconcile what the two sides need before committing to a design. It's a named discipline rather than just "do research" because teams reliably study only one side — usually the easier or louder one — and each omission has a predictable cost: skip the B2C side and you design something stakeholders approve but employees ignore; skip the B2B side and you design something employees love but leadership blocks or can't sustain. It draws on the full kit of research methods (in-depth interviews, observation, surveys, data analysis), and it's where the bias trap and the say-vs-do gap bite hardest — so you ask about real past behaviour, not hypotheticals, and recruit beyond friendly faces.

When to use it

Discovery, as the research engine, planned directly off the stakeholder map and aimed at the assumptions you most need to test. The Discovery exit gate explicitly checks that primary (not desk) research was done and that both sides were covered.

Process

1. From the stakeholder map, identify who to talk to on each side (B2C users and B2B stakeholders).
2. Match method to question: interviews for motivation and story, observation for actual behaviour, surveys for scale of a known issue, data for patterns.
3. Run B2C research — employee/manager needs, pains, motivations — asking about real past behaviour and watching for bias.
4. Run B2B research — stakeholder goals, constraints, success criteria, and what they'd need to approve and sustain the thing.
5. Reconcile: where do the two sides' jobs align, and where do they conflict? Resolve the conflict before designing.
6. Synthesise into personas, JTBD lines, the journey map, and the assumption map.

Pitfalls & how to run it well

Researching only the easy or loud side; leading questions and friendly-faces selection bias; asking "would you use this?" instead of "tell me about the last time…"; gathering both sides but never reconciling them. Run it well by pairing every piece of user research with stakeholder research, splitting interviewer/note-taker roles, and recruiting deliberately diverse participants.

Connects to

Planned off Stakeholder mapping; feeds Personas + JTBD, Journey mapping, and Assumption mapping. It's the evidence engine that turns the Discovery assumptions from guesses into rankings.

Prioritization

What it is

Prioritization is the discipline of choosing — making the trade-offs explicit and comparative rather than defaulting to whoever shouted loudest or whatever's newest. Its governing line is focus: "if everything is priority one, nothing is," and the hardest part of any strategy is what it refuses to do. Two lightweight tools do most of the work. The Impact/Effort matrix plots each candidate by value created against effort to deliver, instantly separating quick wins from long bets, fill-ins, and the money pit. ICE scoring rates each on Impact × Confidence × Ease, where the confidence term is the quiet genius — it docks ideas you believe in but have no evidence for, pushing you to either test them or drop them. Prioritization treats the work as a portfolio of bets, not a wish list.

When to use it

Shape, once Discovery has validated the problem and you have candidate opportunities or directions. It's how you pick the bet to de-risk and build. Use it again to sequence the roadmap (Now / Next / Later).

Process

1. List the candidate opportunities or solutions (ideally from the Opportunity-Solution Tree, so you're comparing opportunities, not pet ideas).
2. Score them — Impact/Effort for a quick read, ICE when confidence varies a lot.
3. Be honest about the confidence term: an idea you love but can't evidence scores low until tested.
4. Pick one defensible direction and be able to say why this, not that.
5. Commit — one direction carried properly beats three half-bets.

Pitfalls & how to run it well

Prioritising by loudness or recency; false precision in the scores (they're for sorting, not accounting); and producing a ranking but never actually cutting anything. Run it well by force-ranking, defending "this not that" out loud, and protecting focus.

Connects to

Takes candidates from the Opportunity-Solution Tree and ideation; the chosen bet then goes through Four-risk assessment and Experiments; the sequence feeds the Roadmap.

Opportunity-Solution Tree

What it is

An opportunity-solution tree is a structure with four layers, top to bottom: a desired outcome at the root (laddered up to the North Star); the opportunities beneath it (the user needs, pains, and desires from Discovery that, if addressed, would move the outcome); the solutions under each opportunity; and the experiments under each solution. Read downward it says "to move this outcome, we could pursue these opportunities, for which we have these solution ideas, which we'll test like this." Its purpose is to prevent the most common failure in product work — jumping straight from a goal to a favourite solution, skipping the opportunity space entirely. By forcing every solution to hang off an explicit opportunity, it makes prioritization happen at the opportunity level (compare problems worth solving, not pet ideas), exposes tunnel vision, and makes the team's reasoning legible to stakeholders.

When to use it

Shape — it's the bridge from Discovery's insights to the solution search. Build it from journey breakpoints, JTBD, and the insights discovery produced.

Process

1. Set the root: the outcome you're trying to move, tied to the North Star.
2. Branch into opportunities — the distinct needs/pains from discovery that could move that outcome. Aim for a few real ones, not one.
3. Under each opportunity, list candidate solutions (this is where ideation lives).
4. Under each solution, name the experiment that would test it.
5. Prioritise at the opportunity level first — which problem is most worth solving — then pick solutions within it.
6. Prune relentlessly; a sprawling tree is a sign of avoiding the choice.

Pitfalls & how to run it well

Starting from a beloved solution and reverse-engineering an opportunity to justify it; growing only one branch (tunnel vision); letting the tree sprawl into documentation. Run it well by prioritising opportunities before solutions and keeping it pruned to what you'll actually pursue.

Connects to

Built from Discovery insights (journey breakpoints, JTBD); feeds Prioritization (compare opportunities) and Experiments (the leaf nodes are tests). Sits at the seam between understanding the problem and choosing the solution.

6-3-5 Brainwriting

What it is

6-3-5 brainwriting is structured, silent ideation: 6 participants each write 3 ideas in 5 minutes on a worksheet, then pass it to the neighbour, who reads what's there and adds three more — new ideas, variations, or builds on the rows above. After six rounds (~30 minutes) every sheet is full: up to 108 idea slots. Published by Bernd Rohrbach in 1968 (in the German magazine Absatzwirtschaft), it fixes the classic failures of shout-it-out brainstorming: dominant voices setting the agenda, anchoring on the first idea said aloud, and production blocking (only one person can talk at a time — but six can write at once). Writing is parallel, silent, and leaves a paper trail of who built on what. It's the best-known member of the brainwriting family, and the same write-first discipline behind note-and-vote facilitation.

When to use it

Shape — at the ideation seam, when the Opportunity-Solution Tree has named the opportunity and you need to fill its solutions layer with real options instead of the first pet idea. Reach for it any time the room needs volume and variety fast, or when the group has strong personalities and quiet experts. Remote works fine: a shared board where each "sheet" is a column and rotation is moving one column right.

Process

1. Sharpen one prompt — a single "How might we…" tied to the chosen opportunity — and give everyone a worksheet of 3 columns × 6 rows.
2. Round one: each person writes 3 ideas in their top row, silently, in 5 minutes.
3. Pass the sheet one seat to the right. Read the rows above before writing — then add 3 more: new ideas, variations, or direct builds.
4. Repeat until the sheets are full — 6 rounds, about 30 minutes, up to 108 slots.
5. Cluster duplicates and near-duplicates, then converge: dot-vote or ICE-score the strongest candidates.
6. Hang the survivors on the tree as solutions and send them into Prioritization.

Pitfalls & how to run it well

A vague prompt produces 108 vague slots — sharpen the "how might we" first. People stalling at one idea per round — push for quantity; the odd rows are where the builds come from. Skipping the read first step, which turns it into six parallel monologues and kills the building effect. And treating the number as the result — 108 slots are raw material for clustering, not 108 good ideas. Run it in true silence with an honest, visible 5-minute timer.

Connects to

Fills the solutions layer of the Opportunity-Solution Tree; its survivors flow into Prioritization (ICE) and on to Experiments. Kin to note-and-vote and silent-brainstorm facilitation — same write-first, speak-later muscle.

Four-Risk Assessment

What it is

Every solution must survive four risks, assessed before the expensive build: Value (will people choose to use it?), Usability (can they figure out how to use it?), Feasibility (can we build it with what we have?), and Viability (does it work for the business — financially, legally, operationally, for the brand?). This is the same lens as desirability / feasibility / viability, broken one finer (desirability splits into value + usability). The framework's payoff is diagnostic: instead of vaguely "validating," you name which risk is largest and aim the right test at it. It maps cleanly onto the product trio — the PM carries value and viability, the designer carries usability and desirability, the tech lead carries feasibility — and onto the experiment types — value → pretotype, usability → prototype, feasibility → POC, viability → business/legal case. One thing teams routinely get wrong: legal belongs under viability, not feasibility (feasibility is "can we build it," viability is "are we allowed to and should we").

When to use it

Shape, on the chosen bet, before committing to build. It tells you what to test first.

Process

1. State the solution clearly.
2. Ask the four questions and rate where the risk is highest — honestly, not where it's easiest to test.
3. Map each high risk to the cheapest test that attacks it (value → pretotype/concierge; usability → prototype; feasibility → POC; viability → business case / legal review).
4. Test the biggest risk first.
5. Assess it as the trio — each member surfaces the risk they own, together, not in sequence.

Pitfalls & how to run it well

Polishing usability on something nobody wants (value unaddressed); proving feasibility of something the business can't sustain or isn't allowed to do (viability unaddressed); filing legal under feasibility. Run it well by naming the single biggest risk honestly and testing that, not the one that's most comfortable to test.

Connects to

Applied to the bet chosen in Prioritization / OST; routes each high risk to an Experiment type; mirrors the product trio. The Shape exit gate checks that all four were assessed.

Experiments

What it is

"Experiments" is the family of build-to-learn tests, and the parent of the specific types that follow (pretotype, prototype, POC, MVP, A/B, concierge, Wizard-of-Oz). The discipline is constant regardless of type: take the assumption that's highest-importance and lowest-certainty, write it as a falsifiable hypothesis, pick the cheapest test that could disprove it, and define what counts as pass or fail before you run it. Two choices set the test: which of the four risks you're attacking, and how real the thing needs to be to learn (the build-to-learn ladder runs lightest to most real: pretotype → prototype → POC → MVP). A one-page Lean Experiment Canvas captures hypothesis, what you'll learn, the test, the success metric, and the next step if it works or doesn't — which is what stops "experiments" from being unfalsifiable demos. The mindset is "build to learn, not to launch": a test that disproves a hypothesis cheaply has succeeded.

When to use it

Shape (and on into Build), to move top-left assumptions from hope to evidence and to satisfy the gate that the riskiest assumption has been moved.

Process

1. Take the riskiest assumption from the assumption map.
2. Write it as a hypothesis: "We believe [change] will produce [measurable result] for [user]."
3. Identify which risk it's really about (value / usability / feasibility / viability).
4. Pick the cheapest test that fits that risk and the realness needed (see the ladder below).
5. Fill the Lean Experiment Canvas — define the success threshold and the if-works / if-not next steps up front.
6. Run it small, on real users where possible.
7. Decide honestly: proceed, iterate, or kill against the pre-set threshold.

Pitfalls & how to run it well

Building to launch instead of to learn; running a "test" with no pre-defined success threshold (so any result can be spun); picking the test you find fun rather than the one that fits the risk; testing the easy risk rather than the biggest. Run it well with one canvas per experiment, the success metric and next steps defined before you start, and the smallest version that can still teach you something.

Connects to

Fed by Assumption mapping (the hypotheses) and Four-risk assessment (which risk to attack); each type is detailed below; results feed the Shape and Build exit gates and trigger kill criteria when a threshold is missed.

Pretotype (fake door)

What it is

A pretotype tests one thing: does anyone actually want this? — demand — at near-zero cost and before any real build. The classic form is the "fake door": a sign-up button, a landing page, or an announcement for a service that doesn't yet exist, where you measure how many people click or register. It sits at the bottom of the build-to-learn ladder because it challenges the assumption every other test takes for granted — that the thing is worth making at all. Where a prototype asks "can they use it?" and a POC asks "can we build it?", a pretotype asks the prior question: "should this exist?"

When to use it

Shape, against a value/demand assumption, when building even a prototype would be premature. It's the antidote to building something beautifully that nobody wanted.

Process

Create the lightest possible signal of the real thing (a button, a page, an email offer); expose it to real users; measure the action that indicates genuine interest (clicks, sign-ups, replies); compare against a pre-set threshold. Handle the ethics: tell sign-ups it's "coming soon," or route them to a manual fallback — never leave someone deceived or stranded.

Pitfalls & how to run it well

Deceiving or stranding users (always provide a real fallback); reading vanity clicks as commitment (pick an action that costs the user something); pretotyping when you already know there's demand. Run it well with a clear pre-set threshold for "enough interest."

Connects to

A type of Experiment; attacks value risk; the lightest rung below Prototype, POC, and MVP.

Prototype

What it is

A prototype is a mock-up, clickable screen, paper sketch, script, or staged walkthrough made to provoke real reactions and surface confusion early, when changing direction is cheap. It tests usability and desirability — "do they get it, and do they want it?" — and it is deliberately not functional underneath; the value is in what users do and say, not in the artifact. It comes in a fidelity range (paper → clickable → high-fidelity), and you use the lowest fidelity that answers the question. It sits above the pretotype on the ladder (it assumes demand and tests the experience) and below the POC and MVP.

When to use it

Shape, against a usability/desirability assumption, once demand is plausible. Use it to learn before a line of production code exists.

Process

Pick the fidelity that fits the question (don't polish a high-fi mock to test a flow); build the representation of just the slice you're testing; put it in front of real users; watch where they hesitate, misread, or reach for something that isn't there; capture the reactions, not applause.

Pitfalls & how to run it well

Over-investing in fidelity (you're testing reactions, not shipping); leading the user; mistaking polite praise for usability. Run it well by testing the lowest fidelity that answers the question and observing behaviour over opinion.

Connects to

A type of Experiment; attacks usability/desirability risk; distinct from POC (internal feasibility, no users) and MVP (real, live, delivers value).

POC (proof of concept)

What it is

A proof of concept targets feasibility — the technical or practical "is this approach even possible with what we have?" It's allowed to be ugly, throwaway, and hidden from users; its only job is to retire a "we're not sure this can be done" doubt before the team bets real resources. The thing that sets it apart from every other test is the kind of uncertainty it resolves: not whether anyone wants it (value), not whether it works for the business (viability), only whether the approach is technically workable. That's why a POC is not an MVP — a POC proves can we, an MVP tests should we by putting real value in front of real users.

When to use it

Shape, against a feasibility assumption — when there's a genuine "can this be built / integrated / made to work at all?" doubt. Skip it when feasibility was never really in question.

Process

Isolate the single technical question; build the minimum wiring that answers it (a spike), with no interface and no users; confirm it works or doesn't; throw the code away. The output is a yes/no on feasibility, not a product.

Pitfalls & how to run it well

Shipping a POC to users (it was never meant for them); over-building it into a half-product; running one when feasibility was never actually the risk. Run it well by keeping it isolated, internal, and disposable.

Connects to

A type of Experiment; attacks feasibility risk (the tech-lead's seat in the trio); distinct from Prototype (usability, with users) and MVP (value in real use).

MVP (minimum viable product)

What it is

The Minimum Viable Product is the smallest real version of a solution that delivers genuine value to real users and lets you learn from how they actually use it. Both words carry weight: minimum means stripped to the smallest thing that can stand on its own; viable means it must actually work and deliver value — a broken fragment is minimum but not viable. It's the top of the build-to-learn ladder and the most abused term in product, usually misused to mean "version one" or "the cut-down scope we could afford." It is none of those: not a prototype (not live, delivers no real value), not a POC (internal, proves only buildability), and not "everything minus polish." The discipline is the question: what is the smallest live thing that lets a real user get real value, so we learn whether this is worth scaling? The mindset is "build to learn, not to launch."

When to use it

The end of Shape into Build, against value and viability in real use, once cheaper tests have de-risked demand and usability. It's the first thing that's actually real.

Process

Define the single core value the user must get; strip everything not required to deliver that value once; build it for real but small; release it to a bounded group; measure the outcome (not just usage); learn and decide whether to scale.

Pitfalls & how to run it well

Calling a feature-complete v1 an "MVP"; shipping something minimum but not viable (no real value); treating launch as the finish rather than the start of learning. Run it well by defining the one core value first and instrumenting the outcome from day one.

Connects to

A type of Experiment and the bridge into Build; attacks value/viability risk; the most-real rung above Pretotype, Prototype, and POC.

A/B Test

What it is

An A/B test shows two (or more) versions of something to comparable groups of real users at the same time and measures which performs better on a pre-defined metric. Because the only meaningful difference between the groups is the change you're testing, a difference in results can be attributed to that change. It replaces taste and seniority with data on decisions that are genuinely uncertain and measurable — wording, layout, flow, timing. It is not a discovery tool: it optimises among options you already have, it won't tell you what to build.

When to use it

When you have two concrete variants of a live thing and a measurable outcome, and the decision between them is worth resolving with data rather than argument. Needs enough users for the difference to be real, not noise.

Process

Define the success metric before running; create the two variants differing in one thing; split comparable users between them; run until you have enough signal; pick the winner on the pre-set metric.

Pitfalls & how to run it well

Choosing the metric after seeing results (so you cherry-pick); too few users (noise read as signal); using it to "discover" rather than optimise. Run it well by fixing the metric up front and changing one variable at a time.

Connects to

A situational Experiment; mainly attacks value/usability at the margin; optimises among options that earlier methods (OST, prioritization) produced.

Concierge Test

What it is

In a concierge test the team does by hand, in the open, what a finished product would eventually automate. The user gets a real outcome; the team just provides it through human effort, and the user knows it's manual. The name comes from a hotel concierge personally handling each request. Its purpose is to learn the shape of the solution cheaply, on real cases — every step, exception, and judgement call the real service will have to handle — before committing to a build. It delivers genuine value (unlike a prototype) and builds nothing (unlike a pilot or MVP).

When to use it

Shape, against value and "what does this experience actually require" uncertainty, when you want to learn the service design before automating it.

Process

Pick a few real users; deliver the service to them by hand, openly; capture every step, decision, and edge case you hit; use that to design (or decide against) the eventual automated version.

Pitfalls & how to run it well

Automating before you understand the edge cases (the whole point is to find them by hand); doing it at a scale you can't sustain. Run it well with a deliberately tiny n and a disciplined log of what you learned.

Connects to

A type of Experiment; attacks value and surfaces feasibility/operational realities; distinct from Wizard-of-Oz (manual but hidden) and Prototype (delivers no real value).

Wizard-of-Oz

What it is

In a Wizard-of-Oz test the user believes the system is real and automated, while a person quietly does the work behind the scenes — the wizard behind the curtain. That hidden-ness is the whole point and the difference from a concierge test: because the user thinks it's automated, you observe their genuine, unselfconscious behaviour with the "product," letting you test the real experience and demand for an automated solution without building the automation. It answers "if this worked automatically, would people use it and would it deliver value?" at a fraction of the cost.

When to use it

Shape, against value / the experience of an automated solution, when the cost or risk of building the automation is high and you want real behaviour, not stated intent.

Process

Build a convincing front (what the user sees as automated); have a human generate the responses/results live behind it; let real users interact believing it's real; measure whether they engage and benefit; only then decide whether the automation is worth building.

Pitfalls & how to run it well

Letting the deception harm or mislead users in ways that matter (keep it honest and low-stakes — the test-ideas-responsibly principle applies); not being able to sustain the manual effort even briefly. Run it well at small scale, with a clear read on the behaviour you're testing.

Connects to

A type of Experiment; attacks value/experience risk for would-be automated solutions; distinct from Concierge (manual but open) and from POC (proves the automation is buildable, with no users).