# Value Proposition Canvas > 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… - **Type:** Skill - **Install:** `agentstack add skill-monikazapisek-design-engineering-playbook-value-proposition-canvas` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [monikazapisek](https://agentstack.voostack.com/s/monikazapisek) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [monikazapisek](https://github.com/monikazapisek) - **Source:** https://github.com/monikazapisek/design-engineering-playbook/tree/main/skills/value-proposition-canvas ## Install ```sh agentstack add skill-monikazapisek-design-engineering-playbook-value-proposition-canvas ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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](https://github.com/monikazapisek) - **Source:** [monikazapisek/design-engineering-playbook](https://github.com/monikazapisek/design-engineering-playbook) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-monikazapisek-design-engineering-playbook-value-proposition-canvas - Seller: https://agentstack.voostack.com/s/monikazapisek - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.