Value Proposition Canvas

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

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: monikazapisek
• Source: monikazapisek/design-engineering-playbook
• License: MIT

Install and usage instructions live in the source repository linked above.