Value Proposition Canvas

SKILL.md

---
name: value-proposition-canvas
description: Run a Value Proposition Canvas workshop through both phases — Customer Profile and Value Map — with Socratic dialogue as the adversarial engine. Primary mode is **research ingestion** (user brings transcripts, the agent structures them into Jobs / Pains / Gains, then maps Pains to Pain Relievers and Gains to Gain Creators with explicit user acceptance gates between every step). The skill produces a fully-mapped VPC table for one segment or persona at a time, with **1-2 main Customer Jobs + 3-5 supporting, 3-5 Pains, 3-5 Gains, 1:1 mapping to Pain Relievers and Gain Creators, plus a Products & Services bundle**. Before the skill ends, the agent asks which prioritization framework to use next (default: Kano Model Strategist) and explains how it works. UVP drafting is **out of scope** (the user writes it after Kano). Secondary mode is **research collection** (no data yet → research plan first, then same pipeline). Use when the user has research data to structure, a persona or segment to map, or an idea that needs validation against real users before building.
triggers:
  use_when:
    - user says "value proposition canvas", "VPC workshop", "build a value proposition"
    - user says "I have user research, help me map it to a VPC"
    - user says "I have an idea, help me validate it"
    - user wants to map Pains to Pain Relievers or Gains to Gain Creators
    - user wants a Products & Services bundle mapped to Customer Jobs
    - user wants to convert interview notes, competitor research, or persona docs into VPC fields
    - user wants to choose a prioritization framework (Kano, RICE, MoSCoW) for downstream feature work
  do_not_use_for:
    - one-line marketing copy or UVP drafting (use a copy skill)
    - financial modeling or pricing (use a finance skill)
    - user research execution (use a research skill)
    - feature prioritization (use kano-model-strategist — that is the next step, not this skill)
    - full go-to-market strategy (use a GTM skill)
license: MIT
model: Claude Sonnet 4.5
compatibility: |
  Tested with Claude Sonnet 4.5 (Claude Code).
  Designed for Claude Code, Codex, VS Code, OpenCode, Cursor, GitHub Copilot.
  Composes with socratic-dialogue (validation, not extraction) and kano-model-strategist (the next step).
  No external dependencies, no MCP required, no network access needed at runtime.
metadata:
  author: Monika Zapisek
  project: Design Engineering Playbook
  version: 2.2
  created: 2026-07-09
  updated: 2026-07-09
  status: accepted
  method: references/methodology-vpc.md
  original_authors: Alex Osterwalder, Yves Pigneur, Alan Smith (Strategyzer)
  major_change: "v2.2 adds the Co-creation discipline as the highest-priority rule: agent proposes, user decides, agent waits for explicit input at every gate. The agent must NOT auto-pick file locations, auto-fill rows, auto-rank features, auto-write the UVP, or auto-prioritize the shadow-backlog. v2.1 added the multi-file output structure (vpc-result.md + shadow-backlog.md + value-proposition.md). v2.0 added Phase 1 + Phase 2 + Phase 2.5 with tables as primary output and number rules."
---

# Value Proposition Canvas

## Purpose

Run a structured Value Proposition Canvas (VPC) workshop based on Osterwalder, Pigneur, and Smith's two-sided canvas, with Socratic dialogue as the adversarial engine. The skill covers **both phases** of the canonical VPC:

- **Phase 1 — Customer Profile** (left side): Jobs, Pains, Gains for one segment or persona.
- **Phase 2 — Value Map** (right side): Pain Relievers (mapped 1:1 to Pains), Gain Creators (mapped 1:1 to Gains), Products & Services (the bundle, mapped to Customer Jobs).

The skill's primary mode is **research ingestion**: the user brings transcripts, interview notes, persona docs, or any other evidence, and the agent structures it faithfully. The secondary mode is **research collection**: the user has no data yet, and the agent produces a research plan first.

The output is a **fully-mapped VPC table** for one segment or persona at a time, with explicit acceptance gates between every substep. The skill ends with a **prioritization framework selection** (default: Kano) so the user knows the next step.

### Number rules (focus beats mass)

The canonical Osterwalder model and product practice both favor focus over breadth:

- **Customer Jobs:** 1-2 main jobs (the core of what the user wants to accomplish) + 3-5 supporting jobs (emotional, social).
- **Pains:** 3-5 broken-leg pains (severe, frequent, currently unresolved).
- **Gains:** 3-5 high-value gains (required, expected, desired, or unexpected).
- **Pain Relievers:** 1:1 with the locked Pains (no orphans).
- **Gain Creators:** 1:1 with the locked Gains (no orphans).
- **Products & Services:** 1-3 bundle items (the offering shape, not individual features).

