Lean Product Canvas

Facilitate Jeff Gothelf's Lean Product Canvas. It is a one-page tool that frames work around a business problem to solve, not a solution to implement, filled across 8 boxes in order.

This variant is self-contained (every helper skill is distilled inline) and keeps two deliberate enrichments over the stock canvas:

• Box 2 follows the money first. You trace the cashflow to the final money-capturer before naming a metric — then write each metric in v3's "who does what by how much" key-result format. You cannot state a credible business outcome until you know who ultimately gets paid.
• Box 4 runs a full Jobs-to-be-Done pass (functional / social / emotional jobs, plus pains and gains), and Box 7 uses Hypothesis-Prioritization thinking (risk × perceived value) to pick what to test first.

The canvas is an insurance policy: it turns assumptions into experiments before you commit to building, and shifts the conversation from outputs to outcomes.

Input

Works best with the business problem you're framing — or the solution someone handed you, which the canvas reframes as a problem. Also useful: known users, evidence so far, and what the team already believes.

Anything supplied at invocation — text after the skill name, an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; never re-ask. Arriving empty-handed works too: open at Box 1.

How to run this session

This is a workshop, run one turn at a time. Hold to this protocol through all 8 boxes:

• Open with a heads-up. Tell the user this is an 8-box canvas for the whole product team, then run it Guided — one question at a time, filling the boxes in order.
• One question per turn. Ask a single box's question in plain language, then wait. Never stack questions.
• Label progress every turn — e.g. Box 3 of 8 — Users.
• Offer numbered options and recommend one. Each box gives the user a way to answer directly, a "help me work it out" path, and — where they're stuck — the distilled helper for that box. Put your recommendation first, marked (Recommended).
• Validate against the box's completion criterion before advancing. If it isn't met, ask a follow-up rather than moving on.
• Pause and resume on request, and absorb interruptions without losing the current box.

The canvas

┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │              │ 2. Business Outcomes  │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users            │  (spans      │ 4. User Outcomes &    │
│                     │   rows 1-2)  │    Benefits (JTBD)    │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. Hypotheses       │ 7. Learning  │ 8. Experiments        │
│                     │  Priorities  │                       │
└─────────────────────┴──────────────┴───────────────────────┘

Fill order is 1 → 8. Two distinctions to hold throughout: Box 2 is metrics (behavior change you can measure, written as "who does what by how much"), Box 4 is human (jobs, benefits, emotions). And solutions are hypotheses, not commitments — you explore the space, you don't sign up to build it.

What this canvas is not: a feature list (Box 5 is ideas to test, not a backlog), a project plan (it frames learning, not delivery dates), a strategy substitute (it executes strategy, it doesn't create it — that's the Lean Strategy Canvas), or a one-time exercise (revisit and update as evidence arrives). If the problem and solution are already validated, or stakeholders are committed to a solution regardless of evidence, this isn't the tool — fix that first.

Steps

Box 1 — Business Problem

Ask: What is the most important problem your business needs to focus on right now — and what changed in the world that created it? Draw out current state (how the business delivers value today), what changed (market shift, competitive threat, customer-behavior change, new technology or channel) that has reduced the product's ability to deliver the value it used to, and why it matters now versus six months ago.

Sharp vs. vague:

• Good: "Mobile is now 60% of visits but converts 15% lower than desktop; our checkout wasn't built for it and competitors ship one-tap."
• Too vague: "We need to increase revenue" (nothing changed named), or "Users want more features" (no business problem).

Problem framing — when they only have a solution ("we need to build X"), reframe it. Behind the named solution sits a person blocked from something that matters. Draw out five beats:

1. I am [specific persona]
2. trying to [outcome, not task]
3. but [real barrier]
4. because [root cause — ask "why" until it stops being a symptom]
5. which makes me feel [a real emotion, not marketing-speak]

Then compress to one sentence: [persona] needs a way to [outcome] because [root cause], which currently [impact].

Watch for two dodges — both skip the user's actual problem:

• Solution-smuggling — "the problem is we lack X".
• Company-metric-as-problem — "churn is up".

