lean-ux-canvas

## Purpose

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.

## Key Concepts

### What is the Lean UX Canvas?

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:
- What problem exists (and why it matters now)
- What measurable outcomes indicate success
- Who we're solving for
- What assumptions we're making
- What we need to learn first
- What experiments will test those assumptions

**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.

---

### Canvas Structure (8 Boxes)

**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):**

1. **Business Problem** — What changed in the world that created a problem worth solving?
2. **Business Outcomes** — What measurable behavior change indicates success?
3. **Users** — Which persona(s) should you focus on first?
4. **User Outcomes & Benefits** — Why would users seek this? What benefit do they gain?
5. **Solutions** — What features/initiatives might solve the problem and meet user needs?
6. **Hypotheses** — Testable assumptions combining boxes 2-5 (If/Then format)
7. **What's Most Important to Learn First?** — The single riskiest assumption right now
8. **What's the Least Work to Learn Next?** — Smallest experiment to validate/invalidate that assumption

---

### Why This Works

**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.

---

### Key Distinctions (Avoid Confusion)

**Box 2 (Business Outcomes) vs. Box 4 (User Outcomes):**
- **Box 2:** Measurable **behavior change** (retention rate, time on site, average order value)
- **Box 4:** **Goals, benefits, emotions, empathy** (save money, get promoted, spend time with family)

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.

---

### Anti-Patterns (What This Is NOT)

- **Not a feature list:** Solutions are ideas to test, not a backlog
- **Not a project plan:** Canvas frames learning, not delivery timelines
- **Not a replacement for strategy:** Canvas executes strategy; it doesn't create it
- **Not a one-time exercise:** Re-visit as you learn; update assumptions

---

### When to Use This

✅ **Use this when:**
- Starting a new product initiative or feature
- Reframing an existing project (suspect you're building the wrong thing)
- Aligning cross-functional teams on assumptions and experiments
- Planning discovery sprints or MVPs
- Stakeholders are solution-driven ("we need to build X") and you need to expose assumptions

❌ **Don't use this when:**
- Problem and solution are already validated (move to execution)
- Tactical bug fixes or technical debt (no learning needed)
- Stakeholders have committed to a solution regardless of evidence (address alignment first)

---

### Facilitation Source of Truth

Use [`workshop-facilitation`](../workshop-facilitation/SKILL.md) as the default interaction protocol for this skill.

It defines:
- session heads-up + entry mode (Guided, Context dump, Best guess)
- one-question turns with plain-language prompts
- progress labels (for example, Context Qx/8 and Scoring Qx/5)
- interruption handling and pause/resume behavior
- numbered recommendations at decision points
- quick-select numbered response options for regular questions (include `Other (specify)` when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

## Application

Use `template.md` for the full fill-in structure.

This interactive skill wa