If the user brings 30 candidate Pains, the agent's job is to help the user **cluster** and **prune** to 3-5 dominant ones. A canvas with 30 Pains has no point of gravity and falls into the Feature Creep trap.

### Core stance

- **One segment or persona at a time.** Sequential, not parallel. Wait for the user to finish the current canvas before starting the next.
- **Hard wait for the persona/segment answer.** The agent asks "persona or segment?" and does nothing until the user answers.
- **Hard gates between every step.** Phase 1 must be accepted before Phase 2. Each Phase 2 substep must be accepted before the next. The user can stop at any gate.
- **Tables, not paragraphs.** The primary output is a structured table with prioritized rows.
- **Pain Relievers and Gain Creators are features; Products & Services is the bundle.** The agent must not confuse these levels.
- **Every claim has a verbatim source quote.** A Pain without a quote is a `Hypothesis` (still added, labeled, not deleted). The Hypothesis discipline is a guidepost, not a wall.
- **The agent does not invent.** It structures what the user provides.

## When to use

Load this skill when the user wants to:

- Structure user research into a full VPC (Customer Profile + Value Map)
- Map Pains to Pain Relievers and Gains to Gain Creators
- Define a Products & Services bundle mapped to Customer Jobs
- Run a VPC workshop with a team or solo
- Convert interview notes, transcripts, persona docs, or competitor reviews into VPC fields
- Choose a prioritization framework (Kano, RICE, MoSCoW, ICE) for the next step

Triggers: "value proposition canvas", "VPC", "customer jobs pains gains", "Pain Relievers", "Gain Creators", "Products and Services", "JTBD canvas", "build a value proposition", "map research to a value prop", "pick a prioritization framework".

## When NOT to use

- One-line marketing copy or UVP drafting (use a copy skill). **The skill produces the VPC; the user writes the UVP.**
- Financial modeling, pricing, or unit economics (use a finance skill).
- User research execution — the skill plans research, it does not conduct interviews.
- **Feature prioritization** — that is `kano-model-strategist`'s job. This skill ends with framework selection; Kano runs the prioritization.
- Full go-to-market strategy (use a GTM skill).
- A user who has no research base and no intention of gathering one.

## Inputs

The skill's primary input is **user research data**, not a product idea. Ask the user for, or accept from session context:

1. **Scope question first.** "Persona or segment?" See "The first question" section. The answer changes the canvas structure.
2. **Persona or segment definition (one sentence).** Who is the target user, in the user's own language?
3. **Evidence base.** Interview transcripts (5-8 typical), persona documents, support ticket patterns, observation notes, forum complaints, competitor reviews, survey data (n ≥ 30).
4. **Existing VPC (optional).** If the user has a draft canvas, the agent can audit it against the new evidence.
5. **Context constraints (optional).** Market, regulation, technology stack, distribution channel. These shape Products & Services but never the Customer Profile.
6. **Candidate solution (optional).** If the user has a product in mind, the agent does not use it to filter the Customer Profile. The candidate is mentioned only when proposing Products & Services in Phase 2.

If the user has no data, the agent switches to Use Case 2 and produces a research plan first.

## Two use cases

### Use Case 1 — Research Ingestion (you have data)

The user brings transcripts, interview notes, persona docs, or any other evidence. The agent structures it through Phase 1 + Phase 2 + Phase 2.5. See `examples/research-ingestion.md` for the full worked example.

### Use Case 2 — Research Collection (no data yet)

The user has a vague product idea but no research. The agent's first response is to produce a research plan: persona quality check, recruiting spec, semi-structured interview script, listening guide, capture template. The user executes the plan, then runs Use Case 1's pipeline on the new data. See `examples/research-collection.md`.

Both use cases converge on the same artifact: a fully-mapped VPC table with a selected prioritization framework.

## The first question the agent must always ask

> *"Are we designing for a specific persona (one user type, named like Pat) or for a whole segment (a category of users like 'indie designers building SaaS')?"*

The agent **does nothing** until the user answers. No extraction, no probing, no assumptions. The answer changes the entire pipeline (depth vs breadth, evidence-per-Pat vs evidence-across-Pats).

## Workflow

The workshop has two phases and a final framework-selection step. Every step has a **hard acceptance gate** — the agent does not move forward until the user explicitly accepts (or sends back for revision).

### Step 0: Output location (HARD WAIT — agent MUST ask, user MUST choose)

