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