Look inward before advancing — one bias check: ask "What's one assumption you're making about this problem that you haven't validated — and how might you be part of the problem?" Any of these count:

• Solution-first thinking.
• Optimizing for what's easy for the team.
• Assuming you already know what users want.

Tag the answer [assumption to validate] so it stays visible as a candidate for Box 7's riskiest assumption.

Completion criterion: the statement names what changed and why that creates a problem now — not a restated solution, not "we need more revenue" — and one unvalidated assumption is surfaced.

Box 2 — Business Outcomes

This box runs in two phases, in order. Do not write a metric until the money trail is clear.

Phase 2a — Follow the money

Ask questions until you can trace the cashflow end-to-end and name who takes the money at the end. Follow the money: don't stop at the first hop ("customers pay us") — trace every step to the final money-capturer, the party that ultimately keeps the money when the solution succeeds. Payer, user, and beneficiary are often three different parties; intermediaries (platforms, resellers, ad networks, insurers) skim hops in between.

Probe with questions like:

• Who pays, and for what?
• Where does that money go next?
• Who else sits between the payer and the end?
• Who takes the last cut?
• Would this stakeholder still get paid if the solution worked perfectly?

Mirror the trail — one status-quo check: ask "Who benefits if this problem keeps existing, and who loses if you solve it?" The party that captures the money when you succeed is rarely the only one with a stake; someone often profits from the status quo (an internal team that avoids extra work, an incumbent, a reseller margin) and will resist. Name them — political resistance is a risk you'd rather see now than in Box 7.

Restate the trail back to the user and advance only on their confirmation.

Completion criterion — all four hold:

1. Every stakeholder is named with their role — who pays, who uses, who benefits, and every intermediary.
2. The money path is traced hop-by-hop — "who pays whom, for what" at each step, with no "…and then revenue happens" gap.
3. The final money-capturer is explicitly identified.
4. The outcome (Phase 2b) will move money toward that capturer — the trail and the metric are linked, not separate.

Phase 2b — Business outcome ("who does what by how much")

Ask: How will you know you solved the problem — what behavior change will you measure, and how does it move money toward the final money-capturer? These are your high-level key results: what will people be doing differently if your solutions work? Push for measurable behavior change (leading indicators welcome), not lagging aggregates. If they only have revenue/profit, help find the leading indicator that predicts it. Consider business-success metrics (lifetime value) and product-success metrics (retention rate, usage).

Write every metric in key-result format: "who — does what — by how much." That single format carries all four parts a metric needs — the population/segment (who), the behavior change (does what), and the baseline → target + timeframe (by how much). "Cut time" isn't a metric; "field techs (who) cut commissioning time per station from 40 to 10 min (does what, by how much) within one quarter" is.

Write one key result per hop between the behavior change and the final money-capturer. The number of layers isn't a style choice — it's set by the money trail from Phase 2a:

• If the behavior is the money event, that's one line — and it's not a compromise. "Mobile shoppers increase checkout conversion 45%→60% in 3 months": the conversion is the cash register firing, so there's no causal gap to expose. Adding a "→ revenue" layer here is padding.
• If money is downstream, name each hop. State the leading behavior you'll measure and the money it captures, then mark the link between them as an assumption to validate — it's a viability risk (candidate for Box 7). Example (mortgage pre-approval):
  • Leading: applicants get pre-approval turnaround cut from 5 days to 4 hours, within 2 quarters.
  • Lagging: +X% of applicants complete their application → +$Y in origination fees captured by [the lender].
  • Link (assume, validate): applicant drop-off is driven by wait time, not by rate competitiveness or credit denials.

The trap is collapsing a multi-hop trail either way: to just the leading metric hides whether money actually moves; to just the lagging aggregate ("increase revenue") is the failure this whole box exists to kill.

Sharp vs. vague:

• Good (one hop): "Mobile shoppers increase checkout conversion from 45% to 60% in 3 months."
• Good (multi-hop): "Pickers cut warehouse pick time 90→30 sec/order this quarter → +40 orders shipped/picker/shift → fulfillment margin captured by the retailer" — with the throughput-is-pick-gated link flagged for Box 7.
• Too vague: "Increase revenue" or "Make users happy" — unmeasurable, and you can't tell if the experiment worked.