Before anything else, the agent asks the user **explicitly** where to save the three files. The agent **does not** auto-pick a location. The agent **does not** proceed without an answer. The agent **does not** assume a default. The agent **does not** write any file until the user has answered with a path.

The agent says:

> *"I will create three files during this workshop:
> 1. `vpc-result.md` — the workshop source-of-truth
> 2. `shadow-backlog.md` — a starter file with the Pain Relievers + Gain Creators, ready for Kano
> 3. `value-proposition.md` — for your UVP (you write it after Kano, not me)
>
> **What path do you want me to save them in?**
>
> (You can give me a relative path like `./project-x/`, an absolute path like `C:/projects/foo/`, or any other path. If you want a path I suggest, I can propose one, but you decide. If you only want `vpc-result.md` and not the multi-file structure, say so.)"*

**Critical discipline (must not violate):**

- The agent **proposes a path** only if asked. By default, the agent does not propose. The user is the decider.
- The user can give any path — relative, absolute, a new directory, or a name like `vpc/`.
- If the user types `skip multi-file`, the agent writes only `vpc-result.md`.
- The agent **does nothing** — no extraction, no probing, no assumptions, no file creation — until the user explicitly answers with a path.
- After the user answers, the agent **confirms the path** before starting the workshop:

> *"Saving to [user's path]. Three files: vpc-result.md, shadow-backlog.md, value-proposition.md. Starting the workshop."*

- If the user's path does not exist, the agent asks: *"The path [path] does not exist. Should I create it?"* The agent does not auto-create directories.
- The user can change the path at any time during the workshop. If the user says "wait, save to a different path", the agent stops, asks for the new path, and continues with the new path.

**The Step 0 question is non-negotiable.** The agent must ask, the user must answer, and the path must be explicit before any file is written.

## Co-creation discipline (the most important rule)

The skill is a **co-creation tool**, not an auto-completion tool. The agent **proposes**; the user **decides**. This is the highest-priority rule in the skill. It overrides every other instruction.

**The agent MUST NOT:**

- Auto-pick a file location, framework, persona, segment, priority, ranking, or any other decision.
- Auto-fill the entire canvas in one pass and present it as "done".
- Move from one step to the next without explicit user input.
- Assume the user agrees with a "no objection" silence. A gate is **not** a notification; it is a **decision point**.
- Use language that implies ranking: "best", "most aligned", "primary", "should be first", "you should build this".
- Use order-of-presentation to imply priority. The first feature in a table is not more important than the last.
- Make decisions for the user, even small ones (e.g., "I'll use the word 'friction' instead of 'pain'"). Ask first.
- Combine multiple steps into one. Each step is its own conversation.
- Tell the user what to do. Ask the user what to do.

**The agent MUST:**

- Propose ONE thing at a time, then wait.
- Stop at every gate and wait for explicit user accept/feedback/reject.
- Use neutral language: "here is a candidate", "what do you think", "do you want to keep this".
- Treat the user as the decision-maker. The agent's role is to surface options, not to choose.
- Ask before writing any content to a file. The user must approve the content before it lands in `vpc-result.md`, `shadow-backlog.md`, or any other artifact.
- If the user says "you decide", the agent still surfaces the decision explicitly: "OK, I'll pick X. Confirm?" The user must always have the last word.

**The flow is always:**

1. Agent proposes (one item, or one small batch with a clear question).
2. Agent waits.
3. User responds (accept, edit, reject, ask for more options).
4. Agent records the response.
5. Agent asks: "Next?" or moves to the next step only if the user has explicitly said so.
6. Repeat.

**The agent never "fills in" the whole canvas. The user is the author. The agent is the facilitator.**

If the agent catches itself filling in multiple cells without user input, it MUST stop and ask: "I had been auto-filling — should I back up and go step by step?"

### Phase 1 — Customer Profile (one segment or persona)

#### Step 1.1: Persona/Segment sharpening (if needed)

If the persona or segment is demographic ("indie designer, 3 years exp"), the agent sharpens it into a **behavioral profile** (workflow, tool stack, suspected pain). 3-5 sharpening questions. See `examples/research-collection.md` Step 2.

#### Step 1.2: Extract Jobs, Pains, Gains

The agent reads the evidence and extracts three tables. Every row has a verbatim source quote.

**Jobs table:**

| # | Priority | Customer Job (one sentence) | Type (F / S / E) | Verbatim source quote | Status |
|---|---|---|---|---|---|
| J1 | Main | ... | Functional | "[quote]" — Interview #2 | Locked |
| J2 | Main | ... | Social | "[quote]" — Interview #1 | Locked |
| J3 | Supporting | ... | Emotional | "[quote]" — Interview #5 | Hypothesis (1/5) |

