メニュー
Guide teams through Lean UX Canvas v2. Use when framing a business problem, surfacing assumptions, and defining what to learn next.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Evaluate acquisition channels using unit economics, customer quality, and scalability. Use when deciding whether to scale, test, or kill a growth channel.
Assess whether your product work is AI-first or AI-shaped. Use when evaluating AI maturity and choosing the next team capability to build.
Diagnose SaaS business health across growth, retention, efficiency, and capital. Use when preparing a business review or prioritizing urgent fixes.
Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.
Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.
Create a customer journey map across stages, touchpoints, actions, emotions, and metrics. Use when diagnosing a broken experience or aligning a team on the full customer flow.
SOC 職業分類に基づく
| name | lean-ux-canvas |
| description | Guide teams through Lean UX Canvas v2. Use when framing a business problem, surfacing assumptions, and defining what to learn next. |
| intent | Guide product managers through creating **Jeff Gothelf's Lean UX Canvas (v2)**—a one-page facilitation tool that frames work around a **business problem to solve**, not a **solution to implement**. Use this to align cross-functional teams around core assumptions, craft testable hypotheses, and ensure learning happens every sprint by exposing gaps in understanding (problem, users, value, and why the solution should work). |
| type | interactive |
| best_for | ["Framing a business problem before solutioning","Surfacing assumptions in a cross-functional workshop","Turning a vague initiative into hypotheses and learning goals"] |
| scenarios | ["Help me run a Lean UX Canvas workshop for onboarding drop-off","Use Lean UX Canvas to frame a new AI product idea","We have a business problem but too many assumptions. Run a Lean UX Canvas session."] |
Guide product managers through creating Jeff Gothelf's Lean UX Canvas (v2)—a one-page facilitation tool that frames work around a business problem to solve, not a solution to implement. Use this to align cross-functional teams around core assumptions, craft testable hypotheses, and ensure learning happens every sprint by exposing gaps in understanding (problem, users, value, and why the solution should work).
This is not a roadmap or feature list—it's an "insurance policy" that turns assumptions into experiments before committing to full development. The canvas shifts conversations from outputs to outcomes and ensures teams build the right thing, not just build things right.
The Lean UX Canvas (v2) is a structured, one-page template designed to help teams frame their work around a business problem, not a solution. It aligns cross-functional teams on:
Origin: Created by Jeff Gothelf, author of Lean UX (O'Reilly, 2013). Version 2 was released to improve clarity around business vs. user outcomes.
Key Insight: The canvas acts like an insurance policy—it exposes gaps in understanding before you build, ensuring you don't waste sprints on the wrong thing.
Layout (3 columns × 3 rows):
┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │ │ 2. Business Outcomes │
│ │ │ │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users │ (tall box │ 4. User Outcomes │
│ │ spanning │ & Benefits │
├─────────────────────┤ rows 1-2) ├───────────────────────┤
│ 6. Hypotheses │──────────────┤ 8. Least Work / │
│ │ 7. Learn │ Experiments │
│ │ First │ │
└─────────────────────┴──────────────┴───────────────────────┘
The 8 Boxes (fill in this order):
Problem-First, Not Solution-First: Starts with "what changed in the world?" not "we should build X." This prevents solution-driven thinking.
Assumption-Driven: Makes hypotheses explicit before building. Every discipline surfaces their risks (technical feasibility, user value, business viability).
Experiment-Focused: Tests assumptions before committing resources. Small experiments beat big bets.
Cross-Functional Alignment: Shared canvas creates common language. Everyone sees the same gaps in understanding.
Box 2 (Business Outcomes) vs. Box 4 (User Outcomes):
Box 2 is metrics. Box 4 is human.
Solutions (Box 5) Are Hypotheses, Not Commitments: List candidate solutions (features, policies, even business model shifts). You're not committing to build all of them—you're exploring the solution space.
Hypotheses (Box 6) Are Testable: Use the template: "We believe [business outcome] will be achieved if [user] attains [benefit] with [solution]." Each hypothesis focuses on one solution.
✅ Use this when:
❌ Don't use this when:
Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
Other (specify) when useful)This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
Use template.md for the full fill-in structure.
This interactive skill walks through 8 adaptive questions (one per canvas box) in sequence. At each step, the agent offers guidance, examples, and options to help you fill the box correctly.
Agent asks:
Before we fill out the Lean UX Canvas, let's gather context. Please share:
Business Context:
User Context:
You can paste:
Agent asks:
What problem does the business have that you are trying to solve?
Describe:
Good examples:
Bad examples (too vague):
Agent offers 3 options:
skills/problem-statement/SKILL.md or skills/problem-framing-canvas/SKILL.md first]User response: [Selection or description]
Agent validates: Does this describe what changed and why it creates a problem? If not, ask clarifying questions.
Agent asks:
How will you know you solved the business problem? What will you measure?
Focus on measurable behavior change (leading indicators welcome). Ask yourself: "What will people be doing differently if the solution works?"
Examples of business outcomes:
Important: This is Box 2 (behavior change), not Box 4 (user benefits/empathy). Metrics go here. Emotions go in Box 4.
Agent offers 3 options:
User response: [Selection or description]
Agent validates: Are these measurable? Observable? Do they indicate behavior change (not just "increase revenue")?
Agent asks:
What types (i.e., personas) of users and customers should you focus on first?
Consider:
Why this matters: Teams tend to shortcut here ("everyone"). The canvas wants a shared vision of the user—and it's not always "the customer."
Examples:
Agent offers 3 options:
skills/proto-persona/SKILL.md or paste persona]skills/proto-persona/SKILL.md component skill]User response: [Selection or description]
Agent validates: Is this specific enough to imagine a real person? Or is it too broad ("all users")?
Agent asks:
Why would your users seek out your product or service? What benefit would they gain? What behavior change can we observe that tells us they've achieved their goal?
Focus on goals, benefits, emotions, empathy—not metrics (those go in Box 2).
Examples of user outcomes & benefits:
Why this matters: This is the empathy box. It's about human motivation, not just behavior change.
Agent offers 3 options:
skills/jobs-to-be-done/SKILL.md or skills/discovery-interview-prep/SKILL.md]User response: [Selection or description]
Agent validates: Does this explain why the user cares (not just what they'll do)?
Agent asks:
What can we make that will solve our business problem and meet the needs of our customers at the same time?
List features, initiatives, policies, systems, or even business model shifts that might work. Encourage a wide solution space: big/small, innovative, "weird," and non-technical solutions.
Examples:
Important: These are hypotheses, not commitments. You're exploring options, not committing to build everything.
Agent offers 3 options:
User response: [Selection or description]
Agent validates: Do you have at least 3 candidate solutions? (More options = better hypotheses later)
Agent asks:
Now let's create testable hypotheses by combining assumptions from Boxes 2-5.
Use this template:
We believe that [business outcome from Box 2] will be achieved if [user from Box 3] attains [benefit from Box 4] with [solution from Box 5].
Rules:
Example:
We believe that increasing mobile checkout conversion rate from 45% to 60% will be achieved if mobile-first millennials (25-35) attain faster, friction-free checkout with one-tap Apple Pay integration.
Agent offers:
Based on your inputs, here are suggested hypotheses (one per solution from Box 5):
Options:
User response: [Selection or description]
Agent validates: Does each hypothesis clearly state what you believe will happen if the solution works?
Agent asks:
For each hypothesis from Box 6, identify its riskiest assumptions. Then determine the riskiest one right now.
Types of risk:
Hint: Early on, focus risk on value more than feasibility (most of the time). Don't build something users don't want, even if it's technically feasible.
Agent offers:
Based on your hypotheses, here are the riskiest assumptions:
Which is the riskiest right now?
Options:
User response: [Selection]
Agent records: This is the assumption we'll test first.
Agent asks:
Design an experiment to validate or invalidate the riskiest assumption (from Box 7) as fast as you can.
Examples of experiment types:
Reminder: Experiment design is an art. The canvas nudges you to do it—expect to iterate on the experiment design separately.
Agent offers:
Based on your riskiest assumption, here are experiment options:
Which experiment will you run?
User response: [Select one or describe custom experiment]
Agent validates: Is this the smallest test that can validate/invalidate the assumption? (If it takes >2 weeks, it's too big—break it down.)
Agent summarizes:
Here's your completed Lean UX Canvas (v2):
┌─────────────────────────────────────────────────────────────┐
│ Lean UX Canvas (v2) │
│ Initiative: [Title] │
│ Date: [Today's date] │
│ Iteration: 1 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────┬──────────────┬───────────────────────┐
│ 1. Business Problem │ │ 2. Business Outcomes │
│ [Your input] │ │ [Your input] │
│ │ │ │
├─────────────────────┤ 5. Solutions ├───────────────────────┤
│ 3. Users │ │ 4. User Outcomes │
│ [Your input] │ [Your input] │ & Benefits │
│ │ │ [Your input] │
├─────────────────────┤──────────────┼───────────────────────┤
│ 6. Hypotheses │ 7. Learn │ 8. Experiments │
│ [Your input] │ First │ [Your input] │
│ │ [Your input] │ │
└─────────────────────┴──────────────┴───────────────────────┘
Next steps:
Agent asks:
Would you like me to:
skills/discovery-interview-prep/SKILL.md for customer interviews)?See examples/sample.md for full Lean UX Canvas examples.
Mini example excerpt:
**Box 1:** Mobile checkout conversion is 15% lower than desktop
**Box 2:** Increase mobile conversion from 45% to 60%
**Box 8:** Wizard-of-Oz test with one-tap checkout
Failure Mode: Box 1 says "We need to build X" instead of describing what changed.
Consequence: You build the solution someone already decided on, without validating the problem exists.
Fix: Ask: "What changed in the world? Why is this a problem now (vs. 6 months ago)?"
Failure Mode: Box 2 says "Increase revenue" or "Make users happy."
Consequence: No way to measure success; can't tell if experiments worked.
Fix: Define measurable behavior change. "Increase average order value from $50 to $75" or "Reduce support tickets by 30%."
Failure Mode: Box 3 says "All users" or "Everyone."
Consequence: Can't design targeted experiments; waste time on personas who won't adopt.
Fix: Pick one persona to start. You can expand later.
Failure Mode: Putting emotions in Box 2 and metrics in Box 4 (or vice versa).
Consequence: Misaligned hypotheses; unclear success criteria.
Fix: Box 2 = Behavior change (metrics). Box 4 = Goals, benefits, emotions (empathy).
Failure Mode: Listing one feature because stakeholders already decided.
Consequence: No exploration of alternatives; can't test which solution is best.
Fix: Force yourself to list 3+ solutions. Ask: "What else could solve this problem?"
Failure Mode: "We'll just build it and see what happens."
Consequence: Waste weeks/months building the wrong thing.
Fix: Design smallest experiment first. If you can't think of one, use skills/pol-probe-advisor/SKILL.md to choose a validation method.