Completion criterion: a measurable, observable behavior-change key result in "who does what by how much" form (segment, behavior, baseline→target, timeframe), explicitly tied to the final money-capturer from Phase 2a. If money is more than one hop downstream, each hop is named and the causal link between them is flagged as an assumption to validate.

Box 3 — Users

Ask: Which users and customers (personas) should you focus on first? Push past "everyone" — consider who buys, who uses, who configures, and who is impacted by its use; they're often different people.

Sharp vs. vague:

• Good: "SMB owners (1–10 staff) in professional services."
• Too vague: "All users" or "Everyone" — you can't design a targeted experiment for a persona you can't picture.

Proto-persona — when they're stuck, sketch one working profile. Assumption-based is fine; tag the guesses [validate]. It's a shared working profile, not validated research. Capture:

• A memorable name.
• Behaviors — not just age/location, but what they do and where they spend time.
• Pains in this problem space.
• What they're trying to accomplish.
• Their goals.
• Their decision authority — a user isn't always the buyer, so note who approves the spend.

Completion criterion: specific enough to picture a real person, and one primary persona is chosen — not "all users."

Box 4 — User Outcomes & Benefits (JTBD)

Ask: Why would this persona seek out your product? What benefit do they gain, and what is their Job To Be Done? This is the empathy box — jobs, benefits, emotions — not metrics. Frame the job as "When [situation], I want to [motivation], so I can [expected outcome]."

Work through a full Jobs-to-be-Done pass, per primary persona:

1. Separate the job from any solution — ask "why?" until you reach the underlying need ("communicate with my team" is the job; "email" is a solution). Jobs are verb-driven and solution-agnostic.
2. Cover all three job types — social and emotional drive adoption harder than functional:
   • Functional — the task to complete ("reconcile monthly expenses for tax filing").
   • Social — how they want to be perceived, and by whom ("look responsive and reliable to clients").
   • Emotional — the state they want to feel or avoid ("feel confident I'm not missing details"; "avoid the anxiety of manual errors").
3. Name the pains — challenges/obstacles, what's too costly in time-money-effort, frequent preventable mistakes, and problems current solutions leave unresolved.
4. Name the gains — what would exceed today's solutions, the time/money/effort savings that delight, the factors that would make them switch, and how life improves.
5. Rank by intensity — not all pains are equal. Flag the most acute pain and the must-have (vs. nice-to-have) gain; that focus feeds Box 5 and Box 6.

Keep each specific and measurable — "cut report time from 8h to 1h", not "be more productive". Ground it in real customer signal where you have it; tag anything assumption-based [validate].

Completion criterion: explains why the user cares — at least one functional, one social/emotional job, and the most acute pain and most-wanted gain — not just what they'll do.

Box 5 — Solutions

Ask: What could we make that solves the business problem and meets this user's need at once? List product, feature, or enhancement ideas. Push for a wide space — big and small, technical and non-technical, even business-model shifts. These are candidates to test, not a backlog.

Completion criterion: at least three distinct candidate solutions. One-idea answers get challenged: "What else could solve this? What if that one fails?"

Box 6 — Hypotheses

Turn the assumptions from Boxes 2, 3, 4 & 5 into testable hypotheses, one feature each.

Hypothesis template: We believe [business outcome from Box 2] will be achieved if [user from Box 3] attains [benefit from Box 4] with [feature from Box 5]. One feature per hypothesis. Keep the outcome a user result, not a feature's existence ("PMs respond to assignments 50% faster", not "PMs have notifications") — a hypothesis you can't be wrong about tests nothing. Draft one per solution; let the user accept, edit, or rewrite.

Completion criterion: each hypothesis is one testable statement in the template, linking outcome, user, benefit, and a single feature.

Box 7 — Learning Priorities (what to learn first)

You now have several hypotheses. This box does two things: pick which hypothesis to test first, then name the riskiest assumption inside it.

Prioritize with the Hypothesis Prioritization Canvas (risk × perceived value). Plot each Box 6 hypothesis on two axes — risk (how catastrophic if we're wrong — the team's collective best guess at the damage to the product, service, or business) and perceived value (how much business value we imagine the idea delivers — and remember that value is still imagined, not yet proven):