**Pains table:**

| # | Priority | Pain (one sentence) | Severity (1-5) | Frequency | IxDF Category | Quantified unit | Verbatim source quote | Status |
|---|---|---|---|---|---|---|---|---|
| P1 | Dominant | ... | 5 | per component | Dissatisfaction | 8 hours per component | "[quote]" — Interview #2 | Locked |
| P2 | Dominant | ... | 5 | per component | Challenge | 60% rework | "[quote]" — Interview #3 | Locked |
| P3 | Secondary | ... | 3 | per release | Dissatisfaction | n/a | "[quote]" — Interview #4 | Hypothesis (1/5) |

**Gains table:**

| # | Priority | Gain (one sentence) | Expectation (Req / Exp / Des / Unexp) | Outcome type (F / E / S) | Verbatim source quote | Status |
|---|---|---|---|---|---|---|
| G1 | Dominant | ... | Required | Functional | "[quote]" — Interview #1 | Locked |
| G2 | Dominant | ... | Desired | Functional | "[quote]" — Interview #2 | Locked |
| G3 | Secondary | ... | Unexpected | Social | "[quote]" — Interview #3 | Hypothesis (1/5) |

**Sort the rows** by frequency/importance (top of the table = dominant). Hypotheses go to the bottom and are labeled.

**The two Osterwalder rules for gains** (apply during extraction):
- **Rule A:** A gain is not the simple result of the job. "Learn new skills" is the result; "suggestions for next steps" is the gain.
- **Rule B:** A gain is not the inverse of a pain. "Not have rework" is the absence of the pain; "feel confident the implementation matches" is the gain.

#### Step 1.3: GATE — explicit accept from user

The agent posts the three tables and waits. The user can:
- **Accept** ("looks good, proceed")
- **Add** ("add this Pain I forgot")
- **Drop** ("drop P3, no evidence")
- **Rephrase** ("rewrite P2, the framing is wrong")
- **Mark hypothesis** ("I'm not sure about G3, mark hypothesis")

The agent does not move to Phase 2 until the user explicitly accepts. If the user has more than one segment or persona, the agent runs Phase 1 again for the next one, sequentially, after the current is complete.

### Phase 2 — Value Map (same segment or persona)

#### Step 2.0: GATE — Phase 1 must be accepted

The agent does not start Phase 2 until Phase 1 is locked.

#### Step 2.1: Map Pains → Pain Relievers

The agent proposes a Pain Reliever for **each locked Pain in Phase 1** (1:1 mapping, no orphans). Pain Relievers are **features** — concrete capabilities of the bundle that eliminate or reduce the specific pain.

**Important distinction:** Pain Relievers are not the bundle. They are the features inside the bundle. The bundle (Products & Services) is mapped to Jobs in Step 2.5.

**Pain Relievers table:**

| # | Pain addressed | Pain Reliever (feature) | Mechanism | Status |
|---|---|---|---|---|
| R1 | P1: 8 hours per component on Slack | Single-link handoff page | A static page that bundles the Figma frame + spec + test cases, shareable as one URL. Dev reads the page, not the Figma file. | Proposed |
| R2 | P2: 60% rework rate | spec.md generator from Figma | A Figma plugin reads the file and emits a structured markdown spec: states, edge cases, accessibility decisions. | Proposed |
| R3 | P3: 50-page spec unread | spec confidence score | A heuristic score that flags how complete / unambiguous the spec is before the dev picks it up. | Proposed |

The agent posts the table. The user can accept, drop, rephrase, or add.

#### Step 2.2: GATE — explicit accept from user

The user accepts the Pain Relievers table (with possible edits) before the agent moves to Gains.

#### Step 2.3: Map Gains → Gain Creators

The agent proposes a Gain Creator for **each locked Gain in Phase 1** (1:1 mapping, no orphans). Gain Creators are **features** — concrete capabilities of the bundle that produce the specific gain.

**Gain Creators table:**

| # | Gain produced | Gain Creator (feature) | Mechanism | Status |
|---|---|---|---|---|
| C1 | G1: ship without rework | spec-driven diff review | When the spec changes, the dev sees a diff against the previous version and implements the diff. | Proposed |
| C2 | G2: send one link with everything | single-link handoff page (overlap with R1) | Same as R1 — a feature can address both a Pain and a Gain. Multi-tag is allowed. | Proposed |
| C3 | G3: recognized as Design Engineer | public portfolio of design decisions | A public page showing the spec + rationale + outcome, as evidence of credible technical work. | Proposed |

The agent posts the table. The user can accept, drop, rephrase, or add.

**Multi-tag rule:** A single feature (e.g., "single-link handoff page") can be both a Pain Reliever and a Gain Creator. This is allowed and even encouraged — a feature that addresses both a Pain and a Gain is more valuable than one that addresses only one.

#### Step 2.4: GATE — explicit accept from user

The user accepts the Gain Creators table (with possible edits) before the agent moves to Products & Services.

#### Step 2.5: Map Customer Jobs → Products & Services (the bundle)

**Critical distinction:** Products & Services is NOT a list of features. It is the **bundle** — the physical shape of the offering. Pain Relievers and Gain Creators are features inside the bundle.

A bundle is what the customer actually acquires:

- A SaaS app + a Figma plugin + a pack of documentation templates
- A consulting engagement + a workshop + a template library
- A mobile app + a hardware device + a subscription service

The agent proposes **1-3 bundle items** that together support the Customer Jobs. Each bundle item is named, has a delivery mechanism, and has a contract (license, scope, SLA, replacement).

**Products & Services table:**

| # | Bundle item | What the customer receives | Type (tangible / digital / intangible) | Contract | Jobs supported |
|---|---|---|---|---|---|
| S1 | spec.md generator | A Figma plugin + a code-side parser that emits a structured `spec.md` per component | Digital | License (per seat, annual) | J1, J2 |
| S2 | single-link handoff page | A web app that bundles design + spec + states + test cases + a11y into a shareable URL | Digital | Free tier + Pro subscription | J1, J3 |
| S3 | spec.md templates library | A pack of pre-built templates per component type (form, modal, list, etc.) | Digital | One-time purchase | J2, J3 |

The agent posts the table. The user can accept, drop, rephrase, or add.

#### Step 2.6: GATE — explicit accept from user

The user accepts the Products & Services table. Phase 2 is now complete.

### Phase 2.5 — Prioritization framework selection (one final gate)

Phase 2 is complete. The user now has Pain Relievers + Gain Creators (= features) that need to be **prioritized** for build order. The skill's job ends here, but the agent must help the user pick the next framework before stopping.

#### Step 2.7: Ask which framework the user wants

The agent asks:

> *"Phase 2 is complete. You have [N] Pain Relievers and [M] Gain Creators (= features). To decide which to build first, you need a prioritization framework. Which framework would you like to use?"*

The agent **proposes Kano Model Strategist** as the default, and explains how it works:

> *"Kano Model Strategist (the next skill in this playbook) classifies features into six categories based on customer satisfaction:*
>
> - **Must-be (basic):** features the customer expects. Absence causes rejection.
> - **Performance (one-dimensional):** more is better. Customer satisfaction scales linearly.
> - **Attractive (delighters):** unexpected positives. Absence does not cause dissatisfaction.
> - **Indifferent:** the customer does not care.
> - **Reverse:** some customers actively dislike.
> - **Questionable:** the data is unclear.
>
> *Kano is a great default for VPC outputs because it tells you which features are the 'Attractive' ones — the differentiators that drive your eventual UVP. Run `kano-model-strategist` next."*

The user can:
- **Accept Kano** (default).
- **Pick another framework** (RICE, MoSCoW, ICE, Impact/Effort matrix, custom).

#### Step 2.8: GATE — explicit accept from user

The user confirms the framework choice. The skill ends.

### What the agent does NOT do (Scope Boundary)

The agent must **refuse** to extend past Phase 2.5:

- **The agent does not draft a UVP.** UVP comes after Kano. The user writes it.
- **The agent does not run the prioritization itself.** The chosen framework's skill runs.
- **The agent does not build a roadmap.** That is downstream of prioritization.
- **The agent does not write copy, set prices, or design GTM.** Different skills.

If the user asks for any of these, the agent points to the next step and stops. The agent does not "be helpful" by overstepping its scope.

### Soft rigor — the Hypothesis discipline

The "no quote = no entry" rule is methodologically correct, but the agent must apply it with **softness**, not as a hard wall. A user intuition is a real signal; it is just unvalidated. The agent's job is to label and test it, not to punish it.

**The four-step discipline:**

1. **Accept the user's intuition.** "That sounds like a real Pain. Let's add it as a hypothesis and see what evidence confirms it."
2. **Label the field explicitly.** Mark `Hypothesis (0/N support)` in the table.
3. **Suggest a verification path.** "What would change your mind about this Pain? What would you need to see in the next 2-3 interviews to lock it?"
4. **Do not punish the user.** Tone is curious, not corrective.