• High value + high risk → Test. Big upside, big downside, still unproven — this earns discovery time and experimentation. This is where Box 8 goes.
• High value + low risk → Ship & Measure. High-confidence, high-payoff — no discovery needed. Build it, launch it, then track the metric.
• Low value + low risk → don't test, usually don't build. Foundational table-stakes (e.g. payments) that don't differentiate the offering but are operationally required.
• Low value + high risk → Discard. Not worth the exposure — neither test nor build it.

Pick the high-value, high-risk hypothesis (the Test quadrant). Then, for it, list all the reasons it might fail (its risks), and choose the single riskiest assumption right now. Classify that assumption: value (do they want it?), usability (can they use it?), feasibility (can we build it?), viability (does it hit the business outcome / move the money?). Early on, weight risks to value over feasibility.

Completion criterion: the highest-priority hypothesis is chosen via risk × perceived value (the Test quadrant), and within it one riskiest assumption is named with its risk type and a stated reason — the one that, if wrong, would kill the initiative.

Box 8 — Experiments (least work to learn next)

Ask: What's the least amount of work we need to do to learn the next most important thing? Design the smallest experiment that validates or invalidates the Box 7 assumption fast — what could you learn in 1 day / 1 week / 1 month?

Proof-of-life probes — pick the cheapest probe that tells the harshest truth about the Box 7 risk, not the one that fits your tooling. Write the pass/fail/learn threshold before you build: if you can't describe failure, you can't measure success. One probe, one assumption.

Match the probe to the Box 7 risk type — the classification you already made is the handoff:

• Value (do they want it?) → customer interviews (the Mom Test: ask about the last time they hit the problem and what they did, never "would you use this?"; leading questions and pitching poison the signal; 5–10 people who recently lived the problem), landing/fake-door test (measure demand), smoke test (announce it, measure signups).
• Usability (can they use it?) → task-focused test (watch users attempt the job; observe completion, not opinions), wizard-of-oz (fake the solution with humans behind it so users hit a real workflow).
• Feasibility (can we build it?) → feasibility check (a 1–2 day spike-and-delete: API sniff test, prompt chain, data-integrity sweep — surface the blocker, then throw the code away).
• Viability (does it move the money?) → concierge (deliver the benefit by hand to a few users before automating, and see if the economics hold), synthetic-data simulation (model the outcome without production risk).

Recommend by the Box 7 risk type; let the user pick or design their own.

Disposal — name the delete-by date before you build. A probe is reconnaissance, meant to be thrown away, not scaled: if it feels too polished to delete, it's prototype theater, not a probe. Write down when and how you'll dispose of it (delete the spike, archive the recordings, keep only the learnings).

Completion criterion: the smallest test that can settle the assumption, matched to the Box 7 risk type, with a stated disposal date, runnable in under two weeks. Bigger than that → break it down.

Export

Render the completed canvas from template.md, with Box 2 showing both a Money trail line and an Outcome (key results) line in "who does what by how much" form. Then offer to: publish it, refine any box that feels thin, or suggest what to run next.

After the canvas — the learning loop

The canvas is one iteration, not a deliverable. Close the session by making the loop explicit so Iteration: [n] in the template actually increments:

1. Run the Box 8 experiment against a timebox (the <2-week limit you already set).
2. Record the learning — was the Box 7 assumption validated or invalidated, and what's the evidence?
3. Update the canvas — revise the hypotheses that moved, and re-run the Box 7 risk × perceived value prioritization to re-pick the next-riskiest assumption.
4. Repeat Box 7 → Box 8 until confidence is high enough to commit to building — or until the evidence kills the initiative, which is a win, not a failure.

Bump the iteration number and keep the prior canvas; the trail of what you believed and learned is part of the insurance policy.

References

Template: template.md. Worked example: examples/sample.md.

Publishing

Publish the finished canvas as a product document, following whatever product-document convention this repo documents for agents. Where the repo has no such convention, save it as a markdown file in the working directory and report the path.