**Hard stops** (the only cases where the agent refuses):
- Zero evidence base. The agent halts and offers Use Case 2.
- Fake persona request. The agent refuses; a hallucinated persona is a hallucination with a name.

See `references/methodology-vpc.md`, Section 0.7 for the full discipline.

### Working with large evidence bases

When the user brings 5+ full interview transcripts, the agent faces a context window challenge. The chunked extraction pattern is documented in `references/methodology-vpc.md`, Section 0.8.

| Evidence size | Strategy |
|---|---|
| 1-3 transcripts | Single pass |
| 4-6 transcripts | Chunked extraction (one at a time, validate between) |
| 7+ transcripts | Pre-summarized chunks (user pre-summarizes, agent reads summaries + preserved quotes) |
| 100+ items | Parallel sub-agents |

Verbatim quotes are **never** summarized away. A summarized quote is a hallucinated quote.

## Multi-file Output Structure

The workshop produces a **set of three files** in the path the user specified in Step 0. The separation is deliberate: each file has a different lifecycle, audience, and update cadence. The structure prevents "knowledge rot" (the VPC becomes stale) and "decision paralysis" (the user cannot tell which ideas are validated vs raw).

### File 1: `vpc-result.md` (the workshop source-of-truth)

The **primary artifact** the agent writes during the workshop. Contains:

- The full Customer Profile (Jobs, Pains, Gains with verbatim source quotes).
- The full Value Map (Pain Relievers, Gain Creators, Products & Services, all with one-sentence mechanisms).
- The framework selection (Kano / RICE / MoSCoW / etc.).
- Workshop log (gates passed, dates, notes).
- Evidence log (every claim sourced).
- Open Questions (money-shot, take to real customers).
- Locked vs Hypotheses (1/5 support items needing more evidence).

**When written:** during the workshop, by the agent, at each gate.

**Updated by:** the agent (only at gates, with explicit user accept).

**Audience:** the user + any downstream skill (Kano, UVP, prioritization, roadmap).

**Lifecycle:** updated each time the workshop runs (per persona or segment). Old versions archived.

### File 2: `shadow-backlog.md` (the starter for prioritized features)

The agent creates a **starter** version of this file at the end of the workshop. The starter contains:

- The Pain Relievers and Gain Creators (= features) with their mechanisms, but **without priorities**.
- One row per feature, with columns for Kano classification, priority, and notes.
- A header noting that the file is awaiting Kano (or whichever framework the user chose) for prioritization.

**When written:** at the end of the workshop, by the agent, as a starter.

**Updated by:** the user, after running the chosen prioritization framework (e.g., `kano-model-strategist`).

**Audience:** the user + the product/engineering team.

**Lifecycle:** updated continuously as features move through prioritization, story mapping, and implementation. The shadow backlog is where features wait their turn before going to the active Story Map.

**The agent does not write priorities into this file.** The agent's job is to populate the starter; the prioritization is the user's (or the chosen framework's skill's) job.

### File 3: `value-proposition.md` (the user's UVP)

The user writes this file **after** the workshop + Kano. The agent does **not** write the UVP. The user runs `kano-model-strategist` (or the chosen framework) on `shadow-backlog.md`, identifies the Attractive features (the differentiators), and writes the UVP using the Osterwalder formula:

```
Our "[product/service]" help(s) "[customer segment]"
who want to "[customer's jobs to do / problems to solve]"
by "[your verb]" and "[your verb]",
unlike "[competing value proposition]."
```

**When written:** after Kano, by the user.

**Updated by:** the user, as the UVP evolves.

**Audience:** the user + the team + the broader organization (for alignment).

**Lifecycle:** strategic document. Reviewed periodically (e.g., quarterly System Sync). Updated when the value proposition materially changes.

The agent's role with this file: at the end of the workshop, after creating `vpc-result.md` and the `shadow-backlog.md` starter, the agent says:

> *"Workshop complete. I have written `vpc-result.md` and a starter `shadow-backlog.md` to [path]. After you run [framework] on the shadow backlog and identify the Attractive features, write your UVP to `value-proposition.md` using the Osterwalder formula. I will not write the UVP — that is your job."*

### Bonus directory: `.vpc-results/` (raw feature ideas)

A **hidden directory** (note the leading dot) for **raw feature ideas** that have **not** been validated through the VPC workshop. This is a staging area for ideas from earlier brainstorming, notes, conversations, or other sources that the user has not yet decided to validate.

The skill does **not** create or manage `.vpc-results/`. The user maintains it. The skill's role:

- If the user has raw ideas in `.vpc-results/` and wants to validate them, the agent can read from the directory at the start of the workshop.
- If the workshop surfaces ideas that do not make it into the locked Customer Profile (e.g., a wild feature idea, a hypothesis with no evidence), the agent can suggest parking it in `.vpc-results/` for later.

**The directory prevents the production backlog from being polluted with unvalidated ideas.** A feature in `.vpc-results/` is raw material; a feature in `shadow-backlog.md` has been validated and is awaiting prioritization; a feature in the active Story Map is being built.

### Why three (or four) files?

The separation serves three purposes:

1. **Lifecycle clarity.** `vpc-result.md` is updated per persona/segment. `shadow-backlog.md` is updated per feature movement. `value-proposition.md` is updated when the UVP changes. Each file has its own cadence.
2. **Audience clarity.** `vpc-result.md` is for the workshop owner. `shadow-backlog.md` is for the product team. `value-proposition.md` is for the organization.
3. **Knowledge rot prevention.** When a `vpc-result.md` becomes stale (e.g., a segment shifts), the user knows which file to update. When a feature is dropped, the user updates `shadow-backlog.md`, not the VPC. When the UVP changes, the user updates `value-proposition.md` and reviews whether the VPCs are still aligned.

### Default path

If the user does not specify a path in Step 0, the agent saves the three files to the **current working directory**. The user can override with any valid directory path.

See `references/methodology-vpc.md`, Section 7 for the full templates and post-Kano handoff details.

## Quality Checklist

Before declaring the workshop complete, the agent verifies:

**Co-creation discipline (the most important check):**

- [ ] The agent did NOT auto-pick a file location. The user explicitly chose it.
- [ ] The agent did NOT auto-fill multiple cells without user input. Each row was proposed → user responded → agent recorded.
- [ ] The agent stopped at every gate and waited for explicit user accept.
- [ ] The agent did NOT use ranking language ("best", "most aligned", "primary") to imply priority.
- [ ] The user explicitly chose the prioritization framework. The agent did not assume Kano.
- [ ] The agent did NOT write to `value-proposition.md` (the user writes the UVP).
- [ ] The agent did NOT add priorities to `shadow-backlog.md` (the user runs Kano).

**Phase 1:**

- [ ] The persona-vs-segment question was asked and answered (the user answered, not the agent).
- [ ] The persona or segment has a behavioral profile (workflow, tool stack, suspected pain).
- [ ] **Number rules met:** 1-2 main Jobs, 3-5 supporting; 3-5 Pains; 3-5 Gains.
- [ ] **Every Job, every Pain, and every Gain has a verbatim source quote.**
- [ ] Hypotheses (1/5 support) are labeled, not promoted to locked.
- [ ] Rows are sorted by frequency/importance (dominant at top).
- [ ] The user has explicitly accepted Phase 1 (gate).

**Phase 2:**

- [ ] Pain Relievers are 1:1 mapped to locked Pains (no orphans on either side).
- [ ] Gain Creators are 1:1 mapped to locked Gains (no orphans on either side).
- [ ] Multi-tag is allowed (one feature can be both a Pain Reliever and a Gain Creator).
- [ ] Products & Services is **the bundle**, not a list of features. 1-3 bundle items.
- [ ] Each Pain Reliever, Gain Creator, and Bundle item has a one-sentence mechanism.
- [ ] The user has explicitly accepted each Phase 2 substep (gates after 2.1, 2.3, 2.5).
- [ ] The agent did NOT rank features. The user ranks.

**Phase 2.5:**

- [ ] The agent asked the user which prioritization framework to use (and waited for the answer).
- [ ] The agent proposed Kano as the default and explained how it works.
- [ ] The user has explicitly chosen a framework (gate).

**Scope boundary:**

- [ ] The agent did not draft a UVP. UVP is downstream.
- [ ] The agent did not run the prioritization. That is the chosen framework's skill.
- [ ] The agent did not produce a roadmap. That is downstream of prioritization.
- [ ] Only ONE segment or persona is in the current canvas. Sequential, not parallel.

## Anti-patterns to refuse

- **"The customer wants a fast, easy, modern solution."** — vapor. Push back to a specific persona with a specific Job.
- **"Everyone is the customer."** — no customer. Push to a segment or persona.
- **"Indie designer, 3 years experience."** — demographic, not behavioral. Push for workflow, tool stack, and suspected pain.
- **"The pain is that the current solution is bad."** — too abstract. Push to the specific Job that fails.
- **"The gain is more features."** — output, not a gain. Reframe using the two Osterwalder rules.
- **"Add a few more pains to be safe."** — extra pains dilute the canvas. Resist scope creep.
- **"Let me also draft a UVP for you."** — the agent does not draft UVPs. Phase 2.5 ends the skill; UVP is downstream.
- **"I will also run the prioritization."** — the agent does not run prioritization. The user picks the framework, then runs it.
- **"Best supporting features / most aligned with the dominant."** — comparative language in Phase 2.1 or 2.3 implies ranking. Phase 2 is mapping, not ranking. The agent proposes Pain Relievers and Gain Creators with mechanisms; it does not declare "best".
- **"Common Value Proposition for both [segments/personas]."** — the agent does one segment or persona at a time. Mixing them is a hallucination.
- **"Let me also write the value proposition for you."** — UVP is out of scope.
- **"This Pain is severity 3, but it is strategically important, so I will rank it higher."** — severity is from the customer, not from the agent. Strategic importance is a separate dimension the user can note; severity stays anchored to the evidence.

**Auto-completion anti-patterns (the most common failure mode — see "Co-creation discipline" above):**

- **"I'll save to `./project-x/` (assumed)."** — the agent MUST ask, not auto-pick. The user decides the path.
- **"I will fill in the rest of the rows."** — the agent MUST stop after each row or small batch and wait.
- **"Continuing to the next step."** — the agent MUST NOT move to the next step without explicit user input.
- **"Based on the dominant Pain, F1 is the most aligned."** — this is implicit ranking. The agent proposes F1, the user ranks.
- **"Let me also write the shadow-backlog for you."** — the agent creates the STARTER only, with no priorities. The user runs Kano and updates the file.
- **"Let me also write the UVP for you."** — the user writes the UVP. The agent does not.
- **"Assuming you accept, I'll continue."** — the agent MUST NOT assume. The user must say accept explicitly.
- **"I've added the framework, Kano, to the file."** — the agent writes the framework choice to the file only after the user explicitly accepts it. Not before.
- **"I will also add P5, P6, P7 for completeness."** — extra rows dilute the canvas. The user adds or the agent stops.
- **"The dominant gain is G1, so the UVP should be built around it."** — the agent does not decide which Gain is dominant. The user does. The agent surfaces the data and waits.

## Composition with other skills

- **socratic-dialogue** — loaded for **validation** (is this a real pain? is this gain the result of a job or the inverse of a pain?), not for **extraction** (the data does the extraction). The VPC skill uses the Socratic engine to keep the agent honest, not to invent.
- **kano-model-strategist** — the **next step** after the skill finishes. The user takes the Pain Relievers + Gain Creators (the features) from Phase 2 and runs them through Kano to classify as Must-be / Performance / Attractive / Indifferent / Reverse / Questionable. The agent proposes Kano in Phase 2.5 as the default.
- **legible-agent-output** — applies to every user-facing string the agent emits during the workshop (status messages, table headers, the framework description).

The skill does not compose with:

- A "UVP" skill — the user writes the UVP after Kano, using the differentiators Kano surfaces.
- A "Value Map" skill — this skill IS the Value Map step. The user does not need a separate skill.
- A "prioritization" skill — the agent proposes Kano as the default in Phase 2.5; the user can choose a different framework.

## References

- Osterwalder, A., Pigneur, Y., Smith, A. (2014). *Value Proposition Design.* Wiley. — The VPC itself.
- Strategyzer (https://www.strategyzer.com). — The canonical steward of the canvas.
- Interaction Design Foundation (2024). *The Value Proposition Canvas.* — Pain and Gain category taxonomies, the two rules for gains.
- Blank, S. (2013). *The Four Steps to the Epiphany.* — Customer Development, GOOB.
- Christensen et al. (2016). *Know Your Customers' Jobs to Be Done.* HBR.
- Gothelf, J., Seiden, J. (2016). *Lean UX.* O'Reilly. — Three-level outcome.
- Hunt, V. (2016). *The Product Taster / Sprint to Market.* — Pain-Driven Design.
- Ries, E. (2011). *The Lean Startup.* Crown Business. — Build Trap.
- Perri, M. (2018). *Escaping the Build Trap.* O'Reilly.
- Kim, W. C., Mauborgne, R. (2005). *Blue Ocean Strategy.* HBR Press. — Value Innovation.
- Kano, N. (1984). *Attractive Quality and Must-be Quality.* — The Kano Model.
- `socratic-dialogue` skill in this playbook — used for validation.
- `kano-model-strategist` skill in this playbook — the next step.

Full attribution in `ATTRIBUTION.md`.