Hung Quoc To

---
name: message-clinic-runner
description: "Run the full Made-to-Stick Idea Clinic on a draft message — diagnose it against SUCCESs, rewrite the weak dimensions, and ship a before/after pair with a one-sentence punch line explaining why the revision works. This is the end-to-end rework orchestrator for ONE draft at a time. Use this skill whenever the user says 'make this stickier', 'rewrite this message', 'improve this draft', 'run the clinic on this', 'full SUCCESs rework', 'before and after rewrite', 'fix this pitch', 'rework this announcement', 'this copy isn't landing — fix it', 'I need a sticky version of this', 'turn this into a kidney-heist version', 'make my announcement memorable', 'revise this fundraising email', 'rewrite this landing page hero', 'clinic this', 'do the Heath brothers treatment on this', 'rewrite end-to-end', or pastes a draft and asks for both a diagnosis AND a rewritten version. Also triggers when the user has already run a stickiness audit and now wants the rewrite executed, or when they hand over a draft plus audience plus goal and say 'just fix it.' Produces message-clinic-output.md containing SITUATION, MESSAGE 1 (original verbatim), DIAGNOSIS (routed through stickiness-audit), MESSAGE 2 (revised draft that preserves the user's tone and brand constraints), and a one-sentence PUNCH LINE explaining the key change and why it works. Delegates targeted fixes to foundation skills (core-message-extractor, curiosity-gap-architect, concrete-language-rewriter, credibility-evidence-selector, emotional-appeal-selector, story-plot-selector, curse-of-knowledge-detector) based on which dimensions scored weak. Preserves voice, brand, and legal constraints the user provides. Also handles the 'already sticky' case — if the draft passes the audit, returns a no-rework verdict with an explanation of why it already works rather than rewriting for the sake of rewriting. Does NOT process multi-message campaigns (one draft per invocation); does NOT replace stickiness-audit for diagnosis-only use; does NOT invent facts or testimonials the user has not supplied."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/message-clinic-runner
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [1, 2, 3, 4, 5, 6]
tags: [communication, messaging, rewriting, clinic, workflow, before-after, orchestrator, copywriting, communications-review, sticky]
depends-on:
  - stickiness-audit
  - curse-of-knowledge-detector
  - core-message-extractor
  - concrete-language-rewriter
  - curiosity-gap-architect
  - credibility-evidence-selector
  - emotional-appeal-selector
  - story-plot-selector
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Draft message to rework — pitch, announcement, landing page hero, email, memo, slide text, tweet, or speech excerpt as markdown or pasted text"
    - type: document
      description: "Audience — role, context, and what they care about"
    - type: document
      description: "Goal — what the reader must remember, feel, or do after reading"
    - type: document
      description: "Tone and brand constraints — voice guidelines, legal language, forbidden claims, character limits (optional but strongly recommended)"
  tools-required: [Read, Write]
  tools-optional: [Grep, TodoWrite]
  mcps-required: []
  environment: "Any agent environment with file read/write. Document-set working environment: the agent operates on short-form prose drafts supplied by the user."
discovery:
  goal: "Produce a ready-to-ship rewritten draft with a full audit trail — SITUATION, MESSAGE 1 (original), DIAGNOSIS, MESSAGE 2 (revised), PUNCH LINE — that preserves the user's voice and brand constraints while fixing the dimensions the SUCCESs audit flagged."
  tasks:
    - "Take a draft and rewrite it end-to-end into a stickier version with per-change rationale"
    - "Run the book's Idea Clinic template on a real user message"
    - "Decide dimension-by-dimension which foundation skill to invoke and assemble the fixes into a single revised draft"
    - "Handle the 'already sticky' case without forcing a rewrite"
  audience:
    roles: [marketer, founder, communicator, product-manager, teacher, technical-writer, fundraiser, internal-comms, copywriter]
    experience: any
  when_to_use:
    triggers:
      - "User pastes a draft and asks for both a diagnosis and a revised version"
      - "User has an audit result and now wants the rewrite executed end-to-end"
      - "User says 'make this stickier', 'rewrite this', 'fix this pitch'"
    prerequisites:
      - skill: stickiness-audit
        why: "The clinic uses the audit as its DIAGNOSIS stage; weak dimensions drive which foundation skills get invoked."
    not_for:
      - "Diagnosis-only use — invoke stickiness-audit directly"
      - "Multi-message campaigns — run the clinic once per draft"
      - "Writing a message from scratch with no draft — use core-message-extractor first, then compose"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
---

# Message Clinic Runner

## When to Use

The user has ONE draft — a pitch, announcement, landing page hero, email, memo, slide, tweet, or speech excerpt — and wants both a diagnosis AND a revised version they can ship. Use this skill when the goal is **end-to-end rework with a full audit trail**, not diagnosis alone.

**Preconditions to verify before starting:**
- The draft exists as text the agent can read.
- The audience is named (even roughly — "mid-market SaaS buyers", "all 400 employees", "first-time $25-$100 donors").
- The goal is stated or can be extracted — what must the reader remember, feel, or do?
- Tone and brand constraints are captured if the user has them. If not, ask ONCE and accept "no explicit constraints, keep my voice."

**The framing restated for the agent:** The Heath brothers' Idea Clinics — inspired by before/after weight-loss photos — follow a fixed five-part template:

1. **THE SITUATION** — 2-3 sentences of context: who is communicating, to whom, and why.
2. **MESSAGE 1** — the draft verbatim, unedited.
3. **DIAGNOSIS** — a principle-by-principle commentary on what is broken, routed through the SUCCESs rubric.
4. **MESSAGE 2** — the revised draft, preserving the user's voice and brand constraints.
5. **PUNCH LINE** — one sentence naming the central change and why the revision works.

The canonical Idea Clinic example, from the book's Introduction, is the CEO who announces "maximize shareholder value" — zero on Simple (no memorable core), zero on Concrete (nothing observable), zero on Emotional (no named person), zero on Stories (pure assertion). The book contrasts it with JFK's "put a man on the moon and return him safely by the end of the decade" — 2/2 on every dimension. Your rewrites aim for the JFK pole.

---

## Context & Input Gathering

### Required Context (must have — ask if missing)

- **The draft:** The actual text — not a summary.
  -> Check prompt for: pasted text, file path, document attachment.
  -> Ask if missing: "Paste the draft you want me to rework, or give me the file path."

- **The audience:** Who the draft is for.
  -> Check prompt for: audience description, persona, reader profile.
  -> Ask if missing: "Who is this for? One sentence: role + context + what they care about."

- **The goal:** What must the reader remember, feel, or do after reading?
  -> Check prompt for: "the ask is…", "I want them to…", "the takeaway is…".
  -> Ask if missing: "If a reader forgets everything except one thing, what must that one thing be? And what do you want them to do next?"

### Observable Context (gather from environment)

- **Tone and brand constraints:** Voice guide, legal language, forbidden claims, character limits.
  -> Look for: `brand.md`, `voice.md`, style guide file, or prior user messages mentioning tone.
  -> If unclear: ask ONCE — "Any tone, brand, or legal constraints I must preserve? Or should I keep your current voice?"

- **Channel and length constraints:** A tweet, a keynote, and an all-hands memo have different rewrite tolerances.
  -> Infer from: file name, draft length, stated character limits.
  -> Default if unclear: keep the revised version within ±20% of the original length.

- **Prior clinic runs or audits:** If a `stickiness-scorecard.md` already exists, reuse it rather than re-auditing.
  -> Look for: `stickiness-scorecard.md` in the working directory.

### Default Assumptions

- **Assumption: voice preservation is ON by default.** Never rewrite in a generic marketing tone. If the draft is casual, the revision is casual. If the draft is clinical, the revision is clinical-but-concrete.
- **Assumption: no invented facts.** The clinic never invents statistics, customer names, testimonials, or credentials the user has not supplied. If a fix requires evidence the user has not given, flag it as `[NEEDS FROM USER: <what>]` in MESSAGE 2.
- **Assumption: one draft per invocation.** If the user pastes three messages, ask which one to clinic first.

### Sufficiency Threshold

- **SUFFICIENT:** Draft + audience + goal + (tone constraints OR explicit "keep my voice").
- **PROCEED WITH DEFAULTS:** Draft + audience + inferred goal. Flag `[assumed goal: X]` in the output.
- **MUST ASK:** No draft, OR audience is "general public" with no narrowing, OR user pastes multiple drafts without indicating which one to rework.

---

## Process

### Step 0: Initialize task tracking
**ACTION:** Create a TodoWrite checklist with entries: "gather inputs", "run stickiness-audit (DIAGNOSIS)", "invoke foundation skills for weak dimensions", "assemble MESSAGE 2", "write PUNCH LINE", "assemble clinic output", "structural self-check".
**WHY:** The clinic has seven phases and the middle one fans out to multiple foundation skills. Without a checklist the agent tends to collapse DIAGNOSIS and MESSAGE 2 into a single vague "improved version" — losing the audit trail that is the clinic's entire differentiator. Tracking enforces the book's before/DIAGNOSIS/after discipline.

### Step 1: Gather inputs and establish the SITUATION
**ACTION:** Ask the user (or infer from prompt) for: draft text, audience, goal, tone/brand constraints. Then write the SITUATION paragraph: 2-3 sentences naming (a) who is communicating, (b) to whom, (c) why it matters, (d) channel. Match the compact voice of the book's Clinics ("Health educators at Ohio State University want to inform the academic community about the risks of sun exposure.").
**WHY:** The SITUATION is the lens the rest of the clinic uses. A rewrite without an explicit situation drifts toward generic "better writing" advice — because without audience and goal, "sticky" collapses into "good prose." The book's Clinics always start here, and for the same reason: stickiness is relative to an audience.

**Save:** SITUATION draft to the working scorecard.

### Step 2: Record MESSAGE 1 verbatim
**ACTION:** Copy the user's original draft unedited into the MESSAGE 1 section. Do not fix typos, do not soften tone, do not "lightly improve" anything. Wrap the draft in a code fence or blockquote so it is visually distinct.
**WHY:** The "before" photo only has value if it is the actual before. Any silent improvement to MESSAGE 1 destroys the clinic's entire credibility contract — the user cannot verify the delta if the baseline was already pre-polished. The book's Clinics reproduce Message 1 verbatim even when it is painful to read.

### Step 3: Run the stickiness audit (DIAGNOSIS stage)
**ACTION:** Invoke the `stickiness-audit` skill on the draft with the same audience and goal. Capture the scorecard: seven 0/1/2 scores (Simple, Unexpected, Concrete, Credible, Emotional, Stories, Curse of Knowledge), the kidney-heist comparison, the Top 3 rewrite targets, and the Handoff Recommendations. If a scorecard already exists in the working directory from a prior audit, read and reuse it rather than re-auditing.

**IF** the audit returns **Sticky** (no 0s, at most one 1, no structural anti-pattern) -> skip to Step 7 (already-sticky branch).
**ELSE** -> proceed to Step 4.

**WHY:** The DIAGNOSIS is not "what do I think is wrong" — it is the structured output of the SUCCESs rubric with quoted evidence. The book's Clinics always diagnose principle-by-principle before rewriting, because a rewrite without a diagnosis produces stylistic variation rather than targeted fixes. Delegating to stickiness-audit guarantees the diagnosis is dimension-labeled, evidence-quoted, and ranked — which is exactly what MESSAGE 2 needs as input.

**Save:** DIAGNOSIS section = condensed scorecard + Top 3 targets + handoff list.

### Step 4: Delegate targeted rewrites to foundation skills
**ACTION:** For each dimension that scored 0 or 1, invoke the matching foundation skill with the draft, the audience, the goal, and the tone constraints. Use the delegation table in [references/rewrite-delegation-playbook.md](references/rewrite-delegation-playbook.md). Collect each skill's output as a "fix fragment" — a targeted replacement, addition, or restructuring move. Do NOT run every foundation skill; run only the ones flagged by the audit's Top 3 plus any dimension that scored 0.

**Order matters.** Run the fixes in this priority:
1. **Simple (core-message-extractor)** — must happen first; every other fix is downstream of the core.
2. **Curse of Knowledge (curse-of-knowledge-detector)** — run second; removes blockers that would otherwise survive other rewrites.
3. **Concrete (concrete-language-rewriter)** — third; grounds the core in sensory language.
4. **Unexpected (curiosity-gap-architect)** — fourth; builds the hook on top of the now-concrete core.
5. **Credible (credibility-evidence-selector)** — fifth; picks the one proof point that best anchors the claim.
6. **Emotional (emotional-appeal-selector)** — sixth; wires the core into an existing reader emotion.
7. **Stories (story-plot-selector)** — seventh; wraps the fixes in a plot if the channel allows it.

**IF** a foundation skill asks for information the user has not supplied (customer name, statistic, testimonial) -> do NOT invent it. Insert `[NEEDS FROM USER: <what>]` as a placeholder in the fix fragment and flag it in the PUNCH LINE.

**WHY:** The order reflects dependency: you cannot concretize an abstract sentence until you know what the core actually is; you cannot build a curiosity gap around a hidden core; you cannot pick the right credibility anchor until the core claim is decided. Running fixes out of order produces fragments that contradict each other. The book's Clinics apply principles in roughly this order for the same reason — Simple first, Stories last.

**Save:** One fix fragment per invoked skill, labeled with the dimension.

### Step 5: Assemble MESSAGE 2
**ACTION:** Produce the revised draft by weaving the fix fragments into a single coherent message. Rules:
- **Preserve the user's voice.** Cadence, register, and brand vocabulary stay. If the original is casual, MESSAGE 2 is casual-but-concrete.
- **Respect stated constraints.** Character limits, legal language, forbidden claims, tone rules. If a fix would violate a constraint, drop the fix and use the second-best option from the foundation skill's output.
- **Keep it within ±20% of original length** unless the user explicitly asks for a different length or the channel demands it.
- **Never introduce facts, customer names, statistics, or testimonials the user did not supply.** Use `[NEEDS FROM USER: <what>]` placeholders.
- **Do not ship a rewrite that scores worse than the original on any dimension.** Re-check mentally: did any of my fixes flatten a strength?

Write MESSAGE 2 in the same format and medium as MESSAGE 1 (if the original was an email, MESSAGE 2 is an email; if a landing page hero, MESSAGE 2 is a hero). Wrap it in the same visual container (code fence or blockquote) for visual symmetry with MESSAGE 1.

**WHY:** MESSAGE 2 is the artifact the user actually ships. Voice preservation is non-negotiable because a rewrite in a generic "sticky" tone is functionally useless — the user cannot send it without re-editing, which defeats the clinic. The ±20% length rule prevents the common failure mode where the rewrite balloons into a 3x-longer paragraph because every SUCCESs fix adds a sentence. The no-invented-facts rule is the clinic's integrity contract: the user's trust in the output depends on knowing that every proof point is one they gave you.

**Save:** MESSAGE 2 to the working scorecard.

### Step 6: Write the PUNCH LINE
**ACTION:** Write a single sentence (two sentences maximum) naming (a) the central change between MESSAGE 1 and MESSAGE 2 and (b) why the revision works. The punch line is a teaching sentence — it should answer "what did I learn from this rework?" in words the user can quote back. Model it on the book's Clinic punch lines: compact, principle-named, and connected back to the SUCCESs framework.

Examples of punch-line shape (paraphrased from the book's Clinics):
- "Message 2 works because it replaces an abstract strategy statement with a single concrete constraint — the Boeing 727 move — which the reader can actually picture."
- "Message 2 wins on the Mother Teresa principle: one named person creates emotional traction that 47,000 statistical beneficiaries destroy."
- "Message 2 opens a curiosity gap in the first sentence rather than answering a question the reader was not yet asking — the Gap Theory fix."

**IF** MESSAGE 2 contains `[NEEDS FROM USER: <what>]` placeholders -> name them in the punch line so the user knows what to fill in before shipping.

**WHY:** The punch line is the clinic's teaching surface. Without it, the user sees a before/after but does not learn the principle — which means they will make the same mistake on the next draft. The book's Clinics end with a punch line because the rework is meant to be a worked example, not a one-off fix. A clinic without a punch line is a haircut; a clinic with a punch line is a lesson.

**Save:** PUNCH LINE to the working scorecard.

### Step 7: Handle the already-sticky branch (early exit)
**ACTION:** If Step 3's audit returned a **Sticky** verdict, do NOT rewrite. Instead, produce a clinic output where:
- SITUATION is written normally.
- MESSAGE 1 is recorded verbatim.
- DIAGNOSIS explicitly states: "Draft passes the audit — no rework needed."
- MESSAGE 2 section says: "(unchanged — MESSAGE 1 is already sticky)" and does NOT duplicate the draft.
- PUNCH LINE explains which two or three dimensions the draft is already winning on, quoting specific phrases from MESSAGE 1 as evidence.

**WHY:** Rewriting for the sake of rewriting is the single worst failure mode for this skill — it erodes user trust and often flattens strengths. The Heaths warn against this directly ("some ideas only need to lose a few pounds; some don't need to lose any"). An honest "this is already good and here's why" output is more valuable than a cosmetic rework that damages a working draft.

### Step 8: Assemble the clinic output file
**ACTION:** Write `message-clinic-output.md` using the template at [references/clinic-template.md](references/clinic-template.md). The file contains exactly these sections in this order:
1. **THE SITUATION** — 2-3 sentences.
2. **MESSAGE 1** — original verbatim, in a visual container.
3. **DIAGNOSIS** — per-dimension scorecard (score + one-line verdict + quoted evidence) from Step 3, plus the Top 3 rewrite targets. This is the condensed audit — not the full `stickiness-scorecard.md`.
4. **MESSAGE 2** — revised draft, in the same visual container as MESSAGE 1 (or "unchanged" if already sticky).
5. **PUNCH LINE** — one sentence (two max), principle-named.
6. **Rationale** — a short bulleted list mapping each change in MESSAGE 2 to the SUCCESs dimension it fixes and the foundation skill that produced the fragment. This is the audit trail.
7. **Constraints preserved** — a one-line statement of which tone/brand/legal constraints the rewrite respected.

**Save:** `message-clinic-output.md` in the user's working directory.

### Step 9: Structural self-check
**ACTION:** Before returning, verify:
- [ ] SITUATION names audience, goal, and channel.
- [ ] MESSAGE 1 is verbatim — no silent edits.
- [ ] DIAGNOSIS is dimension-labeled (all seven axes listed, even if some scored 2) with quoted evidence.
- [ ] MESSAGE 2 is either a rewritten draft in the user's voice OR explicitly marked "unchanged — already sticky."
- [ ] MESSAGE 2 contains no invented facts — any fabricated claim must be a `[NEEDS FROM USER: ...]` placeholder.
- [ ] MESSAGE 2 length is within ±20% of MESSAGE 1 unless explicitly requested otherwise.
- [ ] PUNCH LINE names at least one SUCCESs dimension by name ("Concrete", "Emotional", "Curse of Knowledge", etc.).
- [ ] Rationale section maps each change to a dimension AND a foundation skill.
- [ ] Constraints-preserved line exists and is accurate.
- [ ] No dimension was collapsed — Curse of Knowledge is addressed separately from Simple.

**IF** any check fails -> fix before returning the output.
**WHY:** Each of these checks defends against a specific baseline failure mode (silent polishing, invented testimonials, missing punch line, collapsed Curse axis). Skipping the self-check lets the clinic degrade into "an LLM rewrote your copy" — which is exactly what the skill exists to out-perform.

---

## Inputs

- `draft` — the text to rework (markdown, pasted text, or file path).
- `audience` — one sentence: role + context + what they care about.
- `goal` — what the reader must remember, feel, or do.
- `constraints` — tone, brand, legal, length, channel rules (optional but recommended).
- `prior_scorecard` — path to an existing `stickiness-scorecard.md` if one exists.

## Outputs

A single file, `message-clinic-output.md`, structured as:

```markdown
# Message Clinic — {draft name}

## THE SITUATION
{2-3 sentences: who, to whom, channel, why it matters.}

## MESSAGE 1
> {the original draft, verbatim}

## DIAGNOSIS
| Dimension            | Score | Verdict              | Evidence              |
|----------------------|-------|----------------------|-----------------------|
| Simple               | 0/1/2 | {...}                | "..."                 |
| Unexpected           | 0/1/2 | {...}                | "..."                 |
| Concrete             | 0/1/2 | {...}                | "..."                 |
| Credible             | 0/1/2 | {...}                | "..."                 |
| Emotional            | 0/1/2 | {...}                | "..."                 |
| Stories              | 0/1/2 | {...}                | "..."                 |
| Curse of Knowledge   | 0/1/2 | {...}                | "..."                 |

**Top 3 rewrite targets:** {dimension → fix → effort}

## MESSAGE 2
> {the revised draft, same medium and voice as MESSAGE 1}

## PUNCH LINE
{One sentence (two max) naming the central change and which SUCCESs principle it lands.}

## Rationale
- **{Dimension}** — {what changed} — produced by `{foundation-skill}`
- ...

## Constraints preserved
{One line: voice, brand, legal, length — what the rewrite respected.}
```

---

## Key Principles

- **Preserve voice, always.** A rewrite in generic marketing tone is functionally useless — the user cannot ship it. Cadence, register, and brand vocabulary stay; only the SUCCESs-failing moves change. If the original is clinical, the revision is clinical-but-concrete. If the original is casual, the revision is casual-but-emotional. This is the difference between "a clinic" and "an LLM smoothed my copy."

- **Never invent facts.** The clinic never introduces customer names, statistics, testimonials, or credentials the user has not supplied. Every fix that needs evidence becomes a `[NEEDS FROM USER: <what>]` placeholder. This is the skill's integrity contract — users can only trust the before/after if they know the "after" contains nothing fabricated. A clinic that invents a testimonial is worse than no clinic at all.

- **The diagnosis is delegated, not improvised.** The DIAGNOSIS stage runs `stickiness-audit` — the rubric-based hub skill — rather than guessing. Without a structured audit the rewrite drifts toward stylistic variation, which is the baseline agent failure mode. The audit's Top 3 + handoff list is the work order for Step 4.

- **Fix order follows the dependency graph.** Simple first (nothing else works without a clear core), then Curse of Knowledge (removes blockers), then Concrete, Unexpected, Credible, Emotional, Stories. Running fixes out of order produces fragments that contradict each other — e.g., concretizing a sentence whose core has not yet been decided.

- **The already-sticky case is a legitimate output.** If the draft passes the audit, returning "no rework needed — here's why it already works" is the right answer. The book is explicit: some ideas only need to lose a few pounds; some don't need to lose any. A cosmetic rework that damages a working draft is the worst possible outcome.

- **The punch line is a teaching sentence, not a summary.** It names a SUCCESs principle, quotes the central change, and explains why the revision works in terms the user can apply to the next draft. A clinic without a punch line is a haircut; a clinic with a punch line is a lesson.

- **Voice preservation beats rubric optimization.** If a fix would win a dimension but break the user's voice or brand, drop the fix and use the second-best option. The goal is not a 14/14 scorecard; it is a ship-ready draft. Rubric-chasing at the cost of voice is the "robot-wrote-this" smell.

- **One draft per clinic.** Multi-message campaigns fan out into contradictory fixes. If the user pastes three drafts, run the clinic three times in sequence — not fused into one output.

---

## Examples

**Scenario: The "maximize shareholder value" CEO memo (canonical weak baseline)**

Trigger: User pastes a short all-hands announcement: "Team — as we enter FY26 we will maximize shareholder value through synergies across business units and a best-in-class North Star metric. Our goal is operational excellence." Audience: "all 400 employees across mixed roles, most have never been in strategy meetings." Goal: "get everyone rowing in the same direction on Monday morning." Constraints: "keep my plainspoken voice — I don't use corporate buzzwords in person."

Process: (1) SITUATION: "The CEO is addressing 400 employees across mixed roles in an all-hands memo ahead of FY26 kickoff; the goal is to give everyone a shared direction they can act on Monday morning." (2) MESSAGE 1 captured verbatim. (3) Audit returns: Simple 0/2, Unexpected 0/2, Concrete 0/2, Credible 1/2, Emotional 0/2, Stories 0/2, Curse of Knowledge 0/2. Top 3 = (a) extract a concrete core, (b) replace "North Star metric" with the actual metric and target number, (c) add a "what changes for you on Monday" paragraph. Verdict: Not sticky — structural rework required. (4) Delegation: core-message-extractor → curse-of-knowledge-detector → concrete-language-rewriter → emotional-appeal-selector. Each returns a fix fragment. (5) MESSAGE 2: "Team — this year we want one thing: every customer keeps their service working during our platform migration. We're moving 400 services to the new stack between now and December. For you on Monday: if you own a service on the list below, your sprint changes — talk to your manager. If you don't, nothing changes yet. [NEEDS FROM USER: the actual service-count number and the migration deadline]." (6) PUNCH LINE: "Message 2 works because it replaces an abstract strategy statement ('maximize shareholder value') with one concrete Commander's Intent the reader can act on Monday — the Simple + Concrete combination the book calls the core of stickiness." (7) Rationale lists each change and its source skill. (8) Constraints preserved: "plainspoken voice, no corporate buzzwords — FY26 is the only business term retained."

Output: `message-clinic-output.md` with the above sections. The placeholder flags what the CEO must fill in before shipping.

**Scenario: Nonprofit giving-day email (the Mother Teresa inversion)**

Trigger: User pastes a 120-word email: "Our 2026 impact report shows 14 programs reached 47,000 beneficiaries across sub-Saharan maternal health. Every dollar donated supports our work. Donate today to continue our mission." Audience: "first-time $25-$100 donors, no prior engagement." Goal: "convert to a first gift." Constraints: "keep under 150 words, compliant with UK fundraising regulator — no emotional manipulation or graphic imagery."

Process: (1) SITUATION captured. (2) MESSAGE 1 verbatim. (3) Audit: Credible 2/2 (numbers are testable), Simple 1/2, Emotional 0/2 (Mother Teresa inverted — no named person), Stories 0/2 (no narrative), Unexpected 0/2, Concrete 1/2, Curse 1/2 ("impact report" leaks through). Top 3 = emotional-appeal-selector, story-plot-selector, fix burying-the-lead. (4) Delegation: emotional-appeal-selector returns "lead with one named mother + one specific detail"; story-plot-selector returns a Connection-plot micro-narrative. Both respect the regulator constraint — no graphic imagery, no manipulation. (5) MESSAGE 2: "Last March, Amina walked 11 km to our clinic in Kebri Dehar. She was in her eighth month. The clinic was open because a donor like you had paid for the month's supplies. Your £25 today keeps one clinic open for a day. Donate here. [NEEDS FROM USER: confirmation that Amina is a real case you have permission to cite, or substitute a permitted story]." (6) PUNCH LINE: "Message 2 inverts the Mother Teresa effect — one named mother and one specific walk creates emotional traction that 47,000 aggregate beneficiaries flatten; the regulator constraint is respected because the detail is factual, not graphic." (7) Rationale. (8) Constraints preserved: "under 150 words, no graphic imagery, no manipulation."

Output: `message-clinic-output.md` with placeholder flagging the consent check before shipping.

**Scenario: Already-sticky landing page hero (no rework needed)**

Trigger: User pastes a landing page hero: "Know which of your 400 microservices broke in the last deploy before your customers do." Audience: "backend engineers at mid-size SaaS companies." Goal: "sign up for a 14-day trial." Constraints: "engineering-tone, no hype."

Process: (1) SITUATION captured. (2) MESSAGE 1 verbatim. (3) Audit: Simple 2/2, Unexpected 1/2, Concrete 2/2 ("400 microservices", "last deploy"), Credible 1/2 (reader can verify from memory), Emotional 1/2 (wires into fear of a customer-reported incident), Stories 1/2 (implicit micro-narrative), Curse 2/2. Verdict: Sticky. (4) Early exit — skip rewrite. (5) MESSAGE 2: "(unchanged — already sticky)". (6) PUNCH LINE: "Ship it. The hero is winning on Simple (a single Commander's Intent — catch bad deploys), Concrete (the 400-microservice number the reader can picture), and Curse of Knowledge (zero insider jargon); a rewrite would flatten at least one of those strengths." (7) Rationale: "no changes made; audit verdict and reasoning retained for the author's records." (8) Constraints preserved: "engineering-tone, no hype — already compliant."

Output: `message-clinic-output.md` with an unchanged MESSAGE 2 and an honest punch line explaining why the draft already works.

---

## References

- For the exact markdown template `message-clinic-output.md` must fill in, see [clinic-template.md](references/clinic-template.md)
- For the decision table mapping audit dimensions to foundation skills and the dependency-ordered fix priority, see [rewrite-delegation-playbook.md](references/rewrite-delegation-playbook.md)

---

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath and Dan Heath.

## Related BookForge Skills

This is a Level 2 orchestrator — it delegates diagnosis to the Level 1 hub and targeted rewrites to the Level 0 foundation skills. Install from ClawhHub:

- `clawhub install bookforge-stickiness-audit` — the DIAGNOSIS stage (required)
- `clawhub install bookforge-core-message-extractor` — invoked when Simple scores low
- `clawhub install bookforge-curse-of-knowledge-detector` — invoked when the Curse axis scores low
- `clawhub install bookforge-concrete-language-rewriter` — invoked when Concrete scores low
- `clawhub install bookforge-curiosity-gap-architect` — invoked when Unexpected scores low
- `clawhub install bookforge-credibility-evidence-selector` — invoked when Credible scores low
- `clawhub install bookforge-emotional-appeal-selector` — invoked when Emotional scores low
- `clawhub install bookforge-story-plot-selector` — invoked when Stories scores low

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/clinic-template.md
# Message Clinic Output Template

This is the fixed template the `message-clinic-runner` skill fills in when producing `message-clinic-output.md`. The structure mirrors the Heath brothers' Idea Clinics from Made to Stick (Chapters 1-6): SITUATION → MESSAGE 1 → DIAGNOSIS → MESSAGE 2 → PUNCH LINE, with a Rationale audit trail and a Constraints-preserved line appended.

Do not reorder sections. Do not drop sections. If a section is inapplicable (e.g., MESSAGE 2 in the already-sticky branch), keep the heading and use the explicit marker "(unchanged — already sticky)".

---

```markdown
# Message Clinic — {draft name or short descriptor}

## THE SITUATION

{2-3 sentences. Name: (a) who is communicating, (b) to whom, (c) the channel, (d) why it matters. Match the compact voice of the book's Clinics — e.g., "Health educators at Ohio State University want to inform the academic community about the risks of sun exposure."}

## MESSAGE 1

> {The user's original draft, verbatim. No typo fixes. No silent polishing. Wrap in blockquote or code fence for visual symmetry with MESSAGE 2.}

## DIAGNOSIS

Audit produced by `stickiness-audit`. 0/1/2 per dimension. No summed score — the book is explicit: it's a checklist, not an equation.

| Dimension            | Score | Verdict (one line)          | Evidence (quoted)        |
|----------------------|-------|-----------------------------|--------------------------|
| Simple               | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |
| Unexpected           | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |
| Concrete             | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |
| Credible             | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |
| Emotional            | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |
| Stories              | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |
| Curse of Knowledge   | 0/1/2 | {one-line verdict}          | "{quoted passage}"       |

**Top 3 rewrite targets** (ranked by severity × fraction of draft poisoned):
1. **{Dimension}** — "{quoted passage from MESSAGE 1}" — Fix: {specific move}. Effort: S/M/L.
2. **{Dimension}** — "{quoted passage}" — Fix: {specific move}. Effort: S/M/L.
3. **{Dimension}** — "{quoted passage}" — Fix: {specific move}. Effort: S/M/L.

## MESSAGE 2

> {The revised draft, in the same medium and voice as MESSAGE 1. Within ±20% of original length unless explicitly requested otherwise. Any unsourced claim replaced with [NEEDS FROM USER: <what>]. If MESSAGE 1 was already sticky, this section reads exactly: "(unchanged — already sticky)".}

## PUNCH LINE

{One sentence (two max). Names at least one SUCCESs dimension explicitly. Explains the central change and why the revision works in terms the user can quote back. Modeled on the book's Clinic punch lines — compact, principle-named, and tied back to the framework.}

## Rationale

Audit trail mapping each change in MESSAGE 2 to the SUCCESs dimension it fixes and the foundation skill that produced the fragment.

- **{Dimension}** — {what changed in one phrase} — produced by `{foundation-skill-name}`
- **{Dimension}** — {what changed} — produced by `{foundation-skill-name}`
- **{Dimension}** — {what changed} — produced by `{foundation-skill-name}`

{If the already-sticky branch fired, this section contains one bullet: "No changes made. Audit verdict retained for the author's records."}

## Constraints preserved

{One line naming which tone, brand, legal, length, or channel constraints the rewrite respected. Example: "Plainspoken voice, no corporate buzzwords, under 150 words, UK fundraising regulator compliance — no graphic imagery."}

{If placeholders exist in MESSAGE 2, add a second line: "Placeholders to fill before shipping: [NEEDS FROM USER: ...], [NEEDS FROM USER: ...]."}
```

---

## Filling notes

- **DIAGNOSIS** is a condensed version of `stickiness-scorecard.md`, not a full copy. The full scorecard can be referenced in the user's working directory; this table is the at-a-glance version.
- **MESSAGE 2** uses the same visual container (code fence or blockquote) as MESSAGE 1 so the user can see the before/after side by side without squinting.
- **PUNCH LINE** is the single highest-value sentence in the entire output. If you can only save one section, save this one — it is the teaching moment.
- **Rationale** bullets are what distinguishes a clinic from a rewrite. Without them the user sees a change but does not learn the principle.
- **Constraints preserved** is the voice-integrity receipt. It lets the user verify you respected their brand before they read the rewrite.

## Branch: already-sticky output

When Step 3's audit returns **Sticky** (no 0s, at most one 1, no structural anti-pattern), the output still uses this template, but:

- DIAGNOSIS table is filled in with the actual scores (most will be 2/2) and quoted evidence from MESSAGE 1.
- **Top 3 rewrite targets** section is replaced with: "**No rework needed.** Draft passes the audit. Below: the two or three dimensions the draft is already winning on."
- MESSAGE 2 reads exactly: `> (unchanged — already sticky)`
- PUNCH LINE explains WHICH dimensions the draft is already winning on, with quoted phrases from MESSAGE 1.
- Rationale contains one bullet: "No changes made. Audit verdict retained for the author's records."
- Constraints preserved line still fires — "already compliant with {constraint}."

This branch is a legitimate output, not a failure mode. The book is explicit: some ideas only need to lose a few pounds; some don't need to lose any.

FILE:references/rewrite-delegation-playbook.md
# Rewrite Delegation Playbook

This playbook tells the `message-clinic-runner` WHICH foundation skill to invoke for EACH weak dimension flagged by the stickiness audit, in WHICH order, and with WHAT to pass as input. It is the dispatch logic for Step 4 of the clinic workflow.

The core idea: the clinic does not fix drafts itself — it delegates each dimension-specific fix to the Level 0 foundation skill that owns that dimension, then assembles the fragments into MESSAGE 2 in Step 5.

---

## Delegation table

| Audit dimension          | Invoke this skill              | What to pass in                                                                                         | What you get back                                                                                         |
|--------------------------|--------------------------------|---------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
| **Simple** (0 or 1)      | `core-message-extractor`       | Draft + audience + goal + tone constraints                                                              | A single-sentence Commander's Intent to anchor MESSAGE 2 around                                           |
| **Curse of Knowledge** (0 or 1) | `curse-of-knowledge-detector` | Draft + audience profile (what the reader does NOT know)                                              | List of flagged insider terms, acronyms, buried assumptions + rewrite guidance                            |
| **Concrete** (0 or 1)    | `concrete-language-rewriter`   | Draft (or the flagged abstract passages) + audience + the Commander's Intent from core-message-extractor | Side-by-side before/after of each abstract passage with the concretizing technique named                  |
| **Unexpected** (0 or 1)  | `curiosity-gap-architect`      | Draft + audience + core message + channel (email subject? tweet? landing hero?)                         | 3 scored hook variants with pattern-break + curiosity-gap structure                                       |
| **Credible** (0 or 1)    | `credibility-evidence-selector`| Draft's claim(s) + audience skepticism profile + available proof (ONLY what the user supplied)         | Ranked evidence list with the Sinatra-test winner picked; weak chains flagged for removal                 |
| **Emotional** (0 or 1)   | `emotional-appeal-selector`    | Draft + audience + goal + forbidden moves (fear appeals? manipulation?)                                 | Chosen lever (Association / Self-Interest / Identity) + named-person framing plan + forbidden-move list   |
| **Stories** (0 or 1)     | `story-plot-selector`          | Draft + audience + goal + available raw story material the user has supplied                           | Plot type (Challenge / Connection / Creativity) + structured story skeleton using real user-supplied facts |

**Rule:** Pass the user's tone and brand constraints to EVERY foundation skill. A fragment that violates voice is useless downstream — it will be dropped in Step 5 and the dimension will remain broken.

---

## Dependency order

Run the invocations in this order. This is not arbitrary — it reflects the dependency graph between dimensions.

1. **Simple → core-message-extractor** (if flagged)
2. **Curse of Knowledge → curse-of-knowledge-detector** (if flagged)
3. **Concrete → concrete-language-rewriter** (if flagged)
4. **Unexpected → curiosity-gap-architect** (if flagged)
5. **Credible → credibility-evidence-selector** (if flagged)
6. **Emotional → emotional-appeal-selector** (if flagged)
7. **Stories → story-plot-selector** (if flagged)

**Why this order:**

- **Simple must be first.** You cannot concretize, hook, or emotionally anchor a message whose core has not yet been decided. Every downstream fix takes the Commander's Intent as input. Running Concrete before Simple produces vivid language around the wrong idea.
- **Curse of Knowledge is second.** Removing buried insider assumptions is a prerequisite for every other fix — a fragment written on top of jargon-corrupted scaffolding inherits the corruption. Also, the Curse fixes are usually cuts (removing terms), which shrinks the draft before the other skills add new material.
- **Concrete is third.** Now that you have a clear core and no insider jargon, you can ground the core in sensory language. Running Concrete before Curse means you re-concretize passages that will then be cut; wasted work.
- **Unexpected is fourth.** The hook (pattern-break + curiosity gap) is built ON TOP of the concrete core. A hook around an abstract core is a gimmick; a hook around a concrete core is the kidney heist.
- **Credible is fifth.** Once the core, the concrete language, and the hook are in place, you can pick the single best proof point. Picking evidence before the core is decided often produces credibility that points at the wrong claim.
- **Emotional is sixth.** The emotional lever wires the (now-decided, now-concrete) claim into an existing reader emotion. Running Emotional first tends to produce sympathy-begging copy that does not connect to a specific claim.
- **Stories is last.** The story wraps everything in a plot — it is the skin, not the skeleton. A story written before the core, hook, and credibility exist is a story about nothing.

**Skip rules:**

- If a dimension scored 2/2 in the audit — do NOT invoke the foundation skill for it. Preserve the existing strength; running the skill anyway risks flattening it.
- If a dimension scored 1/2 and is NOT in the audit's Top 3 — it is optional. Invoke only if the fix is cheap and does not risk breaking other dimensions.
- If a dimension scored 0/2 — ALWAYS invoke the foundation skill, even if it is not in the Top 3. A 0 is always worth fixing.

---

## Passing data between skills

Each skill runs independently and does not see the other skills' outputs. Pass data forward explicitly:

- **core-message-extractor output (Commander's Intent)** → pass to every downstream invocation as `core_message`.
- **curse-of-knowledge-detector output (flagged terms list)** → pass to concrete-language-rewriter so it does not re-use the flagged terms when concretizing.
- **concrete-language-rewriter output (concrete swaps)** → pass to curiosity-gap-architect so the hook builds on the concrete phrasing.
- **credibility-evidence-selector output (Sinatra-test winner)** → pass to emotional-appeal-selector so the emotional framing points at the same proof.
- **emotional-appeal-selector output (chosen lever + named person)** → pass to story-plot-selector so the plot uses the same person.

If a downstream skill would need a fragment from a skill you did NOT invoke (because that dimension scored 2/2), pass the original draft's wording for that dimension instead.

---

## When NOT to delegate

- **Already-sticky branch.** If the audit returns a **Sticky** verdict in Step 3, do not invoke any foundation skill. Skip to the already-sticky output (Step 7 of the main workflow).
- **Single-dimension request.** If the user only asks for one thing ("just make this more concrete"), do not run the full clinic — invoke the single foundation skill directly. The clinic is for end-to-end rework, not single-axis fixes.
- **User provides a locked version.** If the user says "rewrite only the first sentence — leave the rest alone", honor the lock. Delegate fixes only within the unlocked portion and carry the locked text through MESSAGE 2 unchanged.
- **Constraint violation.** If a foundation skill returns a fragment that violates the user's tone, brand, or legal constraints, drop the fragment and use the skill's second-best option. If no option respects the constraints, leave the dimension unchanged and note it in the Rationale ("Emotional dimension unchanged — no lever respected the no-manipulation constraint").

---

## Fix-fragment format

Each foundation skill should return its fix as a structured fragment the clinic can weave into MESSAGE 2:

```
Dimension: {S | U | C | C | E | S | Curse}
Target in MESSAGE 1: "{quoted passage}"
Replacement or addition: "{the new text}"
Technique named: {e.g., "schema tap", "Sinatra Test", "Connection plot"}
Constraint check: {passes / violates — if violates, use second-best}
Needs from user: {list of [NEEDS FROM USER: <what>] placeholders, or "none"}
```

Step 5 of the clinic workflow assembles these fragments by walking MESSAGE 1 and applying the replacements/additions in-place, preserving voice.

---
name: emotional-appeal-selector
description: Choose the emotional lever that will make an audience actually care about a message — and strip out the analytical priming that kills charity before the emotional ask lands. Use this skill whenever a message is technically correct but emotionally flat, whenever the user asks "how do I make them care", "nobody cares about this", "why won't people act", "why should they care", "make this emotional without being cheesy", "motivate people", "this fundraising email isn't working", "rewrite this pitch so it lands", "our cause is important but donations are dropping", or "this announcement is dry and people are ignoring it". Also triggers when the user has a spreadsheet-heavy pitch, a statistics-first fundraising appeal, a recruiting message that lists benefits nobody responds to, a behavior-change campaign that's being ignored, a change-management memo that reads like a policy document, or a mission statement that employees cannot see themselves inside. Applies three named levers from Made to Stick — Association (tap emotions they already have), Self-Interest (what's in it for you, stated plainly), and Identity (who am I and what do people like me do) — plus the Mother Teresa / identifiable-victim rule (one specific person beats aggregate statistics) plus Maslow's eight needs used as a non-hierarchical palette (warning against "Maslow's basement" — assuming others are motivated only by money and security). Critically detects and removes analytical priming — calculations, spreadsheets, statistics placed before an emotional ask — because the mere act of calculation has been shown to reduce charitable response. This skill does NOT manipulate via fear, exploit vulnerability, or produce sympathy-begging copy. It does NOT write the full message end-to-end (pair with a rewriting skill); it produces an emotional-appeal plan — chosen lever, framing, concrete moves, and forbidden moves — that a writer or another skill can execute.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/emotional-appeal-selector
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [5, 13]
tags: [emotional-appeal, persuasion, messaging, motivation, fundraising, change-management, identity, storytelling, copywriting, communication]
depends-on: []
execution:
  tier: 1
  mode: plan-only
  inputs:
    - type: document
      description: "Core message or current draft — the one thing you want the audience to feel, believe, or do"
    - type: document
      description: "Audience profile — who they are, what group they belong to, what they currently care about"
    - type: document
      description: "Type of action sought — donate, join, change behavior, approve a budget, vote, rally around a mission"
  tools-required: [Read, Write]
  tools-optional: [Grep]
  mcps-required: []
  environment: "Any agent environment with file read/write. Document-set working environment: the agent operates on short-form prose drafts, briefs, and audience notes provided by the user."
discovery:
  goal: "Select the emotional lever most likely to make a specific audience care about a specific ask, and produce a plan the writer can execute without slipping into manipulation or analytical flattening."
  tasks:
    - "Decide between Association, Self-Interest, and Identity as the primary emotional lever for a message"
    - "Detect and remove analytical priming (stats, calculations, spreadsheets) that precedes an emotional ask"
    - "Convert aggregate statistics into an identifiable-individual frame for fundraising or advocacy"
    - "Diagnose whether a motivational appeal is stuck in Maslow's basement and recommend an upper-level reframe"
    - "Produce a forbidden-moves list for a sensitive appeal to prevent manipulation or cheesiness"
  audience:
    roles: [marketer, fundraiser, founder, communicator, manager, change-leader, nonprofit-leader, product-marketer, teacher]
    experience: any
  when_to_use:
    triggers:
      - "Message is technically correct but the audience is not responding"
      - "Fundraising appeal leads with aggregate statistics"
      - "Recruiting or internal memo lists benefits that nobody is acting on"
      - "User explicitly asks how to make an audience care without being manipulative"
      - "Change-management or mission pitch is being ignored or mocked"
    prerequisites: []
    not_for:
      - "Writing the full rewritten message end-to-end — hand off to a rewriting skill after producing the plan"
      - "Running the full six-principle stickiness audit — use a stickiness-audit skill instead"
      - "Producing fear-based, shame-based, or exploitation-based copy — this skill refuses those paths"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
---

# Emotional Appeal Selector

## When to Use

You have a message, pitch, fundraising appeal, recruiting note, change-management memo, or mission statement that is **technically accurate but emotionally inert**. The audience is not moved. The message may be loaded with statistics, benefits, or strategy language, yet the needle on donations, sign-ups, adoption, or morale is not moving. Use this skill to **choose the single emotional lever that will make them care**, diagnose analytical priming that is suppressing charity, and produce a plan that a writer (or a follow-on rewriting skill) can execute.

**This is a plan-only skill.** It outputs a structured decision and brief, not finished copy. The writer still writes.

**Preconditions to verify before starting:**
- There is a clear **core message** (one sentence) — if not, pair with `core-message-extractor` first.
- There is a clear **audience** — who are they, what group do they belong to, what do they already care about?
- There is a clear **action sought** — donate, join, switch behavior, approve, rally. "Raising awareness" is not an action.
- The user wants a recommendation, not a rewrite.

**Do NOT use this skill to:**
- Produce fear-, shame-, or guilt-based manipulation. The skill will refuse and suggest an identity or transcendence reframe instead.
- Replace an honest value proposition with emotional theatre. If the underlying offer is bad, this skill cannot fix it.
- Run the whole SUCCESs audit — emotional is one principle of six.

## Context & Input Gathering

### Required Context (must have — ask if missing)

- **Core message:** One sentence — the single thing you want the audience to feel, believe, or do.
  -> Check prompt for: a stated ask, a pitch draft, a campaign goal
  -> If missing, ask: "What is the one-sentence message you want to land? (If you don't have one, we should extract it first.)"
- **Audience identity:** Who they are, what group(s) they identify with, what they already care about.
  -> Check prompt for: named audience, segment descriptions, personas
  -> If missing, ask: "Who are you trying to reach? Describe them as a group — not demographics, but shared identity or situation (e.g., 'firefighters in a small-town department' or 'parents of teen soccer players')."
- **Action sought:** The specific behavior you want.
  -> Check prompt for: verbs like donate, subscribe, apply, approve, sign, vote, quit, switch
  -> If missing, ask: "What specific action do you want them to take after reading this?"

### Observable Context (gather from environment)

- **Existing draft:** If a draft exists, read it and scan for analytical priming (numbers, percentages, spreadsheets, ROI language) that appears BEFORE the emotional ask.
  -> Look for: `draft.md`, `brief.md`, pasted copy in the prompt
  -> If unavailable: proceed with the core message + audience only
- **Prior attempts:** Has the user tried a version that failed? Why did they think it failed?
  -> Look for: `previous-version.md`, user's own diagnosis in the prompt
  -> If unavailable: assume no prior signal

### Default Assumptions

- **Tone:** Default to sincere, non-cheesy, non-manipulative. State explicitly in the output brief.
- **Channel:** Default to the channel implied by the draft (email, landing page, speech, memo). If unknown, default to short-form written.
- **Length constraint:** If not stated, assume the writer wants compact — 100-300 words.

### Sufficiency Threshold

- **SUFFICIENT:** Core message + audience identity + action sought are all known.
- **PROCEED WITH DEFAULTS:** Core message + audience known, action sought inferable from context (e.g., fundraising email -> donate).
- **MUST ASK:** Audience is described only demographically ("millennials") with no identity or group context — the three levers need shared-situation context to work.

## Process

### Step 0: Initialize Task Tracking

**ACTION:** Write a lightweight checklist (can be inline markdown) for the steps below: priming scan, lever selection, identifiable-victim check, Maslow check, forbidden-moves list, plan output.

**WHY:** The skill has several independent checks that can be skipped silently if not tracked. Writing the checklist first forces you to run the analytical-priming scan even when the draft "looks fine" — and that scan is the single highest-value step because analytical priming invisibly neutralizes every other move you make.

### Step 1: Scan for Analytical Priming (Before Anything Else)

**ACTION:** Read the existing draft (if any) top to bottom and flag every element that would **prime the reader to think analytically before the emotional ask**. Produce a short list: location + element + why it primes calculation.

Look for:
- Aggregate statistics ("3 million children face hunger", "72% of respondents")
- Dollar figures, percentages, or ROI computations before the ask
- Tables, spreadsheets, comparison charts, "by the numbers" sidebars
- "Let's do the math" / "calculate your savings" / cost-benefit framings
- Dense credentials walls ("PhD, 20 years experience, Harvard-trained")
- Multiple options presented with trade-offs (decision paralysis = analytical mode)
- Forms with required numeric inputs placed before the story

**WHY:** The Rokia / Save the Children experiment showed donors gave **$2.38** after reading about one named girl, but only **$1.14** after reading statistics about millions of hungry children. Worse — people who read BOTH the story AND the statistics gave only **$1.43**, almost a dollar LESS than those who got the story alone. A second study primed half the participants with a calculation problem ("If an object travels at 5 ft/min, how many feet in 360 seconds?") before the Rokia letter. The primed group gave $1.26; the unprimed group gave $2.34. **The mere act of calculation cut charity almost in half.** If you leave analytical priming in front of the emotional ask, the emotional ask cannot do its job. This step is non-negotiable — skip it and the rest of the plan is neutralized.

**IF** analytical priming is found before the emotional ask -> mark every instance with a [REMOVE-OR-MOVE-AFTER-ASK] tag in the plan.
**ELSE** -> note "no analytical priming detected" explicitly in the plan. Absence is a finding, not silence.

### Step 2: Profile the Audience's Current Emotional Tags

**ACTION:** Write a short "what they already care about" note for the audience. What emotions, values, group memberships, and aspirations are ALREADY active in their life — without you putting them there?

Answer four questions:
1. What group(s) do they identify with? (role, profession, region, fandom, cause, family structure)
2. What do they brag about? (what would they post on social media proudly?)
3. What do they resent or mock? (what group do they define themselves against?)
4. What upper-level Maslow need is currently most under-served in their environment? (see `references/maslow-eight-levels.md`)

**WHY:** The book's strongest move in the Emotional chapter is that you usually do not need to **create** emotion — you piggyback on emotion the audience is already feeling. The "Association" lever only works if you know which existing emotional tags to connect to. Skipping this step forces you to manufacture emotion, which is where cheesiness and manipulation come from. The fourth question specifically guards against Maslow's basement: you will default to Security/Esteem appeals unless you explicitly ask what upper need is under-served.

### Step 3: Choose the Primary Lever

**ACTION:** Pick ONE of the three levers as primary. You can add a secondary, but lead with one. Use the decision rules below; they are ordered by priority — use the first one that applies.

**Lever 1 — IDENTITY** ("Who am I? What do people like me do?")
- **Use when:** The audience has a strong shared identity (profession, region, fandom, cause, demographic group), and the action you want is something they would do *because of who they are*, not because of what they get.
- **Decision test:** Can you finish the sentence "A real ___ would ___"? If yes, Identity is your lever.
- **Canonical example:** "Don't Mess With Texas" worked on a littering problem where a self-interest appeal ("fines", "environmental damage") had failed — because the target ("Bubba", a pickup-driving Texan) responded to *identity-as-Texan* much more strongly than to incentives. The appeal's message: *real Texans do not litter.*
- **Counter-example:** The firehouse popcorn-popper incident — an educational film for firefighters was being pitched to chiefs with a free popcorn popper as incentive. One chief exploded: *"You think we need a #*$@! popcorn popper to run a fire-safety program?"* The free-gift appeal insulted the firefighters' identity (we are professionals, not consumers). Any incentive-based move was going to fail; only an identity-appeal could work.

**Lever 2 — SELF-INTEREST** ("WIIFY — What's in it for you")
- **Use when:** The benefit is concrete, personal, and the audience does not have a conflicting identity that makes incentives feel insulting.
- **Decision test:** Can you name a specific, tangible, personal outcome — and is the audience the kind of person who can say "yes, I want that" without feeling embarrassed?
- **Canonical moves:**
  - Say "you", not "people". *"You enjoy a sense of security when you use Goodyear tires"* — not *"people will enjoy a sense of security..."*.
  - **Help them visualize the benefit already happening.** The Tempe cable TV study found that a subtle "imagine coming home and finding your show on cable" pitch outperformed an abstract benefits list. Visualization > enumeration.
  - **Do not bury the self-interest.** Caples: *"First and foremost, try to get self-interest into every headline you write."*
- **Counter-test (Maslow's basement check):** If your self-interest appeal is purely Security/Esteem/Physical (money, bonus, comfort), stop. Re-read `references/maslow-eight-levels.md` and ask whether you could rewrite the appeal from Learning, Aesthetic, Self-actualization, or Transcendence. *"Math is mental weight training"* beats *"you'll need it for your job"* because it moves up out of the basement.

**Lever 3 — ASSOCIATION** ("Tap emotions they already have")
- **Use when:** The audience has strong existing feelings about some adjacent concept, and you can hook your idea onto that concept without semantic stretch.
- **Decision test:** Is there a word, image, or idea they already respond to emotionally that your message is genuinely (not coincidentally) connected to?
- **Canonical example:** Positive Coaching Alliance could not use "sportsmanship" — the word had been stretched thin by overuse. Jim Thompson reframed the concept as **"Honoring the Game"**, a phrase that had not been worn out, and coaches, parents, and kids immediately understood the ask. Same underlying concept, fresh association.
- **Warning — semantic stretch:** Any word that has been overused until it means nothing (unique, passionate, innovative, empowered, next-generation) has lost its emotional voltage. Do not associate your message with words in the stretched zone; either find a fresh word (Honoring the Game) or pick a different lever entirely.

**WHY the ordering matters:** Identity-based appeals are the most under-used and the most motivating when they fit — they recruit the audience's sense of self as an unpaid copywriter on your behalf. Self-interest is the default most people reach for; test whether identity would beat it before committing. Association is the most creative lever and the easiest to get wrong via semantic stretch, so it goes last.

**IF** two levers tie -> run the stronger one as primary and add the second as a supporting line at the end.
**ELSE** -> lock the primary lever and proceed.

### Step 4: Apply the Mother Teresa / Identifiable-Victim Rule

**ACTION:** If the message involves suffering, harm, need, or any collective beneficiary group, convert the collective to **one named individual with concrete details**. Discard aggregate statistics from the emotional section of the message entirely.

**WHY:** Mother Teresa: *"If I look at the mass, I will never act. If I look at the one, I will."* The Rokia study proved the effect is not metaphor — $2.38 vs $1.14 for the same underlying cause, differing only in whether the reader saw one child or a statistic. The theory: individuals produce empathy; masses produce the "drop in the bucket" feeling of futility, which collapses motivation. Worse, combining both modes *lowered* giving below the individual-only version because statistics drag the reader into analytical mode (Step 1's concern, but reinforced here).

**Implementation:**
- Pick ONE real or representative individual the message is ultimately about.
- Give them a name, an age, a place, and one concrete sensory detail (Rokia: *seven years old, from Mali, loves to play soccer, gets annoyed by her little brother*).
- If you have statistics you cannot bear to remove, move them to a **post-ask** context section (e.g., "About this cause" footer), never before the ask.

**IF** the ask has no beneficiary (e.g., a recruiting message for a job, a behavior change with no specific victim) -> skip this step and note "not applicable: no beneficiary frame".
**ELSE** -> produce the one-named-individual frame.

### Step 5: Maslow's Basement Check

**ACTION:** Read the draft (or your working plan) and categorize which of the eight Maslow needs each motivational appeal is targeting. Then ask: "Am I stuck in the basement?"

The eight needs, as a palette not a ladder: Transcendence, Self-actualization, Aesthetic, Learning, Esteem, Belonging, Security, Physical. (See `references/maslow-eight-levels.md` for definitions and the company-bonus experiment that demonstrates the bias.)

**WHY:** Most message designers unconsciously assume the audience is motivated only by Security, Esteem, and Physical needs while themselves pursuing Transcendence and Self-actualization. This projection-in-reverse is Maslow's basement. The Pegasus dining hall in Baghdad is the book's best counter-example: Army cook Floyd Lee ran a mess hall on identical rations and identical Army recipes as every other mess hall, but reframed his mission as *"I am not in charge of food service, I am in charge of morale"* — appealing to Transcendence, Aesthetic, and Learning needs in his staff. Soldiers drove through IED zones for his meals. The same appeal pitched as "we need to hit our meal-service KPI" would have produced nothing. If you are stuck in the basement, the upper-level rewrite is almost always available — you just have to look for it.

**Decision:** If every motivational line in the draft targets only Security/Esteem/Physical, rewrite at least ONE line to target an upper level (Transcendence, Self-actualization, Aesthetic, or Learning). Prefer Transcendence if a shared mission exists; prefer Learning or Self-actualization for professional audiences.

### Step 6: Write the Forbidden-Moves List

**ACTION:** Produce an explicit list of moves the writer MUST NOT use in executing this plan. This is a guardrail against manipulation, cheesiness, and fear-based persuasion.

Include by default:
- No fear appeals that catastrophize beyond the honest stakes.
- No guilt or shame framing ("if you don't donate, you're responsible for…").
- No semantic-stretch words (list the specific stretched words to avoid for this audience).
- No stacking statistics before the ask.
- No cost-benefit tables before the ask.
- No dense credentials walls before the emotional hook.
- No self-interest appeal that would insult the audience's identity (popcorn-popper trap).
- No invented or fictional individual presented as real (use "representative" or "composite" labels if using a constructed person).

**WHY:** The Emotional chapter's main warning is that emotional levers are powerful enough to be abused — and that abuse is what makes audiences defensive and mocking of sincere appeals. Writing the forbidden list before the writer starts forces the writer to stay inside the honest envelope. Skipping this step is how plan-only skills end up producing slick copy that reads as manipulative.

### Step 7: Output the Emotional Appeal Plan

**ACTION:** Write `emotional-appeal-plan.md` with the structure below. Do NOT write the finished copy — that is the writer's job (or a follow-on rewriting skill's job).

```markdown
# Emotional Appeal Plan: {message title}

## Core message
{one-sentence ask, carried from input}

## Audience identity profile
- Group: {who they identify as}
- What they already care about: {list}
- Under-served upper-level need: {Transcendence / Self-actualization / Aesthetic / Learning}

## Primary lever: {Identity | Self-Interest | Association}
**Why this lever:** {reasoning from Step 3 decision rules}
**How to frame it:** {2-3 sentences on the framing}
**Example opening line (for the writer to adapt):** {one line, illustrative only}

## Secondary lever (optional): {lever | none}
**How it supports:** {one sentence}

## Identifiable individual frame
{one named person with concrete details, OR "not applicable: no beneficiary frame"}

## Analytical priming to remove
- {item}: {location in draft} -> move to post-ask section or delete
- {item}: {location in draft} -> ...
OR: "No analytical priming detected."

## Maslow level(s) being targeted
{list of levels, with a note if any upper-level rewrites were applied}

## Forbidden moves
- {specific move to avoid}
- {specific stretched word to avoid}
- ...

## Rationale notes for the writer
{1-2 paragraphs explaining the core strategic choice so the writer can adapt under pressure}
```

**WHY:** The plan is the handoff artifact. A writer (human or agent) executing this plan can produce compliant copy without re-running the analysis. Without the structured output, the recommendation lives in chat and gets lost as soon as the draft needs a revision.

## Inputs

- **Core message:** one-sentence ask
- **Audience profile:** group identity, what they currently care about
- **Action sought:** specific verb — donate, join, switch, approve, rally
- **Optional — existing draft:** for analytical-priming scan and before/after comparison

## Outputs

- **`emotional-appeal-plan.md`** — structured plan (template above) covering lever choice, framing, identifiable-individual frame, analytical priming to remove, Maslow targeting, and forbidden moves. This is a plan, not finished copy.

## Key Principles

- **The mere act of calculation reduces charity.** — This is the most counter-intuitive and the most enforced rule in this skill. Do not put numbers in front of an emotional ask. WHY: Measured in a controlled experiment, analytical priming cut donations nearly in half; the reader's cognitive mode shifts from empathy to evaluation, and evaluation is fatal to charity.
- **One identifiable person beats the aggregate, always.** — WHY: Empathy is a mechanism tuned to individuals. Collective suffering produces the "drop in the bucket" feeling and collapses agency; a single named person produces the felt responsibility that drives action.
- **Identity > self-interest > association, as a default ordering.** — WHY: Identity appeals recruit the audience's self-concept as an unpaid advocate; self-interest is the workhorse default; association is powerful but fragile because stretched words kill it. When in doubt, test identity first.
- **Get out of Maslow's basement.** — WHY: Message designers systematically project a Security/Esteem motivation onto audiences that would respond more strongly to Transcendence, Learning, or Self-actualization. The upper-level rewrite is almost always available; you just have to look for it.
- **Do not manufacture emotion — piggyback on emotion already present.** — WHY: Manufactured emotion is where cheesiness and manipulation come from. Finding what the audience already feels and hooking your message onto that existing feeling is honest, sustainable, and cannot be detected as a trick.
- **Semantic stretch is real and silent.** — WHY: Words like "unique", "passionate", "innovative", "sportsmanship" have been overused until they produce no emotional response at all. The audience does not tell you the word is dead — they just stop reacting. Find a fresh synonym (Honoring the Game) or change levers.
- **Plan-only discipline prevents slick manipulation.** — WHY: If this skill wrote the finished copy, it would be tempted to optimize for punch instead of honesty. Producing a plan + forbidden-moves list forces the writer to execute inside an honest envelope.

## Examples

**Scenario: fundraising email full of statistics**
Trigger: User shares `draft.md` — a wildfire relief email that opens with *"Over 12,000 families have lost their homes in the past 30 days. Donations are down 40% year-over-year. For every $100 we raise, 15 families receive emergency shelter."* The user says: "Donations are flat. Help."
Process: (1) Analytical-priming scan flags three items (12K families, 40% YoY, $100 -> 15 families) all before the ask — [REMOVE-OR-MOVE-AFTER-ASK]. (2) Audience profile: general donors who recently saw wildfire news, already feel concerned but overwhelmed; under-served need is Transcendence (feeling they matter). (3) Primary lever = Association (tap the concern they already feel) + identifiable-individual frame. (4) Identifiable individual: "Marta, 47, a nurse from Paradise, CA, walked out of her home on Thursday with her seven-year-old's asthma inhaler and nothing else." (5) Maslow targeting: Transcendence (you can be the person who made the difference in Marta's week). (6) Forbidden moves: no statistics before ask, no catastrophizing the fire, no "if you don't donate" guilt, no stretched word "devastating". (7) Plan written.
Output: `emotional-appeal-plan.md` recommending an Association-led rewrite opening with Marta, statistics moved to a post-ask "About the crisis" footer, Transcendence framing for the donation, forbidden-moves list appended. Writer (or rewriting skill) executes.

**Scenario: recruiting memo to firefighters ignored**
Trigger: User shares a recruiting memo for a volunteer fire-safety training program. The pitch leads with "free training materials, a $50 gift card per participant, and certificates". Chiefs are ignoring it.
Process: (1) No statistics to flag, but the incentives-first framing is itself an analytical move (cost-benefit calculation). (2) Audience profile: firefighters — strong professional identity, define themselves AGAINST being consumers who need gifts. The popcorn-popper trap is live. (3) Primary lever = Identity. "A real fire chief runs a department where every rookie has had the latest burn-pattern training by week 4." (4) No beneficiary frame needed (not a charitable appeal). (5) Maslow: reframe from Esteem/Security basement to Self-actualization (mastery) and Transcendence (protecting the community). (6) Forbidden moves: do not offer the gift card in the lead, do not lead with "free" anything, do not use "participants" (frames them as consumers), do not use "incentive". (7) Plan written.
Output: `emotional-appeal-plan.md` recommending identity-led reframe ("A real fire chief…"), gift card moved to a practical footer or removed entirely, forbidden-moves list emphasizing the popcorn-popper trap.

**Scenario: change-management memo about a new internal tool**
Trigger: User shares a rollout memo for a new internal reporting tool. Current draft: *"The new dashboard consolidates 7 data sources and saves an estimated 4.2 hours per week per analyst. ROI projected at $480K annually."*
Process: (1) Analytical priming everywhere — every sentence is numbers. (2) Audience profile: analysts, professional identity as craftspeople of insight; under-served upper need is Self-actualization (doing work they're proud of). (3) Primary lever = Self-Interest at the Self-actualization level (not Esteem level) — "spend your hours on the analysis you actually want to do, not the hours you spend hunting for the data". (4) No identifiable individual (not a beneficiary situation). (5) Maslow: explicitly rewritten from Esteem/Security basement ("save time", "ROI") to Self-actualization ("spend your hours on the work you came here for"). (6) Forbidden moves: no $ figures, no % figures, no hour-counting before the ask; no generic "productivity" language (stretched); no "empowered" or "streamlined" (stretched). (7) Plan written.
Output: `emotional-appeal-plan.md` recommending a Self-interest (upper-level) lead, all ROI numbers moved to an appendix, forbidden-moves list flagging the stretched words, Self-actualization reframing noted as the primary strategic move.

## References

- For Maslow's eight needs as a non-hierarchical palette and the Maslow's-basement experiment, see [maslow-eight-levels.md](references/maslow-eight-levels.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath and Dan Heath.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/maslow-eight-levels.md
# Maslow's Eight Needs (Non-Hierarchical)

Maslow originally proposed these as a pyramid, to be climbed rung by rung. Subsequent research (and Made to Stick's reading of it) treats the list as **non-hierarchical**: most people pursue needs across all levels simultaneously. Treat it as a **palette**, not a ladder.

The trap the book calls **"Maslow's basement"**: when you assume other people are motivated only by the bottom three (Physical, Security, Esteem) while you yourself live in the upper levels. This is how a manager ends up offering a cash bonus when the audience would have worked harder for a sense of purpose.

| Level | Need | What it feels like | Example appeal |
|---|---|---|---|
| 1 | **Transcendence** | Helping others realize their potential; being part of something larger than yourself | "I am in charge of morale" (Floyd Lee); "Join the mission to end homelessness" |
| 2 | **Self-actualization** | Realizing your own potential; peak experience; self-fulfillment | "Become the writer you were meant to be"; "Master your craft" |
| 3 | **Aesthetic** | Symmetry, order, beauty | "Design worth touching"; "A kitchen you want to cook in" |
| 4 | **Learning** | Knowing, understanding, mental stimulation | "Math is mental weight training"; "Learn something new every day" |
| 5 | **Esteem** | Achievement, competence, gaining approval and status, recognition | "Be the expert in your org"; performance bonuses framed as recognition |
| 6 | **Belonging** | Love, family, affection, group membership | "A community of people like you"; team rituals |
| 7 | **Security** | Protection, safety, stability | "Protect your family"; insurance; job security |
| 8 | **Physical** | Hunger, thirst, bodily comfort | "Delicious, hot, fresh"; physical pain relief |

## How to use this table in the skill

1. Ask: **Where does my audience actually live?** Not where you assume they live — where the evidence says they live. Soldiers in Baghdad (Pegasus) were not in the physical/security basement; they were starved for Transcendence, Aesthetic, and Learning.
2. Ask: **Am I appealing from my own level, or theirs?** Managers typically assume employees are in the Security/Esteem basement while themselves pursuing Self-actualization. This is projection in reverse.
3. Ask: **Which upper level is the shortest path to action?** Transcendence and Self-actualization are the two most commonly under-used appeals. If your current pitch is stuck at Security/Esteem, try rewriting from Transcendence or Learning first.

## The "company bonus" experiment (from ch10)

Researchers asked people to predict how three versions of a $1,000 bonus pitch would land:

1. **Security framing:** "Think what $1,000 means — a down payment on a car, that home improvement."
2. **Esteem framing:** "Think of what getting a bonus means — the company recognizes how important your work is."
3. **Self-actualization framing:** "Think of what the bonus means — the freedom to do something you've always wanted but couldn't afford."

People correctly predicted that **for themselves**, #3 would be most motivating. But they predicted that **for everyone else**, #1 and #2 would be more motivating. This is Maslow's basement in action — a systematic bias that underweights the upper levels when designing appeals for others.

## Warning: do not use as a ladder

Do not write "first we'll satisfy their security needs, then their belonging needs..." People are not video games. They pursue multiple needs at once. Pick the ONE upper-level need that is most under-served by competing messages in the audience's environment, and lead with it.

---
name: curse-of-knowledge-detector
description: Diagnose a draft for the Curse of Knowledge — the expert blind spot that makes insiders write copy full of unexplained jargon, buried assumptions, strategy-level abstractions, and tacit shared context that lose non-expert audiences. Use this skill whenever reviewing a pitch, announcement, explainer, landing page, onboarding doc, slide, internal memo, or technical write-up for clarity to a non-expert. Activate when the user says things like "why isn't my message landing", "make this clearer", "my audience doesn't get it", "I can't tell if this is too technical", "diagnose this draft", "is this too jargony", "expert blind spot", "tapper listener", "translate for non-experts", "audit this for jargon", "I'm too close to this", or provides a draft plus an audience description and asks for a clarity critique. Also triggers when a user complains that smart readers stare blankly at their copy, when an explainer is full of acronyms, when an announcement leads with context instead of news, or when a strategy deck reads like a mission statement generator. This skill does NOT rewrite the draft end-to-end (that is the message-clinic skill) and does NOT score the full SUCCESs rubric (that is the stickiness-audit skill) — it produces a targeted report of Curse-of-Knowledge violations with locations, reasons, and rewrite guidance.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/curse-of-knowledge-detector
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [1, 12, 13]
tags: [communication, clarity, diagnostic, expert-blind-spot, jargon-detection, copywriting, messaging, audit, writing, plain-language]
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Draft to audit — a message, pitch, announcement, explainer, slide, memo, or product page as markdown or pasted text"
    - type: document
      description: "Audience description — who the draft is for, what they know, what they do not know"
  tools-required: [Read, Write]
  tools-optional: [Grep]
  mcps-required: []
  environment: "Any agent environment with file read/write. Document-set working environment: the agent operates on short-form prose drafts provided by the user."
discovery:
  goal: "Surface every passage in a draft where expert blind spots lose a non-expert audience, with concrete rewrite guidance."
  tasks:
    - "Audit a pitch or announcement for jargon, abstractions, and buried assumptions"
    - "Diagnose why an expert-written explainer is not landing with non-expert readers"
    - "Produce a flagged-passage report before running a full rewrite"
  audience:
    roles: [marketer, founder, communicator, product-manager, teacher, technical-writer]
    experience: any
  when_to_use:
    triggers:
      - "User provides a draft and an audience description and asks for a clarity review"
      - "User complains that smart readers are confused by their copy"
      - "Draft is authored by a subject-matter expert for a non-expert audience"
    prerequisites: []
    not_for:
      - "Rewriting the draft end-to-end — use a message-clinic skill instead"
      - "Scoring the full six-principle stickiness rubric — use a stickiness-audit skill"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
---

# Curse of Knowledge Detector

## When to Use

You have a draft (a pitch, announcement, explainer, slide, landing page, memo, or product write-up) authored by someone who knows the subject deeply, and you need to find the specific places where that expertise has corrupted clarity for a non-expert audience. Use this skill when the goal is **diagnosis, not rewriting** — you want a ranked list of Curse-of-Knowledge violations the user can act on (or hand to a rewriting skill).

**Preconditions to verify before starting:**
- The draft exists as text the agent can read (paste, markdown file, or document).
- The audience is named and at least roughly profiled — without a target audience, "too expert" is undefined.
- The user wants a critique, not a full rewrite. If they want a rewrite, hand off to `message-clinic-runner` after producing the report.

**The Curse of Knowledge, restated for the agent:** Once someone knows something, they cannot imagine not knowing it. Experts "tap" a tune they can hear in their own head (Elizabeth Newton's 1990 Stanford study: tappers predicted listeners would guess 50% of tunes; listeners got 2.5% — a 20x gap). The same expertise that produced the Answer backfires during the Telling Others stage. This skill catches the tapping.

---

## Context & Input Gathering

### Required Context (must have — ask if missing)

- **The draft:** The actual text to audit — not a summary.
  -> Check prompt for: pasted text, file path, document attachment.
  -> Ask if missing: "Paste the draft you want me to audit, or give me the file path."

- **The target audience:** Who the draft is for, and — critically — what they do NOT already know.
  -> Check prompt for: audience description, persona, reader profile.
  -> Ask if missing: "Who is this draft for? Tell me (a) their role, (b) what they already know about the subject, and (c) what you think they do not know. One sentence each is fine."

### Observable Context (gather from environment)

- **Author expertise domain:** Often visible in the prose (heavy acronyms, named frameworks, implied processes).
  -> Infer from: density of jargon, tone, structural choices.
  -> If unclear: ask one question — "Is the author a subject-matter expert in [X]?"

- **Prior attempts:** A note like "I already tried simplifying it" changes the rewrite guidance — you push for more radical reframing, not another smoothing pass.
  -> Look for: user comments about previous drafts.

### Default Assumptions

- **Assumption: the author is closer to the subject than the reader.** State this in the report. The Curse is a one-way disease — detection assumes the author is the "tapper," not the "listener."
- **Assumption: the audience cannot ask follow-up questions.** Drafts are typically read asynchronously. If the audience can ask, note the change in severity (Q&A recovers some clarity; it does not cure the Curse).

### Sufficiency Threshold

- **SUFFICIENT:** Draft text + audience description with at least role and "what they do not know."
- **PROCEED WITH DEFAULTS:** Draft + role-only audience. Flag the missing "does not know" list in the report so the user can supply it later.
- **MUST ASK:** No draft, OR audience is "general public" with no narrowing (too vague — every reader is different and the skill cannot detect insider assumptions without a contrast point).

---

## Process

### Step 0: Initialize task tracking
**ACTION:** Create a TodoWrite checklist with the steps below.
**WHY:** This is a multi-pass audit. Tracking prevents the agent from fusing passes into a single shallow scan, which is the failure mode that produces "looks fine to me" false negatives. Each pass has a different target and must run independently.

### Step 1: Establish the "listener baseline"
**ACTION:** Write a one-paragraph profile of the audience in plain terms. List explicitly: (a) vocabulary they know, (b) vocabulary they do NOT know, (c) processes/workflows they understand, (d) processes they do NOT understand, (e) prior context they have, (f) prior context they lack. Use the audience description supplied by the user and your own reasoning.
**WHY:** You cannot detect Curse-of-Knowledge violations without a contrast point. The tapper/listener experiment works because the listener's state of mind is knowable (they literally cannot hear the tune). For a draft, you simulate the listener by writing down, up front, what the listener can and cannot hear. Every subsequent flag is scored against THIS baseline, not a generic "average reader."

**Save:** The listener baseline as the first section of the output report.

### Step 2: Pass A — Unexplained jargon, acronyms, and named frameworks
**ACTION:** Scan the draft and flag every term that appears in the draft but not in the listener baseline's "vocabulary they know" list. Include: acronyms (including common-in-industry ones the audience may not share), proper nouns referring to internal tools/products/projects, named frameworks (e.g., "SUCCESs framework", "Sinatra Test"), technical verbs used as nouns ("a retro", "a standup"), and metaphors borrowed from a sub-field the audience does not live in.
**WHY:** Jargon is the most visible Curse-of-Knowledge symptom. It is also the easiest to miss in self-review because the author reads every term as transparent. A mechanical pass catches what an "impression pass" glosses over.

**For each hit record:** location (quote or line reference), the term, why a listener would not parse it, and a rewrite option (define on first use, swap for a common-language equivalent, or remove if not load-bearing).

### Step 3: Pass B — Abstraction ladder (strategy-level talk)
**ACTION:** Re-read each paragraph and ask: "Is the sentence operating at the level of STRATEGY (goals, visions, synergies, principles) or the level of ACTION (observable behavior, physical object, named person, concrete step)?" Flag sentences that live at the strategy level without ever dropping to the action level. Apply the Boeing 727 test: "If this were replaced by a concrete constraint ('seat 131 passengers, land on Runway 4-22, one mile long'), would the sentence lose meaning or gain it?" If concrete constraints GAIN meaning, the abstract original is a Curse-of-Knowledge hit.
**WHY:** Experts prefer the strategy level because they have internalized the concrete layer and find it tedious. Non-experts can only anchor to concrete objects, people, and behaviors ("bishops moving diagonally," not "chess strategy"). Abstract-only copy is readable but un-actionable — the reader finishes the paragraph and cannot say what anyone would DO differently tomorrow. This is exactly what the JFK "man on the moon" example contrasts with the modern-CEO "maximize shareholder value" failure mode.

**For each hit record:** location, the abstract phrase, a specific concrete translation (actor + verb + observable object), and whether the fix is "add a concrete example" or "replace the abstraction entirely."

### Step 4: Pass C — Buried assumptions and tacit shared context
**ACTION:** For each claim in the draft, ask: "What does the reader have to ALREADY believe or know for this sentence to land?" Write the implicit premise. Then check it against the listener baseline. If the premise is not on the listener's "known" list, the sentence is a Curse-of-Knowledge hit even if every word is plain English.
**WHY:** This is the subtlest axis and the one where "it sounds clear" audits miss the most. A sentence like "we're deprecating the legacy pipeline" has no jargon to the author — but assumes the reader knows (a) there is a pipeline, (b) there is a legacy version and a new version, (c) "deprecate" is a soft word for "turning off," and (d) the reader is a stakeholder in the decision. Each of those assumptions is a tapper tapping a tune. Surfacing the buried premises IS the diagnosis.

**For each hit record:** location, the explicit premise the reader must hold, whether the listener baseline shows they hold it, and a rewrite option (state the premise, link to a primer, or restructure).

### Step 5: Pass D — Buried lead and common-sense sedation
**ACTION:** Read the first sentence of the draft. Ask: "Is this the single most important thing the reader must walk away with?" If not, flag "buried lead" (the Nora Ephron journalism-teacher test: the lead is `there will be no school Thursday`, not `principal announces faculty retreat`). Then scan the draft for sentences every member of the audience would nod and agree with before reading — "customer service is important," "communication is key." Flag these as "common sense sedation." Both failure modes are Curse-of-Knowledge symptoms: the author is leading with context they already know, or stating positions so internalized they feel like news to the author but are invisible to the reader.
**WHY:** The Heaths frame "burying the lead" as the first villain named after the Curse in the Epilogue — "we're tempted to share it all" because we know it all. Common-sense statements are a second-order Curse effect: the author forgot what it was like not to already agree. Both pass the plain-English test but fail the stickiness test.

**For each hit record:** location, the failure mode (buried-lead OR common-sense), and one concrete replacement sentence.

### Step 6: Synthesize the report
**ACTION:** Combine the four pass outputs into a single prioritized report with this structure:
1. **Listener baseline** (from Step 1).
2. **Tapper/listener gap estimate** — your one-sentence summary of the delta between what the draft assumes and what the listener baseline actually holds. Be specific. ("Author assumes reader knows what a feature flag is, what rollout means, and why staged rollouts reduce risk. Listener baseline shows none of these are held.")
3. **Top 3 rewrite targets** — the three highest-impact hits across all four passes, ranked by (severity × how much of the draft they poison). Each gets: quote, pass it came from, why it hurts, specific rewrite.
4. **Full flagged-passage table** — every hit from Passes A–D with columns: location, passage, pass (A/B/C/D), why, rewrite guidance.
5. **Listener simulation test** — three to five questions the listener baseline-reader would plausibly ask the author after reading the draft. These are the gaps the rewrite must close.
6. **Handoff note** — one sentence saying whether the draft needs jargon substitution (lightweight), structural rework (lead repositioning + abstraction concretization), or a full rewrite from the core message up.

**WHY:** The user asked for diagnosis, not a pile of annotations. The top-3 ranking and the handoff note tell them what to DO with the report. Without prioritization, a long flagged-passage table produces analysis paralysis — the exact anti-pattern Made to Stick warns against in Chapter 1.

**Save:** The full report to `curse-of-knowledge-report.md` in the user's working directory.

### Step 7: Structural self-check
**ACTION:** Before returning, verify: (a) every flagged passage has a location, a reason, and a rewrite option — not just "unclear"; (b) the listener baseline is specific enough that someone else could re-run the audit and reach similar conclusions; (c) the top-3 are actually ranked, not just listed; (d) the handoff note is one decisive sentence, not a hedge.
**WHY:** The audit's value is in its specificity. A report that says "some parts could be clearer" is indistinguishable from generic AI advice — it produces no delta over a baseline agent. Specificity (location + reason + rewrite) is what makes the skill book-derived rather than generic.

---

## Inputs

- `draft` — the text to audit (markdown, pasted text, or file path).
- `audience` — a description of the target reader, minimum role + "what they do not know."
- Optional: `mode_note` — "lightweight pass" or "full four-pass audit" (default: full).

## Outputs

A single file, `curse-of-knowledge-report.md`, with this shape:

```markdown
# Curse of Knowledge Report — {draft name}

## Listener Baseline
{audience role, known vocabulary, unknown vocabulary, known processes, unknown processes, held context, missing context}

## Tapper/Listener Gap Estimate
{one-sentence delta}

## Top 3 Rewrite Targets
1. **{quote}** — Pass {X}. Why: {reason}. Rewrite: {concrete fix}.
2. ...
3. ...

## Flagged Passages (Pass A: Jargon)
| Location | Passage | Why a listener cannot parse it | Rewrite |

## Flagged Passages (Pass B: Abstraction)
| Location | Passage | Abstract level | Concrete translation |

## Flagged Passages (Pass C: Buried Assumptions)
| Location | Passage | Implicit premise | Present in listener baseline? | Rewrite |

## Flagged Passages (Pass D: Buried Lead / Common Sense)
| Location | Passage | Failure mode | Replacement sentence |

## Listener Simulation Questions
- Q1: {a question the listener baseline-reader would ask after reading}
- ...

## Handoff Note
{one decisive sentence: jargon substitution | structural rework | full rewrite}
```

---

## Key Principles

- **You cannot cure the Curse, only route around it.** The Heaths are explicit: "There are only two ways to beat the Curse of Knowledge reliably. The first is not to learn anything. The second is to take your ideas and transform them." Detection means finding what must be transformed — not guilting the author into "trying harder to be clear."

- **The listener baseline is the only ground truth.** Every flag is relative to a specific listener profile. A term that is "jargon" to a recruit is "common language" to an engineer on the same team. If you skip the baseline and audit against a generic reader, you produce generic feedback — which is exactly the delta gap the skill is supposed to close.

- **Multi-pass beats single-pass.** Each pass targets a different axis (lexical, structural, tacit, prioritization). Fused into one pass, the agent defaults to the most visible axis (jargon) and misses the subtler ones (buried assumptions, common-sense sedation). The book's entire methodology is structured this way — six principles, each addressed on its own — because human authors cannot hold all axes at once.

- **Specificity is the value.** "This paragraph is too abstract" is free advice. "Replace `maximize shareholder value` with `grow revenue by 20% this year by winning back 10 lapsed accounts` (actor + verb + measurable object)" is the skill. Every flag must include a concrete rewrite option or it is noise.

- **Prioritize ruthlessly; report faithfully.** The top-3 is the action surface. The full table is the audit trail. Without the top-3, the user drowns in findings (decision paralysis — a named Made to Stick failure mode). Without the full table, the user cannot trust the top-3. Both are required.

- **The author is not the villain.** Curse-of-Knowledge is a natural psychological tendency, not a skill deficit. Frame the report so the author can see the failure mode as structural — "here is where your expertise created a gap" — not as criticism.

---

## Examples

**Scenario: Product announcement for a developer tool, audience is non-technical buyers**

Trigger: User pastes a 400-word announcement that opens "We're shipping v2 of our feature-flag rollout engine with staged canaries and blast-radius controls." Audience: "VP of Engineering buyers at mid-market SaaS companies — they manage engineers but haven't written code in five years."

Process: (1) Listener baseline notes "feature flag" = probably known, "canary", "blast radius" = probably not known, "staged rollout" = known in principle, "rollout engine" = ambiguous. (2) Pass A flags `canaries`, `blast-radius`, `rollout engine`. (3) Pass B flags the abstract noun "controls" with no concrete behavior. (4) Pass C flags the buried assumption that the reader already wanted v2. (5) Pass D flags the buried lead — the actual news ("our tool now prevents the top three rollout-caused outages buyers told us about") is in paragraph 4.

Output: `curse-of-knowledge-report.md` with Top 3 = (1) move the paragraph-4 news to sentence 1, (2) define `canary` on first use as "a small slice of users who see the change first", (3) replace "blast-radius controls" with "automatic rollback if error rate crosses a threshold you set." Handoff note: "Structural rework — lead repositioning plus three jargon substitutions."

**Scenario: Nonprofit fundraising letter, audience is first-time donors**

Trigger: User pastes a 600-word letter from a global-health nonprofit that leads with program architecture, regional coverage statistics, and the M&E framework. Audience: "First-time individual donors, $25–$100 range, no prior engagement with global health."

Process: (1) Listener baseline: knows what a nonprofit is, does not know `M&E`, `catchment area`, `DALY`, does not know the named regions, does not know the organization's history. (2) Pass A flags four acronyms. (3) Pass B flags "program architecture" and "regional coverage" as strategy-level. (4) Pass C flags the assumption that the reader already cares about sub-Saharan maternal health statistics. (5) Pass D flags the buried lead (there is no Rokia-style individual named person) and flags "we are committed to lasting impact" as common-sense sedation.

Output: Top 3 = (1) open with a named beneficiary (the Mother Teresa / Rokia effect — identifiable victim beats statistics), (2) replace `M&E`, `DALY`, and `catchment area` with plain equivalents or cut them, (3) cut the "committed to lasting impact" sentence entirely. Handoff note: "Full rewrite from the core message — the current draft is architected around the organization's self-description, not the donor's decision."

**Scenario: Internal all-hands memo about a strategy pivot, audience is all employees**

Trigger: CEO pastes a memo that mentions "shareholder value," "synergies across business units," and "our North Star metric." Audience: "All 400 employees — roles range from engineers to facilities staff. Most have not attended exec strategy meetings."

Process: (1) Listener baseline: broadly varied — assume the lowest-context reader does not know `North Star metric`, does not know which business units exist, does not know what "shareholder value" means for their day-to-day. (2) Pass A flags `North Star`, `synergies`. (3) Pass B flags the entire memo as strategy-level with no concrete behavior change. (4) Pass C flags the assumption that readers know why the pivot is happening. (5) Pass D flags severe common-sense sedation across three paragraphs that any reader would already agree with.

Output: Top 3 = (1) add a concrete "what changes for you on Monday" paragraph per role category, (2) replace `North Star` with the actual metric and its target number, (3) cut the two paragraphs of values-language that add no news. Handoff note: "Full rewrite — this is the Made to Stick-canonical 'maximize shareholder value' failure at scale."

---

## References

- For the full jargon-substitution decision tree and worked word-swap tables, see [jargon-detection-playbook.md](references/jargon-detection-playbook.md)
- For the abstraction-ladder worked examples (Boeing 727, JFK moon mission, Commander's Intent, maximize shareholder value), see [abstraction-ladder-examples.md](references/abstraction-ladder-examples.md)
- For the full listener-baseline template and audience-profile interview script, see [listener-baseline-template.md](references/listener-baseline-template.md)

---

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath and Dan Heath.

## Related BookForge Skills

This skill is standalone (Level 0 foundation). Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/abstraction-ladder-examples.md
# Abstraction Ladder Examples

Worked before/after pairs for Pass B (Abstraction / Strategy-Level Talk). Each example shows a sentence that sounds clear to an expert but fails the Boeing-727 test, then a concrete rewrite.

## The ladder, briefly

| Level | What lives here | Readability | Coordinates action? |
|-------|-----------------|-------------|--------------------|
| 5. Values | "excellence", "integrity" | feels profound | no |
| 4. Strategy | "maximize shareholder value" | feels important | no |
| 3. Principle | "put the customer first" | feels true | weakly |
| 2. Behavior | "answer every support ticket within 4 hours" | boring | yes |
| 1. Object | "Tracy the flight attendant served complimentary champagne" | vivid | yes |

Made to Stick's central claim: experts drift upward (because they have already internalized the concrete layer). Non-experts can only anchor to levels 1 and 2. Every Pass B flag is a sentence stuck at levels 3–5 that needs a drop to level 1 or 2.

## Example 1 — The canonical contrast (from the book's Introduction)

**Before (level 4):** "Our mission is to maximize shareholder value through synergistic growth and operational excellence."

**After (level 2):** "Ship three new products this year. Double revenue in our European accounts. Cut support-ticket resolution time from 48 hours to 8."

**Why:** The "before" is readable, but after reading it, no employee knows what to do on Monday morning. The "after" specifies observable outcomes. The Heaths contrast this directly with JFK's moon-mission sentence — "put a man on the moon and return him safely to Earth by the end of the decade" — which is a level-1 constraint (man, moon, safely, decade) that coordinated a decade of action without further translation.

## Example 2 — The Boeing 727 test (from Chapter 3 Concrete)

**Before (level 4):** "Design the best single-aisle passenger jet in the world."

**After (level 1):** "Design a plane that seats 131 passengers, flies nonstop from Miami to New York City, and lands on Runway 4-22 at LaGuardia — which is less than a mile long."

**Why:** The "best" phrasing cannot coordinate thousands of engineers across wings, engines, landing gear, and cabin. The "level-1" version constrains every subsystem simultaneously. Wings must produce enough lift at that weight. Landing gear must handle that runway. Engines must reach cruise for that distance. A concrete constraint is a coordination device; an adjective is not.

## Example 3 — Commander's Intent (from Chapter 1 Simple)

**Before (level 3 principle):** "Execute the operational plan with agility and adapt to changing conditions."

**After (level 1 behavior + end state):** "Clear Hill 4305 of enemy remnants so 3rd Brigade can pass through."

**Why:** When the plan doesn't survive contact, the principle ("adapt") gives no guidance. The Commander's Intent sentence — one end state, one named object — lets a subordinate abandon the written plan and still win. If you can't write the one-sentence intent, you don't have a core.

## Example 4 — Southwest Airlines (from Chapter 1 Simple)

**Before (level 4):** "We want to be the best airline experience for value-conscious travelers through operational efficiency."

**After (level 3, but with a delegation test):** "We are THE low-fare airline."

Delegation test: Tracy from marketing wants to add a light chicken Caesar salad on the Houston-Las Vegas flight. Herb Kelleher's answer: "Tracy, is adding the Caesar salad going to make us THE low-fare airline? Because if it isn't, we're not serving it."

**Why this example is subtle:** "THE low-fare airline" sits at level 3, not level 1 — it's still a principle. What makes it work is the exclusion clause ("and nothing else"). A new hire at Southwest can make a contested trade-off from the core alone. "Maximize shareholder value" cannot pass this test. When auditing for Pass B, ask: **can a new hire resolve a contested decision from this sentence alone?** If yes, the sentence passes. If not, it is stranded above the coordination line.

## Example 5 — Nonprofit fundraising (maps to Rokia effect, Chapter 5 Emotional)

**Before (level 5 values):** "We are committed to improving outcomes for vulnerable populations in under-resourced regions."

**After (level 1 object + person):** "We bought mosquito nets for Amina, age 4, and her three siblings in Lilongwe. Last year they had malaria twice. This year: zero."

**Why:** "Vulnerable populations" cannot activate the identifiable-victim effect the Heaths document in the Save the Children Rokia study (donors gave $2.50 to the named child and $1.14 to the statistic). Every abstract population noun in a fundraising letter is a Pass B flag.

## Example 6 — Technical documentation, audience = ops engineers

**Before (level 3):** "The service uses eventual consistency semantics for cross-region replication."

**After (level 2):** "When you write a value in the US region, it appears in the Europe region within 2-5 seconds. During that window, a read from Europe may return the old value. A read from the US returns the new value immediately."

**Why:** "Eventual consistency semantics" is accurate and to an expert it feels precise. To a reader debugging a bug at 2am, it gives no operational prediction. The level-2 rewrite tells the reader what will happen in observable time.

## How to generate the concrete translation

When a Pass B flag fires, apply this template to produce the rewrite:

1. **Who is the actor?** (Not "the team" or "we" — a named role or person.)
2. **What observable verb?** (Not `leverage`, `enable`, `drive` — a verb the actor physically performs.)
3. **What object?** (A physical or digital thing the reader could point at.)
4. **Under what constraint?** (A number, a deadline, a named reference case.)

If any of these four cannot be filled in for the abstract sentence, you have confirmation that the abstract sentence is not actionable — not because you are being pedantic, but because the author has not yet decided what the sentence means in practice. This is a signal to the user: the Curse is covering a decision that has not been made.

## Edge case: when abstraction is intentional

Not every abstract sentence is a Curse-of-Knowledge hit. Values statements, brand voice lines, and aspirational mission text are sometimes supposed to live at levels 4-5. Before flagging, ask: **does the draft have ANY level-1 or level-2 anchor?** If there is at least one vivid concrete scene somewhere in the draft, the abstract sentences around it can stand. If EVERY sentence is at level 3+, the whole draft is Curse-of-Knowledge territory and needs a concretization pass, not a polish pass.

FILE:references/jargon-detection-playbook.md
# Jargon Detection Playbook

Detailed guidance for Pass A (Unexplained Jargon, Acronyms, and Named Frameworks). Use alongside the main SKILL.md Process → Step 2.

## What counts as jargon for this skill

A term is "jargon" relative to a listener baseline if ANY of these are true:

1. **Lexical opacity.** The reader cannot reasonably parse the term from its parts (e.g., `blast radius`, `eventual consistency`, `BATNA`).
2. **Semantic drift.** The term is a common English word used in a specialist sense the reader does not hold (e.g., `commit` for code, `surface` as a verb meaning "reveal", `ship` for release).
3. **Acronym opacity.** The reader may know ONE expansion but not YOURS (e.g., `CDP` = Customer Data Platform vs Continuous Delivery Pipeline vs Clean Development Mechanism).
4. **Named-framework shorthand.** The draft references a framework by name (`SUCCESs framework`, `Sinatra Test`, `STAR format`, `RICE scoring`) without a one-line gloss.
5. **Proper-noun opacity.** References to internal projects, tools, teams, or people the reader does not work with (`the Apollo migration`, `the Foundry team`, `what Sarah said last quarter`).
6. **Borrowed metaphor.** A metaphor taken from a sub-field the reader does not live in (`the chess strategy`, `the orchestration layer`, `the spine of the product`).

## Fast-scan heuristics

When auditing a draft, apply these in order. Each is cheap and catches a distinct failure mode.

### Heuristic 1: Capital-letter density
Count capitalized nouns per 100 words. Above ~6 per 100 is a strong signal of named-framework / proper-noun overload.

### Heuristic 2: Acronym expand-on-first-use test
For every acronym, check: is it expanded on first use in the draft? If no, flag. If yes, is the expansion itself parseable to the listener baseline? (Expanding `API` to `Application Programming Interface` is not parseable to a non-engineer — you need one more hop.)

### Heuristic 3: The "pause test"
Read each sentence aloud. If you have to pause to decide how to pronounce a term, the reader's eye will stutter there too. Flag it.

### Heuristic 4: The "swap test"
For each suspect term, mentally substitute a generic placeholder (`[thing]`, `[process]`). If the sentence still makes sense to the listener, the term was load-bearing jargon and needs a gloss. If the sentence loses nothing, the term was decorative and should be cut.

## Rewrite options (in order of preference)

For each flagged term, offer one of these four fixes. Prefer the earliest option that preserves meaning.

1. **Remove.** The term is decorative. Cut it.
2. **Substitute.** Replace with a common-language equivalent. (`leverage` -> `use`, `bandwidth` -> `time`, `surface` -> `show`.)
3. **Gloss inline.** Keep the term but add a short parenthetical definition on first use. (`We use feature flags (on/off switches that let us turn a new feature on for some users without redeploying)`.)
4. **Gloss in a footnote or sidebar.** Use only for terms the reader will see repeatedly and should learn.

Only keep a term unchanged if the listener baseline explicitly shows the reader knows it.

## Worked examples

### Example 1 — SaaS product announcement, audience = business buyers

Draft: "We are GA on the new idempotent retry handler with exponential backoff."

Flags:
- `GA` — acronym, not expanded. Substitute: "generally available" or just "launched".
- `idempotent` — lexical opacity for business buyers. Substitute: "safe-to-retry".
- `retry handler` — borrowed technical metaphor. Substitute: "automatic retry system".
- `exponential backoff` — named technique. Remove (buyers don't need the algorithm) or gloss: "waits longer between each retry".

Rewrite: "We launched a safe-to-retry system that automatically tries failed requests again with growing wait times between attempts."

### Example 2 — Internal HR memo, audience = all employees

Draft: "Per our new L&D OKR, all ICs should complete the DE&I module by EOQ."

Flags: `L&D`, `OKR`, `ICs`, `DE&I`, `EOQ`. All acronyms, none expanded, reader is "all employees" including facilities and operations staff who do not live in HR shorthand.

Rewrite: "Everyone except managers (we call these 'individual contributors' or ICs) should finish the new diversity, equity, and inclusion training by the end of September."

### Example 3 — Academic grant abstract, audience = program officers from another field

Draft: "We propose a mixed-methods investigation of non-cognitive skill formation using IRT-scaled assessments."

Flags: `mixed-methods` (known in some social sciences, unknown in STEM program offices), `non-cognitive skill formation` (opaque compound), `IRT-scaled` (named technique).

Rewrite options: define each on first use, OR reframe the abstract in plain language and move the technical terms to the methods section.

## Anti-patterns the playbook catches that a generic grammar pass misses

- **"Consultant stack" sentences.** Chains of four+ abstract business nouns: `strategic alignment`, `value creation`, `core competency`, `operational excellence`. Each term is technically English, but together they are pure tapping.
- **Hollow verbs.** `Leverage`, `enable`, `drive`, `facilitate`, `orchestrate`. These verbs carry no sensory information. Flag them as Pass B (abstraction) but note them in Pass A if they let a named framework hide.
- **Framework-name inflation.** Using `SUCCESs framework` in a draft for an audience that has not read the book is a dead giveaway. Same for `BATNA`, `NPS`, `PMF`.

FILE:references/listener-baseline-template.md
# Listener Baseline Template

A filled-in template for Step 1 of the skill. The listener baseline is the single most important artifact in the audit — every subsequent flag is scored against it — so this reference gives you a reliable shape and an interview script to fill in missing information.

## Why this template exists

The Curse of Knowledge experiment works because the listener's state of mind is knowable: they literally cannot hear the tune the tapper is hearing. For prose, we have to manufacture that knowability. The listener baseline is the manufactured listener — a written profile that the rest of the audit treats as ground truth.

Without a written baseline, the agent defaults to "generic reasonable reader" and produces generic feedback. The book is explicit: the Curse cannot be cured, only routed around, and the routing requires a specific listener.

## Template

```markdown
## Listener Baseline: {audience short name}

### Role and context
- **Role:** {e.g., "VP of Engineering at a 200-person B2B SaaS company"}
- **Reading context:** {async email / deck in meeting / landing page / onboarding doc}
- **Can they ask follow-up questions?** {yes / no / partial}
- **Time budget for this draft:** {how long they will realistically read before bouncing}

### Vocabulary they KNOW
- {term 1}: {why — e.g., "used daily in their role"}
- {term 2}: {why}
- {term 3}: {why}
...

### Vocabulary they do NOT know
- {term 1}: {why — e.g., "engineering-internal"}
- {term 2}: {why}
- {term 3}: {why}
...

### Processes they understand
- {process 1}: {depth — surface / working / deep}
- {process 2}: {depth}
...

### Processes they do NOT understand
- {process 1}: {why}
- {process 2}: {why}
...

### Prior context they hold
- {thing 1}: {source — e.g., "from previous email in thread"}
- {thing 2}: {source}
...

### Prior context they LACK
- {thing 1}: {what they do not know}
- {thing 2}: {what they do not know}
...

### Emotional/identity stakes
- **What they care about in this decision:** {the reader's actual motivation}
- **What they do NOT care about:** {items authors often assume the reader cares about but does not}
- **Identity frame:** {who they see themselves as when reading — "pragmatic operator", "strategic thinker", "worried parent", etc.}

### What would make this reader stop reading
- {reason 1 — e.g., "any sentence longer than 30 words in paragraph 1"}
- {reason 2}
...
```

## Interview script (when the user provides a thin audience description)

If the user's audience description is too vague to fill out the template, ask THESE questions — one at a time. Do not batch.

1. **"What is this reader's role and seniority?"** (You need the role to infer vocabulary and processes.)

2. **"Pick one: is this reader (a) a subject-matter expert in the same field as the author, (b) an adjacent expert from a related field, (c) an informed non-expert, or (d) a general reader?"** (This single multiple-choice question does most of the work — the four categories have very different jargon tolerances.)

3. **"Name three things the author knows that you are SURE this reader does not know."** (This is the most valuable question. Authors often know the answer immediately and it anchors the whole baseline.)

4. **"Name three things the author thinks this reader cares about that they actually might not."** (Catches the identity / motivation gap that Pass C will use.)

5. **"What decision do you want this reader to make after reading?"** (If the user cannot answer this in one sentence, flag it — the draft has no core, which is a bigger problem than the Curse.)

6. **"Will this reader see the draft in isolation or inside a thread / deck / conversation?"** (Changes what "prior context they hold" can include.)

Stop after question 6 — even if incomplete, you have enough to begin. Note remaining gaps at the top of the report as "assumptions the audit depends on."

## Worked baseline — Example 1

**Draft:** SaaS product announcement for a developer-tools company.
**User's audience description:** "VP of Engineering buyers at mid-market SaaS companies."

### Filled baseline

- **Role:** VP Eng, mid-market B2B SaaS, budget authority, manages 20-80 engineers
- **Reading context:** async email from their AE, probably on phone
- **Can they ask follow-up questions?** Yes but they will not — they will forward or delete
- **Time budget:** 60 seconds for paragraph 1, another 60 if hooked

**Knows:**
- `feature flag` (they have used LaunchDarkly or similar)
- `staging` and `production` environments
- `incident`, `outage`, `postmortem` (from their ops-review meetings)
- `SLA`, `uptime` (from their vendor contracts)

**Does NOT know:**
- `canary` (knows the concept of gradual rollout but not this word)
- `blast radius` (metaphor, not used outside of SRE subculture)
- `idempotent`, `eventual consistency` (they have not coded in 5 years)
- internal product names of the tool vendor

**Processes they understand:** vendor evaluation, budget cycles, incident-response escalation (at a management level, not at the keyboard level).

**Processes they do NOT understand:** the actual rollout mechanism at the code level. They know that engineers "turn features on for some users first" but not how.

**Prior context they hold:** they have heard of the vendor (probably), they know feature-flag tools exist as a category.

**Prior context they LACK:** what `v1` of this product did, what changed in `v2`, who else is using it.

**Cares about:** reducing incidents, team productivity, budget predictability, CVs for their engineers.
**Does NOT care about:** the algorithmic details of the rollout engine, the vendor's engineering-team size.

**Identity frame:** "pragmatic operator" — does not want to look foolish in front of their engineers by buying a toy, but also does not want to debug vendor pitches.

**Would stop reading if:** first paragraph is full of SRE jargon, or if the first sentence is organizational news ("We're excited to announce...").

## Worked baseline — Example 2

**Draft:** Grant application abstract from a social-science research group.
**User's audience description:** "Program officer at an interdisciplinary foundation — probably trained in a different field."

### Filled baseline

- **Role:** Program officer, PhD in some field (probably not this one), reviews ~200 abstracts per cycle
- **Reading context:** batch review, 3-5 minutes per abstract max
- **Can they ask follow-up questions?** No — the abstract is the decision
- **Time budget:** 90 seconds per abstract at the filter stage

**Knows:**
- general academic vocabulary (`hypothesis`, `sample`, `controls`, `significance`)
- how grants work, budget ranges, review criteria
- the foundation's own program areas

**Does NOT know:**
- field-specific named methods (`IRT scaling`, `difference-in-differences`, `fixed effects`)
- field-specific jargon compounds (`non-cognitive skill formation`)
- which researchers in the field are famous

**Cares about:** does this fit our funding priorities, is the team credible, is the method sound enough that our board won't embarrass us.
**Does NOT care about:** methodological novelty for its own sake.

**Identity frame:** gatekeeper who wants to say yes to good work but has to triage hard.

**Would stop reading if:** the first two sentences are pure methods jargon, or if the problem statement does not connect to a human-visible outcome.

## How to use the baseline

Once filled out, the baseline is the left-hand column of every subsequent flag. For each sentence in the draft, the agent asks:

- Pass A: Is every term in this sentence in the "knows vocabulary" list?
- Pass B: Does this sentence reach down to a process or object the reader understands?
- Pass C: Does this sentence depend on prior context the reader holds?
- Pass D: Does this sentence match what the reader actually cares about and identifies with?

If any answer is no, the sentence is a flag, and the rewrite guidance uses the baseline's vocabulary and context to produce a specific fix.

---
name: curiosity-gap-architect
description: "Build an Unexpected hook for a message, pitch, essay, ad, talk, or email — first break the audience's expected pattern to CAPTURE attention, then open a curiosity gap (a knowledge gap they didn't know existed) to HOLD attention all the way to the core message. Use this skill whenever the user says 'how do I hook them', 'what's my opening line', 'I need to get attention', 'this is boring how do I make it interesting', 'what's my angle', 'stop losing the audience', 'hook for my post', 'cold-open', 'lead paragraph', 'ad headline', 'landing page hero', 'intro for my talk', 'title that makes people click', 'my opening is flat', 'people tune out in the first 10 seconds', 'how do I make this dry topic interesting', 'email subject line', 'tweet hook', 'YouTube intro', 'TED-style opener', 'how Nora Ephron taught leads', 'Cialdini mystery opening', 'how to use surprise without being gimmicky'. Applies the two Unexpected mechanisms from Made to Stick Chapter 2: (1) SURPRISE via schema-break for short-term attention capture, (2) CURIOSITY GAP via Gap Theory of Curiosity (Loewenstein) for long-term attention hold. Every surprise option is scored against the POST-DICTABLE TEST — a good surprise feels inevitable in hindsight and drives home the core message; a gimmicky surprise gets a laugh but the audience can't remember the point. Produces 3 scored hook variants the user can drop into their draft. Does NOT rewrite the body of the message — only the hook and the gap structure. Does NOT manufacture shock or clickbait for its own sake. Relevant for: copywriters, marketers, product marketers, founders pitching, teachers, trainers, public speakers, content writers, journalists, fundraisers, PR, messaging, narrative design, persuasion, attention, Heath brothers, SUCCESs, Unexpected, Gap Theory, Loewenstein, schema break, postdictable, Ephron lead, Nordstrom Nordies, Cialdini Saturn rings, popcorn Silverman."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/curiosity-gap-architect
metadata: {"openclaw":{"emoji":"🪝","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [2, 7]
tags: [communication, messaging, copywriting, marketing, persuasion, attention, curiosity-gap, unexpected-principle, hook-writing, public-speaking, made-to-stick, success-framework]
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "draft.md — the current version of the message, pitch, ad, post, or talk that needs a better hook"
    - type: document
      description: "core-message.md (optional) — the one-sentence thing that must survive if the audience remembers nothing else. If missing, the skill extracts a working core from the draft and asks the user to confirm it."
    - type: document
      description: "audience-beliefs.md (optional) — what the audience currently believes, expects, or takes for granted about the topic. Used to decide which schema to break. If missing, the skill asks 3 targeted questions."
  tools-required: [Read, Write]
  tools-optional: [TodoWrite, Grep]
  mcps-required: []
  environment: "Document set. Agent reads draft + optional brief, writes hook-options.md with 3 scored variants."
discovery:
  goal: "Produce 3 hook variants that break the audience's expected pattern and open a curiosity gap leading directly to the core message, each scored against the post-dictable test."
  tasks:
    - "Extract or confirm the core message the hook must deliver the audience to"
    - "Surface the audience's current schema — the pattern the hook will break"
    - "Draft 3 hook variants across 3 mechanisms (schema-break lead, mystery opener, news-teaser gap)"
    - "Score each variant against the post-dictable test: does the surprise land the core, or just make noise?"
    - "Output hook-options.md ranked with rationale, rejected variants, and drop-in placement notes"
  audience:
    roles: [marketer, copywriter, founder, product-marketer, content-writer, public-speaker, teacher, fundraiser]
    experience: beginner-to-intermediate
---

# Curiosity Gap Architect

Build the opening of a message that captures attention by breaking a pattern, then holds attention by opening a gap the audience needs to close — without falling into shock, clickbait, or gimmick.

## When to Use

Use this skill when:

- **You have a draft but the opening is flat.** The body is solid; the audience would love it — if they got past the first sentence. They don't.
- **Your topic is technically important but feels dry.** You have a statistic, a policy, a feature, a lesson, a cause — and every attempt to open with it sounds like homework.
- **You're competing with infinite scroll.** Email subject, tweet, YouTube intro, landing hero, ad headline, talk opener — anywhere the first 3 seconds decide whether the next 30 happen.
- **You need to HOLD attention across a longer piece.** Not just a one-shot surprise. An essay, a whitepaper, a 20-minute talk, a sales page. You need a gap the reader carries through to the end.
- **Someone tried to be surprising and it backfired.** The shock worked but the message didn't. The audience remembered the stunt, not the point. You need the post-dictable test.

Do NOT use this skill when:

- The draft has no core message yet (the hook has nothing to deliver the audience to). Use `core-message-extractor` or `simple-core-message-distiller` first, or extract a working core inside this skill and confirm it with the user.
- The goal is to rewrite the body of the message for clarity, concreteness, credibility, or emotion. Those belong to the other SUCCESs skills. This skill changes only the hook and the gap architecture that spans the piece.
- The medium forbids a hook entirely (legal disclosures, regulated compliance copy, SLAs). The Unexpected principle does not apply to contracts.

## Context & Input Gathering

### Required Context (must have — ask if missing)

- **Draft:** Current version of the opening you want to rewrite (email, ad, post, talk script, lead paragraph, landing hero).
  - Look for: `draft.md`, `copy.md`, `post.md`, `hook.md`, pasted text in the prompt.
  - If missing: "Paste the current opening — just the first 1–5 sentences, plus one line of what comes after."

- **Core message:** The one thing the audience must walk away remembering. (Commander's Intent.)
  - Look for: `core-message.md`, `brief.md`, or a labeled line in the draft.
  - If missing: extract a candidate from the draft, show it to the user, and ask "Is this the thing you want to land? If not, correct it in one sentence."
  - WHY blocking: a hook without a destination is clickbait. The post-dictable test is impossible to apply without knowing what the surprise is supposed to make inevitable.

### Observable Context (gather, do not block on)

- **Audience beliefs / schema:** What does the audience currently assume about the topic? What's the default pattern the hook will break?
  - Look for: `audience-profile.md`, `audience-beliefs.md`, a section in `brief.md`.
  - If missing, ask up to 3 short questions:
    1. "Who is the audience in one line?"
    2. "If the audience had to finish the sentence '[topic] is usually ___,' what would they write?"
    3. "What would make them say 'huh, I didn't expect that'?"

- **Medium and length budget:** one-line subject? 280 char tweet? 90-second cold open? 3-paragraph lead?
  - Affects the mechanism choice (see Step 3).

- **Prior attempts that failed:** If the user has tried hooks before, what was rejected and why ("too gimmicky", "too slow", "off-brand")?
  - Look for: `rejected-hooks.md`, inline comments in the draft.
  - Use to avoid re-suggesting the same failure mode.

### Sufficiency Threshold

- **SUFFICIENT:** Draft opening + confirmed core message + at least one sentence on audience schema.
- **PROCEED WITH DEFAULTS:** Draft + core message, no explicit audience schema (infer from the draft, flag assumption in output).
- **MUST ASK:** No draft OR no recoverable core message.

## Process

### Step 0: Initialize Task Tracking

**ACTION:** Create a TodoWrite list with the 5 process steps below.
**WHY:** This skill's failure mode is skipping the post-dictable test and shipping a clever-but-empty hook. Tracking forces you to hit Step 4 before declaring the artifact ready.

### Step 1: Confirm the Core Message

**ACTION:** Find or extract the one sentence the hook must deliver the audience to. If you had to extract it, write it back to the user in the form `"Core message I'm building the hook for: <sentence>. Confirm or correct."` Wait for confirmation only if the extraction is ambiguous.

**Artifact:** One-sentence core message logged at the top of `hook-options.md`.

**WHY:** The Unexpected principle only works in service of a core. Heath brothers' rule: surprise must be *postdictable* — in hindsight it must feel like the inevitable setup for this specific core. If the core is vague, every hook will feel gimmicky because nothing can make it feel inevitable. Garbage core in, gimmick out.

### Step 2: Surface the Audience Schema

**ACTION:** Write down, in 1–3 bullets, the expectations the audience brings to this topic right before they hit the hook. Specifically:
- What category do they file this topic under?
- What's the standard opening for a message in this category?
- What's the predictable next sentence after the draft's current first line?

**Artifact:** `## Schema to break` section in `hook-options.md`.

**WHY:** You cannot break a pattern you have not named. The Enclave minivan ad (Ch2) works because the writer first identified the minivan-commercial schema (cup holders, sky-view roof, suburban dad) and then violated it at a sharp moment (T-bone collision). Without naming the schema, the "surprise" is just a random swerve — the audience has nothing to be surprised *from*. Most failed hooks skip this step and jump straight to "be punchy."

### Step 3: Draft 3 Hook Variants Across 3 Mechanisms

**ACTION:** Produce exactly three variants, each using a different mechanism. Drafting fewer than three hides the tradeoff; drafting more wastes tokens and dilutes the post-dictable test.

**Mechanism A — Schema-Break Lead (capture, short-form):**
- Set up the default category for a half-beat, then violate it in the next beat.
- Use when the medium is short (headline, subject line, ad, cold open, first paragraph).
- Target: an instant "wait, what?" that resolves immediately into the core.
- Exemplar: **Nora Ephron's journalism teacher.** The class wrote leads like "Principal Kenneth L. Peters announced this morning that the entire high school faculty will travel to Sacramento for a colloquium." The teacher's flip: *"The lead is — there will be no school Thursday."* The schema ("announcements are about who announced what") is violated by the real lead ("what does this mean for me").

**Mechanism B — Schema-Break Dramatization (capture, mid-form):**
- Build up the expected pattern deliberately, then collapse it at a single sharp moment that the core message then explains.
- Use when you have 3–10 sentences, a short video, a landing hero section, or a cold-open scene.
- Target: a vivid image the audience can replay in their head that *already contains* the core.
- Exemplar: **CSPI's Art Silverman on movie popcorn.** A medium popcorn has 37g of saturated fat. Instead of quoting the number, Silverman staged a table: a bacon-and-eggs breakfast, a Big Mac lunch, a steak dinner — and the bag of popcorn, which equalled all three combined. The schema ("popcorn is a snack") breaks the moment the camera pans. Rule of thumb: if your statistic won't stick, find a familiar reference object that makes the magnitude visceral.
- Exemplar: **Nordstrom Nordies.** To teach "outstanding service" the company doesn't post a values poster; it tells the story of the Nordie who refunded snow tires Nordstrom never sold, or gift-wrapped goods bought at Macy's. The schema ("retail workers follow rules") is broken by a specific, repeatable incident. Use this pattern when the core is a cultural norm or behavior.

**Mechanism C — Curiosity Gap Opener (hold, long-form):**
- Open with a genuine knowledge gap the reader didn't know existed, then make the rest of the piece the resolution.
- Use when the medium is long: whitepaper, essay, sales page, 20-minute talk, feature announcement you want people to finish.
- Target: a gap painful enough that the reader commits to staying until it closes.
- Exemplar: **Cialdini's Saturn-rings opener.** Cialdini found the most memorable science writing started with a genuine mystery — *"three top labs disagree on what the rings of Saturn are made of"* — and used the essay to resolve it. The reader didn't know there was a disagreement; now they need to.
- Exemplar: **News-teaser pattern** ("Which local restaurant has slime in its ice machine? Details at 11."). A pointed, specific question whose answer is exactly the core message.
- Exemplar: **Priming a gap in a boring domain** (Roone Arledge's NCAA football broadcasts). When the topic is dry, front-load questions the novice now realizes they can't answer, then pay them off one by one.

**For each variant, write:**
```
### Variant [A|B|C]: <mechanism name>
Hook (drop-in text): <1–5 sentences, exact copy the user can paste>
Pattern broken: <the schema or expectation the hook violates>
Gap opened: <the specific knowledge gap — only for Mechanism C; for A/B, write "N/A — capture only">
Bridges to core via: <one sentence showing how this hook makes the core message feel inevitable>
```

**WHY three:** The Heath brothers distinguish SURPRISE (short-term capture) from INTEREST (long-term hold) as two different problems. Drafting only capture variants solves the first problem and loses the second; drafting only curiosity-gap variants solves the second and fails at the door. Forcing one of each makes the mechanism choice visible to the user rather than hidden behind the writer's instinct.

**Artifact:** `## Variants` section with three subsections.

### Step 4: Score Each Variant Against the Post-Dictable Test

**ACTION:** For every variant, answer four questions in writing. No variant ships without all four answered.

1. **Post-dictable?** *After the audience reads the full message, does the surprise feel inevitable — like of course the piece had to open that way?* If yes, 1 point. If the surprise is an unrelated stunt the audience would have to forgive, 0.
2. **Delivers the core?** *Is the specific core message the thing the surprise makes inevitable?* If yes, 1. If the surprise lands some core but not the one you confirmed in Step 1, 0.
3. **Schema actually present?** *Is the pattern being broken a pattern the audience actually holds?* If the schema is only in the writer's head, the surprise will land as "weird" rather than "unexpected." 1 or 0.
4. **Gap resolvable by this specific piece?** *(Mechanism C only)* The gap must be payable off by the body the user already has. A gap this piece can't close is clickbait. 1 or 0 for C; N/A for A and B.

**Reject any variant that scores 0 on question 1 or 2.** Those are the gimmick-trap failures. Rewrite the variant or mark it as rejected with a note.

**Rank the surviving variants.** Tiebreaker goes to the variant whose pattern-break is tightest (fewest words between setup and violation) for short-form, or whose gap is narrowest (most specific unanswered question) for long-form.

**Artifact:** `## Post-dictable scorecard` table in `hook-options.md` with one row per variant, plus a `## Ranking` section.

**WHY:** This is the skill's core defense against the single failure mode the Heaths call out repeatedly: surprise used as decoration. The test is written explicitly because even experienced writers skip it — if the hook *feels clever*, they ship it. The question "would this feel inevitable in hindsight?" is the only reliable filter between sticky Unexpected and forgettable gimmick.

### Step 5: Write the Hook-Options Artifact

**ACTION:** Assemble `hook-options.md` with the sections produced above, in this order:
1. `# Hook options for: <short title>`
2. `## Core message (confirmed)` — one sentence.
3. `## Schema to break` — 1–3 bullets.
4. `## Variants` — Variant A, B, C with drop-in text.
5. `## Post-dictable scorecard` — 4-column table.
6. `## Ranking` — numbered list with one-line rationale per variant, rejected variants flagged.
7. `## Placement notes` — where in the draft each ranked variant should be dropped and what line of the current draft it replaces.
8. `## What this skill did NOT change` — explicit note that the body of the message is untouched; point to the appropriate SUCCESs skills if further rewriting is needed (concrete-language swapper, credibility anchor, emotional pathway, story frame).

**WHY a physical artifact:** The user ships copy, not understanding. An explanation of "how to write a better hook" is worth nothing at 11pm before the launch; three variants and a ranking with drop-in text are immediately usable. Every BookForge skill ends with an artifact the user can ship or paste.

## Key Principles

- **Surprise is a tool, not a goal.** The Heath brothers repeat this with the word *postdictable*: the surprise must make the core feel inevitable. If your hook could sit on top of any message, it's decoration. Kill it.
- **Capture and hold are two jobs.** Short-form media only needs capture (Mechanism A). Long-form media dies without hold (Mechanism C). Mid-form usually needs both in sequence. Decide which job you're doing before you draft.
- **You can only break a named schema.** Spend a minute writing down the audience's default pattern. Every failed "surprising" hook in the wild violates a schema that existed only in the writer's head.
- **A gap is a promise, and the body must pay it.** Curiosity gap openers fail when the piece cannot resolve the gap they opened. A whitepaper that opens "why is X true?" and never answers X teaches the audience the source lies. Open only gaps this piece can close.
- **Gimmick vs Unexpected is a single question.** "After the audience has read the core, does the surprise feel inevitable?" No other test matters. Feels clever, makes them laugh, gets retweets — all irrelevant if the answer is no.
- **Specific always beats abstract in a hook.** Slime in the ice machine beats "contamination in restaurants." Three labs disagreeing on Saturn's rings beats "open questions in astronomy." Tire chains Nordstrom never sold beats "outstanding service." Concrete nouns are what let the schema break land.

## Examples

### Example 1: Dry product announcement needs a hook (short-form)

**Scenario:** A SaaS company is launching a new feature: their database migration tool now validates row counts before cutover. The PM writes: "We're excited to announce a new pre-cutover validation step in our migration tool, providing additional safety for enterprise customers."

**Trigger:** "Help me, this is boring, nobody's going to read past the first line."

**Process:**
1. Core message confirmed: *"Our migration tool now catches silent data loss before cutover, not after."*
2. Schema to break: audience (platform engineers) assumes feature-launch posts open with "we are excited to announce…" and are safe to skim.
3. Variants:
   - **A (Schema-break lead):** *"The worst kind of migration bug is the one that succeeds."* Pattern: launch posts open with a feature; this opens with a fear the reader has lived.
   - **B (Schema-break dramatization):** *"Imagine: the migration finishes green. Every monitor is calm. Three days later, support tickets start arriving from customers whose orders have vanished. Nobody knows when it happened."* Pattern: launch posts are about what the tool does; this is about what you'll never notice it doing until now.
   - **C (Curiosity gap opener):** *"Why did 7 of the last 10 silent-data-loss incidents we investigated look green in the migration console? Three answers, and the fix we shipped last week."* Pattern: promises a count and a fix.
4. Post-dictable scorecard: A scores 3/3, B scores 3/3, C scores 4/4. All three ship. Ranking: C first (long-form post, best hold), A second (best drop-in for subject line), B third.

**Output (`hook-options.md`):** Three drop-in variants, scorecard, placement notes. The PM picks C for the blog post, A for the email subject line.

### Example 2: Fundraiser for a research nonprofit (mid-form)

**Scenario:** A nonprofit studying rare pediatric kidney disease has a donation letter. Current opening: "Our team has been working tirelessly to advance research into pediatric nephrotic syndrome."

**Trigger:** "This reads like every other nonprofit letter. How do I make it actually land?"

**Process:**
1. Core message confirmed: *"A single researcher, funded by people like you, is the only person in the world studying the subtype that killed Emily."*
2. Schema to break: nonprofit letters open with "our team" / mission-speak / statistics.
3. Variants:
   - **A (Schema-break lead):** *"There is one doctor in the world studying what killed Emily. Her name is Dr. Martinez. Her lab has three people. You fund two of them."* Pattern broken: fundraising letters are about the cause; this is about a count — one, three, two.
   - **B (Dramatization):** Silverman-style — *"Pediatric nephrotic syndrome has more research dollars than you'd think — roughly the cost of one Super Bowl ad per year. Spread across the whole field. Now subtract the subtypes that already have funding. Now subtract the ones with fewer than 200 known cases. What's left is Dr. Martinez's lab."* A bagged-popcorn-next-to-a-steak-dinner staging in words.
   - **C (Gap opener):** *"Why does the rarest kidney disease in children have exactly three researchers worldwide? The answer isn't money. Keep reading."*
4. Post-dictable scorecard: A 3/3, B 3/3, C rejected — the letter cannot pay off "the answer isn't money" because the body's ask IS money. Fails test 4. Rewrite C as: *"Three people in the world are trying to save children like Emily. Here is what each of them does on Monday morning."* This version opens a gap the letter can close (specific work). Rescored 4/4.

**Output:** Two surviving variants plus the rewritten C, with a note that the original C was rejected because the curiosity gap did not match what the body of the letter was capable of resolving.

### Example 3: Conference talk cold-open (mid-form)

**Scenario:** A senior SRE is giving a 20-minute talk on post-incident reviews. Opening slide currently says "Learning from Production Incidents: A Practitioner's Guide."

**Trigger:** "Give me a cold open that isn't 'hi my name is.'"

**Process:**
1. Core message confirmed: *"The post-incident review you write in the first 48 hours is almost always wrong about the cause, and that's fine — write it anyway."*
2. Schema to break: SRE talks open with a definition of reliability or a fancy outage graph.
3. Variants:
   - **A (Schema-break lead):** *"Every post-incident review I've ever written has been wrong. So has every one you've written. Let's talk about why that's the right outcome."*
   - **B (Dramatization):** *Slide 1: an incident timeline. Slide 2: the same timeline six months later, with three of the 'root causes' struck through. 'This is the same incident. The middle version is what we told leadership. The bottom version is what actually happened. I want to talk about the gap between them.'*
   - **C (Gap opener):** *"Why do the best post-incident reviews tend to be the ones that contradict themselves six months later? I'll tell you what I found after reviewing 40 of ours."* (Nordie-style specific count.)
4. Post-dictable scorecard: A 3/3, B 4/4 (strongest because the schema-break is built into the visual), C 4/4. Ranking: B first, A second, C third.

**Output:** Three cold-open variants with exact speaker lines and slide cues. The SRE opens with B.

## References

- Source: *Made to Stick* Chapter 2 "Unexpected" and the "Easy Reference Guide" — Gap Theory of Curiosity (Loewenstein), postdictable surprise, schema-break, movie-popcorn/Silverman, Nordstrom Nordies, Nora Ephron lead, Buick Enclave ad, Cialdini Saturn-rings mystery.
- Related SUCCESs skills in this book (forthcoming in the same skill set): `core-message-extractor`, `curse-of-knowledge-detector`, `velcro-theory-concretizer`, `compact-message-pattern-picker`, `stickiness-audit`.

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — *Made to Stick: Why Some Ideas Survive and Others Die* by Chip Heath and Dan Heath.

## Related BookForge Skills

This skill is part of the forthcoming `bookforge-made-to-stick` skill set covering the full SUCCESs framework. It is designed to be used standalone, but composes naturally with `core-message-extractor` (to confirm the core before drafting the hook) and `stickiness-audit` (to score the whole message after the hook is in place). Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills).

---
name: credibility-evidence-selector
description: "Pick the strongest credibility evidence for a claim and kill weak evidence chains with the Sinatra Test. Use this skill whenever the user asks 'how do I prove this?', 'how do I make this more credible?', 'which statistic should I cite?', 'do I need a source for this?', 'how do I build trust?', 'this claim sounds unbelievable', 'they won't believe us', 'we need a case study', 'should I quote an expert?', 'is this testimonial strong enough?', 'which proof point should I lead with?', 'my pitch needs more evidence', 'the numbers aren't landing', 'how do I back this up without a credentials wall?', 'who should say this for maximum credibility?', or 'is one example enough or do I need data?'. Also invoke when the user has a marketing claim, sales pitch, fundraising ask, research finding, policy argument, product benefit, or security/reliability promise and must choose between authority quotes, customer stories, statistics, vivid details, testable demos, or a single hero example. This skill ranks evidence across six named credibility categories (external authority, antiauthority, testable credentials, vivid details, Sinatra Test hero example, statistics-as-illustration) and applies the Sinatra Test as a pass/fail filter to cut weak chains. Run BEFORE shipping any claim that a skeptical audience might doubt."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/credibility-evidence-selector
metadata: {"openclaw":{"emoji":"🔬","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [9, 13]
tags: [credibility, evidence, persuasion, marketing, sales, messaging, sinatra-test, proof, bookforge]
depends-on: []
execution:
  tier: 1
  mode: plan-only
  inputs:
    - type: document
      description: "The claim the user needs to support (one sentence)."
    - type: document
      description: "Evidence inventory — the proof points, stories, stats, testimonials, and demos the user has available."
    - type: document
      description: "Audience profile — who will judge the claim and what they are skeptical about."
  tools-required: [Read, Write]
  tools-optional: [Edit]
  mcps-required: []
  environment: "Operates on prose artifacts — claims, pitches, marketing copy, fundraising asks, research summaries. No codebase or tooling required."
discovery:
  goal: "Select the strongest credibility evidence for a claim and apply the Sinatra Test to kill weak evidence chains."
  tasks:
    - "Rank available evidence across six credibility categories"
    - "Run the Sinatra Test on a candidate hero example as a pass/fail gate"
    - "Decide whether to lead with an authority quote, a testable demo, a single hero case, or vivid details"
    - "Diagnose a claim that feels unconvincing and prescribe the missing credibility type"
    - "Convert an abstract statistic into a human-scale illustration"
  audience:
    roles: [marketer, founder, sales-professional, communicator, fundraiser, researcher, policy-writer]
    experience: any
  when_to_use:
    triggers:
      - "User has a claim that a skeptical audience might reject"
      - "User is choosing between stats, quotes, stories, and demos as proof"
      - "User is drafting a credibility paragraph and has too many options"
      - "A case study feels weak and the user is not sure why"
    prerequisites: []
    not_for:
      - "Fabricating evidence — this skill selects from what already exists"
      - "Running A/B copy experiments — use a testing skill"
      - "Extracting the core message itself — use core-message-extractor first"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores: {}
    tested_at: null
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Credibility Evidence Selector

## When to Use

You have a claim a skeptical audience might reject, and a bag of possible proof points (stats, quotes, stories, demos, details). You need to decide which evidence to lead with — and which to cut. This skill ranks evidence across six named credibility sources and applies the Sinatra Test as a pass/fail filter to kill weak chains before they reach the audience.

Run this skill when the user is about to ship a claim without thinking hard about *why* the audience would believe it. Run it BEFORE writing the final copy, not after — the choice of evidence type reshapes the whole paragraph.

**Preconditions to verify before starting:**
- You know the specific claim. If missing, ask: "What is the exact one-sentence claim you need the audience to believe?"
- You have an evidence inventory (even a rough list). If missing, ask: "What proof points do you have — stats, stories, customers, experts, demos, details?"
- You know the audience's default skepticism. If missing, ask: "Who is judging this, and what is the one thing they'd say to dismiss it?"

**Do NOT use this skill for:**
- Fabricating evidence. This skill ranks what exists; it never invents sources.
- Designing experiments or user studies.
- Extracting the core message (use `core-message-extractor` first — credibility is applied to a core, not in place of one).

## Context & Input Gathering

### Required Context (must have — ask if missing)
- **The claim:** the exact sentence the audience must believe.
  -> Check prompt for: a quoted claim, a pitch paragraph, a headline, a research finding.
  -> Check environment for: `claim.md`, `draft.md`, `pitch.md`, `core-message.md`.
  -> If still missing, ask: "What is the one-sentence claim — the thing the audience must believe?"
- **Evidence inventory:** the candidate proof points available.
  -> Check prompt for: lists of customers, stats, quotes, case studies, demos, testimonials.
  -> Check environment for: `evidence.md`, `proof-points.md`, `case-studies/`, `testimonials.md`, `customer-stories/`, a `data/` dir.
  -> If still missing, ask: "What evidence do you already have? Dump a rough list — customers, numbers, experts, stories, demos, details — I will rank them."
- **Audience skepticism profile:** who judges the claim, and their default objection.
  -> Check prompt for: role, domain, familiarity, prior objections.
  -> If missing, ask: "Who will read this, and what would they say to dismiss the claim?"

### Observable Context (gather from environment)
- **Prior credibility drafts:** existing "why trust us" copy, testimonial pages, case study PDFs.
  -> Look for: `about.md`, `trust.md`, `social-proof.md`, `testimonials.md`, `case-studies/`.
  -> If present: mine for candidate evidence; treat as raw material, not final answer.
- **Brand voice constraints:** legal review rules, claims guidelines.
  -> Look for: `brand-guide.md`, `legal/claims.md`.
  -> If present: note which evidence types are disallowed (e.g., "no unverified customer quotes").

### Default Assumptions
- Medium: short-form text (one paragraph, one slide, one email). State this assumption if used.
- Audience default: mildly skeptical professional, not a hostile expert. Upgrade to hostile if the user says so.
- Evidence claims are truthful — the skill trusts the user's inventory and does not fact-check.

### Sufficiency Threshold
- SUFFICIENT: claim + evidence inventory + audience known.
- PROCEED WITH DEFAULTS: claim + evidence known, audience inferable from context (state the inference).
- MUST ASK: claim is not a single sentence, OR evidence inventory is completely empty (cannot rank nothing).

## Process

### Step 1: Lock the Claim to a Single Sentence
**ACTION:** Write the claim as one sentence with a clear subject, verb, and measurable predicate. Reject hedges ("might," "could help," "in some cases"). Save it under a `## Claim` heading in `credibility-plan.md`.

**WHY:** Credibility attaches to a specific assertion, not a vibe. If the claim is "we help teams ship faster," no evidence can be strong or weak — the claim is too fuzzy to judge. Locking the sentence forces the later steps to pick evidence that actually answers the specific assertion. Fuzzy claims are where weak evidence hides; tightening the claim is half the work of ranking the proof.

**IF** the claim is still multi-part ("we are fast, cheap, and reliable") -> split into one file per claim and run this skill once per claim.
**ELSE** -> proceed.

### Step 2: Inventory Evidence Into the Six Categories
**ACTION:** Take every proof point the user has and sort it into one of six credibility categories. Some evidence fits multiple — list it under the strongest fit only. Write the result as a `## Evidence Inventory` section with six sub-headings.

**The Six Credibility Sources (from Chapter 4 CREDIBLE):**

1. **External Authority** — a recognized expert, institution, or celebrity endorsement. Example: a Nobel laureate, an industry analyst, a peer-reviewed study. *Strength:* borrows the audience's existing trust. *Weakness:* cheap to fake and audiences are now skeptical of expert voices; "analyst-quoted" pitches blur together.
2. **Antiauthority (Credible Victim / Lived Experience)** — an ordinary person who lived the consequences. Not an expert; their biography IS the proof. Example: Pam Laffin — age 29, mother of two, started smoking at 10, emphysema at 24, failed lung transplant — used for anti-smoking messaging because no statistic lands like a face that earned the cost. *Strength:* inverts expert fatigue. *Weakness:* emotionally heavy; must be ethical and consensual.
3. **Testable Credentials ("Try It Yourself")** — the audience can verify the claim in real time, with their own senses, before committing. Example: Wendy's "Where's the beef?" (you can see the tiny patty). Snickers "satisfies" (you can feel it). Barry Marshall drinking a beaker of *H. pylori* bacteria, inducing gastritis, then curing himself — a self-experiment as a public, falsifiable demonstration that ulcers are bacterial. *Strength:* collapses the skeptic's objection into a single observable act. *Weakness:* only works when real-time verification is possible.
4. **Vivid, Convincing Details** — specific sensory or biographical detail that an inventor could not have bothered to fake. Example: the juror study where jurors believed a mother who testified her child had a "Goofy toothbrush" he loved to brush with — the trivial detail signaled an observer telling the truth, not a litigant pitching a case. *Strength:* non-obvious signal that the speaker has been close to the thing. *Weakness:* easy to confuse with purple prose; the detail must be load-bearing, not decorative.
5. **Sinatra Test (One Overwhelming Hero Example)** — a single reference so dominant that the audience cannot doubt you afterward. Named after "If you can make it there, you'll make it anywhere." Example: Safexpress, an Indian logistics firm, won enterprise contracts by saying "we delivered the final Harry Potter book to 6,000 Indian bookstores in one day, sealed, no leaks" — one sentence that obliterates the due-diligence conversation. Fort Knox security contractor = you're in the running for every security contract. *Strength:* replaces a wall of credentials with one unforgettable story. *Weakness:* only works when the hero case is genuinely the hardest case in the domain.
6. **Statistics-as-Illustration (Human Scale)** — a number converted into a concrete, sensory comparison so the audience can feel the magnitude. Example: explaining US/Soviet nuclear arsenals not as "thousands of warheads" but as "if a BB represents the Hiroshima bomb, the world's nuclear stockpile is a garbage can full of BBs — and one BB can level a city." Stats as raw numbers are forgettable; stats as illustration are sticky. *Strength:* anchors an abstract scale to a physical image. *Weakness:* only works if the illustration is honest — if the analogy flatters the number, the audience will catch you.

**WHY:** Sorting forces you to see that you usually do not have six types of evidence — you have two or three, and one slot is empty. The empty slots are signals: if you have zero testable credentials, ask whether you can manufacture one (a free trial, a public benchmark, a demo). The inventory is also the cut list; evidence that does not fit any category is usually rationalization, not proof.

**Anti-pattern to flag:** *credentials wall.* If the entire inventory lands under "External Authority," the user is leaning on a stack of expert quotes. Audiences skim credentials walls and remember nothing. Go find one testable credential or one Sinatra hero and lead with that instead.

### Step 3: Rank by the Default Preference Order
**ACTION:** Apply the default preference order from strongest to weakest and rank the candidates. Write the result as a `## Ranked Evidence` section.

**Default preference order** (Chapter 4 CREDIBLE):
1. **Testable Credentials** — the audience verifies with their own senses.
2. **Sinatra Test Hero Example** — one overwhelming case.
3. **Vivid Convincing Details** — truthful trivia that signals firsthand knowledge.
4. **Antiauthority (Credible Victim)** — lived experience beats expertise for behavior change.
5. **Statistics-as-Illustration** — numbers rescued by human-scale analogy.
6. **External Authority** — expert quote as last resort, not first move.

**WHY:** The ordering is not arbitrary — it tracks how audiences actually process claims. Testable credentials short-circuit skepticism ("I just saw it"); Sinatra heroes override it ("if they did THAT, I believe the rest"); vivid details bypass it ("no one would bother to invent that"); antiauthorities reframe it ("a doctor would lie; this mother wouldn't"); illustrated stats make it tangible; and authorities — cheapest to fake, most diluted by overuse — come last. Inverting this order is the most common credibility mistake: leading with a quote from a Gartner report when you have a customer who would pass the Sinatra Test.

**Override rules** (apply when defaults don't fit):
- **IF** the audience is a domain of credentialed peers (scientists reviewing research, doctors reading a trial) -> External Authority moves up to #1 or #2, because the audience's own credential norms require it.
- **IF** the claim is a behavior-change ask aimed at the people who resist expert messaging (teens on smoking, developers on technical debt, users on security hygiene) -> Antiauthority moves to #1.
- **IF** the claim is about scale / magnitude / cost / risk that audiences cannot feel intuitively -> Statistics-as-Illustration moves up (nuclear-warheads-as-BBs was the only way to make that scale real).

### Step 4: Run the Sinatra Test as a Pass/Fail Gate
**ACTION:** Take the strongest candidate from Step 3 (especially if it's a case study, customer example, or hero story) and run the Sinatra Test as a binary pass/fail. Write the result as a `## Sinatra Test` section with verdict, reasoning, and — if failed — a replacement plan.

**The Sinatra Test, stated formally:**
> An example passes the Sinatra Test when ONE example alone is enough to establish credibility in a given domain — because the example represents the *hardest case* the domain can throw at you.

**The three questions:**
1. **Is this the hardest case?** If the audience heard only this one example and nothing else, would they concede the full category? (Fort Knox security = yes, any security contract follows. Harry Potter delivery for 6,000 bookstores in one day, sealed = yes, any logistics contract follows.)
2. **Is the hard part legible?** Can the audience *see* why it was hard without a paragraph of explanation? Sinatra examples are self-evidently difficult — "Fort Knox" and "Harry Potter launch day" need no setup. If you must explain why the case was hard, it is not Sinatra material.
3. **Is it verifiable?** Can the audience check the claim if they wanted to? A Sinatra hero that cannot survive a two-minute Google search is worse than no Sinatra at all — it becomes a credibility *liability* on discovery.

**WHY:** The Sinatra Test exists because one dominant example is cheaper and stickier than a capabilities deck, but a *weak* hero example is worse than a deck — the audience senses the cherry-picking and punishes you. The three questions are the diagnostic: hardest case, legibly hard, checkable. Any failure means replace, don't patch. The Marshall ulcer story passes because drinking a beaker of bacteria is unambiguous; a vendor's "we helped a Fortune 500 save 15%" fails because it is neither the hardest case nor self-evidently hard.

**IF** the candidate passes all three questions -> mark PASS, make it the lead evidence.
**ELSE IF** it fails one question -> mark FAIL, cut it from the lead, and either find a stronger example or fall back to the next category in the ranking (vivid details or testable credentials).
**ELSE IF** no candidate passes -> do NOT fabricate one. Accept that the claim has no Sinatra-grade proof and move to multi-source credibility (testable demo + vivid detail + illustrated stat).

**Anti-pattern to flag:** *Sinatra inflation.* The user wants their best customer to pass the Sinatra Test and is willing to argue for it. If you have to argue, it fails — the test is whether the audience recognizes the hardness instantly. Three extra sentences of framing is a flunk.

### Step 5: Check for the "Sound Bite / Credentials Wall" Failure Modes
**ACTION:** Review the ranked evidence against two named failure modes from the book and note any hits in a `## Diagnostic Notes` section.

**Failure mode A — The Credentials Wall.** Symptom: the evidence is a list of logos, titles, and expert quotes with no single piece of proof an audience can remember. Consequence: audience forgets everything and defaults to their prior belief. Fix: replace the wall with one Sinatra hero or one testable credential. If you cannot, your claim is stronger than your evidence — shrink the claim.

**Failure mode B — The Raw Statistic.** Symptom: a scary or impressive number without a human-scale translation ("we prevent 3.2M attacks per day"). Consequence: the number washes past the audience. Fix: apply the nuclear-warheads-as-BBs move — convert to a sensory comparison. "3.2M attacks per day = 37 attacks every second — one every time you blink."

**WHY:** Credibility is a negative-space problem. The right evidence makes the claim stick, but the *wrong* evidence actively weakens it — a credentials wall signals insecurity, and a raw statistic signals that the speaker never tested their own number on a human. Running these checks after ranking catches cases where the strongest evidence in the inventory still triggers a failure mode, and the fix is not ranking-higher but *rewriting* the evidence into a stronger form.

### Step 6: Write the Output Artifact
**ACTION:** Assemble the final `credibility-plan.md` with these sections, in order:

```
# Credibility Plan

## Claim
<one-sentence claim>

## Audience Skepticism
- Who: <role / segment>
- Default objection: <the one thing they'd say to dismiss this>

## Evidence Inventory (Six Sources)
### External Authority
- <evidence> — <one-line note>
### Antiauthority (Credible Victim)
- ...
### Testable Credentials
- ...
### Vivid Convincing Details
- ...
### Sinatra Test Hero Example
- ...
### Statistics-as-Illustration
- ...

## Ranked Evidence
1. <category> — <evidence> — <why it leads>
2. ...

## Sinatra Test
- Candidate: <the hero example tested>
- Hardest case? <yes/no + reasoning>
- Hard part legible? <yes/no + reasoning>
- Verifiable? <yes/no + reasoning>
- VERDICT: PASS | FAIL
- IF FAIL: <replacement plan>

## Diagnostic Notes
- Credentials wall? <yes/no + fix>
- Raw statistic? <yes/no + illustration>

## Recommendation
Lead with: <the one piece of evidence to put first>
Support with: <1-2 backup pieces>
Cut: <evidence that weakens the claim and should be removed>

## Assumptions
- <any inferred audience/claim/evidence assumption the user should confirm>
```

**WHY:** The artifact separates *ranking* (what I have) from *recommendation* (what to lead with) from *cut list* (what to remove). Users resist cuts; seeing them attached to specific failure modes ("this is a credentials-wall entry") makes the cut negotiable point-by-point rather than an all-or-nothing argument. The Sinatra Test section is kept verbatim (three questions, verdict, replacement) because it is the single most defensible step — a downstream reviewer who disagrees with the lead evidence has to disagree with a named, checkable test.

## Inputs

- The one-sentence claim that needs credibility.
- The evidence inventory (rough dump is fine — customers, stats, experts, stories, demos, details).
- The audience skepticism profile (who judges; their default objection).
- Optional: medium constraints (character limit, slide vs paragraph vs email), legal/brand guidelines on allowed evidence.

## Outputs

- `credibility-plan.md` — the artifact defined in Step 6, containing:
  - The locked claim.
  - Evidence sorted into the six categories.
  - Ranked evidence with an explicit lead.
  - A Sinatra Test block with pass/fail and reasoning.
  - Diagnostic notes on credentials-wall and raw-statistic failure modes.
  - A cut list of evidence that should be removed.
  - An assumptions block for anything inferred.

## Key Principles

- **One overwhelming example beats a wall of credentials.** — The Sinatra Test exists because audiences remember one hero case and forget ten expert quotes. When you have a genuine hardest-case reference, lead with it and cut the quote stack; when you don't, do not manufacture one — fall back to testable credentials or vivid details.
- **Testable credentials collapse skepticism into a single observable act.** — "Where's the beef?" works because the audience verifies with their own eyes. Barry Marshall drinking *H. pylori* works because the demonstration is public and falsifiable. When you can give the audience a way to check the claim themselves, nothing else in the evidence stack matters nearly as much.
- **Antiauthority beats authority for behavior change.** — The people most resistant to expert messaging — teens on smoking, developers on technical debt, users on security — are often best reached by someone who lived the consequences, not someone who studied them. Pam Laffin's biography outperformed any Surgeon General report because her body was the proof.
- **Raw statistics are forgettable; illustrated statistics are sticky.** — A number alone ("3.2M attacks per day") washes past. The same number translated to human scale ("37 every second — one every time you blink") lands. The nuclear-warheads-as-BBs move is not decoration; it is how abstract magnitude becomes emotionally real.
- **Vivid details signal firsthand observation.** — The juror who believed a mother because she mentioned a "Goofy toothbrush" did not decide on the toothbrush — she decided on the fact that no liar would bother inventing that detail. Load-bearing trivia is a credibility signal; decorative trivia is just prose.
- **Evidence ordering is a trust hierarchy, not a taste preference.** — The default preference order (testable > Sinatra > details > antiauthority > illustrated stats > authority) tracks how skepticism actually resolves. Inverting it — leading with a credentials wall — is the most common and most damaging credibility mistake in this book.
- **When the evidence fails, shrink the claim.** — If no evidence category produces a defensible lead, the claim is stronger than the proof supports. The fix is not to pad with weaker evidence; it is to tighten the claim until the available evidence is genuinely sufficient.

## Examples

**Scenario: B2B security startup with a credentials wall**
Trigger: Founder says "our homepage lists 14 analyst quotes and 40 customer logos but nobody books a demo. How do I make the security claim more credible?"
Process: (1) Lock claim: "Our system blocks every known credential-stuffing attack pattern." (2) Inventory — 14 entries under External Authority, 2 under Vivid Details (an incident-response write-up mentioning a specific attacker TTP), 1 under Sinatra (they run security for a top-3 global bank's consumer login). (3) Rank: the bank reference is Sinatra-grade; testable credentials missing; authority dominates inventory (credentials wall). (4) Sinatra Test on the bank reference — Hardest case? Yes (top-3 global bank, consumer login = highest-volume attack surface). Legibly hard? Yes (audience instantly recognizes). Verifiable? Partial — the bank will not be named publicly. VERDICT: PASS with anonymization ("a top-3 global bank, consumer login, 400M accounts, zero successful credential-stuffing incidents in 18 months"). (5) Diagnostic flags credentials-wall (14 analyst quotes). Fix: cut to 3. (6) Recommendation: lead with the anonymized bank Sinatra hero; back with two incident-response details; cut 11 of 14 analyst quotes.
Output: `credibility-plan.md` with the bank Sinatra as lead, the quote wall shrunk, and a note that the founder should push for a testable credential (open benchmark or public red-team) to upgrade the credibility stack further.

**Scenario: Nonprofit fundraising email, abstract statistics**
Trigger: Fundraiser has a draft saying "3.2 million children are affected by food insecurity each year" and asks "why isn't this landing?"
Process: (1) Lock claim: "Child food insecurity is a scale emergency in our region this year." (2) Inventory — 1 raw statistic (the 3.2M number), 1 External Authority (a public-health study), 0 Testable, 0 Sinatra, 0 Antiauthority, 0 Vivid Details. (3) Rank: only two entries, both weak; the statistic is a Raw Statistic failure mode and needs illustration. (4) Sinatra Test: no hero candidate exists. Do NOT fabricate. Instead: convert the statistic. "3.2M children = every elementary-school seat in the five largest school districts in the country, empty at breakfast." (5) Diagnostic: Raw Statistic HIT. Fix: the BB-translation above. Also: add one Antiauthority — a single named family from the region, their story, their specific morning (vivid-details pairing). (6) Recommendation: lead with the illustrated statistic AND the one-family Antiauthority story side-by-side (Mother Teresa effect — identifiable victim paired with illustrated scale). Cut the authority-study citation to a footnote.
Output: `credibility-plan.md` recommending a two-piece lead (illustrated stat + identifiable family) with a note that the fundraiser should recruit an antiauthority spokesperson BEFORE next campaign.

**Scenario: Academic publishing a counterintuitive research finding**
Trigger: Researcher has a finding that contradicts 20 years of prior consensus. Asks "how do I make this credible to reviewers who will dismiss it on sight?"
Process: (1) Lock claim: "Finding X contradicts prior consensus Y because of mechanism Z." (2) Inventory — External Authority is dominant (peer-reviewed replication); Testable Credentials possible (open data + reproducible pipeline); one Antiauthority candidate (a respected prior defender of Y who reversed position); no Sinatra hero. (3) Rank: override default — audience is credentialed peers, so External Authority upgrades to #1. But lead with the Testable Credentials (open data) because a reviewer who can reproduce the result in an hour is more convinced than one reading a methods section. Antiauthority (the reversed defender) comes next — a Barry-Marshall-pattern Sinatra hero by analogy: someone who publicly reversed position is the "hardest case" this audience responds to. (4) Sinatra Test on the reversed defender: Hardest case? Yes (they were a public critic). Legibly hard? Yes (the reversal is documented). Verifiable? Yes. VERDICT: PASS. (5) Diagnostic: no credentials wall, no raw-stat failure. (6) Recommendation: lead with the open-data link (testable), follow with the reversed-defender statement (Sinatra-pattern antiauthority), support with the peer-reviewed replication. Cut nothing.
Output: `credibility-plan.md` with a testable-credential lead, a named Sinatra-pattern antiauthority, and a note that the open dataset should be ready BEFORE submission — the credibility plan depends on it.

## References

- For long-form worked examples of each of the six credibility sources, see [credibility-sources-catalog.md](references/credibility-sources-catalog.md)
- For the Sinatra Test worksheet and replacement decision tree, see [sinatra-test-worksheet.md](references/sinatra-test-worksheet.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — *Made to Stick: Why Some Ideas Survive and Others Die* by Chip Heath and Dan Heath.

## Related BookForge Skills

This skill is standalone (a Level 0 foundation skill in the Made to Stick skill set). It pairs well with `core-message-extractor` (run first to lock the claim) and with downstream Concrete, Emotional, and Story skills (which apply stickiness techniques once credibility is established).

Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/credibility-sources-catalog.md
# Credibility Sources Catalog

Long-form worked examples for each of the six credibility sources from Chapter 4 CREDIBLE of *Made to Stick*. Use this when the SKILL.md summary is not enough and you need to see the full pattern of what good evidence in each category looks like.

---

## 1. External Authority

**Definition:** A recognized expert, institution, celebrity, or credentialed body vouches for the claim. The audience transfers their pre-existing trust in the source to the claim itself.

**When it works:**
- Audience is credentialed peers (scientists, doctors, lawyers) who enforce citation norms.
- The expert is unexpected — e.g., a former opponent of the claim now endorsing it.
- The expert is paired with at least one other category so the evidence does not become a credentials wall.

**When it fails:**
- Expert is over-quoted in the category (analyst quotes in B2B tech are now background noise).
- The claim and the expert's domain don't exactly match ("Nobel laureate says X" — in what field?).
- It is the ONLY evidence type used (credentials-wall failure mode).

**Patterns from the book:** Authorities used well are rare in the book — the authors mostly warn against over-reliance on them. The strongest use is when the authority has reversed position on the claim, which functionally converts them into a Sinatra-pattern antiauthority.

**Checklist:**
- [ ] Expert is credentialed IN the exact domain of the claim.
- [ ] The audience would independently recognize the source.
- [ ] The expert is not the only category represented in the inventory.

---

## 2. Antiauthority (Credible Victim / Lived Experience)

**Definition:** An ordinary person who lived the consequences of the claim. Not an expert — their biography is the proof. The credibility comes from personal stakes, not credentials.

**Canonical example — Pam Laffin:** An anti-smoking ad campaign used Pam Laffin — 29 years old, mother of two, started smoking at 10, diagnosed with emphysema at 24, underwent a failed lung transplant. No statistic about smoking mortality lands the way a 29-year-old mother walking through her own dying does. Surgeon General reports had existed for decades; Laffin's biography reached the audience that had ignored every expert.

**Why it works:** The resistance to expert messaging is highest in audiences who have already decided the experts are lying to them (teens on smoking, developers on technical debt, users on security, citizens on policy). An antiauthority bypasses that resistance because the messenger has no institutional stake — they are paying the cost in public.

**When it works:**
- Behavior-change messaging to a resistant audience.
- Topics where lived experience is legibly superior to abstract study.
- When you can pair the antiauthority with a specific, vivid, concrete biography (Pam Laffin is not a generic "smoker" — she is 29, two kids, started at 10, emphysema at 24).

**When it fails:**
- The lived experience is vague or anonymized to the point of losing biographical texture.
- The antiauthority is not actually antiauthority — e.g., a former executive at the competitor (too close to expert).
- Consent and ethics not handled: using someone's story without genuine consent is a credibility bomb on discovery.

**Checklist:**
- [ ] Messenger is not a credentialed expert in the domain.
- [ ] Messenger has personally paid the cost the claim is about.
- [ ] Biography is specific and verifiable (name, age, dates, details).
- [ ] Consent is real and documented.

---

## 3. Testable Credentials ("Try It Yourself")

**Definition:** The audience can verify the claim themselves, in real time, with their own senses. The evidence collapses skepticism into a single observable act.

**Canonical examples:**

- **Wendy's "Where's the beef?" (1984)** — Wendy's ran an ad campaign contrasting their burgers with competitors' oversized buns hiding undersized patties. The claim ("our patties are bigger") was instantly verifiable: walk into any location, unwrap a burger, compare. The campaign became a cultural phenomenon because the challenge was testable.
- **Snickers "satisfies" / the snack-bar category generally** — the credential is that the audience experiences satisfaction immediately after eating, so the claim self-validates in real time.
- **Barry Marshall drinking H. pylori (1984)** — Australian researchers Marshall and Warren proposed that stomach ulcers were caused by *Helicobacter pylori* bacteria, not by stress and stomach acid as the medical establishment had insisted for decades. Their peer-reviewed papers were ignored. Marshall then drank a beaker of *H. pylori* cultures, developed gastritis within days, documented it with endoscopy, and cured himself with antibiotics. The self-experiment converted an abstract claim into a public, falsifiable demonstration. Marshall and Warren won the Nobel Prize in Physiology or Medicine in 2005.

**Why it works:** Testable credentials are the strongest credibility category because they force the audience to run their own experiment. No middleman, no trust transfer, no credentials gap. The audience's own senses become the proof.

**When it works:**
- Claims about products or experiences the audience can sample cheaply (taste, feel, see).
- Claims about reproducible phenomena (benchmarks, open data, free trials).
- Claims where the demonstration is cheaper than the argument.

**When it fails:**
- The verification cost is too high (enterprise software with a 3-month implementation).
- The demonstration is rigged (audience discovers and punishes).
- The testable credential is available but the copy fails to explicitly invite the test.

**Checklist:**
- [ ] Audience can verify the claim with their own senses within a short time window.
- [ ] The invitation to test is explicit in the copy (not buried in a footer).
- [ ] The test is honest — no rigging or selective framing.

---

## 4. Vivid, Convincing Details

**Definition:** Specific sensory or biographical detail that a fabricator could not have bothered to invent. The detail is not load-bearing for the argument; its credibility value is precisely that it is too trivial to be a lie.

**Canonical example — the Goofy toothbrush juror study:** In a jury simulation study on the effect of vivid details, jurors were more likely to believe a mother testifying about her child's dental hygiene when she mentioned that he had a Goofy-the-Disney-character toothbrush he loved to brush with. The toothbrush had nothing to do with the case — but the jurors reasoned, unconsciously, that no one inventing a story would bother with the brand of the toothbrush. The detail signaled firsthand observation.

**Other patterns from the book:** The dancing 73-year-old in a fitness claim outperformed a generic "exercise works at any age" pitch because the specific age and specific activity signaled a real person, not a marketing composite.

**Why it works:** Humans have a trained ear for the texture of truth. We do not consciously evaluate details, but we unconsciously flag copy that has the smooth, context-free feel of invention. Load-bearing trivia (the Goofy toothbrush) breaks the smoothness and signals that the speaker has been close to the thing.

**When it works:**
- Stories and testimonials where you have firsthand access to small sensory details.
- Case studies where the client's actual workflow has specific quirks.
- Journalism and long-form nonfiction where the reader is scanning for texture.

**When it fails:**
- The detail is purple prose — decorative rather than load-bearing.
- The detail is suspiciously perfect (signals invention rather than observation).
- The detail is too on-the-nose to the claim (rigging).

**Checklist:**
- [ ] The detail is specific enough that no one would bother fabricating it.
- [ ] The detail is NOT directly relevant to the claim (its credibility value comes from its irrelevance).
- [ ] The detail is first-person observed, not a stereotype.

---

## 5. Sinatra Test (One Overwhelming Hero Example)

**Definition:** A single reference so dominant — typically the hardest possible case in the domain — that one mention establishes credibility for the entire category. Named after "If you can make it there, you'll make it anywhere" from the Sinatra song about New York.

**Canonical examples:**

- **Fort Knox (the book's defining example):** A security contractor who has the contract for Fort Knox is in the running for any security contract. You do not need a capabilities deck after that sentence.
- **Safexpress and the Harry Potter delivery:** Safexpress, an Indian logistics firm, won enterprise contracts by telling one story: on the launch day of the final Harry Potter book, they delivered sealed copies to 6,000 Indian bookstores across the country in one day, zero leaks, zero early releases. One sentence carried the entire due-diligence conversation. The audience did not need to hear about other customers — the Harry Potter launch was legibly the hardest possible case (distribution, secrecy, deadline), and Safexpress passed it.

**Why it works:** A wall of credentials dilutes. A single hero case concentrates. The audience reasons: "If they did THAT, the rest follows." The Sinatra Test is the book's most important credibility insight because it inverts the instinct to pile up proof.

**The three pass/fail questions** (also in the SKILL.md):
1. Is this the hardest case in the domain?
2. Is the hard part legible without explanation?
3. Is it verifiable?

**When it works:**
- Sales pitches with one customer who is legibly the hardest case.
- Reference stories where the hard part is self-evident to the audience.
- Domains where customers talk and a verifiable reference survives discovery.

**When it fails:**
- The hero case needs a paragraph of setup to explain why it was hard (Sinatra inflation — see anti-pattern in SKILL.md).
- The hero case is cherry-picked and the audience can sense it.
- The reference is unverifiable (unnamed customer, lost records).

**Checklist:**
- [ ] Passes all three Sinatra Test questions (hardest / legible / verifiable).
- [ ] Requires no setup paragraph — the audience recognizes the hardness instantly.
- [ ] Replacing the entire credentials section with just this one example would still work.

---

## 6. Statistics-as-Illustration (Human Scale)

**Definition:** A number translated into a concrete, sensory comparison so the audience can physically feel the magnitude. Raw statistics wash past; illustrated statistics stick.

**Canonical example — the nuclear-warheads-as-BBs illustration:** Explaining the US/Soviet nuclear arsenals during the Cold War using raw numbers ("5,000 warheads") produced incomprehension — the audience could not feel the scale. The illustrated version: imagine a single BB represents the Hiroshima bomb. Now picture a garbage can full of BBs. That is the world's nuclear stockpile. And one BB — the Hiroshima bomb alone — flattened a city. The garbage can is terrifying in a way the number "5,000" is not.

**Other patterns from the book:** A Stephen Covey example rescales company headcount into a "soccer team" analogy so the audience can grasp the human footprint. Any time the book converts a number to a body-sized reference (a football field, a school bus, a blink), it is applying the Human Scale principle.

**Why it works:** Human brains cannot natively process magnitudes above roughly the size of a small tribe. Numbers in the millions and billions are technically precise but emotionally equivalent. Translating the number into a sensory anchor (can, blink, football field) hands the audience a body they can use to feel the scale.

**When it works:**
- Large-scale claims (infrastructure, epidemiology, finance, climate).
- Rate statistics ("per second," "per day") that benefit from a body-sized comparison.
- Risk statistics that are emotionally flat as raw numbers.

**When it fails:**
- The analogy is dishonest (the comparison flatters the number, and the audience catches it).
- The analogy is to an abstraction the audience cannot feel ("the size of Belgium" to an American).
- The illustration replaces the number entirely and loses technical credibility with credentialed audiences.

**Checklist:**
- [ ] The analogy uses a body-sized or daily-life-sized reference (blink, can, school bus, elementary class).
- [ ] The analogy is honest — not flattering the number.
- [ ] The precise number is still present alongside the illustration for audiences that need it.

---

## Default Preference Order (Summary)

From strongest to weakest credibility, absent overrides:

1. Testable Credentials
2. Sinatra Test Hero Example
3. Vivid Convincing Details
4. Antiauthority (Credible Victim)
5. Statistics-as-Illustration
6. External Authority

**Override rules:**
- Credentialed-peer audience (scientists, doctors): External Authority moves to #1-2.
- Resistant behavior-change audience (teens on smoking, developers on technical debt): Antiauthority moves to #1.
- Scale / magnitude / risk claim: Statistics-as-Illustration moves up.

Apply these in Step 3 of the SKILL.md process.

FILE:references/sinatra-test-worksheet.md
# Sinatra Test Worksheet

A structured worksheet for applying the Sinatra Test (Chapter 4 CREDIBLE, *Made to Stick*) as a pass/fail gate on a candidate hero example. Use this when Step 4 of the SKILL.md process needs a deeper treatment than the three-question summary.

---

## The Test, Stated Formally

> An example passes the Sinatra Test when ONE example alone is enough to establish credibility in a given domain — because the example represents the hardest case the domain can throw at you.

Origin: "If you can make it there, you'll make it anywhere" — the Sinatra lyric about New York City. The book's defining example: a security contractor with the Fort Knox contract is in the running for any security contract. The Safexpress/Harry Potter case is the operational example: one sentence about delivering the final Harry Potter book to 6,000 Indian bookstores in a single day, sealed, passed the entire due-diligence conversation for enterprise logistics buyers.

---

## Worksheet: Run This For Each Candidate Hero Example

### Candidate: _____________________________________________

### Domain: _____________________________________________
(What category of claim does this example establish credibility for?)

---

### Question 1 — Is this the hardest case in the domain?

If the audience heard only this one example and nothing else, would they concede that the rest of the category follows?

**Pass if:**
- The case is self-evidently the top of the difficulty ranking the audience would apply.
- A reasonable person hearing it would think "well, if they can do THAT, they can do anything."

**Fail if:**
- The case is merely a good example, not the hardest example.
- The audience would accept it as evidence but still ask "what about harder cases?"

**Verdict:** PASS / FAIL

**Reasoning:**
_______________________________________________

---

### Question 2 — Is the hard part legible without explanation?

Can the audience see WHY it was hard without a setup paragraph? The Sinatra effect is lost if you have to explain.

**Pass if:**
- A single phrase captures the hardness ("Fort Knox" / "Harry Potter launch day, 6,000 stores, sealed" / "drank a beaker of H. pylori").
- A layperson in the audience gets it on first read.

**Fail if:**
- You must write three sentences of context before the case lands.
- The audience would say "OK, but was that actually hard?"

**Verdict:** PASS / FAIL

**Reasoning:**
_______________________________________________

---

### Question 3 — Is it verifiable?

Can the audience check the claim if they wanted to? A Sinatra hero that fails a two-minute Google search is worse than no Sinatra at all — discovery turns it from proof into liability.

**Pass if:**
- The case is public, documented, and survives basic search.
- The audience could independently confirm the key facts.

**Fail if:**
- The reference is anonymized AND the anonymization hides the verification pathway.
- Key details are embellished or cannot be sourced.
- The customer has asked not to be discussed.

**Verdict:** PASS / FAIL

**Reasoning:**
_______________________________________________

---

## Final Verdict

| Question | Verdict |
|---|---|
| Q1: Hardest case | PASS / FAIL |
| Q2: Legibly hard | PASS / FAIL |
| Q3: Verifiable | PASS / FAIL |

**OVERALL:** All three must pass.

- **If all three PASS** → This is a Sinatra Test hero. Lead the credibility stack with it. Cut redundant supporting evidence.
- **If any FAIL** → Do NOT use as lead. See replacement decision tree below.

---

## Replacement Decision Tree (If Sinatra Fails)

### IF Question 1 failed (not the hardest case)
→ **Search the inventory for a harder case.** If one exists but the user skipped it because it was "boring" or "small logo," reconsider — the audience's hardness ranking often differs from the seller's. If no harder case exists, fall through to Question 2's failure path (the inventory lacks a Sinatra candidate entirely).

### IF Question 2 failed (hard part not legible)
→ **Try to rephrase the case into a phrase the audience recognizes instantly.** Safexpress did not say "we ran a challenging logistics operation"; they said "we delivered the final Harry Potter book to 6,000 Indian bookstores in one day, sealed." The rephrase is the whole skill — find the one noun-phrase the audience already flags as hard.
→ **If no rephrase works:** the case is not Sinatra material. Fall back to category #3 (vivid details) or #1 (testable credentials) from the SKILL.md preference order.

### IF Question 3 failed (not verifiable)
→ **Attempt anonymization with a verifiable pathway.** "A top-3 global bank, consumer login, 400M accounts" is anonymized but the audience can verify the class. "A Fortune 500 customer" is anonymized and unverifiable — do not use.
→ **If anonymization fails:** treat as a Vivid Detail instead of a Sinatra hero, pair with a testable credential, and abandon the "one overwhelming case" lead strategy.

### IF NO candidate in the inventory passes all three questions
→ **Do NOT fabricate a Sinatra hero.** The most damaging credibility mistake is inflating a weak case into a hero that the audience sniffs out.
→ **Fall back to multi-source credibility:** combine a testable credential + a vivid convincing detail + an illustrated statistic. Three moderately strong categories outperform one inflated Sinatra.
→ **Alternative:** shrink the claim. If no evidence passes Sinatra, the claim is often stronger than the proof supports. Tightening the claim until the inventory is genuinely sufficient is the honest move.

---

## Common Anti-Patterns

**Sinatra Inflation.** The user wants their best customer to pass the test and is willing to argue for it. Rule: if you have to argue, it fails. The test is whether the audience recognizes the hardness instantly, without framing. Three extra sentences of context is a flunk.

**The Retro-Sinatra.** The user picks a case that was hard BEFORE the audience had context, but the audience now takes that capability for granted. "We handled the 2015 holiday peak" does not land in 2026 — the peak is old news. A Sinatra hero must be currently legibly hard.

**The Insider Sinatra.** The case is legibly hard to the seller's own team but not to the audience. Sellers consistently underestimate how much domain knowledge they have that the audience does not. Always test the case on someone outside the seller's domain before trusting the legibility verdict.

**The Unverifiable Boast.** A named customer reference that the customer has asked not to be discussed publicly. Using it anyway is a breach and a credibility bomb on discovery. Either secure explicit permission to name the customer, or use the Vivid Details fallback path instead.

---
name: core-message-extractor
description: "Extract the single-sentence core of any message — the one thing that must survive if everything else is lost. Use this skill whenever the user asks 'what's my one sentence?', 'simplify this pitch', 'find the core', 'one-liner for this', 'elevator pitch', 'boil this down', 'what's the headline?', 'TL;DR this', 'what's the one thing?', or has a draft, announcement, pitch, product description, speech, or strategy memo that says too many things at once. Also invoke when the user struggles with 'my message isn't landing', 'I have 30 seconds to explain this', 'we can't agree on messaging', 'nobody remembers our pitch', or wants a Commander's Intent, high-concept pitch, tagline, mission statement, or forced prioritization of candidate points. This is the foundation skill for all sticky messaging — run it BEFORE any unexpected/concrete/credible/emotional/story framing work."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/core-message-extractor
metadata: {"openclaw":{"emoji":"🎯","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [1, 13]
tags: [messaging, communication, copywriting, pitching, prioritization, commanders-intent, bookforge]
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Draft, idea brief, or raw message the user wants compressed"
    - type: document
      description: "Audience description and communication goal"
  tools-required: [Read, Write]
  tools-optional: [Edit]
  mcps-required: []
  environment: "Operates on short-form prose — pitches, drafts, announcements, briefs, product copy."
discovery:
  goal: "Produce a single-sentence core message that captures the one thing that must survive if everything else is lost."
  tasks:
    - "Distill a verbose draft into one sentence"
    - "Force-rank candidate messaging points and cut to one"
    - "Write a Commander's Intent for a team, project, or launch"
    - "Compress a complex idea into a high-concept pitch ('X for Y')"
    - "Diagnose a 'nothing-sticks' draft as having no core"
  audience:
    roles: [marketer, founder, product-manager, communicator, teacher, manager]
    experience: any
  when_to_use:
    triggers:
      - "User has a draft, pitch, or announcement that says too many things"
      - "User asks for a one-liner, tagline, elevator pitch, or TL;DR"
      - "Team cannot agree on what the message 'really is'"
    prerequisites: []
    not_for:
      - "Emotional framing or story wrapping — use sibling Emotional/Story skills"
      - "Adding sensory detail to an already-focused message — use a Concrete skill"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores: {}
    tested_at: null
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Core Message Extractor

## When to Use

You have been handed a draft, a brief, or a rambling idea, and the user wants it compressed into a single sentence — the one sentence that must survive if everything else is lost. This is the Commander's Intent: the plain-language statement of end-state that lets a subordinate abandon the written plan and still accomplish the mission.

Run this skill BEFORE any downstream sticky-messaging work (unexpected hooks, concrete sensory detail, credibility anchors, emotional framing, story wrapping). Without a core, those techniques decorate the wrong message.

**Preconditions to verify before starting:**
- You have the draft text (or raw idea). If missing, ask the user to paste it.
- You know who the audience is. If missing, ask: "Who specifically is this for?"
- You know the communication goal — what the audience should *do* or *decide* after reading. If missing, ask: "If one person acts on this message, what do they do?"

**Do NOT use this skill for:**
- Emotional framing (use an Emotional/pathways skill).
- Story structure (use a Story/narrative skill).
- Adding sensory detail (use a Concrete skill) — unless you find the core first, then return.

## Context & Input Gathering

### Required Context (must have — ask if missing)
- **Draft or idea brief:** the raw material being compressed.
  -> Check prompt for: pasted text, attached draft, a document the user references.
  -> Check environment for: `draft.md`, `brief.md`, `pitch.md`, `announcement.md` in the working directory.
  -> If still missing, ask: "Can you paste the current draft (or a bullet list of the points you want to include)?"
- **Audience:** who specifically will read or hear this.
  -> Check prompt for: role, title, segment, familiarity level.
  -> If missing, ask: "Who is the specific audience — a role, not a company?"
- **Goal (what the audience should do or decide):** the behavioral outcome.
  -> Check prompt for: CTA, action verb, decision to be made.
  -> If missing, ask: "If the audience remembers only one thing and acts on it, what do they do?"

### Observable Context (gather from environment)
- **Existing core statements:** prior taglines, mission statements, internal one-liners.
  -> Look for: `core-message.md`, `about.md`, `README.md`, brand docs.
  -> If present: treat as candidates, not constraints.
- **Prior drafts and rejected versions:** useful as negative signal.
  -> Look for: `*-v1.md`, `*-draft*.md`, git history on a message file.

### Default Assumptions
- Medium: short-form text (email, slide headline, landing hero, 30-second pitch). State this assumption if used.
- Tone: neutral-professional unless brand voice docs say otherwise.

### Sufficiency Threshold
- SUFFICIENT: draft + audience + goal are all known.
- PROCEED WITH DEFAULTS: draft + audience known, goal inferable from draft content (state the inference explicitly and ask the user to confirm in the output).
- MUST ASK: draft text missing, OR audience completely unspecified.

## Process

### Step 1: Inventory the Candidate Points
**ACTION:** Read the draft. List every distinct message point as a bullet — one claim, benefit, feature, fact, or call-to-action per bullet. Do not edit, merge, or rank yet. Write this as `core-message.md` under a `## Candidate Points` heading.

**WHY:** You cannot force-prioritize what you have not enumerated. Drafts hide their own over-stuffing — a single paragraph can contain five distinct points fused by connective tissue. Making them visible as a flat list is the move that enables ranking. Skipping this step and jumping to "what's the core?" usually yields the *most emotionally loaded* point, not the most important one.

**Output artifact:** `core-message.md` with a `Candidate Points` section listing 3-15 bullets.

### Step 2: Apply Forced Prioritization (The "If You Say Three Things, You Say Nothing" Rule)
**ACTION:** For each candidate point, perform the Removal Test: imagine the point is deleted and ask, "Can the message still achieve its goal for this audience?" If yes -> mark as CUT. If no -> mark as KEEP. When multiple points survive, rank them and force a single #1. Write results as a `## Ranked Candidates` section with KEEP/CUT markers and rationale.

**WHY:** Forced prioritization is uncomfortable because every point feels important to the author — that is the Curse of Knowledge talking. The rule from Carville's 1992 Clinton war room applies: three priorities posted on the wall ("Change vs. more of the same / The economy, stupid / Don't forget health care") with Carville's rule "if you say three things, you don't say anything." Audiences remember the #1 and lose everything below it. If you refuse to rank, the audience will rank for you — badly, and probably on whatever sounded most familiar, not most important.

**IF** two points tie for #1 -> ask the user: "Which of these would you rather your audience remember in six months?" Force the choice.
**ELSE** -> proceed with the clear #1.

**Anti-pattern to flag:** *burying the lead* — the #1 point appears in paragraph 3 of the draft instead of paragraph 1. Inverted-pyramid journalism exists because readers stop reading; the most important fact must come first.

### Step 3: Draft the Commander's Intent (First Pass)
**ACTION:** Write the #1 point as a single plain-language sentence describing the end state the audience should reach. Format: plain English, no jargon, no internal acronyms, no hedging ("might," "could," "in some cases"). State it as if briefing someone who will execute on it after you leave the room. Write it as a `## Commander's Intent (draft)` section.

**WHY:** The US Army adopted Commander's Intent because elaborate plans "don't survive contact with the enemy" — the plan decays the moment reality intervenes. A single end-state sentence lets subordinates improvise when the written plan breaks. The same is true for messages: your audience will not read every word, will forget most of what they read, and will paraphrase what remains. The sentence you write here is the paraphrase you are willing to let survive.

**Anti-patterns to check:**
- Abstract adjectives ("world-class," "innovative," "best-in-class") — these fail the Boeing 727 test (see Step 4).
- Metrics without subject ("grow 10%") — who grows, toward what end?
- Process descriptions ("we use AI to...") — the process is not the end state.

### Step 4: Run the Three Tests
**ACTION:** Test the draft Commander's Intent against three named tests. If any test fails, revise and re-test.

**Test A — The Delegation Test (Southwest Test):**
Could a new hire use this sentence alone to make a contested trade-off decision without asking a manager? Herb Kelleher's 30-second orientation at Southwest was "We are THE low-fare airline." When a marketer proposed adding a light entree on a flight, Kelleher could answer without a meeting: would a light entree help Southwest be THE low-fare airline? No. Cut. "Maximize shareholder value" fails this test; "THE low-fare airline" passes.

**Test B — The Outsider-Judgeable Test (Kennedy Test):**
Could an outsider tell in five years whether you succeeded? JFK's 1961 goal — "put a man on the moon and return him safely to Earth by the end of the decade" — is pass/fail judgeable by anyone. A hypothetical modern rewrite — "become the leading space-faring nation through teamwork and strategic innovation" — is un-judgeable. If your sentence cannot be falsified, it is not a core message; it is corporate atmosphere.

**Test C — The Constraint Test (Boeing 727 Test):**
Does the sentence contain measurable constraints that could coordinate work across teams without meetings? Boeing's 1960s design goal for the 727 was "seat 131 passengers, fly nonstop Miami-NYC, land on La Guardia Runway 4-22" — the runway was under a mile long, impossible for then-current jets. Thousands of engineers self-coordinated against that sentence. Compare: "best passenger plane in the world." Constraints coordinate; adjectives don't.

**WHY:** Each test catches a different failure mode. The Delegation Test catches messages that are too abstract to guide action. The Outsider-Judgeable Test catches messages that cannot be verified (and therefore cannot be trusted or tracked). The Constraint Test catches adjective-stuffed corporate voice that no cross-functional team can align on. A sentence that passes all three is a Commander's Intent; one that passes fewer needs revision.

**IF** the sentence fails any test -> return to Step 3 and revise with the failed test's corrective in mind.
**ELSE** -> proceed to Step 5.

### Step 5: Compact the Core Using One of Three Packing Techniques
**ACTION:** Choose ONE of three named techniques to compact the core further. Apply it. Write the result as a `## Compacted Core` section.

Selection rule:
- **IF** the audience shares a clear existing mental model with you -> use Technique 1.
- **ELSE IF** you can borrow a widely known reference point -> use Technique 2.
- **ELSE IF** the message must generate many downstream decisions over time -> use Technique 3.
- **ELSE** -> keep the Step 4 sentence unchanged.

**Technique 1 — Tap Existing Schema:**
Describe the new thing in terms the audience already has. The classic example: explaining a pomelo as "a grapefruit-like citrus" — one phrase, the audience's existing "grapefruit" schema does the heavy lifting. Use when audience familiarity with an adjacent concept is high.

**Technique 2 — High-Concept Pitch:**
Hollywood greenlights $100M films on one-sentence "known-movie + twist" pitches. *Speed* = "Die Hard on a bus." *Alien* = "Jaws on a spaceship." *13 Going on 30* = "Big for girls." Formula: `[Famous reference] + [specific twist]` or `X for Y` / `X but Z`. Use when a widely-known reference is available and your twist is clean.

**Technique 3 — Generative Analogy:**
Pick an analogy that keeps producing new decisions. Disney's "cast members" (instead of "employees") generates uniform rules, break vocabulary ("backstage"), and audition norms — all without a policy manual. Use when the core must propagate decisions across many future unknown situations.

**WHY:** The Step 4 sentence is defensible but may still be long or abstract. These three techniques compact further by offloading semantic work onto the audience's existing brain — schema-tapping reuses their concepts, high-concept reuses their media memory, generative analogy reuses their inferential machinery. Compaction is not decoration; it is how you fit the same meaning into fewer tokens of audience attention.

### Step 6: Write the Output Artifact
**ACTION:** Assemble the final `core-message.md` with the following sections, in order:

```
# Core Message

## The One Sentence
<final compacted core message — one sentence>

## Why This Is The Core (Justification)
- Audience: <who>
- Goal: <what they should do or decide>
- Passed Delegation Test: <how>
- Passed Outsider-Judgeable Test: <how>
- Passed Constraint Test: <how>
- Packing technique used: <Schema | High-Concept | Generative Analogy | None>

## Cut List (what was removed and why)
- <cut point 1> — <one-line rationale>
- <cut point 2> — <one-line rationale>
...

## Assumptions
- <any inferred audience/goal/medium assumption the user should confirm>
```

**WHY:** The cut list is as important as the kept sentence. Users resist cuts; seeing the cut list lets them challenge specific removals rather than the whole compression. The three-test justification converts "the agent picked this" into "the sentence passed three named, checkable criteria" — which is what makes the output defensible in a team meeting.

## Inputs

- The raw draft text (or a bullet list of candidate points).
- The target audience (role, not company).
- The communication goal (what the audience should do or decide).
- Optional: medium constraints (character limit, time limit), brand tone constraints.

## Outputs

- `core-message.md` — the artifact defined in Step 6, containing:
  - One final sentence (the core).
  - A justification block naming the three tests it passed.
  - A cut list of removed points with rationale.
  - An assumptions block for anything inferred.

## Key Principles

- **If you say three things, you say nothing.** — Carville's war-room rule. Audiences remember the #1 and lose everything below it. Ranking is not optional; the only question is whether you rank or your audience ranks for you.
- **Commander's Intent is a survival sentence, not a summary.** — The sentence must still be useful after the written plan collapses. Summaries preserve content; Commander's Intent preserves end state. These are different outputs.
- **Constraints coordinate; adjectives don't.** — "Best" and "world-class" do not tell a cross-functional team what to build. "Land on a runway under a mile long" does. When in doubt between an adjective and a measurable constraint, take the constraint.
- **Compaction offloads work onto the audience's existing brain.** — Schema-tapping, high-concept pitches, and generative analogies are not literary flourishes; they are compression techniques that reuse the audience's prior knowledge so you do not have to carry it in your token budget.
- **The Curse of Knowledge hides the core from the author.** — The author knows everything and finds it all important. Forced prioritization is painful precisely because the author has already mentally integrated the full message. If the Removal Test feels easy, you probably did it wrong.

## Examples

**Scenario: Product launch announcement, too many features**
Trigger: User pastes a 6-paragraph launch email listing 8 features and says "help me find the core."
Process: (1) Inventory produces 8 candidate points. (2) Removal Test cuts 5 feature points that don't change the purchase decision; 3 survive. (3) Forced rank picks one: "the app now works offline." (4) First-pass draft: "our app now works offline." (5) Delegation Test: could a support rep prioritize roadmap bugs from this? Yes — "does this make offline better?" Passes. Outsider Test: Can you verify offline works? Yes. Constraint Test: measurable. Passes all three. (6) High-concept packing: "Notion that works on a plane." Final core.
Output: `core-message.md` with one sentence ("Notion that works on a plane"), justification block, cut list of 7 features that got demoted to "feature table in the appendix."

**Scenario: Internal strategy memo, nobody remembers it**
Trigger: Founder says "we sent a 4-page strategy memo and a week later my leads are each describing a different strategy."
Process: (1) Inventory of the memo finds 11 distinct claims, including "focus on enterprise," "ship faster," "improve onboarding," "raise ARPU." (2) Removal Test — "focus on enterprise" is the only point that changes every downstream decision; the rest are second-order. (3) First-pass: "we are moving upmarket to enterprise customers." (4) Delegation Test: can a PM decide between two backlog items with just this sentence? Yes — "which serves a 5000-seat customer better?" Passes. (5) Generative analogy chosen (decisions will propagate over a year): "We are the Salesforce of X, not the Notion of X." Final core.
Output: `core-message.md` with the one sentence, tests passed, cut list (10 demoted points), and an assumption flag: "Assuming 'enterprise' = 1000+ seats — please confirm."

**Scenario: Government mission statement audit**
Trigger: User shares "Our mission is to empower citizens through innovative, data-driven, inclusive, transparent services."
Process: (1) Inventory — 5 adjectives, zero end state. (2) Removal Test — you can remove any one adjective and the sentence has the same meaning (or the same meaninglessness), which means none of them are load-bearing. (3) Ask user: "What is the one outcome a citizen should get?" User answers: "Renew any permit in under 10 minutes online, on any device." (4) This passes all three tests directly — Southwest-style delegation ("does this help renew faster?"), Kennedy-style outsider-judgeable ("10 minutes, measurable"), Boeing-style constraint ("any device"). No packing technique needed. (5) Final core: "Renew any permit in under 10 minutes, on any device."
Output: `core-message.md` with the JFK-style final sentence, justification, and a cut list explicitly naming the original 5 adjectives as the removed material.

## References

- For the long-form breakdown of the three packing techniques with worked examples, see [packing-techniques.md](references/packing-techniques.md)
- For the four-question forced-prioritization worksheet, see [forced-prioritization-worksheet.md](references/forced-prioritization-worksheet.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — *Made to Stick: Why Some Ideas Survive and Others Die* by Chip Heath and Dan Heath.

## Related BookForge Skills

This skill is standalone (a Level 0 foundation for the Made to Stick skill set). It is the prerequisite for all sibling sticky-messaging skills — run this first, then layer Unexpected, Concrete, Credible, Emotional, and Story techniques on top of the extracted core.

Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/forced-prioritization-worksheet.md
# Forced Prioritization Worksheet

Use this worksheet when the user has multiple candidate points and cannot pick one. It operationalizes the "if you say three things, you say nothing" rule from Carville's 1992 Clinton war room.

## The Four Questions

For each candidate point in the inventory, answer:

### Q1 — The Removal Test
"If I delete this point, can the message still achieve its goal for this audience?"
- **Yes** -> CUT. This point is decorative, not load-bearing.
- **No** -> KEEP. This point is structural.

### Q2 — The Delegation Test (Southwest)
"Could a new hire make a contested trade-off decision from this point alone?"
- **Yes** -> this point is actionable for frontline decisions. Strong candidate for #1.
- **No** -> this point describes atmosphere, not action. Weak candidate.

### Q3 — The Outsider-Judgeable Test (JFK)
"Could an outsider verify success or failure against this point in a fixed timeframe?"
- **Yes** -> the point has a falsifiable end state. Strong candidate.
- **No** -> the point is corporate atmosphere. Weak candidate.

### Q4 — The Six-Month Recall Test
"If the audience remembers only one thing six months from now, would I rather they remember this point or another?"
- This is the tiebreaker when Q1-Q3 leave multiple survivors. Force the choice. Ties are not permitted.

## Cut List Format

When writing the cut list in `core-message.md`, use this format for each cut point:

```
- <cut point> — FAILED <Q1|Q2|Q3|Q4>: <one-sentence rationale>
```

Example:

```
- "Our platform is enterprise-grade" — FAILED Q1: removing this does not change whether a buyer acts.
- "We have 99.9% uptime" — FAILED Q2: not something a sales rep uses to close a deal.
- "We're the fastest-growing in our category" — FAILED Q3: "fastest-growing" is not outsider-verifiable without comparative data.
- "We save customers time AND money" — FAILED Q4: "time" survived the other tests; "money" is the weaker co-claim and gets cut in the tiebreaker.
```

## Anti-Patterns to Flag During Prioritization

- **"Everything is #1"** — the author refuses to rank. Push back: "If the audience can only remember one, which one?"
- **Burying the lead** — the #1 point appears after paragraph 2. Inverted-pyramid journalism exists because readers quit; the most important fact must come first.
- **Compound #1** — "We are fast, affordable, and reliable" — three #1s in a coat. Force the split; pick one.
- **Process as message** — "We use AI to..." is not an end state, it is a method. Ask: "What does the audience *get* because of the method?" That is the #1.

FILE:references/packing-techniques.md
# Packing Techniques — Long Form

Three named techniques for compacting a core message by offloading semantic work onto the audience's existing brain. Pick ONE per message — stacking them usually clouds rather than compresses.

## Technique 1 — Tap Existing Schema

**Mechanic:** Describe the new thing in terms of a concept the audience already holds with high fidelity. You do not have to teach the concept; you reference it and attach a small modifier.

**Classic example:** A pomelo is "a grapefruit-like citrus, the size of a softball, yellow-green, with a thicker rind." The word "grapefruit" does most of the work — the audience already owns a rich schema (taste, texture, color, rind, seeds) and you inherit all of it for free by saying "grapefruit-like."

**When to use:**
- The audience has strong familiarity with an adjacent concept.
- The adjacent concept is close enough that the differences are small.
- You can name the one or two modifiers that distinguish the new thing.

**When NOT to use:**
- The audience does not share the schema (a pomelo described as "grapefruit-like" fails in a culture with no grapefruit).
- The differences from the schema are so large that borrowing misleads more than it teaches.
- You are describing something genuinely novel — you will need Generative Analogy instead.

**Format:** `<New thing> is a <schema>-like <category>, <distinguishing modifier 1>, <modifier 2>.`

## Technique 2 — High-Concept Pitch

**Mechanic:** A one-sentence pitch built as `[widely known reference] + [specific twist]`. Borrowed from Hollywood greenlight meetings where $100M+ decisions are made on sentences like these.

**Canonical examples:**
- *Speed* = "Die Hard on a bus."
- *Alien* = "Jaws on a spaceship."
- *13 Going on 30* = "Big for girls."
- *The Lion King* = "Hamlet with lions."

**Formulas:**
- `[Known thing] on/in/for a [new context]` — "Die Hard on a bus."
- `[Known thing] for [new audience]` — "Big for girls" or "LinkedIn for veterinarians."
- `[Known thing] but [twist]` — "Uber but the driver is your neighbor."

**When to use:**
- There is a reference the full audience is guaranteed to know.
- Your twist is clean and expressible in 2-4 words.
- Decision-makers have 30 seconds, not 30 minutes.

**When NOT to use:**
- The reference is unknown to part of the audience — the compression inverts and confuses.
- The twist is "better than X" — "better" is not a twist, it is a claim. High-concept twists must change something structural.

## Technique 3 — Generative Analogy

**Mechanic:** An analogy that keeps producing new decisions across unforeseen situations without policy manuals or follow-up meetings. The analogy is not a one-time description; it is a decision engine.

**Classic example:** Disney theme-park employees are called "cast members." That one choice generates: uniforms become "costumes," breaks happen "backstage," hiring is "audition," the workplace is "on stage," guest behavior becomes part of "the show." No one had to write a rule for "should employees stay in character when cleaning up trash?" The word "cast" answered it.

**When to use:**
- The message must propagate decisions across many future unknown situations.
- Culture or behavior change is downstream of the message.
- You need one term that team members will reach for instead of asking their manager.

**When NOT to use:**
- One-time pitches (a sales email does not need a generative analogy).
- Technical specs where precise vocabulary matters more than inferential richness.
- Audiences that will resist metaphor as imprecise.

**Test:** Before shipping a generative analogy, list 5 downstream situations and predict what the analogy says about each. If the analogy stays silent on all 5, it is not generative — it is just decorative.

## Picking Between the Three

| Situation | Technique |
|-----------|-----------|
| Audience knows a near-adjacent concept | Schema |
| 30-second pitch with a known reference available | High-Concept |
| Message must drive many future decisions | Generative Analogy |
| None of the above | Keep the plain Commander's Intent sentence from Step 4 |

If two techniques seem to fit, prefer the simpler one (Schema > High-Concept > Generative Analogy). The more inferential machinery you require from the audience, the higher the risk of misinterpretation.

---
name: concrete-language-rewriter
description: Rewrite abstract, theoretical, or jargon-heavy passages into sensory, schema-based language the audience can already picture — using three named techniques (schema tap, high-concept pitch, generative analogy). Use this skill whenever a draft sounds abstract, strategy-level, or theoretical and the user wants it grounded in concrete imagery the reader can see, hear, touch, or do. Activate when the user says "this sounds abstract", "make it more concrete", "feels jargon-y", "how do I explain this", "rewrite this pitch", "too theoretical", "simplify the language", "ground this", "make it tangible", "the reader can't picture it", "I'm stuck at the strategy level", "translate this into plain language", "make this vivid", "needs an analogy", "give me a one-liner pitch", "explain this to a 5-year-old", "we need a metaphor for this", or provides an abstract passage plus an audience and asks to concretize it. Also triggers when a mission statement, value prop, policy memo, product page, cultural value, onboarding doc, or training scenario reads like a thesaurus of abstractions (synergy, excellence, alignment, optimize, empower, leverage, robust, scalable, best-in-class). The skill does NOT invent fake sensory details to ground a claim the user has not actually made, does NOT score the whole SUCCESs rubric (that is the stickiness-audit skill), and does NOT write full narrative stories (that is the story-framing skill) — it produces a side-by-side before/after rewrite of each flagged abstract passage with the technique used and why.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/made-to-stick/skills/concrete-language-rewriter
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: made-to-stick
    title: "Made to Stick: Why Some Ideas Survive and Others Die"
    authors: ["Chip Heath", "Dan Heath"]
    chapters: [3, 13]
tags: [communication, concrete-language, rewriting, analogy, messaging, copywriting, plain-language, metaphor, pitch, clarity]
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Draft with abstract passages — a message, pitch, value prop, mission statement, explainer, cultural values doc, or product page"
    - type: document
      description: "Audience reference points — what the audience already knows, does, sees daily, or has experienced (used as the source material for schemas and analogies)"
  tools-required: [Read, Write]
  tools-optional: [Grep]
  mcps-required: []
  environment: "Any agent environment with file read/write. Document-set environment — the agent operates on short prose artifacts supplied by the user."
discovery:
  goal: "Rewrite abstract passages into concrete, schema-anchored language by applying one of three named techniques chosen to fit the passage and the audience."
  tasks:
    - "Rewrite a jargon-heavy value proposition into something the reader can picture"
    - "Produce a one-sentence high-concept pitch for a new product or idea"
    - "Design a generative analogy that keeps steering behavior after it is stated"
    - "Swap abstract strategy talk for behavior-level language in a cultural values doc"
  audience:
    roles: [marketer, founder, product-manager, communicator, teacher, executive, technical-writer]
    experience: any
  when_to_use:
    triggers:
      - "User says a passage sounds abstract, jargon-y, or theoretical and asks to ground it"
      - "User needs a one-liner pitch for a product or initiative"
      - "Cultural values or strategy doc is full of words like synergy, alignment, empower"
      - "User wants an analogy that non-experts will immediately picture"
    not_for:
      - "Inventing fabricated sensory details to prop up a claim the user has not actually made"
      - "Full SUCCESs rubric scoring (use stickiness-audit)"
      - "Multi-paragraph narrative stories (use story-framing)"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: "pending"
    eval_count: 0
---

# Concrete Language Rewriter

## When to Use

You have a draft — a pitch, value prop, mission statement, explainer, internal memo, training doc, or product page — containing passages that sound abstract, theoretical, or jargon-heavy. The user wants those passages rewritten into sensory, schema-based language the audience can already picture. Before starting, confirm: (1) which passages are to be rewritten (user-flagged or agent-flagged), (2) who the audience is and what reference points they already share, (3) whether the user wants a one-shot pitch (high-concept), an idea that keeps producing behavior (generative analogy), or fast comprehension (schema tap).

The core mechanic: abstract ideas only stick when they hook onto concrete things already in the reader's memory (the "Velcro theory of memory" from Chapter 3). The more sensory hooks, the better the retention. "White things" is vague; "white things in your refrigerator" is concrete. This skill turns the first into the second.

## Context & Input Gathering

### Required Context (must have — ask if missing)
- **The draft:** The actual passage(s) to rewrite, verbatim.
  -> Check prompt for: pasted text, a file path, or attached document
  -> If missing, ask: "Paste the passage you want rewritten, or give me the file path."
- **The audience:** Who will read this and what schemas they already have.
  -> Check prompt for: role names, job titles, prior experience mentions
  -> Check environment for: `audience-profile.md`, `brief.md`, `persona.md`
  -> If still missing, ask: "Who is the audience? What do they already know and see every day that I can anchor this to?"

### Observable Context (gather from environment)
- **Related drafts:** Other versions, earlier pitches, or competitor messaging.
  -> Look for: `draft.md`, `existing-copy.md`, `core-message.md`
  -> If unavailable: work from the single passage provided.
- **Technique preference:** Whether the user wants a pitch, a generative analogy, or a quick explanation.
  -> Look for: words like "pitch", "one-liner", "culture", "values", "explain"
  -> If unavailable: infer from the passage type (see Step 2).

### Default Assumptions
- If no audience is given and one cannot be asked for: assume "intelligent non-expert in the domain" and state this in the output.
- Preserve the user's claim. Do not invent new facts to ground it — find existing audience schemas that match the claim you already have.

### Sufficiency Threshold
SUFFICIENT: passage + audience schemas known
PROCEED WITH DEFAULTS: passage known, audience assumed as "intelligent non-expert" (noted in output)
MUST ASK: no passage provided

## Process

### Step 1: Flag abstract passages
**ACTION:** Read the draft and mark every passage that is (a) a pure abstraction with no sensory anchor, or (b) strategy-level language that does not specify observable behavior. Output a numbered list of flagged passages. If the user already flagged specific passages, use their list and skip scanning.

**WHY:** Rewrites fail when applied to the wrong target. Concrete language is not always better — a correctly concrete sentence should be left alone. Flagging first forces an explicit decision about what actually needs work and produces an auditable list the user can challenge before any rewriting starts.

**Flag tests (any one triggers a flag):**
- Contains an abstract noun with no example: `synergy`, `excellence`, `innovation`, `alignment`, `value`, `quality`, `empowerment`, `transformation`, `optimization`.
- Describes a goal without naming an observable behavior or measurable constraint (e.g., "be the best airline" vs "land a 131-passenger jet on La Guardia Runway 4-22").
- Uses a word the reader cannot picture, touch, or do.
- Is a cultural value or strategy statement that does not name the daily object, phrase, or action the reader should change.

**Artifact:** `flagged-passages.md` — numbered list with the verbatim text of each flagged passage.

### Step 2: Pick the technique for each flagged passage
**ACTION:** For each flagged passage, choose ONE of three techniques based on the decision rule below. Record the choice and the one-sentence reason.

**WHY:** The three techniques are not interchangeable — they solve different problems. Schema tap is for explaining *what a thing is* in under five seconds. High-concept pitch is for positioning a new thing relative to two familiar things. Generative analogy is for seeding a mental model that will keep producing decisions long after the user stops reading. Mixing them up produces rewrites that are clever but do not fit the job.

**Decision rule:**

| If the user needs... | Use | Why |
|---|---|---|
| Quick comprehension ("what IS this thing?") | **Schema tap** | Leverages one existing schema the audience already owns |
| A one-shot positioning pitch ("how is this different?") | **High-concept pitch** | Combines two schemas to place a new idea at their intersection |
| Behavior that keeps aligning after the message is delivered | **Generative analogy** | Seeds a frame that the audience re-uses to make new decisions autonomously |

**IF** the passage is a product tagline, cold-open, or elevator line -> **High-concept pitch**
**ELSE IF** the passage is a cultural value, onboarding frame, or ongoing team norm -> **Generative analogy**
**ELSE** -> **Schema tap**

**Artifact:** Extend `flagged-passages.md` with a `technique:`, `why:`, and `canonical exemplar:` line under each entry.

**MANDATORY — name the lineage.** Every rewrite must cite BOTH (a) the technique used, and (b) the closest canonical exemplar from *Made to Stick* that the rewrite echoes. This is not optional decoration — it is how the user builds the catalog mentally while using the skill, and how a reviewer can trace the rewrite back to the book's proven patterns. Use this map:

| Technique | Canonical exemplars from the book (pick the closest fit) |
|---|---|
| Schema tap | **the pomelo example** (grapefruit crossed with a football); **Aesop's Fox & the Grapes** (parable as packed schema) |
| High-concept pitch | **"Die Hard on a bus"** (the movie *Speed*); other "X meets Y" Hollywood pitches |
| Generative analogy | **Disney "cast members"** (theme park as stage production); **Kris & Sandy** (accounting class reframed as investigative journalism) |
| Behavior-level swap | **Boeing 727 constraint** ("seat 131 passengers, fly Miami–NYC nonstop, land on La Guardia Runway 4-22"); **Jane Elliott's blue-eyes / brown-eyes exercise** (felt experience replaces lecture) |

Every rewrite's output row MUST carry a phrase like *"Schema tap — like the pomelo example"* or *"Generative analogy — like Disney cast members"*.

### Step 3: Rewrite with Technique 1 — Schema tap
**ACTION:** If the chosen technique is schema tap, find one thing the audience already owns in memory that shares the most critical feature of the abstract idea, then describe the abstract idea in terms of that thing plus a minimal delta.

**WHY:** A new abstraction with zero sensory hooks fails to stick regardless of how accurately it is stated. Tapping an existing schema inherits all of the hooks from the familiar thing for free — the reader does not have to build new memory, only modify existing memory.

**Template:** `{new thing} is like {familiar thing} except {one delta}.`

**Example — pomelo:** Instead of "a large citrus fruit native to Southeast Asia with a thick rind and mild flavor", say "a pomelo is a grapefruit crossed with a football." The reader owns both "grapefruit" and "football" — size, shape, and category arrive in one sentence.

**Checklist for a good schema tap:**
- The familiar thing is visible, touchable, or doable — not another abstraction.
- The delta is ONE thing, not five.
- The reader could draw it after reading it.

### Step 4: Rewrite with Technique 2 — High-concept pitch
**ACTION:** If the chosen technique is a high-concept pitch, find two familiar things from the audience's cultural library whose intersection captures the new idea, and write it as "`{familiar thing A} meets {familiar thing B}`" or equivalent.

**WHY:** High-concept pitches are the Hollywood trick: they let a producer green-light a new project in 30 seconds because both reference points are already fully loaded in the audience's head. The pitch is doing the work of a five-paragraph positioning statement by paying in two words of borrowed context.

**Templates:**
- `{A} meets {B}`
- `{A} for {new domain}`
- `The {A} of {new domain}`
- `{A}, but {B}`

**Example — "Die Hard on a bus":** The movie *Speed* was pitched as "Die Hard on a bus." Both reference points are concrete and already loaded in every producer's head (action-hero hostage thriller + claustrophobic single-location constraint). The audience knew the genre, the pacing, and the stakes immediately.

**Checklist for a good high-concept pitch:**
- Both reference points are genuinely known to the audience (not just to you).
- The combination actually captures the new thing's main feature, not just its vibe.
- It fits in one breath.

### Step 5: Rewrite with Technique 3 — Generative analogy
**ACTION:** If the chosen technique is a generative analogy, choose a source frame whose internal vocabulary, roles, and daily actions will re-apply to the target domain in ways that keep generating decisions after the message is stated. Then rewrite the passage to install the analogy and, optionally, list 2–4 specific objects or actions it renames.

**WHY:** Generative analogies are the highest-leverage concrete technique because the analogy keeps doing work after the user is gone. A good generative analogy lets frontline employees make dozens of small decisions correctly without ever checking back with a manager — the frame tells them what to do.

**Example — Disney "cast members":** Disney reframed the theme park as a stage production. Employees became "cast members", customers became "guests", uniforms became "costumes", walking areas became "onstage" vs "backstage". An 18-year-old hired last week knows — without being told — that you do not step "offstage" in costume, that you perform your role even on a bad day, and that guests are your audience, not your transaction counterparty. The analogy generates the policy for situations no handbook covered.

**Checklist for a good generative analogy:**
- The source frame has a rich internal vocabulary the audience already knows (theater, kitchen, cockpit, newsroom, emergency room, baseball).
- At least 3 daily objects or actions can be renamed without forcing it.
- The new frame steers a behavior the user actually wants (not a behavior that just sounds good).

### Step 6: Swap abstract strategy talk for behavior-level language
**ACTION:** For flagged passages that describe a *strategy* or *goal* rather than a *schema* — e.g., "be the leading provider of X" — do not apply an analogy. Instead, rewrite the passage as a measurable constraint or observable behavior. Replace quality adjectives with numbers, dates, or named actions.

**WHY:** Strategy-level statements ("be the best", "excellence in Y", "world-class Z") do not coordinate behavior because they cannot be pictured, measured, or disputed. A concrete constraint can be shared across teams that never meet — it acts as a self-coordinating reference point. This is why Boeing's 727 design goal was "seat 131 passengers, fly nonstop Miami–NYC, land on La Guardia Runway 4-22" rather than "best passenger plane in the world". Thousands of engineers across specialties could self-coordinate from the constraint; no one could coordinate from the adjective.

**Transform:**
- Quality adjective -> measurable constraint (`best` -> `under 200ms p95`)
- Abstract goal -> observable action (`empower our users` -> `every user can publish without asking support`)
- Strategy noun -> verb the reader performs (`alignment` -> `everyone writes the same one-sentence answer when asked what we are building`)

### Step 7: Produce the side-by-side deliverable
**ACTION:** Write the final artifact as a side-by-side before/after table (or structured markdown), with technique, canonical exemplar, rationale, and any caveats. For each flagged passage, include:
1. The original text (verbatim).
2. The technique chosen.
3. The **canonical exemplar** from *Made to Stick* whose pattern this rewrite echoes (e.g., "like the pomelo example", "like Disney cast members", "like Die Hard on a bus", "like Boeing's 727 runway constraint", "like Jane Elliott's blue-eyes exercise", "like Kris & Sandy", "like Aesop's Fox & the Grapes"). REQUIRED — not optional.
4. The rewrite.
5. One line explaining why the rewrite uses concrete hooks the original lacked.
6. (If applicable) A "caveat" line noting any claim the rewrite intentionally did not invent support for.

**Table form (REQUIRED columns):** Every side-by-side table must have four columns:

| Original | Rewrite | Technique | Canonical Exemplar |
|---|---|---|---|

The `Canonical Exemplar` column is non-optional — a row missing it is an incomplete deliverable and must be rejected during Step 8.

**WHY:** A rewrite without the reasoning is a magic trick — the user cannot apply it to the next passage, and cannot tell whether to accept or reject it. Showing the technique and its rationale turns the deliverable from a one-shot fix into a teachable artifact.

**Artifact:** `concrete-rewrite.md` — see template in `references/output-template.md`.

### Step 8: Self-check for fabricated detail
**ACTION:** Re-read each rewrite and verify that no sensory detail was invented to prop up a claim the original did not make. If a rewrite added a number, a name, a physical feature, or a specific example that is not in the source material or the user's knowledge, either flag it as `[assumption — verify]` or remove it.

**WHY:** Concrete language can become a lie if it invents specifics the user cannot defend. "We serve 10,000 customers daily" is concrete and sticky — and catastrophic if the user only has 400 customers. This skill is explicitly out-of-scope for fabricating details; Step 8 is the enforcement step. A rewrite that needs invented detail means the user must supply the detail or the technique was wrong.

**IF** any rewrite contains fabricated specifics -> mark `[assumption — verify]` inline or replace with a schema tap that uses only the audience's existing knowledge
**ELSE** -> mark the artifact complete.

## Inputs
- **Draft:** prose passage(s) to rewrite.
- **Audience schemas:** what the audience already knows, sees, or does (roles, domain, prior experience).
- **Optional:** technique preference (schema / pitch / generative), channel (tagline / memo / slide), tone constraints.

## Outputs
- **`flagged-passages.md`** — numbered list of abstract passages with assigned technique and reason.
- **`concrete-rewrite.md`** — the side-by-side deliverable. Template:

```markdown
# Concrete Rewrite

Audience: {audience description}

## Summary table

| Original | Rewrite | Technique | Canonical Exemplar |
|---|---|---|---|
| {verbatim original} | {rewrite} | {schema tap / high-concept pitch / generative analogy / behavior-level swap} | like {pomelo / Disney cast members / Die Hard on a bus / Boeing 727 runway constraint / Jane Elliott blue-eyes / Kris & Sandy / Aesop's Fox & the Grapes} |

## Passage 1
**Technique:** {schema tap | high-concept pitch | generative analogy | behavior-level swap}
**Canonical exemplar:** like {pomelo example | Disney cast members | Die Hard on a bus | Boeing 727 runway constraint | Jane Elliott blue-eyes exercise | Kris & Sandy | Aesop's Fox & the Grapes}

**Before:**
> {verbatim original}

**After:**
> {rewrite}

**Why this works:** {one line — which existing hook(s) the rewrite taps, and how it echoes the exemplar's pattern}

**Caveats:** {any `[assumption — verify]` flags, or "none"}

## Passage 2
...
```

## Key Principles

- **Velcro, not paint.** Concrete language is not about making prose prettier — it is about attaching the idea to hooks already in the reader's memory. More hooks = better retention. If a rewrite adds adjectives but no new hooks, it has not concretized anything.
- **Borrow schemas, do not manufacture facts.** The sensory detail must come from what the audience already owns (pomelo leans on grapefruit + football) or from what the user can honestly claim (Boeing's actual runway constraint). Never invent specifics to make an abstract claim feel more real — that is lying, not concretizing.
- **Three techniques, three jobs.** Schema tap = comprehension speed. High-concept pitch = one-shot positioning. Generative analogy = ongoing behavior steering. Picking the wrong technique wastes the rewrite: a high-concept pitch cannot run a culture, and a generative analogy cannot fit on a billboard.
- **Constraints coordinate, adjectives do not.** When a passage describes a goal or strategy, the fix is not an analogy — it is a measurable constraint. "Best" cannot coordinate 500 engineers; "fits in under a mile of runway" can. Replace quality adjectives with numbers, dates, or named actions whenever the passage is a goal.
- **Rewriting is audit-able or it is arbitrary.** Always show the technique and the reason next to the rewrite. The user needs to be able to reject a rewrite and know why it is wrong, or apply the same move to the next passage tomorrow.
- **Name the lineage.** Every rewrite declares which of the 3 techniques it used AND which canonical book exemplar it echoes — "like the pomelo", "like Disney cast members", "like Die Hard on a bus", "like Boeing's 727 runway constraint", "like Jane Elliott's blue-eyes exercise", "like Kris & Sandy", "like Aesop's Fox & the Grapes". This is how users build the catalog mentally while using the skill, not just the technique abstraction. An unlabeled rewrite is an incomplete rewrite.
- **More hooks = more memory.** "White things" is vague. "White things in your refrigerator" is concrete. Every additional hook (color, container, location, use) multiplies retention — but only if each hook is real to the audience.

## Examples

**Scenario: abstract value proposition for a developer tool**
Trigger: User says "our landing page hero feels too abstract — it says 'unified observability platform for cloud-native workloads' and nobody gets it. Audience: backend engineers at mid-size startups."
Process: (1) Flag the passage — "unified observability platform for cloud-native workloads" is three stacked abstractions. (2) Choose high-concept pitch — it is a product tagline. (3) Rewrite: "Datadog for teams that can't afford Datadog" — two familiar reference points (known product + known pain), instant positioning. (4) Self-check: "can't afford Datadog" is a claim about audience economics, not about our product — safe.
Output: `concrete-rewrite.md` row — **Technique:** high-concept pitch; **Canonical exemplar:** like "Die Hard on a bus" (the *Speed* pitch); **Rationale:** "leverages the audience's existing schema of Datadog and its known price-point pain, placing the new product at a specific intersection in one breath — the same two-schema collision trick that let a Hollywood producer green-light *Speed* in 30 seconds."

**Scenario: mission statement for customer support reorg**
Trigger: User shares a draft values doc: "We aim to empower partnership-oriented interactions that drive mutual long-term value with our customer community." Audience: customer support agents.
Process: (1) Flag — entire sentence is strategy-level abstraction with zero behavior. (2) Choose generative analogy — it is meant to shape ongoing behavior, not a one-shot pitch. (3) Rewrite: reframe support agents as "co-pilots, not gate agents." List renames: tickets -> "missions", SLAs -> "flight plans", escalations -> "hand-offs to the captain". (4) Self-check — no invented facts; all renames are metaphor, not claim.
Output: `concrete-rewrite.md` row — **Technique:** generative analogy; **Canonical exemplar:** like Disney "cast members" (theme park as stage production); **Rationale:** "the co-pilot frame keeps generating decisions the way Disney's cast-member frame tells a brand-new hire they do not step offstage in costume — a co-pilot does not close a mission before the captain lands safely, which maps to 'do not close a ticket until the customer confirms resolution.' Daily vocabulary (tickets -> missions, SLAs -> flight plans, escalations -> hand-offs) renames at least 3 objects, clearing the Disney-style test from Step 5."

**Scenario: training material for new product managers**
Trigger: User asks, "How do I teach new PMs what it feels like when another team blocks their work? It keeps coming out as a lecture about stakeholder alignment."
Process: (1) Flag — "stakeholder alignment" is the core abstraction. (2) Choose schema tap — the goal is comprehension, not positioning. (3) Rewrite: design a short in-class simulation modeled on Jane Elliott's blue-eyes/brown-eyes exercise (Chapter 3) — split the PMs into two teams, give team A the tooling and team B the deadline, force team B to request every build from team A for 20 minutes. (4) Self-check — simulation rules are concrete and can be run with no invented facts about the PMs.
Output: `concrete-rewrite.md` row — **Technique:** schema tap (delivered as a felt experience); **Canonical exemplar:** like Jane Elliott's blue-eyes / brown-eyes exercise (Chapter 3); **Rationale:** "a felt experience (being blocked by another team's schedule) builds direct memory the way Elliott's blue-eyes / brown-eyes exercise made discrimination concrete for a classroom of 8-year-olds — lecturing about 'alignment' does not. The PMs now own a 20-minute schema they can tap when the abstract word 'stakeholder' resurfaces."

## References
- For a reusable output template, see [references/output-template.md](references/output-template.md)
- For an expanded catalog of schema-tap, high-concept-pitch, and generative-analogy patterns with more worked examples (Aesop's Fox and Grapes parable compression, Disney cast-member system, Kris & Sandy accounting case, Boeing 727 runway constraint, Jane Elliott blue-eyes exercise), see [references/technique-catalog.md](references/technique-catalog.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — *Made to Stick: Why Some Ideas Survive and Others Die* by Chip Heath and Dan Heath.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/output-template.md
# Concrete Rewrite — Output Template

Use this structure for `concrete-rewrite.md` deliverables.

```markdown
# Concrete Rewrite

**Audience:** {role, domain familiarity, what they see/do daily}
**Source draft:** {file path or "pasted in chat"}
**Date:** {YYYY-MM-DD}

---

## Summary

{N} passages flagged. Techniques used: {schema tap: X, high-concept pitch: Y, generative analogy: Z, behavior-level swap: W}.

## Side-by-side table (REQUIRED)

Every rewrite must appear in this four-column table. The `Canonical Exemplar` column is non-optional — it names the *Made to Stick* pattern the rewrite echoes, so the user builds the catalog mentally as they use the skill.

| Original | Rewrite | Technique | Canonical Exemplar |
|---|---|---|---|
| {verbatim original} | {rewrite} | {schema tap / high-concept pitch / generative analogy / behavior-level swap} | like {pomelo example / Disney cast members / Die Hard on a bus / Boeing 727 runway constraint / Jane Elliott blue-eyes exercise / Kris & Sandy / Aesop's Fox & the Grapes} |

Canonical exemplar map:
- **Schema tap** — like the **pomelo** example ("grapefruit crossed with a football"); or **Aesop's Fox & the Grapes** (parable as packed schema)
- **High-concept pitch** — like **"Die Hard on a bus"** (the *Speed* pitch); other X-meets-Y Hollywood pitches
- **Generative analogy** — like **Disney "cast members"** (theme park as stage production); or **Kris & Sandy** (accounting reframed as investigative journalism)
- **Behavior-level swap** — like **Boeing's 727 runway constraint** ("seat 131 passengers, fly Miami-NYC, land on La Guardia Runway 4-22"); or **Jane Elliott's blue-eyes / brown-eyes exercise** (felt experience replaces lecture)

---

## Passage 1 — {short label}

**Technique:** {schema tap | high-concept pitch | generative analogy | behavior-level swap}
**Canonical exemplar:** like {pomelo example | Disney cast members | Die Hard on a bus | Boeing 727 runway constraint | Jane Elliott blue-eyes exercise | Kris & Sandy | Aesop's Fox & the Grapes}

**Before:**
> {verbatim original text}

**After:**
> {rewrite}

**Why this works:**
{One line — which hook(s) in the audience's existing memory the rewrite taps, how it echoes the canonical exemplar's pattern, and what the original was missing.}

**Generated vocabulary (generative analogy only):**
- {old term} -> {new term}
- {old term} -> {new term}

**Caveats:**
- {Any `[assumption — verify]` flags, e.g., "rewrite implies a performance claim the source did not state — confirm before shipping"}
- {Or: "none — rewrite uses only audience-known schemas"}

---

## Passage 2 — {short label}

...

---

## Notes for the user

- Reject any rewrite whose `[assumption — verify]` flag cannot be substantiated.
- For cultural-values rewrites, the generative analogy is only useful if at least 3 daily objects or actions can be renamed without forcing it — if fewer, downgrade to schema tap.
- For one-shot pitches (tagline, cold open), prefer high-concept pitch; verify both reference points are genuinely known to the audience, not just to you.
```

FILE:references/technique-catalog.md
# Technique Catalog — Concrete Language Rewriter

Expanded reference for the three concrete-rewrite techniques plus the behavior-level swap. Each entry includes the mechanic, worked examples from *Made to Stick*, adaptation patterns, and failure modes.

---

## Technique 1: Schema Tap

**Mechanic.** Find one thing the audience already owns in memory that shares the most critical feature of the abstract idea, then describe the new idea as `{familiar thing} + {one delta}`. The audience inherits every existing hook of the familiar thing for free.

**Why it works.** Memory is a network. A brand-new abstraction with zero connections to the existing network decays fast; a new node connected to a well-known node gets pulled along every time the known node is activated. The Velcro theory of memory: more hooks to existing knowledge = stickier retention.

**Template.** `{new thing} is like {familiar thing}, except {one delta}.`

**Worked example — pomelo.** Instead of "a large citrus fruit native to Southeast Asia, pale yellow to pink flesh, thick rind, mild sweet flavor," say: "a pomelo is a grapefruit crossed with a football." Two schemas the audience already owns (grapefruit: citrus taste, segmented flesh; football: size, oval shape) convey category, size, shape, and texture in one sentence.

**Worked example — Jane Elliott blue-eyes/brown-eyes exercise.** To teach the abstract concept of *discrimination* to third-graders who had never experienced it, Elliott did not lecture. She split the class by eye color, gave blue-eyed children privileges and brown-eyed children restrictions, then flipped the arrangement the next day. Students recalled the lesson vividly 20 years later. The abstract concept inherited the concrete sensory memory of being favored or shunned. (This is a schema tap at the classroom-experience level — the simulation *becomes* the audience's new schema.)

**Adaptation patterns.**
- Physical product descriptions -> compare to an existing product with one visible delta.
- Org concepts (e.g., "squad", "guild") -> compare to a non-work group the reader already belongs to.
- Technical processes -> compare to a domestic or mechanical process the reader has done themselves.

**Failure modes.**
- The "familiar thing" is only familiar to the writer, not the audience.
- The delta is several things at once — the reader cannot tell which feature matters.
- The schema is too close to the new thing, so there is no actual delta to learn ("it is like email, but for messages").

---

## Technique 2: High-Concept Pitch

**Mechanic.** Position a new idea as the intersection of two things the audience already understands. Both reference points must be rich enough that naming them loads their entire context into the reader's head.

**Why it works.** A new concept takes seconds to positioning-test if both reference points are already loaded. This is why Hollywood green-lights movies on a one-line pitch: the producer's mental model of "Die Hard" (action-hero hostage, ticking-clock stakes, confined space) plus "on a bus" (single location, constant motion) instantly builds the movie concept for Speed. No further explanation needed.

**Templates.**
- `{A} meets {B}`
- `{A} for {new audience or new domain}`
- `The {A} of {new domain}`
- `{A}, but {B}`
- `It is like {A}, except {B}`

**Worked examples.**
- *Speed* = "Die Hard on a bus" — action thriller in a confined moving vehicle.
- Airbnb early pitch = "eBay for space" — peer-to-peer marketplace, but for rooms.
- Uber = "push a button, get a ride" — not a pitch per se, but a high-concept description by action.

**Adaptation patterns for product marketing.**
- `{Known product} for {underserved segment}` — "Slack for construction crews"
- `{Consumer behavior} for {enterprise use case}` — "Tinder for warehouse shift swapping"
- `{A} without {pain of A}` — "Datadog without the enterprise contract"

**Failure modes.**
- One or both reference points are known only to the writer ("It is Substack for Roon users").
- The combination captures a *vibe* but not the actual job to be done.
- Used for a situation that needs generative steering, not a one-shot pitch — the analogy does not carry further into decisions.

---

## Technique 3: Generative Analogy

**Mechanic.** Choose a source frame whose internal vocabulary, roles, and daily actions will keep re-applying to the target domain to generate new decisions long after the analogy is stated. The analogy is not a description — it is an operating system that runs in the audience's head for months.

**Why it works.** A generative analogy preloads an entire decision framework. An employee who is told "you are a cast member on a stage" inherits rules about costumes, audience, breaks, and performance that the handbook could never enumerate. The analogy does the work of policy documents because humans are very good at transferring rules between analogous domains.

**Worked example — Disney cast members.** Disney reframed the theme park as a stage production. Employees -> "cast members"; customers -> "guests"; uniforms -> "costumes"; public areas -> "onstage"; staff areas -> "backstage". The frame generates decisions: you stay in character while onstage, you do not eat lunch in costume in the guest area, you treat guests as an audience not a transaction counterparty. None of these rules had to be written; the analogy generates them.

**Worked example — Kris & Sandy accounting case.** Instead of teaching accounting concepts with disconnected textbook problems, one instructor anchored an entire semester's worth of abstract accounting topics (leasing, working capital, profitability vs cash flow) around a single evolving fictional business: Kris and Sandy's SNO device company. Every lesson extended the same story. The characters and prior decisions carried context that disconnected examples could not, and the class retained abstract principles because they were always attached to one concrete, growing business.

**Worked example — Aesop's Fox and the Grapes.** A 2,500-year-old story encoding the psychological principle of rationalization. The one-scene parable is generative: "sour grapes" now serves as a two-word frame the audience applies to new situations they encounter (a person dismissing what they cannot have). The frame keeps producing interpretations long after the story is told.

**Adaptation patterns.**
- Pick a source frame with rich internal vocabulary: theater, kitchen, cockpit, newsroom, baseball team, emergency room, orchestra.
- List 3–5 daily objects/actions from the current domain that the frame will rename.
- Test: does the frame generate at least one new behavior you had not written into policy?

**Failure modes.**
- The source frame is picked for style, not for the behaviors it generates.
- The analogy renames things but does not actually change any behavior (cosmetic relabeling).
- Fewer than 3 daily terms fit the frame — the analogy peters out.
- The generated behaviors are the wrong ones (the analogy pulls users toward outcomes you did not intend).

---

## Technique 4 (out of the three, but essential): Behavior-Level Swap

**Mechanic.** When the flagged passage is a *goal* or *strategy* rather than an explanation, do not apply an analogy — replace quality adjectives with measurable constraints or named behaviors.

**Why it works.** Adjectives do not coordinate action. A 500-person engineering org cannot self-organize around "the best user experience", but it can self-organize around "the page loads in under 200ms on a 3G connection." Constraints are shareable across teams that never meet; adjectives are not.

**Worked example — Boeing 727.** Boeing's 1960s design brief for the 727 was not "build the best passenger plane." It was: "Seat 131 passengers, fly nonstop from Miami to New York, and land on La Guardia Runway 4-22." That runway was under a mile — impossible for then-current jets. Thousands of engineers across dozens of specialties self-coordinated from that single constraint. The runway defined the airframe.

**Transforms.**
- `best` -> specific measurable threshold (`p95 < 200ms`, `bounce rate < 30%`)
- `delightful` -> observable user action (`new users publish their first post without opening the help docs`)
- `aligned` -> specific verbal behavior (`every PM writes the same one-sentence answer to "what are we building this quarter"`)
- `empower` -> specific unblocked action (`every support agent can issue refunds up to $500 without approval`)
- `world-class` -> benchmark against a named competitor's named metric

**Failure modes.**
- Swapping an adjective for a number that is not actually measurable day-to-day.
- Choosing a metric that is measurable but not the metric that matters (Goodhart's law).
- Over-constraining — leaving no room for the creativity the goal was trying to invite.

---

## When to use each technique

| Situation | Technique |
|---|---|
| "What is this thing?" (new product, new term, new concept) | Schema tap |
| "How is this different from X?" (positioning, tagline, one-shot pitch) | High-concept pitch |
| "How should our team behave over time?" (culture, values, long-running frame) | Generative analogy |
| "What does success look like?" (goal, strategy, mission) | Behavior-level swap |

---

## Self-check against fabrication

For every rewrite, verify:
1. Every sensory detail either already exists in the audience's shared knowledge OR corresponds to a fact the user actually supplied.
2. No new numbers, names, or physical features have been introduced that the user cannot defend.
3. If the rewrite *needed* invented detail to work, the technique was wrong — re-pick from the table.

Concrete language is a multiplier on truth, not a substitute for it. A concrete lie is just a sticky lie.

---
name: value-testing-technique-selection
description: "Select and execute the right value testing technique for product discovery. Use when you have a prototype and need to know if customers will actually choose or buy the product, when deciding between a fake door test, usability test, A/B test, or invite-only program, when someone asks 'how do we test if users want this?' or 'should we run an A/B test?', or when setting up analytics instrumentation before launch. Also use when validating demand before building anything, when choosing between qualitative vs. quantitative value testing, or when the team is unsure whether 'people said they liked it' is enough evidence. Covers the 3-level value testing hierarchy (demand / qualitative / quantitative), the usability-then-value session protocol, and the analytics instrumentation checklist. For prototype selection, use discovery-prototype-selection. For finding product-market fit with reference customers, use customer-discovery-program. For stakeholder viability sign-off, use business-viability-stakeholder-testing."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/value-testing-technique-selection
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [50, 51, 52, 53, 54]
tags: [product-management, product-discovery, user-research, testing]
depends-on: [product-discovery-risk-assessment, discovery-prototype-selection]
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Risk assessment output or product/feature description including traffic volume, risk tolerance, and prototype readiness"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Document-based product management environment"
discovery:
  goal: "Select the correct value testing technique and produce an executable test plan"
  tasks:
    - "Apply the 3-level value testing hierarchy to select the appropriate technique"
    - "Design and run a usability test session as a prerequisite to value testing"
    - "Execute the specific value test (demand, qualitative, or quantitative)"
    - "Select among A/B, invite-only, and customer discovery program for quantitative work"
    - "Define the analytics instrumentation plan for the feature"
  audience:
    roles: [product-manager, product-designer, tech-lead, startup-founder]
    experience: any
  when_to_use:
    triggers:
      - "You have a high-fidelity prototype and need to know if customers will choose the product"
      - "Risk assessment has identified value risk as Medium or High"
      - "You need to decide whether to use A/B testing, invite-only, or customer discovery program"
      - "You are launching a new feature and need to define what analytics to instrument"
      - "Sales is hearing demand signals but you have no quantitative evidence"
    prerequisites:
      - "product-discovery-risk-assessment completed (value risk identified)"
      - "discovery-prototype-selection completed (prototype type selected)"
    not_for:
      - "Usability testing alone — this skill uses usability testing as a prerequisite step, not the goal"
      - "Feasibility testing — use engineer-led feasibility spikes"
      - "Business viability review — use stakeholder review process"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: ""
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Value Testing Technique Selection

## When to Use

Apply this skill when you have evidence of a product idea worth testing and need to determine whether customers will actually choose it. This skill answers three questions:

1. Which level of value testing does this situation call for — demand, qualitative, or quantitative?
2. How do I execute the right session protocol?
3. What analytics must be instrumented before or alongside any test?

Do NOT use this skill as a substitute for usability testing alone, feasibility spikes, or business viability stakeholder review. Those are handled by separate skills. This skill assumes a prototype exists or can be built quickly.

**The core insight:** Just because someone can use your product doesn't mean they will choose to use it. Feature parity is not enough. Customers must perceive your product as substantially better to endure the switching costs from their current solution.

## The 3-Level Value Testing Hierarchy

Before selecting any technique, apply this hierarchy in order. Start at Level 1 and only advance if the prior level is satisfied.

| Level | Question Answered | Technique | When to Use |
|-------|------------------|-----------|-------------|
| **1 — Demand** | Do customers care about this problem enough to act? | Fake door test / landing page demand test | Unknown if customers want this at all; new product or feature; before building anything |
| **2 — Qualitative** | Do customers see real value when they experience it? Why or why not? | Interview + usability + specific value tests | You know demand exists but need to understand whether your solution is compelling and why |
| **3 — Quantitative** | Is there statistically meaningful behavioral evidence of value? | A/B test / invite-only / customer discovery program | Usability and qualitative value are confirmed; you need evidence to justify full build investment |

**Why this ordering matters:** Level 1 prevents wasted engineering effort on solutions nobody wants. Level 2 explains what Level 3 will measure and provides the "why" that quantitative data alone cannot. Skipping to Level 3 without Level 2 leaves you with data that tells you something is wrong but not how to fix it.

## Step 1: Determine Which Level to Enter

Read the risk assessment and answer these questions in order:

**Is demand established?**
- No clear evidence anyone wants this → start at Level 1 (demand testing)
- Demand signals exist (sales reports, customer interviews, competitor market) → skip to Level 2

**Is qualitative value confirmed?**
- Have fewer than 5 customers experienced the solution and responded positively → start at Level 2
- 5+ users have tested the prototype and shown genuine value signals → consider Level 3

**What is the risk/traffic profile?**
- New product or startup with low traffic → Level 1 or Level 2; skip quantitative until demand exists
- Established product with traffic but high risk sensitivity → Level 3 invite-only or customer discovery program
- Established product with significant traffic and moderate risk tolerance → Level 3 A/B test

**WHY:** Jumping to A/B testing before qualitative value is confirmed produces data that shows whether a product works, but provides no insight into why it doesn't work or how to fix it. Conversely, stopping at qualitative testing without moving to quantitative leaves the team making claims that cannot be defended to stakeholders.

## Step 2: Execute the Selected Level

### Level 1 — Demand Testing

Use a fake door test (for features on an existing product) or a landing page demand test (for new products).

**Fake door test:**
1. Add the button or menu item to the product interface exactly where users would expect to find it
2. When clicked, redirect to a page explaining you are studying the possibility of adding this feature and inviting them to volunteer for a conversation
3. Collect email addresses or phone numbers from volunteers
4. Measure the click-through rate and compare to baseline feature interaction rates
5. Follow up with volunteers for qualitative interviews

**Landing page demand test:**
1. Build a landing page that describes the new offering exactly as if it were live
2. Drive traffic via existing channels, search engine marketing, or email
3. When users click the call to action, redirect to a page explaining you are studying this offering and would like to speak with them
4. Collect volunteer contact information and measure click-through rate

**What success looks like:** Meaningful click-through rate relative to other features/products, and a list of users actively willing to discuss the problem. The demand test does not prove customers will pay — only that they care enough to investigate.

**WHY:** Building a complete product only to discover nobody wants it is the most avoidable failure in product development. Demand testing takes hours to days, not months. The fake door specifically reveals whether real users in actual context care about this, not just users asked hypothetically in a survey.

See `references/qualitative-value-test-protocol.md` for the follow-up interview protocol after collecting volunteer contacts.

### Level 2 — Qualitative Value Testing

This is the single most important discovery activity for most product teams. Run at minimum two to three qualitative value sessions per week during active discovery.

**The session structure has four parts, always in this sequence:**

**Part A — Interview First (5–10 minutes)**
Confirm the user has the problem you think they have. Ask how they solve it today and what it would take for them to switch. This grounds the value test in actual context.

**WHY:** If the user does not actually have the problem, their response to your solution is meaningless. The interview prevents you from treating a non-customer as a customer.

**Part B — Usability Test (15–20 minutes)**
Before testing value, the user must understand how to use the product. Run a full usability test first. The value test is only valid once the user has operated the prototype and understands what it does.

**WHY:** Without usability testing first, a value session becomes a focus group where users comment hypothetically on something they have never operated. Focus groups produce polite opinions that do not predict behavior. Operate the prototype first, then test value.

See `references/usability-test-protocol.md` for the complete four-phase usability test protocol.

**Part C — Specific Value Tests (10–15 minutes)**
After usability, apply one or more of these four value tests. They are designed to detect genuine enthusiasm, not polite agreeableness.

| Value Test | What to Do | Signal |
|-----------|-----------|--------|
| **Money test** | Ask if they would pay for it right now; request credit card or letter of intent | Willingness to make a financial commitment |
| **Time test** | Ask if they would schedule significant time with you to work on this | Willingness to invest their most scarce resource |
| **Access test** | Ask for login credentials to the competing product they would switch from | Willingness to commit to switching right then |
| **Referral test** | Ask for Net Promoter Score (0–10 likelihood to recommend); ask for their boss's or colleague's email | Willingness to stake their reputation on this |

Use whichever tests fit the context. For consumer products, money and referral tests are most practical. For business products, all four apply. The goal is not to collect the credit card or email — it is to observe whether the user is willing to make a commitment, which reveals genuine perceived value versus politeness.

**Part D — Iterate the Prototype**
As soon as you see a problem or want to try a different approach, update the prototype and test it in the next session. There is no law that says you must keep the test identical across all subjects. Qualitative testing is about rapid learning, not proving anything.

**Cadence:** Target two to three sessions per week throughout discovery. As product manager, you must be present at every session. Do not delegate this.

### Level 3 — Quantitative Value Testing

Quantitative testing collects behavioral evidence. Use it to prove that a solution works, not to discover what to build. The technique depends on your traffic volume and risk tolerance.

**Technique selection:**

| Situation | Technique | Why |
|-----------|-----------|-----|
| High traffic, moderate risk tolerance | **A/B test at 1% exposure** | Gold standard; users don't know which version they see; most predictive data |
| Lower traffic or higher risk aversion | **Invite-only test** | Identifies a willing set of early adopters; less predictive due to opt-in bias, but generates real usage data |
| Maximum risk sensitivity (regulated, enterprise, brand-sensitive) | **Customer discovery program** | Participants under non-disclosure agreement; pre-existing close relationship; most conservative |

**A/B testing (discovery variant):**
Run the live-data prototype against the current product. Show the live-data prototype to 1% or fewer of users. Monitor closely. This differs from optimization A/B testing (which tests surface-level changes at 50/50 splits). Discovery A/B testing tests fundamentally different approaches with minimal user exposure.

**Invite-only testing:**
Identify users to contact directly and invite them to try an experimental version. They know it is experimental, so they are effectively opting in. The data is less predictive than a blind A/B test because early adopters are not representative of the full user base. When quantitative results are negative, follow up immediately with qualitative sessions to understand why.

**Customer discovery program:**
Use your existing customer discovery program members. They have already opted in to testing new versions and are under a non-disclosure agreement. For business-to-business products, this is the primary recommended quantitative technique during discovery. Compare their usage data to the broader customer base.

**WHY for technique selection:** A/B tests produce the most predictive data because users are blind to the test. But they require sufficient traffic to achieve statistical significance, and they expose some users to potentially inferior experiences. Invite-only and customer discovery program reduce exposure risk at the cost of predictive power. Match the technique to what your traffic and risk profile can actually support.

## Step 3: Analytics Instrumentation (Non-Negotiable)

Every feature shipped must have usage analytics instrumented before or at launch. Not doing this is the "flying blind" anti-pattern — a non-negotiable failure.

**The flying blind anti-pattern:** Teams that ship features without instrumentation cannot know whether those features are working, whether users are adopting them, or whether they should be removed. This prevents data-informed decisions and makes roadmap prioritization guesswork.

**Rule:** If you are not willing to instrument a feature to know immediately whether it is working and whether there are significant unintended consequences, do not ship it.

**Minimum instrumentation checklist for any new feature:**
- [ ] Feature adoption rate (are users finding and using it?)
- [ ] Task completion rate (are users completing the intended workflow?)
- [ ] Error/abandonment points (where are users dropping off?)
- [ ] Impact on key business metric (conversion, retention, revenue, or the metric the feature was designed to move)

**Broader analytics strategy:** Product managers must track analytics across all seven categories. Most teams only track user behavior and miss the rest.

| Category | Examples |
|----------|---------|
| User behavior | Click paths, feature engagement, session flow |
| Business | Active users, conversion rate, lifetime value, retention |
| Financial | Average selling price, billings, time to close |
| Performance | Load time, uptime, latency |
| Operational | Storage, hosting costs |
| Go-to-market | Acquisition cost, cost of sales |
| Sentiment | Net Promoter Score, customer satisfaction, survey responses |

See `references/analytics-strategy.md` for the full five uses of analytics and implementation guidance.

## Outputs

After completing this skill, produce:

```
# Value Test Plan: [Feature / Product Name]

## Level Selected
[ ] Level 1 — Demand   [ ] Level 2 — Qualitative   [ ] Level 3 — Quantitative
Rationale: [why this level]

## Technique Selected
[Fake door / Landing page / Qualitative session / A/B test / Invite-only / Customer discovery program]

## Test Plan
[For demand: where the fake door appears, what the redirect page says, how CTR will be measured]
[For qualitative: session structure, value tests selected, target users, weekly cadence]
[For quantitative: traffic %, exposure duration, primary metric, statistical significance threshold or evidence threshold]

## Usability Test Required First?
[ ] Yes — complete usability-test-protocol before value test
[ ] No — user already understands the product

## Value Tests to Apply (qualitative)
[ ] Money test   [ ] Time test   [ ] Access test   [ ] Referral test

## Analytics Instrumentation Plan
[List the specific events and metrics to instrument before launch]

## Success Criteria
[What signal means this test produced sufficient evidence to move to next level or to full build?]

## Next Step
[If positive: proceed to Level 3 / proceed to full build / present to stakeholders]
[If negative: iterate prototype / reconsider problem framing / stop and preserve capacity]
```

## Key Anti-Patterns

**Prototype-as-value-proof:** Showing a high-fidelity prototype to users who say they love it does not validate value. People are polite. Use the specific value tests (money, time, access, referral) to detect genuine commitment, not stated enthusiasm.

**Flying blind:** Shipping features without instrumentation. Non-negotiable failure. Every feature needs basic usage analytics before launch.

**Skipping qualitative before quantitative:** Running an A/B test before qualitative value is confirmed produces data that tells you something is wrong but not how to fix it.

**Focus group substitution:** Asking users to comment on a prototype they have never operated produces hypothetical opinions, not behavioral insight. Always run usability testing before value testing.

**Delegating qualitative sessions:** As product manager, you must attend every qualitative value test. The firsthand exposure to customer reactions is a core part of the role and cannot be substituted with written summaries.

## References

- `references/usability-test-protocol.md` — Complete four-phase usability test protocol (recruit, prepare, test, summarize) with the parrot technique and use-mode guidance
- `references/qualitative-value-test-protocol.md` — Full qualitative value session structure including interview-first approach, all four specific value tests, and iteration cadence
- `references/analytics-strategy.md` — Five uses of analytics in product teams, seven analytics categories, flying blind anti-pattern detail, and instrumentation implementation guidance

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

Install related skills from ClawhHub:
- `clawhub install bookforge-product-discovery-risk-assessment`
- `clawhub install bookforge-discovery-prototype-selection`

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/analytics-strategy.md
# Analytics Strategy for Product Teams

Product managers today are expected to be comfortable with data and understand how to leverage analytics to learn and improve quickly. This is not optional. The teams that fly blind — shipping features without instrumentation — consistently make worse product decisions and cannot justify their choices to stakeholders.

## The Flying Blind Anti-Pattern

Remarkably, too many product teams either do not instrument their products to collect analytics at all, or they do it at such a minor level that they cannot determine if and how their product is being used.

**The anti-pattern:** Ship a feature, see no instrumentation data, guess whether it is working, argue about it in meetings, and eventually either leave it forever or remove it based on opinion rather than evidence.

**The consequence:** Without usage data, you cannot:
- Know whether a feature is being adopted
- Identify which features are unused and should be removed
- Understand whether a change improved or hurt the metric it was meant to affect
- Defend roadmap decisions to leadership and stakeholders
- Know what actually happened when something goes wrong

**The rule:** If you would not be willing to instrument a feature to know immediately whether it is working and whether it is producing significant unintended consequences, do not ship it. Start from the position that you must have this data, then work backward to figure out the best way to get it.

For every new feature, ensure instrumentation is in place before launch. For most cloud-based products, this is straightforward. For installed desktop or mobile applications, the product calls home periodically with anonymized, aggregated usage data. Always anonymize and aggregate to avoid personally identifiable information.

## The Five Uses of Analytics

Strong product teams use analytics for five distinct purposes. Many teams only use the first. Using all five represents a significant competitive advantage.

### Use 1: Understand User and Customer Behavior

When most people think of analytics, they think of user behavior analytics. This is the most common use, but it is only the beginning.

The goal is to understand how users actually use your products versus how you assumed they would use them. The gap between assumption and reality is where product insight lives.

Applications:
- Identify features that are not being used (candidates for removal or redesign)
- Confirm that features are being used as expected
- Understand click paths through complex workflows
- See the difference between what users say they do and what they actually do

This is one of the very few non-negotiables in product: if you add a feature, you need to put in at least basic usage analytics for that feature. How else will you know if it is working?

### Use 2: Measure Product Progress

Rather than measuring progress by features shipped (output), measure progress by business outcomes (outcomes).

Strong product teams receive business objectives with measurable goals. They use analytics to track whether they are making progress against those objectives. This keeps teams focused on outcomes rather than shipping lists.

Application: Define the metric you are trying to move with each initiative. Track that metric before, during, and after the change to measure whether the initiative worked.

### Use 3: Prove Whether Product Ideas Work

For products with sufficient traffic, analytics can isolate the contribution of specific features, workflow changes, or design decisions.

This is the role of A/B testing in the discovery context — not optimization testing (testing button colors at 50/50 splits), but discovery testing (showing a live-data prototype to 1% of users to measure behavioral evidence of value).

Even when traffic volume makes statistically significant results difficult to achieve, actual usage data from live-data prototypes produces better-informed decisions than opinions alone.

Application: For high-risk or high-cost initiatives, require quantitative evidence before committing full engineering investment.

### Use 4: Inform Product Decisions

The worst product decisions are made based on opinion, and typically the most senior person's opinion wins. Data beats opinions.

When a stakeholder argues that a feature must be built because customers have asked for it, analytics can show how many customers actually use the related capabilities today. When someone argues that removing a feature will cause customer outrage, analytics can show how many customers have used that feature in the last 90 days.

Data does not make decisions for you. But it changes the quality of decisions by replacing assertion with evidence.

### Use 5: Inspire Product Work

This is often the most underappreciated use of analytics. The data itself — when explored with curiosity — can reveal product opportunities that no customer interview or stakeholder request would surface.

When you examine how users actually use your product, you encounter surprises. You discover workflows that contradict your design assumptions. You find features used in ways you never intended. You see patterns that suggest entirely new capabilities.

Some of the best product ideas are not requested by customers or proposed by engineering — they emerge from studying the data and asking "why is this happening?"

## The Seven Analytics Categories

Most teams track user behavior and one or two other categories. Strong product managers track across all seven.

| Category | What It Measures | Examples |
|----------|-----------------|---------|
| **User behavior** | How users interact with your product | Click paths, feature engagement, session flow, task completion |
| **Business** | Product-level business health | Active users, conversion rate, lifetime value, retention, churn |
| **Financial** | Revenue and deal metrics | Average selling price, billings, time to close, expansion revenue |
| **Performance** | Technical product quality | Load time, uptime, latency, error rate |
| **Operational** | Infrastructure costs | Storage consumption, hosting costs, API call costs |
| **Go-to-market** | Customer acquisition efficiency | Acquisition cost, cost of sales, program ROI |
| **Sentiment** | Customer perception and satisfaction | Net Promoter Score, customer satisfaction surveys, support ticket themes |

Most product managers have too narrow a view, focusing only on user behavior and business metrics. The other five categories often contain signals that explain why business metrics are moving in unexpected directions.

For example: a drop in conversion rate (business metric) might be explained by a spike in load time (performance metric) or a change in acquisition source (go-to-market metric). Without all seven categories, you see the symptom but not the cause.

## Minimum Instrumentation for a New Feature

Before launching any feature, confirm instrumentation is in place for:

1. **Adoption:** Is the feature being discovered and used? (feature exposure rate, activation rate)
2. **Task completion:** Are users completing the intended workflow? (completion rate, abandonment point)
3. **Error / friction:** Where do users encounter problems? (error events, rage clicks, abandonment steps)
4. **Outcome impact:** Is this feature moving the metric it was designed to affect? (the specific business, financial, or behavioral metric the feature was meant to influence)

For anything with higher risk or higher deployment cost, also add:
- Comparison baseline (what was the metric before the change?)
- Unintended consequence monitoring (are any adjacent metrics moving unexpectedly?)

## Analytics and Qualitative Testing: The Complete Loop

Analytics tells you what is happening. Qualitative testing tells you why.

These two types of learning are not alternatives — they are complements. The complete loop:

1. Analytics reveals an unexpected pattern (adoption is lower than expected; a workflow step has high abandonment; a feature is unused)
2. Qualitative testing (user interviews, value test sessions, usability sessions) explains why
3. The team forms a hypothesis, updates the prototype, and tests it
4. Analytics measures whether the change fixed the problem

Neither analytics alone nor qualitative testing alone is sufficient. Product teams that rely only on analytics optimize metrics without understanding customer motivation. Teams that rely only on qualitative testing cannot validate whether their changes actually worked at scale.

## Implementation Notes

- Analytics are often referred to as key performance indicators (KPIs) in organizational contexts. The categories above map to KPIs used in executive reporting.
- For strict firewall environments (regulated industries, enterprise on-premise software), products can generate periodic usage reports that are reviewed and approved before being forwarded electronically or in print. Even the most conservative environments can implement some form of product instrumentation.
- Use existing web analytics tools where applicable. For cases requiring custom tracking, the process is: (1) define what you need to know, (2) instrument the product to collect it, (3) generate reports for ongoing review.
- The first thing most strong product managers do in the morning is check the analytics from the preceding night's test results. This cadence — daily review of active experiments — is how they stay informed and responsive.

FILE:references/qualitative-value-test-protocol.md
# Qualitative Value Test Protocol

Qualitative value testing is, in Cagan's view, probably the single most important discovery activity for a product team. The goal is rapid learning and big insights — understanding whether customers see real value in your solution, and why or why not.

Quantitative testing tells you what is happening. Qualitative testing tells you why. Both are necessary. Qualitative testing comes first.

**Cadence target:** At minimum two to three qualitative value test sessions per week during active discovery.

**Who must attend:** Product manager, product designer, and at minimum one rotating engineer. The product manager must be present at every session without exception. Do not delegate this. Do not hire a firm to do this for you. The firsthand exposure to user reactions is a core competency of the product manager role.

## The Problem: Politeness Bias

The central challenge in qualitative value testing is that people are generally nice. When sitting face to face with someone who has built something, most people are not willing to tell you what they really think. They give polite, encouraging feedback that does not reflect their actual likelihood to use or pay for the product.

All value tests in this protocol are designed to cut through politeness bias by asking users to make a commitment — not just state an opinion. Commitments (money, time, access, reputation) reveal genuine value perception far more accurately than stated enthusiasm.

## Session Structure

Run each session in four sequential parts. Do not reorder them.

### Part 1: Interview First (5–10 minutes)

Open every session with a short customer interview before showing the prototype.

**Goal:** Confirm that this user actually has the problem you are solving, understand how they currently solve it, and learn what it would take for them to switch.

**Questions to ask:**
- "Tell me about how you currently [handle the problem area]."
- "What's the most frustrating part of that process?"
- "What tools or approaches have you tried?"
- "What would make you consider switching to something new?"

**Why this comes first:** If the user does not actually have the problem, their response to your solution is not useful data. You need to know whether you are talking to a genuine potential customer before interpreting anything they say about the product. This also creates context — after discussing their current approach, users evaluate your solution relative to their actual situation rather than abstractly.

**If the user does not have the problem:** Note this, thank them for their time, and consider whether your recruitment screening criteria need adjustment. Do not proceed with the value test — the data would be invalid.

### Part 2: Usability Test (15–25 minutes)

Before testing value, the user must understand how to use the product. Run a full usability test on the prototype.

**Why usability testing precedes value testing:**

If you attempt value testing without usability testing first, the session becomes a focus group. The user comments hypothetically on something they have never operated — imagining how it might work, asking clarifying questions, making up scenarios. Focus groups provide market insight but do not predict whether your product will work. You need users to have actually operated the product to have a meaningful conversation about value.

After a usability test, the user knows what the product is, how it works, and what it is meant to do. Only then can you have a credible conversation about whether they see value in it.

Follow the usability test protocol in `usability-test-protocol.md`. Use a high-fidelity prototype — value testing requires realism. A live-data prototype or hybrid prototype also works.

**Transition:** After the usability test, the user is in a position to have an informed conversation about the product. Move immediately to specific value tests.

### Part 3: Specific Value Tests (10–15 minutes)

Apply one or more of the four specific value tests. Choose based on what fits the context (consumer vs. business, product type, relationship).

**Value Test 1 — Money**

Ask the user if they would be willing to pay for the product right now.

For consumer products or lower-cost software: "Would you be willing to put in your credit card right now? We don't actually need it, but I'm curious if this is something you'd pay for."

For expensive business products (beyond what an individual would put on a credit card): "Would you be willing to sign a non-binding letter of intent to purchase this if we build it?"

**What the signal means:** You are not collecting the credit card or the letter. You are observing whether the user is willing to make a financial commitment. Willingness to do so — even when told it's not required — reveals genuine perceived value. Refusal or hesitation, even after expressed enthusiasm, reveals politeness bias at work.

**Value Test 2 — Time**

Especially effective for business products:

"Would you be willing to schedule significant time with us — say, a few hours per week over the next month — to work on this with us? We don't necessarily need it, but I'm curious if this is important enough for you to invest that kind of time."

**What the signal means:** Time is the scarcest resource in business. A user's willingness to commit time — even hypothetically — is a strong indicator of how much they value the solution. Businesses that actually have the problem will recognize the value of solving it and will be willing to invest.

**Value Test 3 — Access**

"Would you be willing to give us the login credentials for the product you're currently using for this? We have a migration utility that would help import your data. We don't really need it now, but I'm curious if you'd be ready to switch."

**What the signal means:** Handing over access credentials to a product they are actively using is a significant commitment. It reveals genuine readiness to switch, not just openness to switching someday. Users who are only mildly interested will not do this. Users who genuinely see this as a substantially better solution will.

**Value Test 4 — Referral**

Two variants, use one or both:

Net Promoter Score variant: "On a scale of 0 to 10, how likely would you be to recommend this product to a friend or colleague?"

Commitment variant: "Would you be willing to enter your boss's email address or a colleague's email address so we could tell them about this? We wouldn't actually email them without asking you first — I'm just curious if this is something you'd be willing to put your name behind."

**What the signal means:** Willingness to share on social media, provide a boss's email, or give a high Net Promoter Score indicates that the user is willing to stake their reputation on recommending this product. This cuts through politeness more effectively than asking "Would you use this?" — people are far more careful when their professional reputation is involved.

### Part 4: Iterate the Prototype

After each session (or set of sessions), update the prototype based on what you learned.

**There is no requirement to keep the test identical across all subjects.** The goal is rapid learning, not statistical proof. If session two reveals that users are confused by the navigation, fix the navigation before session three.

**Decision rules:**

- If responses are substantially different across users, investigate why. You may have different customer segments with different problems, or your solution may work for some use cases but not others.
- If you cannot get users interested in the problem or cannot make the solution usable enough that they perceive value, consider stopping and putting the idea on the shelf. This is not failure — it is the discovery process preventing engineering investment in something customers will not value.
- If users consistently show genuine value signals (willingness to pay, invest time, provide access, or recommend), proceed to the next steps: quantitative validation or full build planning.

## Session Notes Template

Use this template to capture findings immediately after each session:

```
Session Date: 
User Profile: [role, company size/type, current solution]
Problem Confirmed: [ ] Yes  [ ] No  [ ] Partial

Usability Issues Observed:
- [Issue 1 — where it occurred, what the user did]
- [Issue 2...]

Value Test Results:
- Money test: [ ] Strong  [ ] Lukewarm  [ ] Declined  [ ] Not administered
- Time test: [ ] Strong  [ ] Lukewarm  [ ] Declined  [ ] Not administered
- Access test: [ ] Strong  [ ] Lukewarm  [ ] Declined  [ ] Not administered
- Referral test: NPS score: __  Willing to provide email: [ ] Yes  [ ] No
  
Verbal Signals: [What did the user say that was most revealing?]
Behavioral Signals: [What did the user do that was most revealing?]
Body Language / Tone: [Did enthusiasm match stated opinion?]
Surprising Observations: 
Prototype Changes Before Next Session:
Overall Value Signal: [ ] Strong  [ ] Mixed  [ ] Weak  [ ] Negative
```

## Email Summary Format

After each session or set of sessions, the product manager or designer sends a brief email to the product team:

**Subject:** Value test learnings — [Feature Name] — [Date]

**Body:**
- What worked (tasks completed, strong value signals)
- What didn't work (friction points, weak value signals)
- What surprised us
- Changes being made to the prototype
- Next session scheduled: [date/time]

Keep it to one page or less. Long reports are obsolete before they are read.

FILE:references/usability-test-protocol.md
# Usability Test Protocol

This document provides the complete four-phase protocol for running usability tests as part of product discovery. In the value testing context, usability testing is always a prerequisite to qualitative value testing — users must understand how to operate the product before their value reactions are meaningful.

## Why Usability Testing in Discovery

Traditional usability testing happened at the end of development, after the product was built. By then, correcting serious issues required significant waste or produced a permanently flawed product.

Modern discovery practice runs usability testing on prototypes — before anything is built — so that issues are corrected at near-zero cost. The main difference is the timing: discovery usability testing uses prototypes, not products.

## Phase 1 — Recruit

You need at minimum 5 test subjects. Research consistently shows that 5 users reveal the majority of serious usability issues.

**Recruitment channels (in order of preference):**

1. **Customer discovery program members** — Pre-qualified, already opted in, best for business products. Use this if you have one.
2. **Email list selection** — If you have a user email list, work with your product marketing manager to select a screened subset matching your target customer profile.
3. **Company website volunteer form** — Solicit test subject volunteers. Screen all volunteers with a phone call to confirm they are in your target market.
4. **Craigslist or search engine marketing campaign** — Especially effective for reaching users who are actively in the moment of experiencing the problem your product solves (for example, a Google AdWords campaign targeting people searching for your problem category).
5. **Intercept at locations where target users congregate** — Trade shows for business software, shopping centers for e-commerce, sports bars for fantasy sports. Bring thank-you gifts.

**Compensation:** If asking users to come to your location, compensate them for their time. A common approach is to meet at a mutually convenient location — a coffee shop works well. This is so common it is called Starbucks testing.

**Screening requirement:** Always screen volunteers by phone before the session. Confirm they match your target customer profile. Volume is less important than quality — five well-matched users are more valuable than fifteen mismatched ones.

## Phase 2 — Prepare

**Prototype:** Use a high-fidelity user prototype for both usability testing and value testing. You can get useful usability feedback from lower-fidelity prototypes, but the value testing that follows requires realism. Build to the fidelity level that the downstream value test demands.

**Attendees:** Product manager, product designer, and at minimum one engineer (rotating among team members). All three must be present. The product manager and designer must attend every session without exception. Engineer attendance is strongly encouraged — the direct exposure to customer behavior produces learning that written summaries cannot replicate.

**Role division:**
- One person administers the test (interacts with the user)
- One person takes notes
- After the session, both debrief to confirm they observed the same things and reached the same conclusions

**Task definition:** Define in advance the specific tasks you want to test. Focus on the primary tasks — the ones users will do most of the time. There may also be less-frequent but important tasks; include those if they are risky. Do not try to test everything in one session.

**Example task list for a report generation feature:**
- Generate a report for last quarter's sales
- Change the date range on a report
- Share a report with a colleague
- Export a report to a spreadsheet

**Venue:**
- Coffee shop table — informal, user feels less like a lab rat, works well for most situations
- Customer's office — excellent for business products; environmental cues (monitor size, desk setup, coworker interruptions) reveal additional context
- Formal testing lab with two-way mirror — useful when available, but not required
- Remote tools — acceptable supplement for usability testing, but less suitable for the value testing that follows (value testing benefits from in-person presence)

## Phase 3 — Test

### Opening the Session

Before presenting any tasks:

1. **Set expectations:** Tell the user this is a prototype, it is a very early product idea, and it is not real. Explain that you are testing the ideas in the prototype, not testing them. They cannot pass or fail — only the prototype can. You want candid feedback, good or bad.

2. **Landing page cold read:** Before jumping into tasks, ask the user to look at the landing page or home screen of your prototype and tell you what they think it does and what might be valuable or appealing to them. Do this before they start interacting with tasks — once they are in task mode, you lose the first-time visitor perspective. Landing pages are critical for bridging the gap between user expectations and what the product actually does.

### During the Test

**Keep users in use mode, not critique mode.**

The goal is to observe what users can and cannot do. It does not matter whether the user thinks something is ugly or that a button is in the wrong place. What matters is whether they can complete the tasks they need to do.

Avoid asking questions like "What three things would you change about this page?" Unless the user is a product designer, their answer to that question is not useful. Watch what they do more than what they say.

**Stay quiet.**

The hardest skill in usability testing is silence. When a user struggles, the natural instinct is to help. Suppress that instinct. Get comfortable with silence — it is your most important tool. Struggle reveals friction; helping the user removes the signal.

**The three outcomes for each task:**
1. User completed the task with no problem and no help — good
2. User struggled but eventually completed the task — friction detected
3. User gave up — failure; note whether they truly abandoned or were about to leave the product entirely

**The parrot technique:**

When you feel compelled to say something (either because the silence is uncomfortable or because you want to prompt the user), parroting is the tool:

- If the user is scrolling and looking confused, say: "I see you're looking at the list on the right." This prompts them to tell you what they are trying to find without leading them toward an answer.
- If the user asks "Will clicking this create a new entry?", respond: "You're wondering if clicking this will create a new entry?" The user will typically answer their own question. This avoids leading the witness.
- Use parroting instead of value judgments. Instead of "Great!" when the user completes a task, say "You created a new entry." This avoids leading value judgments while still acknowledging their action.
- Parroting gives the note-taker more time to write down observations.

**Avoid leading the witness:**

Do not give hints. Do not redirect attention. If you see the user scrolling past the right answer, do not help. What you are observing is exactly the information you need — that the affordance is not discoverable.

**Reading non-verbal signals:**

Users communicate through body language and tone. Genuine enthusiasm is visible — they lean forward, ask follow-up questions, and often ask when the product will be available. Lack of genuine enthusiasm is also visible even when users say polite things. Watch for the gap between what users say and what their body language and engagement level communicate.

## Phase 4 — Summarize

**Immediately fix issues you identify.**

There is no rule that says you must keep the test identical across all subjects. Qualitative usability testing is about rapid learning, not proving anything statistically. As soon as you identify an issue, fix it in the prototype before the next session. This is the power of discovery usability testing — fast iteration at low cost.

**The email summary:**

After each test session (or after each set of sessions if running multiple in a day), the product manager or designer writes a short email summary of key learnings and sends it to the product team. Keep it brief — one page or less. Long reports that take hours to write and days to read are obsolete by the time they are delivered. The prototype will have moved past what was tested.

The email summary should include:
- What tasks users completed successfully
- Where users struggled or failed
- What surprised you
- What changes are being made to the prototype before the next session

**What you are looking for:**

The goal is to identify places in the prototype where the model the software presents is inconsistent or incompatible with how the user is thinking about the problem. When you find this mismatch, the fix is often straightforward — nomenclature, flow, or visual hierarchy — and fixing it can be a significant win.

## Common Mistakes

| Mistake | Why It Fails | Correction |
|---------|-------------|------------|
| Running usability test at the end of development | Issues found too late to fix without significant waste | Run on prototypes during discovery |
| Product manager or designer not attending | Secondhand summaries miss critical nuance; learning must be firsthand | Attend every session — non-negotiable |
| Asking for design opinions ("What would you change?") | Users cannot specify what to build; their opinions predict their own behavior poorly | Watch what they do, not what they say |
| Helping users when they struggle | Removes the friction signal | Stay silent; use the parrot technique |
| Writing long formal reports | Reports are obsolete before they are read | Write brief email summaries immediately after each session |
| Testing too few users | Missing major issues | Target minimum 5 users per round of testing |
| Using internal employees as test subjects | Employees know the product, think like the team, and are not target customers | Always use actual target customers |

---
name: product-vision-strategy-assessment
description: |
  Assess or create a product vision and product strategy. Use when someone asks 'is our product vision strong enough?', 'does our strategy make sense?', 'we keep pivoting — is that a vision problem or a strategy problem?', or 'how do I write a compelling product vision?' Also use when diagnosing why teams lack direction or feel like mercenaries, stress-testing a strategy for focus and market sequencing, checking whether product principles are resolving design debates, or auditing an existing vision statement for ambition and inspiration gaps. Scores vision against 10 principles and strategy against 5 principles, identifies top gaps with specific rewrite guidance, and evaluates whether product principles exist and are functioning as guardrails. Works on vision documents, strategy decks, product plans, or verbal descriptions. Not for OKR setting — use product-okr-implementation. Not for team health or process issues — use product-team-health-diagnostic or product-process-dysfunction-diagnosis.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-vision-strategy-assessment
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
depends-on: []
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [24, 25, 26, 27]
tags: [product-management, product-strategy, product-vision]
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Product vision statement, strategy document, product plan, or a verbal description of your current vision and strategy"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Any agent environment. Works with pasted text or document files."
discovery:
  goal: "Produce a scored, principle-by-principle assessment of a product vision and strategy, with prioritized recommendations for strengthening both"
  tasks:
    - "Score the vision against all 10 vision principles"
    - "Score the strategy against all 5 strategy principles"
    - "Evaluate whether product principles exist and are functioning as design guardrails"
    - "Diagnose whether problems are vision problems, strategy problems, or both"
    - "Produce prioritized recommendations with specific rewrite guidance"
  audience:
    roles: ["product-manager", "head-of-product", "chief-product-officer", "founder", "product-director", "product-lead"]
    experience: "any — no prior framework knowledge required"
  triggers:
    - "User shares a product vision and wants to know if it's strong"
    - "User describes a strategy that seems unfocused or reactive"
    - "User reports teams keep pivoting or losing direction"
    - "User wants to create a vision or strategy from scratch"
    - "User is preparing a product review and wants to stress-test their direction"
    - "User's teams feel like mercenaries rather than missionaries"
  not_for:
    - "Detailed product roadmap planning — this skill evaluates direction, not delivery scheduling"
    - "OKR setting — use product-okr-implementation for objective-key-result implementation"
    - "Team health or process issues — use product-team-health-diagnostic or product-process-dysfunction-diagnosis"
---

# Product Vision and Strategy Assessment

## When to Use

You have a product vision, a strategy (or lack of one), and you need to know whether they are strong, coherent, and aligned — or where they are failing.

This skill covers four interconnected elements:
- **Product vision** — the inspiring future state you are trying to create (2–10 years out)
- **Product strategy** — the sequenced path of product/market bets that get you to that vision
- **Product principles** — the belief statements that resolve design and prioritization conflicts
- **Vision vs. strategy distinction** — diagnosing whether a problem is a direction problem, a focus problem, or both

Use this skill when: you are reviewing an existing vision/strategy for quality; creating a new one; diagnosing why teams are misaligned or reactive; or preparing to evangelize direction to stakeholders, investors, or new hires.

**Do not use this skill if:** You already have a strong vision and strategy and need to write OKRs — use `product-okr-implementation`. If you need to diagnose team dysfunction, use `product-team-health-diagnostic`.

---

## Context and Input Gathering

Before running the assessment, collect:

### Required
- **The vision statement:** What future are you trying to create? How far out? (If none exists, note this — the skill will still run in creation mode.)
- **The strategy:** What is your current plan for getting to that vision? Which markets or customer segments are you targeting, and in what order?
- **The business context:** What stage is the company? Who are the primary customers today?

### Important
- **Team alignment signals:** Do teams know where you are headed? Do they feel motivated by the mission or are they executing a backlog?
- **Recent pivots:** Have you changed vision or strategy in the last 12–18 months? How many times?
- **Competitor pressure:** Is your strategy reactive to competitors or proactively customer-driven?

### Optional (improves scoring precision)
- **Product principles:** Do you have any explicit statements about what you believe is important when building your product?
- **Go-to-market motion:** How do you sell and deliver the product? Is the strategy aligned with your sales and marketing channels?
- **A specific decision or debate:** Is there a current strategic choice you are trying to resolve? Name it — the principles assessment may resolve it directly.

If the required inputs are absent, ask for them before scoring. A vision assessment without the actual vision statement will produce generic, low-value output.

---

## Process

### Step 1: Establish the Vision vs. Strategy Distinction

**Action:** Before scoring, confirm which layer each problem lives in. Separate vision issues from strategy issues explicitly.

**WHY:** Vision and strategy are often confused, which causes the wrong intervention. Vision is inspiring leadership — it sets the 2–10 year direction that motivates missionaries. Strategy is focused management — it identifies which markets or products to pursue in sequence to reach that vision. Confusing them leads to either: (a) over-pivoting the vision when the real problem is an unfocused strategy, or (b) obsessing over execution details when the team fundamentally lacks inspiring direction. The difference, as Cagan states, is analogous to the difference between leadership and management: leadership inspires and sets direction; management helps get there.

**Output:** Write two sentences:
1. "The vision layer concern is: [identified or 'no vision exists']"
2. "The strategy layer concern is: [identified or 'no coherent strategy exists']"

---

### Step 2: Score the Vision Against the 10 Vision Principles

**Action:** Evaluate the vision statement (or its absence) against each of the 10 principles. Score each 1–5. Produce a one-sentence rationale for each score.

**WHY:** Running all 10 prevents selective evaluation. The principles are cumulative — a vision that scores well on ambition (principle 3) but fails on inspiration (principle 5) will still fail to attract missionaries. A vision that articulates the right problem (principle 2) but does not embrace trends (principle 6) will be outdated before it is realized. Scoring all 10 surfaces the specific weaknesses that need addressing rather than vague "the vision needs work" feedback.

**Score scale:**
- **5** — Principle fully satisfied; no meaningful gaps
- **4** — Principle largely satisfied with minor gaps
- **3** — Partial satisfaction; could be meaningfully strengthened
- **2** — Principle largely missing or weakly present
- **1** — Principle absent or actively violated

**Vision scoring template:**

```
1. Starts with why (purpose-led):         [1-5] — [rationale]
2. Problem-oriented (not solution-locked): [1-5] — [rationale]
3. Sufficiently ambitious (2-10 year scope): [1-5] — [rationale]
4. Willing to disrupt self:               [1-5] — [rationale]
5. Genuinely inspiring (missionary fuel): [1-5] — [rationale]
6. Embraces relevant trends:              [1-5] — [rationale]
7. Anticipates where the world is heading: [1-5] — [rationale]
8. Stubborn on direction, flexible on details: [1-5] — [rationale]
9. Accepted as a leap of faith (ambitious enough): [1-5] — [rationale]
10. Actively evangelized:                 [1-5] — [rationale]

Vision total: [X/50]
```

See `references/vision-principles-detail.md` for full activation criteria per principle, including the vision pivot vs. discovery pivot distinction, the missionary vs. mercenary diagnostic, and the over-optimism vs. over-conservatism failure modes for principle 7.

---

### Step 3: Identify the Top Vision Gaps

**Action:** From the scoring, identify the 2–3 lowest-scoring principles. For each, write a specific rewrite suggestion or structural fix.

**WHY:** A ranked gap list converts a score into an action. Without it, the user has numbers but no clear next move. The suggestion should be concrete enough that the user can apply it immediately — not just "make it more inspiring" but "reframe the vision around the customer problem you are solving, removing the product/feature language in sentences 1 and 3."

**Gap output format:**
```
Gap 1: [Principle name] (Score: X/5)
Problem: [What is wrong or missing]
Fix: [Specific rewrite guidance or structural change]

Gap 2: [Principle name] (Score: X/5)
Problem: [What is wrong or missing]
Fix: [Specific rewrite guidance or structural change]
```

---

### Step 4: Score the Strategy Against the 5 Strategy Principles

**Action:** Evaluate the strategy against each of the 5 principles. Score each 1–5. Produce a one-sentence rationale.

**WHY:** Strategy fails in characteristic ways. The most common is serving multiple customer segments simultaneously, which pleases no one well. The second most common is drifting from business strategy when the business model shifts (new monetization, new sales motion). The third is competitor-reactive behavior — abandoning the customer focus when a serious competitor appears. Scoring all 5 surfaces which failure mode is active rather than leaving the diagnosis vague.

**Strategy scoring template:**

```
1. Single target market focus per release:    [1-5] — [rationale]
2. Aligned with business strategy:            [1-5] — [rationale]
3. Aligned with go-to-market strategy:        [1-5] — [rationale]
4. Customer-obsessed (not competitor-driven): [1-5] — [rationale]
5. Communicated across the organization:      [1-5] — [rationale]

Strategy total: [X/25]
```

**Prioritization context:** When the strategy has not yet identified which markets to tackle first, the three factors to evaluate are: total addressable market size, go-to-market fit (can existing channels serve this market?), and time to market. These three factors, balanced together, should drive sequencing decisions.

---

### Step 5: Identify the Top Strategy Gaps

**Action:** From the strategy scoring, identify the 1–2 most critical gaps with specific interventions.

**WHY:** Strategy gaps are frequently more actionable than vision gaps — a team can decide to focus on one market segment this quarter even if the vision needs months to refine. Naming the specific intervention (e.g., "choose one of your three identified customer segments and defer the other two for at least 6 months") gives the team something to act on immediately.

**Gap output format:**
```
Strategy Gap 1: [Principle name] (Score: X/5)
Problem: [What is wrong or missing]
Intervention: [Specific action or decision required]

Strategy Gap 2: [Principle name] (Score: X/5) — if applicable
Problem: [What is wrong or missing]
Intervention: [Specific action or decision required]
```

---

### Step 6: Assess Product Principles

**Action:** Determine whether the team has explicit product principles. If yes, evaluate whether they are (a) tied to real beliefs rather than aspirational platitudes, and (b) actually resolving design and prioritization debates. If no, recommend creating them.

**WHY:** Product principles are the least-known of the three layers but often the most immediately useful. Where vision describes where you are going and strategy describes how to get there, principles describe the nature of what you are building — specifically, how to resolve conflicts when two valid priorities compete. The eBay example is instructive: sellers generate most of eBay's revenue, yet eBay's principle stated "in cases where buyers and sellers conflict, prioritize the buyer — because that's what makes sellers successful." Without that principle, every design debate about buyer vs. seller experience would require escalation or arbitrary resolution. With it, hundreds of product decisions make themselves. A team without principles is navigating without a decision framework.

**Principles assessment output:**
```
Do explicit product principles exist? [Yes / No / Partially]

If yes:
- Are they belief statements (not feature lists)? [Yes / No]
- Are they specific enough to resolve real conflicts? [Yes / No]
- Have they actually resolved recent design debates? [Yes / No / Unknown]
- Rating: [Strong / Adequate / Weak / Missing]

If no or weak:
- Conflict symptom: [What design or prioritization debate keeps recurring?]
- Principle recommendation: [A draft principle that would resolve it]
  Example format: "In cases where [X] and [Y] conflict, we prioritize [X],
  because [reason that connects to vision]."
```

---

### Step 7: Produce the Overall Assessment

**Action:** Write a structured summary covering: overall diagnosis, top 3 prioritized recommendations, and a corrected or improved vision statement (if the scoring surfaces significant gaps).

**WHY:** The summary synthesizes the scoring into a prioritized action list. The overall diagnosis names whether the core problem is a vision problem, a strategy problem, a principles problem, or some combination. The prioritization ensures the team tackles the highest-leverage fix first rather than spreading effort across all gaps simultaneously.

**Assessment output format:**

```
## Product Vision and Strategy Assessment

### Overall Scores
Vision: [X/50] — [one-line diagnosis]
Strategy: [X/25] — [one-line diagnosis]
Principles: [Strong / Adequate / Weak / Missing]

### Primary Diagnosis
[2–3 sentences: What is the core problem? Is it a vision problem,
a strategy problem, a principles problem, or all three? What is
the highest-leverage fix?]

### Top Recommendations (prioritized)

1. [Highest-leverage fix — most likely a vision or focus issue]
   Action: [Specific, concrete]
   Why first: [Why this has the highest impact]

2. [Second recommendation]
   Action: [Specific, concrete]

3. [Third recommendation]
   Action: [Specific, concrete]

### Vision Rewrite (if vision scored below 30/50)
Current: "[original vision statement]"
Issues: [2–3 specific problems]
Suggested rewrite: "[revised vision statement]"
Note: This is a starting point — refine with your team.

### Strategy Adjustment (if strategy scored below 15/25)
[Specific recommendation for market focus or sequencing]

### Product Principles (if missing or weak)
[Draft 1–2 principles based on recurring conflicts identified]
```

---

## Inputs and Outputs

### Inputs
- Vision statement or description (required — or note that none exists)
- Strategy description or plan (required — or note that none exists)
- Business context: stage, customer type, markets served (required)
- Team alignment signals (important)
- Product principles, if any (optional)
- A specific strategic decision to resolve (optional)

### Outputs
- Vision scored against 10 principles (X/50 with rationale per principle)
- Strategy scored against 5 principles (X/25 with rationale per principle)
- Product principles assessment with draft principles if missing
- Top 2–3 vision gaps with specific rewrite guidance
- Top 1–2 strategy gaps with specific interventions
- Prioritized recommendation list
- Vision rewrite suggestion (if vision scored below 30/50)
- Overall diagnosis statement

---

## Key Principles

**Vision inspires; strategy focuses.** These are distinct jobs. A vision that doubles as a strategy (e.g., "win the SMB accounting market in 3 years") is neither inspiring nor focused — it is an objective. A strategy that is also a vision ("we will build the best product for everyone") is neither inspiring nor actionable. Hold the distinction firmly when diagnosing.

**The leap-of-faith test.** If a vision can be fully validated before committing to it, the vision is not ambitious enough. Vision requires several years to discover whether the solutions exist. If you already know how to deliver it, it is a roadmap, not a vision.

**Vision pivot vs. discovery pivot.** Changing the vision itself (vision pivot) is usually a sign of a weak product organization — the equivalent of a company losing its mission. Changing the approach to reach a stable vision (discovery pivot) is healthy product work. Teams should be stubborn about the destination and flexible about the route.

**Single target market is the most important strategy decision.** There is no single ideal approach to market sequencing, but the decision that matters most is simply committing to one target market at a time. Once that commitment exists, the whole organization — sales, marketing, engineering — can align behind it.

**Customers leave because you stop taking care of them.** When a serious competitor appears, the temptation is to match their features. This is always the wrong move. Customers rarely leave for a competitor's product; they leave because the current product stopped serving them well. Strategy should remain customer-obsessed through competitive pressure, not competitor-obsessed.

**Product principles are a conflict resolution tool, not a values document.** A principle like "we are committed to quality" is a platitude — it resolves nothing. A principle like "when speed of delivery and quality of experience conflict, we choose quality" resolves hundreds of decisions. The test of a good principle: does it tell a team how to decide when two good things are in tension?

---

## Examples

### Example: "Leading Platform for Small Business Accounting" Assessment

**Input provided:** "Our product vision is: 'Be the leading platform for small business accounting.' Our strategy is to add features that our top 10 enterprise customers request. We serve both freelancers and mid-market companies."

**Step 1 — Vision vs. Strategy distinction:**
- Vision layer concern: Vision is solution-locked ("platform for accounting") and market-locked ("small business"), not problem-oriented. It does not articulate why this matters or what future it creates for customers.
- Strategy layer concern: Strategy is driven by enterprise customer requests rather than a target segment, and serves two distinct customer types (freelancers and mid-market) simultaneously without sequencing.

**Step 2 — Vision scoring (selected):**
```
1. Starts with why: 1 — No purpose expressed; "leading platform" is a market position, not a why
2. Problem-oriented: 2 — Mentions accounting (a domain) not the underlying problem customers face
3. Sufficiently ambitious: 2 — "Leading platform" is achievable in 1–2 years; not 5-10 year scope
5. Genuinely inspiring: 1 — No missionary fuel; describes a market position, not a cause
9. Leap of faith: 1 — "Leading platform" is an execution target, not a leap

Vision total: 18/50 — significantly weak
```

**Step 4 — Strategy scoring (selected):**
```
1. Single target market focus: 1 — Serves freelancers AND mid-market simultaneously; no sequencing
2. Aligned with business strategy: 3 — Enterprise feature requests may align but is unclear
4. Customer-obsessed: 2 — Top 10 enterprise customers drive requests; rest of market underserved

Strategy total: 11/25 — focus and customer-obsession are the critical failures
```

**Step 7 — Output:**
```
## Product Vision and Strategy Assessment

### Overall Scores
Vision: 18/50 — solution-locked, uninspiring market position statement
Strategy: 11/25 — no market focus, reactive to loudest customers

### Primary Diagnosis
The vision describes a market position rather than a future worth creating.
It gives product teams no reason to be missionaries. The strategy compounds
this by serving two incompatible segments simultaneously and being driven by
top enterprise customer requests rather than target-market needs. The team
is operating without either inspiring direction or focused strategy.

### Top Recommendations

1. Rewrite the vision around the customer problem
   Action: Identify the specific pain that small business owners face
   (cash flow anxiety? time lost on manual reconciliation? tax season dread?)
   and write a vision that describes a world where that problem is solved.
   Why first: Everything else — strategy, principles, team motivation —
   flows from a vision grounded in the customer problem.

2. Choose one customer segment and defer the other
   Action: Decide whether to pursue freelancers or mid-market companies
   first. Build the smallest product that makes that segment successful.
   Ideas for the deferred segment are saved for future consideration.
   Why second: No strategy can produce a beloved product while serving
   two incompatible customer profiles simultaneously.

3. Replace enterprise-request-driven strategy with target-segment needs
   Action: Identify the job-to-be-done for the chosen primary segment
   (not the top 10 enterprise accounts) and build strategy around it.

### Vision Rewrite (vision scored 18/50 — below threshold)
Current: "Be the leading platform for small business accounting."
Issues: Solution-locked, market-position framing, no why, not inspiring
Suggested rewrite: "Make financial confidence accessible to every
independent professional — so running a business feels less like
surviving tax season and more like understanding your own success."
Note: This is a starting point — validate the specific pain with customers
and refine with your leadership team.

### Product Principles (if missing)
Conflict symptom: Enterprise customers vs. freelancer needs will
constantly compete for product attention.
Draft principle: "When enterprise feature requests and freelancer
workflow needs conflict, we prioritize the freelancer experience —
because delighting freelancers at scale is what builds the network
that makes enterprise customers successful."
```

---

## References

| File | Contents |
|------|----------|
| `references/vision-principles-detail.md` | Full activation criteria for all 10 vision principles; vision pivot vs. discovery pivot definition; missionary vs. mercenary diagnostic; common failure modes per principle; example visions scored against each principle |
| `references/strategy-principles-detail.md` | Full activation criteria for all 5 strategy principles; market prioritization framework (total addressable market, go-to-market fit, time to market); competitor-reactive vs. customer-obsessed strategy patterns; product/market fit sequencing approaches |
| `references/product-principles-guide.md` | What product principles are and are not; eBay buyer/seller case study; how to draft principles that resolve real conflicts; principles as public vs. internal tools; how principles complement vision and strategy |

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

---
name: product-team-health-diagnostic
description: |
  Diagnose why a product team or organization is slow, not innovative, or delivering poor outcomes. Use when a leader or team observes slow velocity, lack of innovation, poor product quality, feature factory behavior, or team dysfunction — and needs root causes and a prioritized fix list. Also use when a new product leader is assessing an organization, when a CEO or board says teams are too slow, or when someone says 'why are we not shipping faster?', 'engineering and design aren't collaborating', 'we ship but nothing moves the needle', or 'I need to assess team health before proposing changes.' Scores 42 diagnostic criteria across team behaviors, innovation capacity, velocity killers, and design integration. Produces a severity-ranked report with a composite health score and remediation priorities. For culture-level issues (innovation vs. execution quadrant), use product-culture-assessment. For process-level waterfall diagnosis, use product-process-dysfunction-diagnosis.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-team-health-diagnostic
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
model: sonnet
context: 200k
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Observations, notes, or description of the team/organization being assessed"
    - type: none
      description: "Skill can work from a verbal description of what the assessor observes"
  tools-required: [Read]
  tools-optional: []
  environment: "No codebase access required; works from observations and descriptions"
source-books:
  - name: inspired-how-to-create-tech-products
    chapters: [11, 64, 65, 66]
depends-on: []
tags: [product-management, team-assessment, product-teams]
---

# Product Team Health Diagnostic

## When to Use

Use this skill when you are:
- **New to a leadership role** — need a structured baseline assessment of product team health before making changes
- **Responding to CEO/board concerns** — told teams are "too slow" or "not innovative" and need to diagnose root causes
- **Running an org health review** — periodic check on whether teams are operating in a strong or weak product model
- **Preparing a remediation plan** — need to prioritize which problems to fix first and justify the investment
- **Onboarding a coach or consultant** — need a common diagnostic language to align on what's broken

Preconditions: you have at least one of:
- Direct observations of team behaviors over at least a few weeks
- A written description of how teams operate (processes, rituals, structure)
- Interview notes or survey data from team members
- Access to team artifacts (roadmaps, sprint boards, release logs, design files)

**Agent:** Clarify the scope before beginning — are you assessing one team, a portfolio of teams, or the entire engineering/product organization? The scoring applies per team; an org-level report aggregates across teams.

---

## Assessment Process

### Step 1 — Gather Observations

Collect evidence for each of the 4 diagnostic categories. WHY: each category targets a distinct failure mode — behavioral dysfunction (Ch64), structural innovation blockers (Ch65), process velocity killers (Ch66), and design integration failures (Ch11). Mixing them obscures root cause.

For each category, ask the assessor (or yourself) the following:

**Category A — Team Behaviors (18 criteria)**
Source: Ch64. These contrast what strong teams do vs. what weak teams do. Ask:
- What drives the team's ideas — vision and customer insight, or stakeholder requests and sales?
- How does the team relate to engineers — do they co-discover, or do engineers only see designs at sprint planning?
- Does the team engage real customers weekly, or do they rely on internal assumptions?
- How does the team measure success — business impact achieved, or features shipped?
- See full criteria: `references/diagnostic-criteria.md#category-a`

**Category B — Innovation Capacity (10 criteria)**
Source: Ch65. These are organizational attributes that determine whether consistent innovation is even possible. Ask:
- Is there direct, frequent customer contact at the team level?
- Does the organization have a compelling, current product vision?
- Are product managers strong and capable, or weak and order-takers?
- Are engineers included from the beginning of ideation?
- See full criteria: `references/diagnostic-criteria.md#category-b`

**Category C — Velocity Killers (10 criteria)**
Source: Ch66. These are the structural and process causes of slowness. Ask:
- What is the current release cadence? (Benchmark: minimum every 2 weeks; great teams release multiple times per day)
- Is there significant accumulated technical debt impeding the architecture?
- Is there a delivery manager role actively removing impediments?
- Are priorities stable, or do they shift frequently?
- See full criteria: `references/diagnostic-criteria.md#category-c`

**Category D — Design Integration (4 criteria)**
Source: Ch11. These identify whether design is integrated as a discovery partner or treated as a service. Ask:
- Who produces wireframes or interaction designs — a trained product designer, or the PM?
- Are designers embedded with the product team, or do they operate as an internal agency?
- Is design involved from the inception of each idea, or does it come in after requirements?
- See full criteria: `references/diagnostic-criteria.md#category-d`

---

### Step 2 — Score Each Criterion

WHY: Scoring converts qualitative observations into a comparable signal, making it possible to prioritize and track improvement over time.

For each of the 42 criteria, assign one of three scores:

| Score | Meaning |
|-------|---------|
| **2** | Healthy — the team clearly exhibits the strong behavior |
| **1** | Partial — the behavior is inconsistent or only sometimes present |
| **0** | Absent — the weak behavior is the norm |

**Scoring rules:**
- Score what you observe, not what the team says they do. WHY: teams frequently describe aspirational practices.
- When evidence is ambiguous, default to 1 (partial), not 2. WHY: over-scoring masks real problems.
- For Category C, Item 4 (release cadence): score 2 if releases happen at least every 2 weeks, 0 if monthly or less, 1 if inconsistent.

---

### Step 3 — Calculate Category and Composite Scores

For each category, calculate:

```
Category score = (sum of item scores) / (max possible score) × 100
```

| Category | Items | Max Score |
|----------|-------|-----------|
| A — Team Behaviors | 18 | 36 |
| B — Innovation Capacity | 10 | 20 |
| C — Velocity Killers | 10 | 20 |
| D — Design Integration | 4 | 8 |
| **Composite** | **42** | **84** |

WHY: Keeping categories separate prevents a strong score in one area from masking a critical failure in another. A team can be fast (good C score) but consistently build the wrong things (low A score).

---

### Step 4 — Classify Severity

WHY: Not all scores below 100% require equal urgency. This classification focuses remediation effort.

**Per-category thresholds:**

| Score | Severity | Interpretation |
|-------|----------|----------------|
| 80–100% | Healthy | Maintain; minor tuning only |
| 60–79% | Caution | Targeted improvements needed |
| 40–59% | Degraded | Structural issues present; prioritize fixes |
| 0–39% | Critical | Fundamental dysfunction; urgent intervention required |

**Red flags — any single criterion scoring 0 in these areas triggers automatic Critical classification for that dimension, regardless of category average:**
- Team behaviors: engineers excluded from discovery (criterion A9)
- Innovation: no customer-centric culture (criterion B1), no compelling vision (criterion B2)
- Velocity: infrequent releases — monthly or less (criterion C4)
- Design: design not involved in discovery (criterion D4)

WHY: These specific items represent systemic dysfunctions that a higher average cannot compensate for.

---

### Step 5 — Produce the Diagnostic Report

Structure the output as follows:

```
## Product Team Health Diagnostic Report

**Organization/Team:** [name]
**Assessment Date:** [date]
**Assessor:** [role]

---

### Composite Score: [X/84] — [XX%] — [SEVERITY]

| Category | Score | % | Severity |
|----------|-------|---|----------|
| A — Team Behaviors | X/36 | XX% | [label] |
| B — Innovation Capacity | X/20 | XX% | [label] |
| C — Velocity Killers | X/20 | XX% | [label] |
| D — Design Integration | X/8 | XX% | [label] |

---

### Red Flags (Criteria scoring 0 that require immediate attention)
[List each, with one sentence describing the observed symptom]

---

### Category Findings

#### A — Team Behaviors
**Strengths:** [criteria scoring 2]
**Gaps:** [criteria scoring 0 or 1, with observed evidence]

#### B — Innovation Capacity
[same format]

#### C — Velocity Killers
[same format]
Note: Release cadence benchmark — minimum every 2 weeks; great teams release multiple times per day.

#### D — Design Integration
[same format]

---

### Prioritized Remediation Plan

Ordered by: (1) Critical severity first, (2) within severity by cross-category impact

| Priority | Issue | Category | Current State | Target State | Estimated Effort |
|----------|-------|----------|---------------|--------------|-----------------|
| 1 | ... | ... | ... | ... | ... |

---

### Summary Narrative
[3–5 sentences: what is working, what is broken, and the single most important thing to fix first and why]
```

---

### Step 6 — Validate the Assessment

Before delivering the report, verify:
- [ ] Every scored criterion has supporting evidence, not assumption
- [ ] Red flags are confirmed, not inferred
- [ ] The prioritized remediation plan addresses root causes, not symptoms
- [ ] The summary narrative is actionable — it tells the reader what to do, not just what is wrong

WHY: Diagnostic reports are only useful if they drive decisions. Vague findings ("culture needs improvement") create no action. Specific findings ("engineers first see features at sprint planning — exclude from discovery") point to a concrete fix.

---

## Interpreting Results

**Common misread — high velocity, low innovation:** A team can score well on Category C (velocity) while scoring poorly on Category B (innovation). This is the "feature factory" pattern — teams ship fast but build the wrong things. The fix is upstream (discovery and vision), not downstream (process acceleration).

**Common misread — blaming individuals:** Low PM capability scores (B4, C2) often reflect structural issues — PMs who are order-takers because leadership treats them as such. Diagnose whether the PM is weak, or whether the PM has been structurally prevented from being strong.

**Common misread — design as optional:** Category D scores are frequently rationalized ("we're a B2B company, design matters less"). The book is explicit: strong design is a competitive differentiator in B2B, and companies that treat it as optional are being displaced.

**The innovation/velocity relationship:** Chapters 65 and 66 share several root causes (weak PMs, engineers excluded, no vision). Fixes to these shared causes yield compound improvements across both dimensions.

---

## Reference

Full 42-criterion reference table with good/bad behavior descriptions:
`references/diagnostic-criteria.md`

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Inspired How To Create Tech Products by Unknown.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/diagnostic-criteria.md
# Diagnostic Criteria — Full Reference

All 42 criteria across 4 categories. Each criterion has a "healthy" state (score 2) and a "dysfunction" state (score 0).

Source: INSPIRED: How to Create Tech Products Customers Love — Marty Cagan, Chapters 11, 64, 65, 66.

---

## Category A — Team Behaviors {#category-a}

Source: Chapter 64 — Good Product Team / Bad Product Team

18 contrasting behaviors. Score 2 (healthy), 1 (partial), or 0 (dysfunction).

| # | Dimension | Healthy (score 2) | Dysfunction (score 0) |
|---|-----------|-------------------|-----------------------|
| A1 | Mission orientation | Teams have a compelling product vision pursued with missionary-like passion | Teams are mercenaries — execute tasks without genuine commitment to outcomes |
| A2 | Idea sourcing | Ideas come from vision, objectives, customer observation, usage data, and new technology | Ideas come from requirements gathered from sales and customers |
| A3 | Stakeholder relationship | Team understands stakeholder constraints and invents solutions that work for users, customers, and the business | Team gathers requirements from stakeholders and treats them as specifications |
| A4 | Idea validation method | Team uses rapid prototyping and experimentation techniques to determine which ideas are worth building | Team holds meetings to generate and prioritize roadmaps |
| A5 | Intellectual openness | Team loves brainstorming with smart thought leaders from across the company | Team is offended when someone outside their group suggests they do something |
| A6 | Collaboration structure | Product, design, and engineering sit side by side and embrace the interplay between functionality, user experience, and technology | Disciplines sit in silos and make requests through documents and scheduled meetings |
| A7 | Testing permission | Team innovates continuously in ways that protect revenue and brand | Team waits for permission before running any test |
| A8 | Design awareness | Team insists on strong product design as a necessary capability for winning products | Team doesn't understand what product designers do or why they matter |
| A9 | Engineer involvement in discovery | Engineers have time to try out prototypes in discovery daily so they can contribute to making the product better | Engineers first see prototypes at sprint planning so they can estimate |
| A10 | Customer engagement | Team engages directly with end users and customers every week to understand them and observe their response to new ideas | Team thinks they are the customer; relies on internal assumptions |
| A11 | Iteration expectation | Team knows favorite ideas often won't work and will need several iterations to produce the desired outcome | Team builds what's on the roadmap, satisfied with meeting dates and ensuring quality |
| A12 | Speed source | Team understands speed comes from the right techniques, not forced labor; rapid iteration is the key to innovation | Team complains it is slow because colleagues aren't working hard enough |
| A13 | Commitment integrity | Team makes high-integrity commitments after evaluating requests and verifying viable solutions that work for customer and business | Team complains about being a sales-driven company; accepts any commitment |
| A14 | Analytics instrumentation | Team instruments their work to immediately understand product usage and adjusts based on data | Team treats analytics and reporting as a nice-to-have |
| A15 | Release cadence | Team integrates and releases continuously; constant stream of smaller releases provides a stable solution | Team tests manually at the end of a painful integration phase, then releases everything at once |
| A16 | Reference customers | Team obsesses over their reference customers | Team obsesses over competitors |
| A17 | Success definition | Team celebrates when they achieve significant impact on business results | Team celebrates when they finally release something |
| A18 | Cross-functional idea sharing | Team actively seeks perspectives from outside the immediate team to strengthen their thinking | Team is closed off, treating outside input as interference |

---

## Category B — Innovation Capacity {#category-b}

Source: Chapter 65 — Top Reasons for Loss of Innovation

10 organizational attributes required for consistent innovation. Score 2 (present), 1 (partial), or 0 (absent).

| # | Attribute | Healthy (score 2) | Dysfunction (score 0) |
|---|-----------|-------------------|-----------------------|
| B1 | Customer-centric culture | Direct and frequent customer contact at team level; team is driven to delight customers | No focus on customers; teams rarely interact with actual users; internal assumptions dominate |
| B2 | Compelling product vision | A clear, current, inspiring vision exists and is understood by all teams; leadership steps up when original vision is realized | Original vision is largely realized; team is struggling to understand what's next; no one has filled the void |
| B3 | Focused product strategy | Strategy spells out a logical, intentional sequence of target markets; teams know what to focus on | Strategy tries to please everyone at once; teams are pulled in too many directions |
| B4 | Strong product managers | Each team has a strong, capable PM who inspires the team and drives clear product thinking | PM role is weak or absent; order-takers rather than product leaders; team operates as mercenaries |
| B5 | Stable product teams | Teams are durable and have had time to learn the space, technology, and customer pain | Team membership is constantly shifting; no institutional knowledge builds up |
| B6 | Engineers in discovery | Engineers are included from the very beginning of ideation and exposed directly to customer pain | Engineers are brought in only at the end, after solutions have been fully specified |
| B7 | Corporate courage | Leadership is willing to risk disruption to current business in the pursuit of innovation | Organization is extremely risk-averse; teams avoid anything that might disrupt existing revenue |
| B8 | Empowered product teams | Teams are given business problems to solve and trusted to determine the best solution | Teams are handed roadmaps of features; empowerment has been revoked as the company scaled |
| B9 | Product mindset | Teams exist to serve the company's customers in ways that meet the needs of the business | IT mindset — teams exist to serve the needs of the internal business; customers are secondary |
| B10 | Time to innovate | Teams have capacity beyond "keep the lights on" activities to pursue harder, more impactful problems | Teams are entirely consumed by bugs, technical debt, and operational requests; no innovation capacity remains |

---

## Category C — Velocity Killers {#category-c}

Source: Chapter 66 — Top Reasons for Loss of Velocity

10 structural and process causes of slowness. Score 2 (not a problem), 1 (partial), or 0 (active problem).

**Release cadence benchmark:** Teams should release no less frequently than every 2 weeks. Great teams release multiple times per day.

| # | Killer | Healthy (score 2) | Dysfunction (score 0) |
|---|--------|-------------------|-----------------------|
| C1 | Technical debt | Architecture facilitates rapid product evolution; debt is actively managed | Architecture does not enable rapid evolution; significant accumulated debt blocks progress |
| C2 | Product manager strength | PM is strong, capable, and inspires the team as missionaries | PM is weak; team operates as mercenaries; no inspiration or evangelism |
| C3 | Delivery management | Delivery manager role exists and actively removes impediments before they compound | No delivery management; impediments accumulate and compound non-linearly |
| C4 | Release cadence | Releases happen at minimum every 2 weeks; great teams release multiple times per day | Releases happen monthly or less; no test or release automation; big-bang releases |
| C5 | Product vision and strategy | Team has a clear vision and understands how immediate work contributes to the big picture | No vision or strategy; team lacks context for why their work matters |
| C6 | Co-located, durable teams | Teams are co-located (or effectively distributed with strong tooling); engineers are not outsourced | Teams are split across locations or engineers are outsourced; communication is costly and slow |
| C7 | Engineer early involvement | Engineers participate in product discovery from the start of ideation, contributing faster implementation alternatives | Engineers are not included until solutions are fully designed; critical input comes too late |
| C8 | Design in discovery | Product design is utilized in discovery; design work is done before engineering begins | Design runs in parallel with or after engineering; design debt and poor outcomes result |
| C9 | Priority stability | Priorities are stable enough that teams can build momentum and complete meaningful work | Priorities shift rapidly; significant churn; throughput and morale suffer |
| C10 | Decision culture | Decisions are made with appropriate authority and clear accountability | Consensus culture; all decisions require group agreement; everything slows to a crawl |

---

## Category D — Design Integration {#category-d}

Source: Chapter 11 — The Product Designer

4 failure modes describing how design is commonly mis-integrated. Score 2 (failure mode absent), 0 (failure mode present).

| # | Failure Mode | Healthy (score 2) | Dysfunction (score 0) |
|---|-------------|-------------------|-----------------------|
| D1 | PM designs without training | A trained product designer owns interaction and visual design on the team | PM produces wireframes despite lacking design training; engineers cobble together visual design from them |
| D2 | PM provides only user stories | A dedicated product designer translates product thinking into interaction and visual design | PM provides only high-level user stories; engineers must work out the design themselves |
| D3 | PM does interaction + separate visual designer | A single product designer handles both interaction and visual design holistically | PM produces interaction design (wireframes); a separate visual/graphic designer provides visual layer; no holistic design ownership |
| D4 | Design as internal agency | Designer is embedded with the product team as a full partner in discovery and delivery | Design operates as an internal agency — the team submits requests, waits for design output; designers are not partners in discovery |

---

## Scoring Summary Template

```
Category A — Team Behaviors:       ___/36 = ___%
Category B — Innovation Capacity:  ___/20 = ___%
Category C — Velocity Killers:     ___/20 = ___%
Category D — Design Integration:   ___/8  = ___%

Composite Score:                   ___/84 = ___%
```

**Severity thresholds:** 80–100% Healthy | 60–79% Caution | 40–59% Degraded | 0–39% Critical

**Automatic Critical red flags (score 0 on any of):** A9, B1, B2, C4, D4

---
name: product-process-dysfunction-diagnosis
description: |
  Diagnose why product efforts fail despite using Scrum, Agile, or roadmaps. Use when a team ships on time but customers don't adopt features, when leadership asks why there's no innovation despite an Agile process, when a new product leader needs to identify root causes quickly, or when someone asks 'are we doing waterfall disguised as Agile?' Also use when someone says 'we follow the process but nothing lands', 'sales keeps driving our roadmap', 'design is always scrambling to catch up', 'our engineers just build what they're told', or 'customers never adopt what we build.' Scores 10 root causes of product failure across startup, growth, and enterprise stages and produces a prioritized dysfunction report. For culture-wide assessment (innovation vs. execution), use product-culture-assessment. For team-level behaviors and velocity, use product-team-health-diagnostic.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-process-dysfunction-diagnosis
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
model: sonnet
context: 200k
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Description of how the team works: how ideas are sourced, how the roadmap is built, PM role, how design and engineering participate, release cadence, and how customer feedback is gathered"
    - type: none
      description: "Skill can work from a verbal description of team processes"
  tools-required: [Read]
  tools-optional: []
  environment: "No codebase access required; works from process descriptions and observations"
source-books:
  - name: inspired-how-to-create-tech-products
    chapters: [3, 4, 5, 6, 7]
depends-on: []
tags: [product-management, process-assessment, agile]
---

# Product Process Dysfunction Diagnostic

## When to Use

Use this skill when you are:
- **Seeing the "shipping but not landing" pattern** — features are delivered on schedule, but customers rarely adopt them or they don't move business metrics
- **Investigating a waterfall-disguised-as-agile process** — the team uses Scrum or Kanban but the upstream process (idea sourcing, roadmaps, business cases) is still waterfall
- **New to a product leadership role** — need to quickly locate which root causes are active before proposing changes
- **Evaluating a team's process** — whether as a coach, consultant, or peer reviewer assessing where dysfunction originates
- **Preparing a process transformation argument** — need to demonstrate to leadership exactly what is broken and why, with specific evidence

Preconditions: you have at least one of:
- A description of how ideas originate and reach the roadmap
- A description of the PM role and how they spend their time
- A description of when design and engineering enter the process
- Information on how and when customers are consulted
- Access to a roadmap, sprint board, or planning artifacts

**Agent:** Before scoring, clarify the company stage — approximately how many engineers are there, and has the company found product/market fit? Stage determines which failure patterns are most likely and which remediations are appropriate.

---

## Diagnostic Framework

The 10 root causes below come directly from Cagan's analysis of the waterfall model (Figure 6.1) practiced by the majority of companies: Ideas → Business Case → Roadmap → Requirements → Design → Build → Test → Deploy. Each root cause is a structural problem in this pipeline, any one of which can derail product efforts.

The two inconvenient truths that make the pipeline especially dangerous:
- **Truth 1 — 50% failure rate:** At least half of all product ideas will not work as expected. The best teams assume at least 75% won't perform like they hope.
- **Truth 2 — Iteration requirement:** Even ideas that do have potential typically require several iterations before they deliver necessary business value ("time to money").

These truths mean the pipeline is not merely inefficient — it is structurally set up to waste the majority of engineering effort.

---

## Step 1 — Identify Company Stage

WHY: The three stages have distinct failure patterns. Applying enterprise remediation to a startup wastes time; applying startup advice to an enterprise ignores real structural constraints.

Classify the company into one of three stages based on engineer count and product/market fit status:

| Stage | Profile | Primary Failure Risk |
|-------|---------|---------------------|
| **Startup** | Fewer than ~25 engineers; pre-product/market fit | Burning runway on wrong product; not doing discovery at all |
| **Growth** | 25 to several hundred engineers; scaling a proven product | Teams don't see the big picture; technical debt accumulates; leadership mechanisms stop scaling |
| **Enterprise** | Hundreds of engineers; established product and brand | Stakeholders protect existing business; innovation atrophies; design by committee; lack of empowerment |

**Stage-specific signals:**

*Startup:*
- The PM role is held by a co-founder with no dedicated product function
- Every pivot is a near-death experience
- "We'll figure it out after we ship" is the standard answer to discovery questions

*Growth:*
- Teams complain they don't understand the big picture or how their work connects to company goals
- Sales and marketing say the go-to-market strategies that worked for the first product don't apply to new ones
- Every engineer mentions "technical debt" unprompted
- Leadership style that worked at 20 people has stopped scaling

*Enterprise:*
- Stakeholders across the business are working hard to protect what the company has already built
- New initiatives get shut down or face so many obstacles that people stop proposing them
- Product teams complain about lack of vision, lack of empowerment, and that getting a decision takes forever
- Leadership resorts to acquisitions or creating separate "innovation centers" when they want new products
- "Design by committee" is how major product decisions are made

---

## Step 2 — Score the 10 Root Causes

For each root cause, score based on the evidence available. WHY: The 10 causes are not equally easy to spot — some are visible in artifacts (roadmaps, sprint boards), others require observing team behavior. Scoring each separately prevents a single visible problem from obscuring others.

**Scoring rubric:**

| Score | Meaning |
|-------|---------|
| **2** | Active dysfunction — the root cause is clearly present and driving poor outcomes |
| **1** | Partial — the root cause is present but partially mitigated |
| **0** | Absent — the team has addressed or does not exhibit this dysfunction |

---

### Root Cause 1 — Sales-Driven and Stakeholder-Driven Idea Sourcing

**Description:** Ideas for new product features originate primarily from sales ("we need this to close a deal"), executives, or internal stakeholders rather than from customer insight, data analysis, or the product team's own discovery work.

**Detection signals:**
- The roadmap looks like a list of feature requests from different parts of the business
- The PM's primary job is to "gather requirements" from stakeholders and translate them into user stories
- Sales specials and one-off customer commitments appear on the engineering backlog
- The quarterly planning meeting is where stakeholders negotiate to get their items prioritized
- Engineers feel like a feature factory — they build what they're told without understanding why

**Why it matters:** This is not the source of best product ideas. It also destroys team empowerment — the team is there to implement, not to solve problems. The team becomes mercenaries rather than missionaries.

**Stage context:**
- *Startup:* Usually surfaces as co-founder or early customer requests driving all decisions without discovery
- *Growth:* Key account management begins dictating product direction; enterprise sales becomes a de facto PM
- *Enterprise:* Full stakeholder negotiation model; roadmap is a political document

---

### Root Cause 2 — Unknowable Business Cases

**Description:** Prioritization is gated on a business case that requires knowing two things that cannot actually be known before building: how much revenue/value the idea will generate, and how much it will cost to build.

**Detection signals:**
- Product ideas require a formal or informal "business case" before getting on the roadmap
- PMs are asked how much revenue a feature will make before any customer validation
- Engineering is asked for estimates before the solution is even defined ("small, medium, large, or extra large")
- Ideas are prioritized by projected ROI that was effectively invented to justify a decision already made
- The business case exercise adds weeks to getting started without actually reducing risk

**Why it matters:** We cannot know either input to the business case at this stage. Revenue depends entirely on how good the solution turns out to be — some ideas generate nothing at all (this is confirmed by A/B testing data). Cost depends on the actual solution, which hasn't been designed. The business case process creates false certainty while adding overhead without reducing the risk of building the wrong thing.

---

### Root Cause 3 — Roadmap as Commitment

**Description:** The product roadmap is treated as a commitment to stakeholders about what will be built and when, rather than as a prioritized hypothesis about how to create value.

**Detection signals:**
- Roadmap items are communicated to sales with specific dates and are used in customer conversations
- Engineers are evaluated on "did we ship what was on the roadmap" rather than "did we achieve the intended outcome"
- Roadmap changes require executive sign-off or cause political conflict
- The PM's primary stress is keeping the roadmap commitments, not solving the underlying customer problem
- Items stay on the roadmap even after evidence emerges that they won't work

**Why it matters:** Most roadmap items are features and projects, not outcomes. The roadmap model predictably leads to teams shipping things that don't meet objectives — orphaned projects that were completed but didn't move the needle. Projects are output; product is about outcome.

---

### Root Cause 4 — Product Manager as Project Manager

**Description:** The PM role is primarily about gathering requirements, writing user stories, and tracking delivery — project coordination — rather than discovering what customers need and finding the best solution.

**Detection signals:**
- PMs spend most of their time in stakeholder meetings, backlog grooming, and sprint ceremonies
- PMs describe their job as "translating business needs into requirements for engineering"
- There is no time in the PM's week for customer interaction, data analysis, or prototype testing
- PMs are evaluated on delivery metrics (story points, on-time releases) rather than business outcome metrics
- The PM is the last person to hear about a customer problem — it comes via sales or support

**Why it matters:** This is 180 degrees from the reality of modern product management. Gathering requirements and documenting them for engineers is project management. Product management is discovering what customers need, finding a solution that works for the business, and working collaboratively with design and engineering to bring it to life.

---

### Root Cause 5 — Design Brought In Too Late (Lipstick on the Pig)

**Description:** UX and product design are engaged after requirements are defined, treating design as execution rather than as a discovery and problem-solving function.

**Detection signals:**
- Design receives a set of requirements or a PRD and is asked to "design the solution"
- Designers are brought into the process after the PM has already defined what is being built
- There is no design involvement in customer discovery or prototype testing
- Designers describe their role as "making it look nice" or "improving usability" of already-decided features
- Design is treated as a service team or internal agency rather than an embedded product team member

**Why it matters:** When design enters after requirements are set, the fundamental problem-solution fit has already been locked in. Design can only "put a coat of paint on the mess." The UX designers know this is not good, but they try to make it as nice as possible given the constraints. The real value of design — finding the right solution before anything is built — is lost entirely.

---

### Root Cause 6 — Engineers Excluded from Ideation

**Description:** Engineers only see product work when it arrives at sprint planning as a defined requirement or design spec, excluding them from the discovery and ideation process.

**Detection signals:**
- Engineers describe their role as "implementing what the PM and designer hand off"
- Engineers first see features at sprint planning (or equivalent)
- No mechanism exists for engineers to propose product ideas or surface technical opportunities
- Engineers are consulted only for effort estimates, not for feasibility exploration or solution options
- "Tech debt" is the only engineering-driven item that reaches the roadmap

**Why it matters:** Engineers are typically the best single source of innovation in a product team. By using engineers only for delivery, the organization gets approximately half their value. Engineers are aware of technical capabilities and constraints that enable entirely new product possibilities that neither PMs nor designers would think of — but only if they are in the room when problems are being explored.

---

### Root Cause 7 — Agile Applied Only to Delivery (20% of the Value)

**Description:** Agile methods (Scrum, Kanban) are applied exclusively to the engineering delivery phase, while the upstream process — idea sourcing, business cases, roadmaps, requirements — remains a waterfall pipeline.

**Detection signals:**
- The team "uses Scrum" but all sprint work is pre-defined before engineering is involved
- Sprint retrospectives never surface that the problem is upstream of the sprint
- Agile ceremonies (standups, sprint reviews, retros) are the only visible product process
- The backlog is a queue of pre-decided work, not a list of hypotheses to test
- "We're Agile" is offered as evidence that the team has a modern process, but delivery timelines are still measured in quarters

**Why it matters:** Teams using Agile in this way are getting approximately 20% of the actual value and potential of Agile methods. The core Agile benefit — fast feedback loops to learn and adapt — requires that discovery and definition are also iterative, not just delivery. What you are actually seeing is Agile for delivery, but the rest of the organization and context is waterfall.

---

### Root Cause 8 — Project-Centric Not Product-Centric

**Description:** The organization funds, staffs, and measures projects rather than products — treating product work as a series of discrete initiatives with start and end dates rather than as ongoing discovery and improvement.

**Detection signals:**
- Teams are assembled for a project and then disbanded or reassigned after it ships
- Budget is allocated per project rather than per product area or team
- Success is defined as "project delivered" (on time, on budget) rather than "outcome achieved"
- There is no ownership of a product or feature area after it ships — it becomes "maintenance"
- Teams have no mandate or time to iterate on launched work to improve outcomes

**Why it matters:** Projects are output; product is about outcome. A project-centric model predictably leads to orphaned launches — something was shipped but didn't meet its objectives, and no one owns improving it. There is simply no way to build strong products without the ability to iterate and improve based on real-world data.

---

### Root Cause 9 — Customer Validation at the End

**Description:** Customer feedback and validation only happen after the product is built — during user acceptance testing, beta programs, or post-launch — rather than during discovery before investment is made.

**Detection signals:**
- "Customer validation" means a beta test of the finished product
- Usability testing, if it happens at all, occurs on production-ready or near-production builds
- The first time real users interact with the idea is after engineering has invested weeks or months
- Discovering that customers don't want the feature is treated as a launch problem, not a discovery failure
- The risk of building the wrong thing is not managed — it is accepted

**Why it matters:** This is the biggest flaw of the waterfall process. All the risk is at the end. The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed. Many teams believe they are applying Lean principles while following exactly this pattern — trying out ideas in one of the most expensive, slowest ways possible.

---

### Root Cause 10 — Opportunity Cost Ignored

**Description:** The cost of not doing alternative work — the opportunity cost — is never accounted for when evaluating the work the team is currently doing.

**Detection signals:**
- No mechanism exists to evaluate what the team is NOT building while building the current roadmap
- The roadmap is evaluated on "are these good ideas?" not "are these better than the alternatives?"
- When a project fails or delivers no value, the conversation is about what went wrong, not about what the team should have been doing instead
- Leadership evaluates the roadmap against stakeholder requests, not against market opportunities
- "We got it done" is the success criterion, even when the outcome was negligible

**Why it matters:** While the team is busy executing a process that generates a high rate of waste, the biggest loss is usually not the wasted effort itself — it is the opportunity cost of what the organization could have and should have been doing instead. That time and money cannot be recovered. The value of discovering what not to build — and redirecting to higher-value work — is invisible until it is calculated.

---

## Step 3 — Calculate the Dysfunction Score

Sum the scores across all 10 root causes:

```
Total dysfunction score = sum of scores (0–20 scale)
```

| Total Score | Severity | Interpretation |
|-------------|----------|----------------|
| 16–20 | Critical | Fundamental process transformation required; systemic waterfall in a non-waterfall costume |
| 11–15 | High | Multiple serious dysfunctions; significant innovation and adoption risk |
| 6–10 | Moderate | Several isolated dysfunctions; targeted fixes will produce meaningful improvement |
| 1–5 | Low | Minor process gaps; incremental tuning sufficient |
| 0 | Healthy | Process is largely sound |

**Automatic escalation:** Root causes 5 (late design), 6 (engineers excluded), and 9 (late customer validation) each represent structural risks that can independently invalidate an entire product process. If any of these three score 2, escalate the overall severity by one level regardless of total score.

WHY: These three are the core of what distinguishes product discovery from project execution. A team that scores well on the other seven but has all three of these active is still fundamentally not doing product development — they are doing project delivery.

---

## Step 4 — Map Findings to Company Stage Remediations

WHY: The same root cause has different remediation paths depending on company stage. A startup cannot adopt enterprise-scale discovery rituals; an enterprise cannot simply "empower the team" without structural change.

**Startup remediations (pre-product/market fit):**
- Focus entirely on getting to product/market fit — nothing else matters until you have a product that meets the needs of an initial market
- Root causes 1, 4, 9 are the most dangerous: any of them can cause a startup to burn runway building what stakeholders want instead of what the market needs
- Remediation is direct: the founding team must talk to real customers weekly, run low-fidelity experiments before building, and treat the roadmap as a hypothesis list

**Growth-stage remediations (scaling a proven product):**
- The organizational stress symptoms (teams don't see the big picture, technical debt, leadership mechanisms not scaling) require structural fixes, not just process changes
- Root causes 1, 3, 7, 8 are the most common at this stage
- Remediation requires: product vision that teams can connect their work to, defined product strategy, team charters that create clear ownership, and technical investment to address debt that is now blocking velocity

**Enterprise remediations (consistent innovation challenge):**
- The challenge is not capability — it is organizational will and structure
- Root causes 1, 3, 4, 7, 8, 10 all tend to be active simultaneously at enterprise scale
- Stakeholder dynamics actively resist the changes needed
- Remediation requires executive sponsorship of a new operating model; incremental process tweaks will not overcome the structural incentives
- Reference organizations: Adobe, Amazon, Apple, Google, Netflix have solved this — it requires making "pretty big changes"

---

## Step 5 — Identify the Waterfall-Disguised-as-Agile Pattern

WHY: This is the most common process misdiagnosis. Teams believe they are Agile because they use Scrum, but the upstream process that feeds the sprint is waterfall. Naming this explicitly is essential for any remediation conversation.

The pattern is present if ALL of the following are true:
- The team uses sprints or Kanban boards (delivery is Agile)
- Ideas arrive at sprint planning as defined requirements or designs (Agile starts downstream of discovery)
- Root causes 1, 3, 4, or 9 score 2 (the upstream pipeline is waterfall)

**Diagnostic test — ask these three questions:**
1. How does a brand-new idea go from "someone has this idea" to "an engineer starts coding"? If the answer involves roadmap, requirements document, or design handoff before any customer interaction, the upstream is waterfall.
2. When do engineers first see a feature? If the answer is sprint planning, standup, or ticket assignment, engineering is in delivery-only mode.
3. When do customers first interact with the idea? If the answer is beta, user acceptance testing, or post-launch, validation is at the end — waterfall.

**Report label:** If the pattern is detected, explicitly state: "This process is waterfall-disguised-as-agile. The Agile practices in use (sprints, standups, retrospectives) apply to approximately 20% of the product lifecycle — the delivery phase. The upstream process remains sequential and output-focused."

---

## Step 6 — Produce the Dysfunction Report

Structure the output as:

```
## Product Process Dysfunction Report

**Organization/Team:** [name]
**Company Stage:** [startup / growth / enterprise]
**Assessment Date:** [date]

---

### Overall Dysfunction Score: [X/20] — [SEVERITY]

**Waterfall-Disguised-as-Agile:** [Yes / No / Partial]

| Root Cause | Score | Severity | Key Signal Observed |
|------------|-------|----------|---------------------|
| 1. Sales/stakeholder-driven ideas | X | [label] | [1-sentence evidence] |
| 2. Unknowable business cases | X | [label] | [1-sentence evidence] |
| 3. Roadmap as commitment | X | [label] | [1-sentence evidence] |
| 4. PM as project manager | X | [label] | [1-sentence evidence] |
| 5. Design brought in too late | X | [label] | [1-sentence evidence] |
| 6. Engineers excluded from ideation | X | [label] | [1-sentence evidence] |
| 7. Agile delivery only (20% value) | X | [label] | [1-sentence evidence] |
| 8. Project-centric not product-centric | X | [label] | [1-sentence evidence] |
| 9. Customer validation at the end | X | [label] | [1-sentence evidence] |
| 10. Opportunity cost ignored | X | [label] | [1-sentence evidence] |

---

### Two Inconvenient Truths Assessment

| Truth | Impact Given Current Process |
|-------|------------------------------|
| At least 50% of ideas won't work | [How many ideas are being built without pre-validation? What is the estimated waste?] |
| Good ideas need several iterations | [Does the process allow for post-launch iteration? Is there team ownership that enables it?] |

---

### Automatic Escalation Triggers
[List any of causes 5, 6, 9 scoring 2 and their escalation impact]

---

### Waterfall-Disguised-as-Agile Analysis
[Result of the three diagnostic questions. If pattern detected, state it explicitly.]

---

### Stage-Appropriate Remediation Plan

**Company Stage:** [startup / growth / enterprise]

Ordered by: (1) escalation triggers first, (2) highest score, (3) cross-cause impact

| Priority | Root Cause | Current State | Target State | Stage-Specific Action |
|----------|-----------|---------------|--------------|----------------------|
| 1 | ... | ... | ... | ... |

---

### Summary

[3–5 sentences: what the process looks like from the outside, what is actually broken, the primary waste being generated, and the single most important change to make first]
```

---

## Step 7 — Validate Before Delivering

Before delivering the report:
- [ ] Every score of 2 has a specific, observable signal — not an assumption
- [ ] The waterfall-disguised-as-agile determination is based on answering all three diagnostic questions
- [ ] Stage classification is confirmed (do not default to "growth" — ask explicitly)
- [ ] The inconvenient truths section quantifies actual waste exposure, not generic risk
- [ ] The remediation plan is stage-appropriate — startup actions are not the same as enterprise actions
- [ ] The summary names the single most important change, not a list of everything that is wrong

WHY: The most common failure of a dysfunction diagnosis is that it becomes a laundry list that overwhelms rather than a prioritized argument for change. The report must end with a clear "start here."

---

## Reference

Full root cause detail with extended detection signals and remediation patterns:
`references/root-cause-reference.md`

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Inspired How To Create Tech Products by Unknown.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/root-cause-reference.md
# Root Cause Reference

Extended detection signals and remediation patterns for each of the 10 root causes of failed product efforts.

Source: INSPIRED by Marty Cagan, Chapters 3–7.

---

## Root Cause 1 — Sales/Stakeholder-Driven Idea Sourcing

**Source chapter:** Ch6 (pp. 17–18)

**Extended signals:**
- Roadmap items can each be traced to a specific stakeholder who requested them
- The PM attends stakeholder "requirements sessions" as a standard part of their week
- Feature descriptions reference a specific customer, deal, or internal sponsor rather than a customer segment or problem
- Engineers describe the product as "Sales' product" or "Marketing's product"

**What this is not:**
- Stakeholder input is not inherently wrong. The problem is when stakeholders are the primary or dominant source, replacing customer insight and discovery.
- Sales feedback can surface real customer problems. The dysfunction is when it bypasses discovery and becomes a direct feature request.

**Remediation by stage:**
- *Startup:* Co-founders must separate "customer request for this feature" from "customer has this problem." Commit to the problem, not the proposed solution.
- *Growth:* Establish a product strategy that gives the team criteria for what goes on the roadmap. Stakeholder requests must be evaluated against strategy.
- *Enterprise:* Requires formal intake process with explicit criteria. Sales specials must be limited and time-boxed; they cannot be the default mechanism.

---

## Root Cause 2 — Unknowable Business Cases

**Source chapter:** Ch6 (pp. 18)

**The two inputs that cannot be known:**
1. How much money/value will the idea make? — Depends entirely on quality of the solution, which hasn't been created yet. Many product ideas generate literally nothing (confirmed by A/B testing data).
2. How much will it cost to build? — Cannot be estimated without knowing the actual solution. Experienced engineers refuse to estimate at this stage; others provide "t-shirt sizes" (S/M/L/XL) that are essentially meaningless.

**Extended signals:**
- The phrase "we need a business case before we prioritize this" is common
- ROI projections are reverse-engineered to justify decisions already made
- Engineering estimates exist on the roadmap next to items that haven't been designed
- Business case effort adds 2–6 weeks to getting started

**Why business cases themselves are not wrong:**
Cagan is in favor of business cases for ideas that need a larger investment. The problem is the sequence — creating business cases before solution discovery produces false precision and bureaucratic overhead without reducing actual risk.

**Remediation:**
Move the business case to after a prototype has been validated with customers. The inputs become real: you have evidence for potential value, and engineering can estimate against a defined solution.

---

## Root Cause 3 — Roadmap as Commitment

**Source chapter:** Ch6 (pp. 18–19)

**Extended signals:**
- Sales references roadmap dates in customer conversations
- When items are removed from the roadmap, it is treated as breaking a promise
- The PM's performance review includes "roadmap delivery" as a metric
- The roadmap is a Gantt chart or dated list, not a prioritized hypothesis backlog

**The output vs. outcome distinction:**
Projects are output. Product is about outcome. The roadmap-as-commitment model focuses entirely on output (features shipped) and has no mechanism for tracking whether those features achieved the intended outcome. This is why teams can ship 100% of their roadmap and still be failing.

**What a healthy roadmap looks like:**
A prioritized list of the most important problems to solve, with success metrics defined, but without commitment to specific solutions or dates until discovery is complete.

---

## Root Cause 4 — Product Manager as Project Manager

**Source chapter:** Ch6 (p. 19)

**The 180-degree problem:**
Gathering requirements and documenting them for engineers is the opposite of what product management should be. Requirements-gathering assumes the solution is known and just needs to be described. Product management starts from the problem and discovers the solution.

**Extended signals:**
- PM job description uses words like "gather," "document," "translate," "coordinate," "track"
- PMs have no time in their calendar marked for customer interviews or prototype testing
- When asked "what problem are we solving with this feature?" the PM quotes the stakeholder's request
- The PM is evaluated on delivery (sprint velocity, milestone completion) not on outcomes (revenue, retention, adoption)

**The "mercenary" vs. "missionary" distinction:**
In the requirements-gathering model, the team is mercenary — they implement what they are told. In product management, the team is missionary — they are given a problem and have the authority and responsibility to find the best solution.

---

## Root Cause 5 — Design Brought In Too Late

**Source chapter:** Ch6 (pp. 19–20)

**The "lipstick on the pig" pattern:**
When design enters after requirements are set, the fundamental problem-solution fit has been locked in by non-designers. Design can only optimize the presentation of a solution that may be fundamentally wrong. The UX designers are aware of this — they are doing their best within structural constraints that prevent them from doing real design work.

**Extended signals:**
- Designers receive wireframes or written requirements as design inputs
- There is no "design studio" or collaborative ideation session early in the process
- Designers are allocated per feature (assigned when a feature starts, done when it ships)
- User research, if it exists, is conducted by a separate research team whose findings are reported out rather than experienced directly by the designers

**The real value of design:**
Design's actual contribution is discovering the right solution before anything is built — prototyping, testing, iterating on interaction patterns and information architecture until a solution is found that customers can actually use and value. This requires design to be a discovery partner from day one, not a delivery service at the end.

---

## Root Cause 6 — Engineers Excluded from Ideation

**Source chapter:** Ch6 (p. 20)

**The "best single source of innovation" problem:**
Engineers are typically the best single source of innovation in a product organization. They have direct knowledge of what is technically possible, what is becoming possible (new APIs, new capabilities, falling costs), and how existing technical investments could be leveraged for new product purposes. Excluding them from ideation means this knowledge is never applied to product decisions.

**Extended signals:**
- Engineers describe their role as "implementing designs"
- Engineering input into product direction is limited to effort estimates
- "Feasibility" is only checked after a feature is spec'd, not explored during ideation
- Engineers propose technical improvements (infrastructure, tooling) but not product ideas
- The phrase "the engineers just build what they're told" is used without irony

**The "half their value" calculation:**
If engineers are used only for implementation, the organization is getting approximately half their value — the labor of building, but not the intellectual contribution to what gets built.

---

## Root Cause 7 — Agile Applied Only to Delivery

**Source chapter:** Ch6 (p. 20), Ch7 (pp. 23–24)

**The 20% value problem:**
Agile methods applied only to the delivery phase capture approximately 20% of the potential value. The core Agile benefit — rapid learning through fast feedback loops — requires that discovery and definition are also iterative. Applying Agile only to engineering delivery turns it into a faster waterfall.

**Extended signals:**
- "We're Agile" is demonstrated by sprint ceremonies, not by discovery practices
- Retrospectives only address delivery issues, not upstream process problems
- The backlog contains no discovery tasks, only implementation tasks
- "Definition of done" is code-complete and QA-passed, not "did it solve the problem?"
- Teams that were told to "be Agile" implemented Scrum and stopped there

**Lean principles also frequently misapplied:**
Teams claim to be applying Lean while working for months on what they call a minimum viable product (MVP) without knowing whether it will sell. Teams also over-apply Lean by testing and validating everything, going nowhere fast. Neither reflects the actual principle: reduce waste through fast, cheap learning before committing to expensive build effort.

---

## Root Cause 8 — Project-Centric Not Product-Centric

**Source chapter:** Ch6 (p. 20)

**The orphaned project pattern:**
A project-centric model produces a predictable failure mode: something was shipped, it didn't meet its objectives, but the team has already been disbanded or reassigned to the next project. No one owns improving it. The organization ships features into a void and moves on.

**Extended signals:**
- The product team changes with each major initiative
- "Maintenance mode" is where products go after their initial launch
- Metrics are checked at launch and then rarely revisited
- There is no defined owner for a given product area who is accountable for its long-term performance
- Budget cycles are project-based, not product-team-based

**The iteration requirement:**
Even ideas that have real potential typically require several iterations to deliver the necessary business value. This is the second inconvenient truth. A project-centric model structurally prevents these iterations from happening, because the project ends at launch.

---

## Root Cause 9 — Customer Validation at the End

**Source chapter:** Ch6 (p. 20)

**The biggest flaw of waterfall:**
Cagan identifies this as the biggest flaw of the waterfall process: all the risk is at the end. The entire engineering investment is committed before the first real customer interaction. By that point, it is too expensive to change direction — so teams either ship something that doesn't work or spend months in rework that could have been avoided with a two-day prototype test at the beginning.

**Extended signals:**
- "User acceptance testing" is the primary customer validation mechanism
- Usability testing happens on production builds or release candidates
- Customer pilots or betas are the first time real users see the product
- Discovery is not a defined phase — it happens implicitly as requirements are gathered from stakeholders
- "We'll see what customers think when we ship" is a common planning assumption

**The cost calculation:**
If a prototype test takes two days and costs essentially nothing, but a full engineering build takes 8 weeks, and 50–75% of ideas won't work as expected, validating before building has an expected value that is straightforward to calculate. Teams that do late validation are trying out ideas in one of the most expensive, slowest ways possible.

---

## Root Cause 10 — Opportunity Cost Ignored

**Source chapter:** Ch6 (p. 20)

**The invisible cost:**
Opportunity cost is invisible because it represents the value of work not done, not the cost of work that was done and failed. This makes it systematically under-weighted in all planning processes — you can see the cost of a failed project, but you cannot see the revenue from a product that was never built because the team was busy on something else.

**Extended signals:**
- Roadmap reviews only ask "are these good ideas?" not "are these better than alternatives?"
- No mechanism exists for surfacing and comparing alternative uses of engineering time
- When a project delivers negligible value, the post-mortem focuses on execution, not on whether the opportunity was worth pursuing
- The team has no visibility into what is being deferred and the cumulative cost of those deferrals
- Leadership evaluates the roadmap against stakeholder requests rather than against market opportunities

**The compounding problem:**
Opportunity cost compounds with the 50% failure rate (Truth 1) and the iteration requirement (Truth 2). If half of all ideas fail, and good ideas need multiple iterations, and the team is executing a process that can't validate ideas cheaply before building them — the opportunity cost of alternative work (correctly prioritized, quickly validated ideas) grows with every sprint.

---
name: product-okr-implementation
description: "Design and implement an OKR (Objectives and Key Results) system for product teams. Use when transitioning away from feature roadmaps to outcome-based planning, setting up OKRs for a product organization, replacing quarterly roadmaps with business objectives, aligning multiple teams to shared goals, or when someone asks 'how do we set up OKRs?' Also use when diagnosing OKR cascade failures, structuring high-integrity commitments to stakeholders, establishing OKR scoring standards, running quarterly OKR planning cycles, or scaling OKRs to 25+ teams. Covers the 12 OKR rules, scoring rubric, functional cascade anti-patterns, and a 6–12 month roadmap-to-outcomes transition plan. Not for diagnosing team health or culture — use product-team-health-diagnostic or product-culture-assessment instead."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-okr-implementation
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [22, 23, 28, 29, 30, 60]
tags: [product-management, okrs, product-strategy, roadmaps, business-objectives, team-alignment, scaling]
depends-on: []
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Company context: team count, current planning system (roadmap or OKR), key business objectives, and any stakeholder concerns about date commitments"
  tools-required: [Write]
  tools-optional: [Read]
  mcps-required: []
  environment: "Any agent environment. Best with: current roadmap or OKR document, org chart, list of product teams."
---

# Product OKR Implementation

## When to Use

You are designing, auditing, or transitioning to an Objectives and Key Results system for a product and technology organization. Specific triggers:

- Leadership wants to move from quarterly feature roadmaps to business-outcome planning
- Product teams lack clear, shared priorities or conflict with functional managers on where to spend time
- The organization is growing (25+ teams) and alignment is breaking down
- Stakeholders (sales, marketing) are demanding date commitments that product teams cannot responsibly make
- Existing OKRs feel like tasks and deliverables rather than measurable business outcomes
- Design, engineering, or QA departments have created their own OKRs that conflict with product team work

## Why Roadmaps Fail (The Two Inconvenient Truths)

Before implementing OKRs, the organization must internalize why feature roadmaps produce poor business results:

1. **At least 50% of product ideas will not work.** Customers may not value the idea, find it too complex to use, or the business constraints make it undeliverable. This is not a failure — it is the nature of product work.
2. **Even ideas that are valuable typically require several iterations** before they deliver the expected business outcome. Time-to-money is rarely the first shipped version.

When a list of features is published on a roadmap, the entire company interprets every item as a commitment — regardless of disclaimers. This forces teams to deliver features even when those features do not solve the underlying business problem. The solution is to give teams business outcomes to achieve and let them discover the best solutions.

## Core OKR Structure

**Objectives** are qualitative statements of what the organization or team is trying to accomplish. They are aspirational and directional, not measurable.

**Key Results** are quantitative measures of whether the objective was achieved. They measure *business results*, not outputs or tasks. Shipping a feature is never a key result. Changing a metric is.

Example:
- Objective: "Dramatically reduce the time it takes for a new customer to go live"
- Key Result: "Average new customer onboarding time less than three hours"

## The 12 OKR Rules for Product Organizations

All 12 rules below are required. See `references/okr-12-rules.md` for extended implementation guidance and worked examples.

**Rule 1 — Objectives qualitative, key results quantitative.**
Objectives are aspirational narrative statements. Key results are specific numbers with a baseline and a target. If a key result cannot be measured, it is not a key result — it is a task.

**Rule 2 — Key results measure business outcomes, not output or tasks.**
"Ship the mobile app" is output. "Increase mobile daily active users from 12k to 20k" is a business outcome. Key results must measure a change in business or customer behavior, not the completion of work.

**Rule 3 — Only two levels: organization OKRs and product team OKRs.**
Do not create OKRs for functional departments (design, engineering, QA) or for individuals. Functional OKRs conflict with product team OKRs and pull individuals in incompatible directions. See the Anti-Pattern section below.

**Rule 4 — Annual cadence for organization objectives; quarterly cadence for team objectives.**
Company-level objectives change rarely — annually or when strategy changes. Product team objectives change quarterly to reflect current priorities and market conditions. Do not run both at the same quarterly cadence — the organization loses strategic continuity.

**Rule 5 — Scope small: 1–3 objectives per team, 1–3 key results per objective.**
More than 3 objectives signals the team has no priorities. A team with 7 key results is covering everything and will achieve nothing. Force prioritization — if everything is important, nothing is.

**Rule 6 — Track progress against objectives weekly.**
OKRs are not a quarterly ritual. Teams should reference their key results in weekly check-ins, note current values versus targets, and call out blockers or drift. Without weekly tracking, teams discover at quarter-end that they were off-track for months.

**Rule 7 — Objectives do not need to cover every team activity.**
Teams do ongoing work (maintenance, support, on-call) that is not captured in OKRs. OKRs capture only what the team needs to *accomplish* — the outcomes they are accountable for changing. This is a scope boundary, not a problem.

**Rule 8 — Substantial failure triggers a post-mortem.**
If a team scores significantly below 0.3 on an objective, they are expected to conduct a post-mortem with peers or management: what went wrong, what was learned, and what will change. This is not punitive — it is how accountability functions without blame.

**Rule 9 — Use a consistent, agreed-upon scoring rubric across the organization.**
Every team must use the same 0 / 0.3 / 0.7 / 1.0 rubric (defined in the Scoring section below). Without shared standards, team scores are incomparable and coordination signals break down.

**Rule 10 — Distinguish high-integrity commitments from normal OKR key results.**
High-integrity commitments are binary (delivered / not delivered) and scored separately. They are never part of the normal OKR scoring curve. See the High-Integrity Commitments section below.

**Rule 11 — Full transparency: every team's objectives and scores are visible organization-wide.**
Every product and technology team can see every other team's objectives, key results, and current progress. This enables coordination, surfaces duplication, and creates peer accountability. Hidden OKRs are not OKRs — they are private goal-setting.

**Rule 12 — Ownership hierarchy: senior management owns organization OKRs; product/technology leadership owns product team OKRs; individual teams propose key results.**
The CEO or executive team defines the organization objectives. Heads of product and technology assign those objectives to specific teams. Teams then *propose* the key results they believe will demonstrate progress. Leadership reviews the proposals for gaps and adjusts. This give-and-take is the mechanism for alignment without top-down dictation.

## OKR Scoring Rubric

Use this rubric consistently across the organization so teams can depend on each other's signals:

| Score | Meaning |
|-------|---------|
| **0.0** | No meaningful progress made |
| **0.3** | Bare minimum — delivered only what was already certain to be achievable |
| **0.7** | Hoped-for result — accomplished more than the minimum, achieved what the team set out to do |
| **1.0** | Exceptional — truly surprised the organization, exceeded what anyone was hoping for |

For normal OKRs, teams should aim for 0.7. Consistently scoring 1.0 means targets are set too low. Scoring below 0.3 consistently requires examination.

**High-integrity commitments are scored differently:** they are binary. Either the commitment was delivered or it was not. Do not apply the 0–1.0 scale to a high-integrity commitment.

## High-Integrity Commitments

High-integrity commitments resolve the tension between stakeholders who need date certainty (hiring plans, marketing spend, contracts, partnerships) and product teams that cannot responsibly commit before knowing what they need to build.

**The root cause of bad commitments is timing.** Commitments made before product discovery are made without knowing: what to build, whether it will solve the problem, or how long it will actually take.

**The protocol:**

1. When an external date commitment is needed, the product team asks for a short product discovery period first — typically days or weeks, not months.
2. During discovery, the team validates the solution with customers (value, usability), with engineers (feasibility), and with the business (viability).
3. After discovery establishes a solution that works, the team makes a high-integrity commitment: a specific date and deliverable that stakeholders can depend on.
4. Delivery managers track these commitments and their dependencies. Engineers' estimates alone are insufficient — the team may be occupied on other work and unable to start immediately.

**Use high-integrity commitments sparingly.** Good product organizations minimize them. When they are made, the organization must be able to depend on delivery.

## Anti-Pattern: Functional OKR Cascade

**What happens:** When organizations first adopt OKRs, each functional department (design, engineering, QA) creates OKRs for their own organization:
- Design: "Move to responsive design by Q3"
- Engineering: "Improve architecture scalability by 40%"
- QA: "Implement full test automation"

**Why it breaks product teams:** The individuals on those functional teams are also members of cross-functional product teams. Those product teams have business-related objectives (reduce acquisition cost, increase daily active users, reduce onboarding time). But each person receives a separate set of objectives that cascade down through their functional manager.

Result: engineers are told to work on re-platforming; designers on responsive design; QA on retooling. These may be worthwhile activities. But the cross-functional product team cannot solve its business problems if its members are pulled in incompatible directions.

**The correct model:** OKR cascading in a product organization runs *upward* — from cross-functional product teams to company or business unit level. Functional leaders (head of design, head of engineering) may have their own organizational objectives (strategy for responsive design, managing technical debt) but these are management-level concerns, not individual contributor conflicts.

If functional concerns like technical debt or design systems need to be addressed, they should be prioritized at the leadership level alongside business objectives and then *incorporated into relevant product team objectives*.

## OKRs at Scale (25+ Teams)

When a product organization has 25 or more product teams, standard OKR mechanics require additional structure:

**1. Leadership must cascade objectives before teams propose key results.**
With 25 teams, not all can pursue all objectives. Leadership (head of product, head of technology, head of design) must first determine which teams are best suited to pursue each organizational objective. Teams then propose key results for the objective(s) they have been assigned.

**2. Multiple teams share objectives.**
Some objectives require contribution from several teams. Leadership coordinates this, identifies dependencies, and ensures teams are not duplicating effort or working at cross-purposes.

**3. Platform and shared services teams need separate treatment.**
At scale, platform product teams (shared services teams) serve other product teams indirectly rather than customers directly. Leadership must coordinate these teams' objectives to ensure they support the objectives of solution-facing teams.

**4. Leadership runs a reconciliation process.**
After teams propose key results, leadership reviews the aggregate to identify gaps — business outcomes that no team is covering — and adjusts team assignments or reprioritizes accordingly.

**5. Delivery managers actively track high-integrity commitments.**
At scale, the list of external commitments grows and dependencies multiply. Delivery managers are responsible for tracking which commitments exist, which teams own them, and whether dependencies are being met.

**6. Enterprise organizations add a business unit layer.**
In companies with multiple business units, the hierarchy is: corporate OKRs → business unit OKRs → product team OKRs. Product teams roll up into the business unit, not directly to corporate.

## Roadmap-to-Outcomes Transition Protocol (6–12 Months)

For organizations where leadership is committed to the quarterly feature roadmap and cannot switch overnight:

**Phase 1 — Parallel run (months 1–6):**
- Continue the existing roadmap process without disruption
- For every roadmap item referenced in a meeting, presentation, or document, immediately add the business outcome that feature is intended to affect, plus the current baseline metric
- Example: "Adding PayPal as payment method — intended to increase conversion rate, which is currently 2.3%"
- This trains the organization to see the *why* behind features, not just the what

**Phase 2 — Impact reporting (months 3–12):**
- After each feature ships, report the actual impact on the business metric
- If impact is positive: celebrate it and attribute it to the outcome, not the feature
- If impact is neutral or negative: explicitly communicate that shipping the feature was not the goal — improving the metric was. The outcome was not achieved. Share what was learned and what the team will try next
- This is the key cultural shift: the team is not off the hook when the feature ships; they are off the hook when the metric moves

**Phase 3 — Outcome graduation:**
- Over time (can take up to a year), the organization develops the habit of evaluating work by business results rather than feature delivery dates
- Stakeholders gain confidence that teams are working on the most important items (visible through OKR transparency) and that critical dates will be honored (through high-integrity commitments)
- The roadmap becomes unnecessary because it served two purposes — priority visibility and date commitments — and the OKR system plus high-integrity commitments serve both more reliably

## Output Template

Use this template to produce a complete OKR document for a product organization:

```markdown
# [Company/Organization] OKR Document
Quarter: [Q? YYYY]  |  Organization: [Product & Technology]

---

## Organization Objectives

### O1: [Qualitative objective statement]
Owned by: [CEO / executive team]

| Key Result | Baseline | Target | Score |
|------------|----------|--------|-------|
| [Quantitative business metric + target] | [Current value] | [Goal value] | — |
| [Quantitative business metric + target] | [Current value] | [Goal value] | — |

---

## Product Team OKRs

### Team: [Team Name]
Owned by: [Product Manager name]
Contributing to: O[n]

**Objective:** [Qualitative statement]

| Key Result | Baseline | Target | Score |
|------------|----------|--------|-------|
| [Business metric + target] | [Current] | [Goal] | — |
| [Business metric + target] | [Current] | [Goal] | — |

**High-integrity commitments this quarter:**
- [ ] [Specific deliverable] — due [date] — owner: [name]

---

## Scoring Reference
0.0 = no progress | 0.3 = bare minimum | 0.7 = hoped-for | 1.0 = exceptional
High-integrity commitments: binary (delivered / not delivered)

---

## Weekly Check-In Log
| Week | Team | KR | Current Value | Trend | Blocker |
|------|------|----|---------------|-------|---------|
```

## References

- `references/okr-12-rules.md` — Full text of all 12 OKR rules with implementation guidance
- `references/functional-cascade-examples.md` — Before/after examples of functional vs. product team OKR structures

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/functional-cascade-examples.md
# Functional OKR Cascade: Before and After

Source: INSPIRED, Chapter 29 (Cagan)

---

## The Anti-Pattern: Functional Department OKRs

When organizations first adopt OKRs, there is a natural instinct to give each functional department its own OKRs. This feels logical — each discipline has professional concerns that matter.

### Example: Functional OKRs for a product team member

**Design department OKR:**
- Objective: Modernize user experience
- KR: Migrate 100% of product surfaces to responsive design by Q3

**Engineering department OKR:**
- Objective: Improve system reliability
- KR: Re-platform authentication service to new infrastructure

**QA department OKR:**
- Objective: Increase release confidence
- KR: Achieve 80% automated test coverage across all modules

A specific individual — say, a frontend engineer — receives all three signals:
- Their product team needs them focused on reducing customer acquisition cost
- Their engineering manager needs them focused on re-platforming
- Their QA manager (if they own shared tooling) expects automation coverage improvements

**Result:** The individual cannot focus. The product team cannot solve the business problem it was formed to solve. Leadership sees poor results and blames the team.

---

## The Correct Pattern: Product Team-Level OKRs

The same functional concerns (responsive design, technical debt, test automation) are legitimate — but they belong in the leadership agenda, not in the individual contributor's objective stack.

**How to handle legitimate functional concerns:**

1. The head of design identifies that responsive design is a strategic need
2. This concern is raised at the leadership team level alongside business objectives
3. Leadership decides which product teams should incorporate responsive design work into their objectives for the quarter
4. The product team objective becomes: "Improve mobile conversion rate" — and responsive design may be one solution they explore

The functional concern is now channeled through the product team objective rather than creating a parallel obligation.

**Product team OKR (correct):**
- Objective: Make it significantly easier for new customers to activate
- KR: Reduce time from signup to first value event from 14 days to 3 days
- KR: Increase 7-day activation rate from 22% to 40%

The engineer, designer, and QA engineer on this team all work toward the same outcome. Their skills are means, not ends.

---

## Who Can Have Their Own OKRs

| Role | Own OKRs? | Reasoning |
|------|-----------|-----------|
| Cross-functional product team | Yes | Primary unit of product delivery |
| Organization (CEO + exec team) | Yes | Sets strategic direction |
| Functional manager (head of design, head of engineering) | Yes, carefully | Not on a product team; organizational objectives are their job |
| Individual contributor on a product team | Small personal growth only | Must not conflict with product team contribution |
| Functional department as a group | No | Creates dual-reporting confusion and conflicting priorities |

---

## The Direction of Cascade

**Wrong direction (functional cascade):**
Corporate → Business unit → Design department → Design team member

**Right direction (product team cascade):**
Corporate → Business unit → Product team → (team proposes KRs up)

The cascade runs *upward* from product team key results to company objectives — product teams propose how they will contribute to the organization's objectives. It does not run *downward* from functional hierarchies through individual contributors.

FILE:references/okr-12-rules.md
# The 12 OKR Rules for Product Organizations

Source: INSPIRED, Chapters 28–30 (Cagan)

These rules are specific to the product management, design, and technology organization. Other parts of the company may use OKRs differently.

---

## Rule 1: Objectives are qualitative; key results are quantitative

Objectives describe direction and aspiration. They should be motivating and clear but are not measurable by themselves.

Key results must be specific numbers that can be objectively evaluated. If there is no number, it is not a key result — it is a task or milestone.

Wrong KR: "Launch the new onboarding flow"
Right KR: "Reduce median time-to-first-value from 14 days to 3 days"

## Rule 2: Key results measure business outcomes, not output or tasks

Key results track whether the business moved — not whether the team shipped something. Shipping is an activity. The question is whether the shipping changed a metric that matters.

Wrong KR: "Deliver payment redesign by March 15"
Right KR: "Increase checkout completion rate from 61% to 75%"

## Rule 3: Focus OKRs at the organization and product team level

For the product and technology organization, there are two valid levels:
- Organization-level OKRs (owned by senior leadership)
- Product team-level OKRs (one set per cross-functional product team)

Functional department OKRs (design OKRs, engineering OKRs, QA OKRs) and individual OKRs for people who sit on product teams create conflicting priorities and should be avoided. See `functional-cascade-examples.md`.

Exception: Functional managers (head of design, head of engineering) who do not sit on product teams may have their own objectives. Individual contributors may have a small number of personal growth objectives, as long as these do not interfere with their product team contributions.

## Rule 4: Annual cadence for organization; quarterly cadence for teams

Organization objectives should be stable enough to last a year. Changing them mid-year signals poor strategic clarity.

Product team objectives refresh quarterly, allowing teams to respond to what was learned in the prior quarter and to what changed in the business.

## Rule 5: Keep the number of objectives and key results small

1–3 objectives per organization or team. 1–3 key results per objective.

More than three objectives at the team level is not focus — it is a task list. Teams that struggle to select three objectives have not made hard prioritization decisions.

## Rule 6: Teams track progress against objectives weekly

Weekly check-ins are not status theater. They are the mechanism by which teams catch problems early, surface blockers to leadership, and maintain accountability to the outcomes they committed to. Quarterly-only reviews are too infrequent to course-correct.

## Rule 7: Objectives do not need to cover every team activity

Teams do ongoing maintenance, bug fixes, technical work, and support activities that are not captured in OKRs. Objectives cover what the team *needs to accomplish* — the meaningful outcomes that require focused effort and represent the team's highest-priority contribution to the business.

## Rule 8: Teams are accountable; failure triggers post-mortems

Accountability means something. Teams that consistently miss objectives should conduct retrospectives with peers or management. The goal is not punishment but learning: did the team set targets that were too ambitious? Did they encounter blockers? Did the key results turn out to be the wrong metrics?

Accountability without inquiry produces fear. Inquiry without accountability produces drift.

## Rule 9: Agree on a consistent scoring rubric organization-wide

| Score | Meaning |
|-------|---------|
| 0.0 | No meaningful progress |
| 0.3 | Bare minimum — only what was already certain to be achievable |
| 0.7 | Hoped-for — accomplished what the team set out to do |
| 1.0 | Exceptional — truly surprised the organization |

Consistency matters more than the specific scale. When every team uses the same rubric, scores communicate real signal. When teams calibrate their own scores privately, the numbers are meaningless for cross-team comparison.

Teams should generally aim for 0.7. An organization where every team scores 1.0 every quarter is setting targets too low.

## Rule 10: Distinguish high-integrity commitments from normal OKRs

High-integrity commitments are specific deliverables promised to external parties (customers, partners, other business functions) with a specific date. They exist because the business sometimes must coordinate across functions with hard dependencies.

They are different from OKR key results in two ways:
1. They are negotiated and date-bound after product discovery, not before
2. They are scored as binary: delivered on time or not delivered

For high-integrity commitments, 0.7 is not acceptable. The organization depends on these.

## Rule 11: Full transparency across the product and technology organization

Every team's objectives and current progress scores should be visible to every other team and to leadership. Transparency prevents redundancy, surfaces dependency conflicts early, and creates social accountability that supplements formal accountability structures.

## Rule 12: Ownership hierarchy

| Level | Owns |
|-------|------|
| Senior management (CEO, executive team) | Organization objectives and key results |
| Heads of product and technology | Product team objectives (ensuring alignment with organization objectives) |
| Individual product teams | Proposed key results for each objective they have been assigned |

The give-and-take process each quarter: leadership assigns objectives to teams; teams propose the key results they believe will demonstrate achievement of those objectives; leadership reviews the aggregate across teams, identifies gaps, and negotiates adjustments.

---
name: product-manager-competency-assessment
description: |
  Evaluate product manager competency for hiring, coaching, or self-assessment. Use when interviewing a VP of Product or head of product candidate, assessing an existing product leader, evaluating an individual contributor PM, conducting a PM self-assessment to find development gaps, or debriefing an interview panel. Also use when someone asks 'is this PM candidate strong?', 'am I a good product manager?', 'what does a strong VP of Product look like?', or 'how do I evaluate PM interview performance?' Covers VP assessment (team development, vision and strategy, execution, culture) and IC PM assessment (customer, data, business, market knowledge plus smart/creative/persistent traits). Diagnoses which of 3 PM working modes the person operates in: backlog administrator, roadmap administrator, or empowered PM. Not for team or organizational assessment — use product-team-health-diagnostic or product-culture-assessment for those.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-manager-competency-assessment
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
model: sonnet
context: 200k
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Interview notes, performance observations, written self-assessment, or verbal description of the person being assessed"
    - type: none
      description: "Skill can work from a verbal description provided in the prompt"
  tools-required: [Read]
  tools-optional: []
  environment: "No codebase access required; works from descriptions, interview notes, or self-assessment input"
source-books:
  - name: inspired-how-to-create-tech-products
    chapters: [10, 17]
depends-on: []
tags: [product-management, hiring, career-development]
---

# Product Manager Competency Assessment

## When to Use

Use this skill when you are:
- **Hiring a VP of Product** — need a structured evaluation framework beyond gut feel and resume review
- **Assessing an existing head of product** — need to determine if the current leader has the competencies the company needs at this stage
- **Evaluating an individual contributor PM candidate** — need to test whether they have the four knowledge domains and three core traits
- **Coaching a PM** — need to identify specific development gaps and create a targeted improvement plan
- **Running a self-assessment** — a PM wants an honest gap analysis against what the role actually requires
- **Debriefing after interviews** — need a shared framework to align an interview panel on evaluation criteria

Preconditions: you have at least one of:
- Interview notes or transcripts from one or more conversations with the person
- Performance observations over at least several weeks
- A self-written description from the person being assessed
- A verbal description you can provide directly in the prompt

**Agent:** Before beginning, clarify the assessment scope:
1. Is this a VP-level / head of product assessment, an individual contributor PM assessment, or both?
2. Is this a hiring evaluation, a performance review, or a self-assessment for development?
3. What is the company stage and CEO profile (for VP assessments — this changes what vision/strategy profile you need)?

---

## Assessment Processes

---

### Use Case A: VP of Product / Head of Product Assessment

Source: Ch17 (pp.79-83)

#### A-Step 1 — Establish CEO and Company Context First

WHY: The VP of Product must complement the CEO, not mirror them. The right VP profile depends entirely on whether the CEO is a product visionary. Getting this wrong is the single most common cause of VP product failure and short tenure.

Determine:

| Question | Why It Matters |
|----------|---------------|
| Is the CEO a strong product visionary (drives vision, deeply involved in product decisions)? | If yes: the VP role is primarily execution. You need someone who can execute the CEO's vision without ego clash. Hiring a visionary VP into a visionary CEO company causes immediate conflict. |
| Has the founder moved on, or is the CEO not strong at product vision? | If yes: the VP must be the product visionary. The company will stagnate without one. |
| How large is the product organization? | Larger organizations require stronger stakeholder management and internal evangelism skills — weight the execution competency accordingly. |
| Is this a Series A/B (building product culture) or Series C+ (scaling an existing culture)? | Shapes how much you weight product culture competency. |

Document the CEO and company profile before evaluating any candidate.

---

#### A-Step 2 — Evaluate the Four Core Competencies

Score each competency: **Strong** (clear evidence), **Developing** (partial evidence), **Absent** (no evidence or counter-evidence).

---

**Competency 1 — Team Development**

This is the single most important competency for a VP of Product. The VP's job is to develop a strong team of product managers and designers.

What to look for:
- Track record of identifying and recruiting product talent
- Evidence of actively developing people — addressing weaknesses, exploiting strengths
- Can articulate a framework for what makes a strong PM and how to develop one
- Has successfully promoted people who then performed well
- Has managed out poor performers without letting them linger

Red flag: candidate was an excellent individual contributor PM who has never had to develop others. Strong IC skills and strong people-development skills are different skill sets. Many excellent PMs never progress to leading organizations because they cannot make this transition.

Interview criteria:
- "Tell me about someone on your team who was struggling. What specifically did you do? What was the outcome?"
- "Describe your recruiting process for PMs. What do you look for and how do you find non-obvious talent?"
- "What is your framework for evaluating a PM's strengths and weaknesses?"
- "Tell me about a PM you developed who went on to do something significant."

---

**Competency 2 — Product Vision and Strategy**

The product vision is what drives and inspires the company and sustains it through ups and downs.

What to look for (shape depends on CEO profile — see Step 1):

*If CEO is a product visionary:*
- Candidate is strong at executing and operationalizing vision, not generating it
- Can translate a founder's vision into concrete product strategy and roadmap
- Does not compete with the CEO for the vision; does not need to own it
- Some strong VP candidates will decline this role precisely because their job would be execution — that is self-awareness, not a weakness

*If CEO is not a product visionary:*
- Candidate is a genuine product visionary in their own right
- Has demonstrated ability to define and communicate a compelling product vision that motivates engineers and designers
- Can provide the strategic coherence that the organization currently lacks

Interview criteria:
- "Tell me about a product vision you defined or operationalized. How did you arrive at it and how did you communicate it to the team?"
- "How do you think about the relationship between your vision and the CEO's direction?"
- "Walk me through a strategic decision where you had to say no to a significant stakeholder request."

---

**Competency 3 — Execution**

Vision without execution is worthless. The product leader must have proven ability to get products into customers' hands.

What to look for:
- Expert in modern product planning: customer discovery, product discovery, product development process
- Proven ability to manage stakeholder relationships and internal evangelism
- Can inspire and motivate the company — gets everyone moving in the same direction
- Has worked effectively at the company's scale (or slightly above it)
- Bigger organizations require stronger stakeholder management; weight this accordingly

Interview criteria:
- "Describe your product development process. How do you run discovery? How do you decide what to build?"
- "Tell me about a situation where you had major stakeholder conflict. How did you resolve it?"
- "How do you keep engineering and design motivated when the roadmap is constrained by business needs?"
- "What does your planning process look like at the start of a quarter or half?"

---

**Competency 4 — Product Culture**

Good product organizations have strong teams, solid vision, and consistent execution. Great product organizations add a strong product culture.

What to look for:
- Understands and can articulate why continuous, rapid testing and learning matters
- Treats mistakes as learning — makes them quickly, mitigates risk, moves forward
- Demonstrates genuine respect for designers and engineers as collaborators, not service providers
- Can give concrete examples from their own experience of building product culture
- Has concrete plans for instilling culture in a new company — not vague aspirations

Interview criteria:
- "Tell me about a time your team was wrong about something important. How did you find out? What did you do?"
- "How do you describe your relationship with engineering leadership? Give me a specific example of how you work with your tech lead."
- "What does a strong product culture look like to you? What specifically would I observe if I spent a week in your current team?"
- "What would be your first 90 days focused on, culturally?"

---

#### A-Step 3 — Evaluate Secondary Criteria

**Experience**
- Minimum: strong technology background + understanding of the economics and dynamics of the business and market
- Domain experience (industry-specific knowledge) varies by company — assess fit for your specific industry

**Chemistry**
- The VP product must be able to work well on a personal level with the CEO and CTO
- This is non-negotiable: if chemistry is absent, the other competencies do not matter
- Assessment method: include a long dinner (not a formal interview) with at least the CEO and CTO, and ideally the head of marketing and head of design. Make it personal, not a continuation of the interview.

---

#### A-Step 4 — Produce the VP Assessment Report

```
## VP of Product Competency Assessment

**Candidate:** [name / role]
**Evaluator:** [name / role]
**Date:** [date]
**Assessment Type:** [hiring / performance review / promotion]

---

### Company Context
CEO profile: [visionary / not visionary]
Company stage: [Series A / B / C+ / public / other]
Organization size: [# PMs, # designers]
Implication for VP profile: [execution-oriented VP / visionary VP needed]

---

### Competency Scores

| Competency | Score | Summary Evidence |
|------------|-------|-----------------|
| Team Development | Strong / Developing / Absent | [1-2 sentences] |
| Product Vision and Strategy | Strong / Developing / Absent | [1-2 sentences] |
| Execution | Strong / Developing / Absent | [1-2 sentences] |
| Product Culture | Strong / Developing / Absent | [1-2 sentences] |
| Experience (secondary) | Strong / Developing / Absent | [1-2 sentences] |
| Chemistry (secondary) | Strong / Developing / Absent | [1-2 sentences] |

---

### Key Strengths
[2-3 bullet points with specific evidence]

### Key Gaps
[2-3 bullet points with specific evidence]

### Critical Risks
[Any red flags — e.g., no people development track record, CEO/VP vision profile mismatch, chemistry concerns]

---

### Recommendation
[Hire / Do not hire / Conditional hire with specific criteria] — [2-3 sentence rationale]

### If Hiring: First 90-Day Priorities
[2-3 specific areas to watch or support in the first quarter]

### If Not Hiring: Profile Clarification
[What the company should look for differently in the next candidate]
```

---

---

### Use Case B: Individual Contributor PM Assessment

Source: Ch10 (pp.41-48)

#### B-Step 1 — Diagnose the Working Mode

Before assessing competency, diagnose how the PM currently works. This determines whether the competency gaps are individual (can be developed) or structural (require organizational change).

There are three PM working modes. Only one leads to success:

| Mode | How to Identify | Root Cause | Outcome |
|------|----------------|-----------|---------|
| **Backlog Administrator** | Escalates every issue and decision to the CEO or manager; treats the job as managing a Jira backlog; works as a Certified Scrum Product Owner | CEO/manager has not given PM authority and decision-making power | Not scaling; CEO bottleneck |
| **Roadmap Administrator** | Calls stakeholder meetings and lets them fight it out; roadmap is set by committee (sales, support, executives); PM's job is to record decisions and write tickets | Organizational culture of design by committee; no PM empowerment | Mediocrity; rarely yields innovation |
| **Empowered PM** | Synthesizes customer knowledge, data, business constraints, and market context to make and own product decisions; accountable for outcomes | PM has authority and the four knowledge domains | The only mode that produces strong products |

**Diagnostic questions:**
- "Walk me through how the last significant product decision was made. Who was in the room? Who decided?"
- "When you and a key stakeholder disagree on a feature priority, what happens?"
- "How do you typically find out what to put in the backlog?"
- "What happens when engineering raises a concern about scope during sprint planning?"

If the PM is operating in Backlog Administrator or Roadmap Administrator mode, determine whether this is individual weakness or structural disempowerment before evaluating the four knowledge domains. A capable PM in a dysfunctional organization will still look like a weak PM.

---

#### B-Step 2 — Evaluate the Four Knowledge Domains

Score each domain: **Strong** (demonstrated depth), **Developing** (partial), **Absent** (gap).

WHY: These are the four things the PM is responsible for contributing to the team that no one else on the team provides. If the PM cannot bring these, the team will build the wrong things or fail to make good decisions.

---

**Domain 1 — Deep Knowledge of the Customer**

The PM must be an acknowledged expert on the actual users and customers: their issues, pains, desires, how they think, how they work (for business products), and how they decide to buy.

This is not optional — without this knowledge, every product decision is guessing.

Requires both:
- Qualitative learning: understanding *why* users and customers behave the way they do
- Quantitative learning: understanding *what* they are doing (usage data, conversion data, behavioral analytics)

The PM must also be an undisputed expert on the product itself.

Evidence to look for:
- Spends time regularly with actual users (not just internal proxies like sales or customer success)
- Can describe specific users by name with detailed empathy for their situation
- Has a systematic practice for staying current on customer behavior
- Their team trusts them as the definitive source of customer truth

---

**Domain 2 — Deep Knowledge of Data**

Product managers are expected to be comfortable with data and analytics: both quantitative and qualitative skills.

Evidence to look for:
- Starts the day reviewing analytics: sales data, usage data, A/B test results
- Can form and test hypotheses using product analytics without delegating the interpretation
- Uses data to challenge assumptions, including their own
- Understands the difference between correlation and causation in product data

Critical: analysis and understanding of data cannot be delegated. Having a data analyst help with queries is fine; having the analyst interpret what the data means for the product is not.

---

**Domain 3 — Deep Knowledge of Business**

Successful products are not only loved by customers — they also work for the business.

This is often the hardest domain for PMs, because it requires understanding:
- Who the key stakeholders are: general management, sales, marketing, finance, legal, business development, customer service
- What constraints each stakeholder operates under
- How the product creates and captures value in the business model

Evidence to look for:
- Can articulate the business constraints they are working within
- Has established trust with key stakeholders by demonstrating they understand and respect their constraints
- Has declined to build features that customers wanted but that would not work within business constraints
- Does not treat stakeholder management as a political obstacle; treats it as part of the job

---

**Domain 4 — Deep Knowledge of Market and Industry**

The PM must know the competitive landscape and the market trajectory — not just where the market is today, but where it will be tomorrow.

Evidence to look for:
- Monitors competitors regularly and understands their strengths, weaknesses, and strategy
- Tracks key technology trends relevant to their market
- Follows relevant industry analysts and understands the role of social media in their market
- Can articulate why feature parity with competitors is not sufficient (switching costs mean users need to be *substantially* better off to switch)
- Thinks about ecosystem fit — how the product fits into a broader ecosystem of tools and workflows

---

#### B-Step 3 — Evaluate the Three Core Traits

These are not skills that can be taught — they are characteristics the person either has or does not have. Passion for the product and for solving customer problems is the prerequisite; these traits determine whether that passion produces results.

| Trait | What It Means | How to Identify |
|-------|--------------|----------------|
| **Smart** | Intellectually curious; quickly learns and applies new technologies to solve problems, reach new audiences, or enable new business models. Not just raw intelligence — learning velocity. | Ask about a recent technology trend they explored. How deeply did they go? Did they connect it to a product opportunity? |
| **Creative** | Thinks outside the normal product feature box to solve business problems. Does not default to "add a feature" as the solution. | Ask about a problem they solved in a non-obvious way. How did they arrive at the solution? |
| **Persistent** | Pushes the company way beyond its comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance. | Ask about a time they were told no and kept going. What was the evidence they used? How did they communicate? Did they succeed? |

---

#### B-Step 4 — Assess Preparation and Development Readiness

A new PM needs approximately 2-3 months to get up to speed — but only if they have the right access:
- Regular access to customers (qualitative and quantitative)
- Access to data and the tools to access it
- Access to key stakeholders
- Time to learn the product and industry

If this access is not available, the onboarding timeline is meaningless. A PM cannot develop deep knowledge in isolation.

**Preparation roadmap for a developing PM (or self-assessment action plan):**

| Priority | Action | Target |
|----------|--------|--------|
| 1 | Become the customer expert | Share customer learnings openly with the team — become the company's go-to person for anything about the customer, quantitative and qualitative |
| 2 | Build stakeholder relationships | Convince each key stakeholder of two things: (1) you understand their constraints; (2) you will only bring solutions consistent with those constraints |
| 3 | Become the product and industry expert | Share knowledge openly and generously; be the person others ask about competitors and market trends |
| 4 | Build collaborative relationship with the team | Nurture the working relationship with design and engineering; make them want to work with you |

---

#### B-Step 5 — Produce the IC PM Assessment Report

```
## Individual Contributor PM Competency Assessment

**Person:** [name / role]
**Evaluator / Context:** [name / hiring / self-assessment / coaching]
**Date:** [date]

---

### Working Mode Diagnosis

Current mode: [Backlog Administrator / Roadmap Administrator / Empowered PM]
Evidence: [2-3 specific observations that indicate the mode]
Root cause: [individual gap / structural disempowerment / both]
Implication: [whether competency gaps are fixable through individual development or require organizational change first]

---

### Knowledge Domain Scores

| Domain | Score | Key Evidence | Primary Gap |
|--------|-------|-------------|-------------|
| Deep Knowledge of Customer | Strong / Developing / Absent | [observation] | [specific gap if any] |
| Deep Knowledge of Data | Strong / Developing / Absent | [observation] | [specific gap if any] |
| Deep Knowledge of Business | Strong / Developing / Absent | [observation] | [specific gap if any] |
| Deep Knowledge of Market and Industry | Strong / Developing / Absent | [observation] | [specific gap if any] |

---

### Core Traits Assessment

| Trait | Present / Partial / Absent | Evidence |
|-------|---------------------------|---------|
| Smart (learning velocity, technology curiosity) | | |
| Creative (non-obvious problem solving) | | |
| Persistent (pushes through resistance with evidence) | | |

---

### Strengths
[2-3 bullet points with specific evidence]

### Development Gaps
[2-3 bullet points with specific evidence and root cause]

---

### Recommendation
[Hire / Do not hire / Continue with development plan] — [2-3 sentence rationale]

### Development Plan (if applicable)
Ordered by priority:

| Priority | Domain/Trait | Current State | Target State | Actions | Timeline |
|----------|-------------|---------------|--------------|---------|----------|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |

### Onboarding Requirements (if new hire)
Access needed: [customers / data tools / stakeholders / product time]
Expected ramp time: 2-3 months with full access
Manager commitment required: [specific]
```

---

## Interpreting Results

**Working mode vs. individual competency:** A PM in Backlog Administrator mode may actually have strong knowledge domains — they are simply not permitted to apply them. Do not equate the working mode diagnosis with individual capability. An empowered PM in a dysfunctional organization looks weak; a weak PM in a supportive organization can look stronger than they are.

**The vision/execution mismatch for VP assessments:** The most common VP hiring failure is not evaluating the CEO's profile first. A visionary VP hired into a visionary CEO company will clash. An execution VP hired into a company with no product vision will leave a dangerous vacuum. The CEO profile assessment in A-Step 1 is not optional.

**Team development is the hardest competency to assess:** VP candidates often have strong individual contributor track records and poor people-development track records. Ask specifically about people they have developed — not just teams they have led. Look for concrete examples of someone struggling and the specific interventions used, not just successful team outcomes.

**Product culture is about concrete plans, not values:** Many VP candidates will say the right things about product culture. Press for concrete evidence: examples of how they instilled culture in a previous company, specific rituals or practices they used, what went wrong and how they corrected it. Vague values ("I believe in data-driven decisions") are not evidence.

**The chemistry criterion for VP assessments:** This is assessed last but is a veto. Strong competencies cannot compensate for a fundamental lack of personal rapport with the CEO and CTO. Build the dinner into the process.

---

## Reference

Detailed interview question banks and scoring rubrics:
`references/competency-interview-guide.md`

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Inspired How To Create Tech Products by Unknown.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/competency-interview-guide.md
# Competency Interview Guide

Supporting reference for `product-manager-competency-assessment` skill.
Source: INSPIRED, Ch10 (pp.41-48) and Ch17 (pp.79-83).

---

## VP of Product Interview Question Bank

### Team Development

Behavioral questions (look for specific examples, not general principles):
- "Tell me about someone on your team who was underperforming. What specifically did you do? What was the result?"
- "How do you identify product management talent that isn't obvious from a resume?"
- "Describe your approach to onboarding a new PM. What do you give them access to and in what order?"
- "Tell me about a PM you developed who went on to do something significant."
- "Have you ever had to manage out a PM? Walk me through how you approached that."
- "What's your framework for evaluating a PM's strengths and weaknesses in the first 90 days?"

Red flag responses:
- Only talks about team outcomes, not individual development
- Cannot name specific people they developed
- Conflates managing a team with developing individuals
- Has never had to address underperformance

---

### Product Vision and Strategy

For visionary CEO / execution VP profile:
- "Describe a situation where you were responsible for executing someone else's vision. What was hard about it?"
- "How do you stay aligned with a CEO who has strong product opinions?"
- "How do you translate a high-level founder vision into a product roadmap that engineering can actually build?"

For non-visionary CEO / visionary VP profile:
- "Walk me through a product vision you defined from scratch. How did you develop it? How did you get the team to believe in it?"
- "Tell me about a time the company lacked product direction and how you addressed it."
- "How do you create strategic coherence across multiple product teams?"

Both profiles:
- "Walk me through a significant strategic decision where you had to decline a stakeholder request."
- "How do you think about the relationship between your role and the CEO's product involvement?"

---

### Execution

- "Describe your product discovery process. What do you actually do before committing to build something?"
- "Tell me about a situation where you had major stakeholder conflict over the roadmap. How was it resolved?"
- "How do you keep engineering and design motivated when business constraints limit what you can build?"
- "What does your planning process look like at the start of a quarter?"
- "How have you scaled your execution approach as the organization grew?"
- "Tell me about a time you missed a significant delivery commitment. What happened and what did you change?"

---

### Product Culture

- "What does a strong product culture look like in practice? What specific behaviors would I observe in a week with your current team?"
- "Tell me about a time your team was significantly wrong about a product direction. How did you find out? What did you do?"
- "Describe your relationship with your engineering lead. Give me a specific example of a decision you made together."
- "What have you done in previous roles to build or change product culture? What worked? What did not?"
- "How do you handle it when the pressure to ship overrides the need to learn?"
- "What are your first 90 days focused on, culturally, if you join this company?"

---

### Chemistry Assessment

Format: informal dinner with CEO, CTO, and ideally head of marketing and head of design.
Duration: 2+ hours, not a structured interview.
Goal: determine personal rapport and whether working closely together would be comfortable for both parties.

Topics to make personal:
- Career path and what they are proud of
- What they find genuinely hard about the role
- What they care about outside of work
- How they handle disagreement in a close working relationship

---

## Individual Contributor PM Interview Question Bank

### Working Mode Diagnostic

- "Walk me through how the last significant product decision was made on your team. Who was involved? Who made the final call?"
- "When you and a key stakeholder disagree on a feature priority, what happens?"
- "How do you typically determine what to put in the backlog?"
- "Tell me about a time you pushed back on a feature request from sales or executive leadership. How did it go?"

---

### Domain 1 — Customer Knowledge

- "How do you stay current on what your users actually need? Walk me through what you did last week."
- "Tell me about a time you discovered something about your users that changed your product direction."
- "How do you balance qualitative user research with quantitative usage data?"
- "Describe a specific user of your product by name. What are their biggest frustrations with the current product?"
- "How do you establish yourself as the customer expert with your engineering team?"

---

### Domain 2 — Data

- "What did you look at in your analytics tools this morning?"
- "Walk me through an A/B test you ran. How did you design it? What did you learn?"
- "Tell me about a time your data analysis led you to a conclusion that was counterintuitive."
- "How do you distinguish between correlation and causation when looking at usage data?"
- "When have you disagreed with a data analyst's interpretation of product data? How did you resolve it?"

---

### Domain 3 — Business Knowledge

- "Who are your key stakeholders? Walk me through the constraints each of them operates under."
- "Tell me about a time you declined to build something a customer wanted because it did not work for the business."
- "How do you build trust with sales leadership when their priorities conflict with your roadmap?"
- "Explain how your product creates value for the business."

---

### Domain 4 — Market and Industry

- "Who are your top three competitors? What are they doing better than you right now?"
- "What is the most important technology trend affecting your market in the next two years? How is it changing what you need to build?"
- "Tell me about a time a competitor move surprised you. How did you respond?"
- "How do you think about ecosystem fit — how your product connects to other tools your customers use?"

---

### Smart, Creative, Persistent Trait Assessment

**Smart (learning velocity):**
- "Tell me about a new technology you explored in the last six months. How deeply did you go? Did it change anything about your product thinking?"
- "How do you learn new domains quickly when you are new to an industry or product area?"

**Creative:**
- "Tell me about a product problem where the obvious solution was to add a feature, but you solved it differently."
- "Walk me through the most creative product decision you have made."

**Persistent:**
- "Tell me about a time you were told no by leadership on something you believed in. What evidence did you gather? How did you communicate? What happened?"
- "Tell me about a time you had to get multiple functions aligned on a direction they were all resistant to. How did you do it?"

---

## Scoring Rubric

| Score | Criteria |
|-------|---------|
| **Strong** | Multiple specific examples with concrete outcomes; demonstrates the behavior as a consistent pattern, not a one-time event; the person can reflect critically on what worked and what did not |
| **Developing** | One or two examples with some specificity; behavior is present but inconsistent or limited in scope; candidate is aware of the gap and can articulate a development direction |
| **Absent** | No specific examples; describes aspirations or general principles rather than demonstrated behavior; or provides examples that actually illustrate the absence of the behavior |

---
name: product-discovery-risk-assessment
description: "Assess product risks and decide whether to build. Use when starting product discovery, evaluating a new feature or product idea, deciding which risks to validate first, choosing between prototyping and testing approaches, or when someone asks 'should we build this?' Maps any idea to the 4-risk taxonomy (value risk, usability risk, feasibility risk, business viability risk) plus ethics risk, sequences discovery by priority, and selects the right technique category for each risk. Also use when a team is unsure what to validate next, when structuring a discovery sprint, or when planning pre-build validation activities. Hub skill for all downstream discovery technique selection — for specific techniques, use discovery-framing-technique-selection, discovery-prototype-selection, value-testing-technique-selection, customer-discovery-program, or business-viability-stakeholder-testing instead."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-discovery-risk-assessment
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [33, 34]
tags: [product-management, product-discovery, risk-assessment]
depends-on: []
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Product idea, feature proposal, or initiative description"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Document-based product management environment"
discovery:
  goal: "Assess product risks and select appropriate discovery techniques"
  tasks:
    - "Identify which product risks (value/usability/feasibility/viability) apply to this idea"
    - "Select the right discovery technique category for each identified risk"
    - "Sequence discovery activities by risk priority"
    - "Flag ethics risk if applicable"
  audience:
    roles: [product-manager, product-leader, tech-lead, startup-founder]
    experience: any
  when_to_use:
    triggers:
      - "Starting product discovery for a new feature or product"
      - "Deciding which risks to validate first before building"
      - "Evaluating whether a product idea is worth pursuing"
      - "Structuring a discovery sprint or planning discovery activities"
    prerequisites: []
    not_for:
      - "Executing specific discovery techniques (use technique-specific downstream skills)"
      - "Post-build retrospectives or delivery planning"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: ""
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Product Discovery Risk Assessment

## When to Use

Apply this skill when you have a product idea, feature proposal, or initiative and need to decide:
- Which risks are present and how severe each is
- Which discovery technique categories to deploy
- In what sequence to run discovery activities

This is the **hub skill** for product discovery. Run it before any technique-specific discovery work. Downstream skills (framing technique selection, prototype selection, value testing, viability testing) consume the structured risk assessment this skill produces.

Do NOT use this skill to execute discovery techniques — it produces a plan, not the techniques themselves.

## Context and Input Gathering

Before running the assessment, collect:

1. **Product idea description** — What is the proposed solution or feature? One paragraph minimum.
2. **Target customer/user** — Who will use it? Buyer vs. user distinction matters.
3. **Business context** — How does this fit the company's revenue model, brand, legal environment?
4. **Team context** — What engineering, design, and product capabilities are on the team?
5. **Stage** — New product, new feature on existing product, or improvement to existing feature?

If a document exists (brief, PRD, opportunity assessment), read it. If not, ask the user to describe the idea before proceeding.

## Process

### Step 1: Classify the Idea by Stage and Novelty

Determine: Is this a new product, a new feature on an existing product, or an improvement to an existing feature?

**WHY:** Stage and novelty determine which risks are most acute. New products carry maximum value risk (customers don't yet choose to buy). Improvements to existing features have lower value risk but higher usability risk (existing users have established mental models to disrupt).

- New product → treat all 4 risks as potentially HIGH until evidence says otherwise
- New feature → value and usability risks are primary; feasibility and viability may be moderate
- Improvement → usability risk often dominates; value risk is lower but not zero

### Step 2: Score Each of the 4 Core Risks

For each risk, assign a severity: **Low / Medium / High / Unknown**.

**Risk 1 — Value Risk**
Question: Will customers choose to buy or use this?

Score High if:
- No direct evidence customers want this
- Customers have not asked for this (note: this is expected — customers often can't articulate what they want until they see it)
- Competing alternatives exist that solve the same underlying problem
- The value prop depends on behavior change

Score Low if:
- Existing customers have explicitly requested this capability AND you have validated they'll pay for or switch to use it
- A/B test or demand signal already exists

**WHY:** Value risk is consistently the hardest risk to address and the most common reason products fail. Most discovery time must be allocated here. A product with usability problems can survive; a product nobody values cannot.

**Risk 2 — Usability Risk**
Question: Can users figure out how to use this without help?

Score High if:
- The workflow is multi-step or requires user judgment
- The target user is not a technical expert in the problem domain
- Interaction design is novel (new UI patterns, voice, gesture)
- Errors are costly or hard to reverse

Score Low if:
- Workflow is a single well-understood action
- Users are power users already familiar with analogous tools

**WHY:** Even technically correct products fail if users cannot figure them out. Design skill and engineering skill are not interchangeable — and not every team has adequate design capacity. Usability must be validated with real users, not internal team members.

**Risk 3 — Feasibility Risk**
Question: Can the team build this within acceptable time, cost, and technical constraints?

Score High if:
- The solution requires technology the team has not used
- Significant scale or performance requirements exist
- Third-party integrations or data sources are unproven
- ML/AI components with uncertain quality thresholds are involved

Score Low if:
- The solution uses well-understood, in-production technology
- Engineering has already built analogous components

**WHY:** Feasibility must be validated during discovery — not at sprint planning. If engineers first see an idea at sprint planning, the team has already failed. Early engineer involvement during discovery also improves the solution itself and enables shared learning.

**Risk 4 — Business Viability Risk**
Question: Does this solution work for the business across all relevant dimensions?

Score High if any of the following are uncertain:
- Financial: Can we afford to build and provision it? Does the pricing model work?
- Sales: Can the sales force sell it?
- Marketing: Is it consistent with brand and go-to-market strategy?
- Legal: Are there regulatory, privacy, or contractual constraints?
- Business development: Does it work for existing partners?
- Executive: Will senior leadership support it?

Score Low if the solution is clearly within current business model, existing contracts, and established go-to-market motion.

**WHY:** Business viability must be validated during discovery — not after a product is built. Discovering a legal or financial blocker post-build destroys team morale and wastes engineering investment. Product managers own this risk, not just legal or finance.

### Step 3: Assess Ethics Risk (Fifth Risk)

Ethics risk is distinct from business viability. Ask:
- Could this solution cause harm to users, third parties, or the environment even if it is technically legal and meets business objectives?
- Does the solution optimize for a business metric (engagement, growth, monetization) in a way that produces harmful side effects?

If yes to either: flag as **Ethics Risk Present** and note the specific concern. When ethics risk is present, explore alternative solutions that solve the same underlying problem without the harmful side effect.

**WHY:** Technology capability does not imply ethical permission to build. Solutions can legally satisfy business objectives while harming users. The product manager's role is to identify ethics risks and bring potential alternative solutions to leadership — not to police, but to enable informed decisions.

### Step 4: Map Risks to Technique Categories

For each risk scored Medium or High, select the appropriate technique category. This mapping tells you which class of discovery activity to run.

| Risk | Technique Category | Purpose |
|------|--------------------|---------|
| Value (High) | **Framing** → then **Testing Value** | Clarify underlying problem first; then validate demand |
| Value (Medium) | **Testing Value** | Validate whether customers will choose this |
| Usability (High/Medium) | **Prototyping** → then **Testing Usability** | Build prototype; test with real users |
| Feasibility (High/Medium) | **Testing Feasibility** | Engineer-led feasibility spikes or proof-of-concept |
| Business Viability (High/Medium) | **Testing Business Viability** | Stakeholder review with legal, finance, sales, marketing |
| Ethics Risk Present | **Framing** + stakeholder review | Explore alternatives before committing to solution |
| All risks present | **Planning** techniques first | Use planning techniques to identify biggest challenges before committing to sequence |

**Technique Category Definitions** (for downstream skill selection):

- **Framing** — Clarifies the underlying problem before committing to a solution. Used when the problem is ambiguous or when handed a solution without a clear problem statement.
- **Planning** — Identifies the biggest challenges across the discovery effort and structures how to attack them. Used when multiple significant risks are present simultaneously.
- **Ideation** — Generates promising solutions aimed at the specific problem. Used after the problem is well-framed and when the current solution set is insufficient.
- **Prototyping** — Creates representations of solutions for testing. Four prototype types exist (detail in downstream skill: discovery-prototype-selection). Used before usability and value testing.
- **Testing** — Validates specific risks. Four sub-categories:
  - *Feasibility testing* — Engineer-led. Technology spikes, proof-of-concept, performance tests.
  - *Usability testing* — Designer-led. Interaction design validation with real users.
  - *Value testing* — Three modes: demand validation (will they buy?), qualitative value (do they see the value?), quantitative value (statistical evidence of value).
  - *Business viability testing* — PM-led. Stakeholder review across finance, legal, sales, marketing, brand, business development, and executive dimensions.

**WHY:** Different risks require different techniques and different team members to lead. Applying a usability test to a value problem wastes time. Applying a demand validation to a feasibility problem produces no useful signal. The mapping prevents mismatch between risk type and technique type.

### Step 5: Sequence Discovery Activities

Apply this sequencing logic:

1. **Framing first** — if value risk is High and the underlying problem is not yet clearly defined
2. **Value and usability validation before feasibility** — do not invest engineering time in feasibility spikes until there is evidence customers will use the solution
3. **Feasibility before deep prototyping** — if feasibility risk is High, validate technical viability before building high-fidelity prototypes
4. **Business viability throughout** — do not defer viability stakeholder review to the end; surface legal, financial, and sales concerns early
5. **Ethics review concurrent with framing** — flag and address ethics risk before committing significant discovery effort

**Exception:** If feasibility risk is so high it makes the idea technically impossible regardless of value, address feasibility first.

**WHY:** Validating value and usability first prevents expensive engineering feasibility work on solutions customers will not use. The sequencing reflects cost-of-being-wrong: value failure is cheap to discover; engineering failure after build is expensive.

### Step 6: Produce the Risk Assessment Document

Write a structured output (see Outputs section) that captures:
- Risk scores for all 4 core risks + ethics flag
- Selected technique categories per risk
- Recommended discovery sequence
- Iteration benchmark calibration

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| Product idea / feature description | Yes | What is being proposed |
| Target customer/user description | Yes | Who will use it and who will buy it |
| Business model context | Yes | Revenue model, pricing, distribution |
| Team capability summary | Recommended | Engineering, design, and PM capacity |
| Existing research or demand signals | Optional | Any prior customer interviews, surveys, or analytics |

## Outputs

### Output Template: Product Risk Assessment

```
# Product Risk Assessment: [Product/Feature Name]

## Idea Summary
[One paragraph description]

## Stage Classification
[ ] New product  [ ] New feature  [ ] Improvement to existing feature

## Risk Scores

| Risk | Score | Evidence / Rationale |
|------|-------|---------------------|
| Value | High / Medium / Low / Unknown | [Why] |
| Usability | High / Medium / Low / Unknown | [Why] |
| Feasibility | High / Medium / Low / Unknown | [Why] |
| Business Viability | High / Medium / Low / Unknown | [Why] |
| Ethics | Present / Not Present | [If present: specific concern] |

## Technique Category Mapping

| Risk | Technique Category | Lead | Priority |
|------|--------------------|------|----------|
| [Risk] | [Category] | PM / Designer / Engineer | 1-4 |

## Recommended Discovery Sequence

1. [First activity — technique category, who leads, what question it answers]
2. [Second activity...]
3. ...

## Iteration Benchmark
Target: 10-20 discovery iterations per week.
Each iteration = one new idea or approach tested.
Current gap to benchmark: [if team is new to modern discovery techniques, note this]

## Dependencies for Downstream Skills
- discovery-framing-technique-selection: [needed yes/no — value risk High]
- discovery-prototype-selection: [needed yes/no — usability risk High/Medium]
- value-testing-technique-selection: [needed yes/no — value risk Medium/High]
- business-viability-stakeholder-testing: [needed yes/no — viability risk Medium/High]
- customer-discovery-program: [needed yes/no — new product with unknown customers]
```

## Key Principles

These 10 principles from structured pre-build validation (product discovery) govern how this assessment is used:

1. **Customers cannot specify what to build** — Your job is to solve the underlying problem, not implement customer requests literally. Customers don't know what's possible; they can't describe solutions they haven't seen.
2. **Value is the hardest problem** — Without compelling value, no other quality matters. Spend most discovery time here.
3. **UX is harder than it looks** — Coming up with a good user experience is often harder and more critical than the engineering. Not every team has adequate design skill.
4. **Functionality, design, and technology are intertwined** — Not sequential. Technology enables design; design enables functionality. This is why product manager, designer, and engineer must work in proximity.
5. **Expect most ideas to fail** — Approach discovery with the assumption that many, possibly most, ideas won't work — or will require several iterations. This is not a failure; it is the discovery process working correctly.
6. **Validate on real users, not proxies** — Internal teams, friendly users, and customer research cannot substitute for testing actual ideas on real target users before building.
7. **Validate fast and cheap** — Discovery iterations should be at least an order of magnitude less time and effort than delivery iterations. Target: 10–20 discovery iterations per week.
8. **Validate feasibility during discovery** — Engineers must see ideas during discovery, not at sprint planning. Early engineer involvement improves solutions and enables shared learning.
9. **Validate business viability during discovery** — Legal, financial, sales, and executive constraints must be surfaced before building, not after.
10. **Shared learning over division of labor** — The team learns together. Shared context about customer pain, failed ideas, and successful approaches is what creates an empowered team (versus a feature-execution team).

## Examples

### Example 1: New AI-Powered Search Feature (SaaS B2B)

**Scenario:** A B2B SaaS company wants to add AI-powered semantic search to replace their existing keyword search. Engineering has proposed using a third-party LLM API.

**Risk Assessment:**
- Value: Medium — existing customers have complained about search quality, but it's unclear they'll pay more or switch usage patterns for semantic search
- Usability: Medium — semantic search behaves differently from keyword search; users may be confused when results don't match their query literally
- Feasibility: High — third-party LLM integration is unproven at the team's data scale; latency and cost per query are unknown
- Business Viability: Medium — LLM API costs could affect gross margin; legal has concerns about customer data being sent to a third party
- Ethics: Not present

**Technique Sequence:**
1. Testing Value (qualitative) — 5 customer interviews: do they see enough value to change search behavior?
2. Testing Feasibility — Engineering spike: can the LLM API meet latency and cost requirements at scale?
3. Testing Business Viability — Legal review of data processing agreement with LLM provider; finance model on per-query cost impact
4. Prototyping + Testing Usability — If value and feasibility clear, build low-fidelity prototype and run usability test with 5 target users

### Example 2: Mobile Onboarding Redesign (Consumer App)

**Scenario:** A consumer app wants to redesign its 7-step onboarding flow to reduce drop-off. Current completion rate is 34%.

**Risk Assessment:**
- Value: Low — the app already has validated demand; onboarding improvement is retention work, not value creation
- Usability: High — 66% of users are dropping out, direct evidence of severe usability failure
- Feasibility: Low — standard mobile UI components; no new technology required
- Business Viability: Low — no legal, financial, or sales constraints on onboarding design
- Ethics: Not present

**Technique Sequence:**
1. Framing — review existing analytics to identify which of the 7 steps has highest drop-off (clarify the specific problem before designing solutions)
2. Prototyping — build 2-3 prototype variants of the redesigned flow
3. Testing Usability — moderated usability test with 5 target users per variant
4. Testing Value (quantitative) — A/B test winning variant for statistical significance on completion rate

### Example 3: New Monetization Feature (Consumer Platform)

**Scenario:** A consumer platform wants to introduce a "boost" feature where users pay to increase visibility of their content.

**Risk Assessment:**
- Value: High — no evidence users will pay; paying for visibility is a new behavior for this user base
- Usability: Low — simple payment and toggle interaction
- Feasibility: Low — payment infrastructure already exists
- Business Viability: Medium — revenue model works, but marketing has concerns about brand perception; legal needs to review advertising regulations
- Ethics: **Present** — boosting visibility for paying users could harm non-paying users' reach and undermine trust in organic content quality

**Technique Sequence:**
1. Framing — clarify the underlying business problem (revenue growth) and explore alternative solutions that do not create a pay-to-win dynamic
2. Testing Business Viability — marketing brand review + legal advertising regulations review
3. Testing Value (demand) — if ethics risk can be mitigated, validate willingness to pay with target users before building
4. Prototyping + Testing Usability — only if value and viability clear

## References

- `references/four-risk-taxonomy.md` — Full definitions and scoring rubrics for all 4 core risks plus ethics risk
- `references/technique-categories.md` — Descriptions of all 5 technique categories and their 4 testing sub-categories
- `references/discovery-sequencing-logic.md` — Decision tree for sequencing discovery activities across risk combinations
- `references/discovery-principles.md` — Full elaboration of all 10 pre-build validation principles

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

---
name: product-culture-assessment
description: |
  Assess the product culture of a company or team across innovation capacity and execution strength. Use when a leader, founder, or product manager wants to understand where the organization sits on the innovation-execution spectrum and which cultural gaps to address. Also use when someone asks 'do we have a strong innovation culture?', 'why does our team ship fast but feel uncreative?', 'how do we build a culture like Amazon or Netflix?', 'are we a feature factory?', or 'I need to assess our product culture before proposing changes.' Scores 14 culture attributes (7 innovation + 7 execution), places the organization in one of four quadrants (Dreamers, Factories, Elite, Stalled), and produces a prioritized 90-day improvement roadmap. For diagnosing specific team-level dysfunctions (velocity, design integration, behaviors), use product-team-health-diagnostic instead. For waterfall process issues, use product-process-dysfunction-diagnosis instead.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/product-culture-assessment
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
model: sonnet
context: 200k
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Observations, notes, interview outputs, or a written description of how the team/company operates"
    - type: none
      description: "Skill can work from a verbal description of what the person observes in their organization"
  tools-required: []
  tools-optional: []
  environment: "No codebase access required; works from observations and descriptions"
source-books:
  - name: inspired-how-to-create-tech-products
    chapters: [67]
depends-on: []
tags: [product-management, organizational-culture, product-culture]
---

# Product Culture Assessment

## When to Use

Use this skill when you are:
- **Diagnosing stagnation** — the company ships reliably but hasn't had a breakthrough product idea in years
- **Diagnosing chaos** — the company has interesting ideas but they rarely make it to customers in a coherent form
- **Leading a culture change** — you need a baseline before setting improvement goals
- **Onboarding into a leadership role** — you want a structured read on what kind of culture you have inherited
- **Preparing for a retrospective** — your team wants to honestly assess what's working and what isn't
- **Evaluating an acquisition or partnership** — you need to understand how their culture will mesh with yours

Do not use this skill to replace qualitative leadership conversations or team surveys. It produces a structured analytical picture; the human layer of trust and context still matters.

---

## Framework: Two Dimensions of Product Culture

Cagan frames strong product culture across two independent dimensions. A company can be strong or weak on each independently.

**Dimension 1 — Innovation Culture:** Can this organization consistently discover and validate valuable solutions?

**Dimension 2 — Execution Culture:** Can this organization reliably ship and deliver on its commitments?

The goal is to be strong on both. Very few companies are.

---

## Step 1: Score the Innovation Culture Attributes

Score each attribute 1–5:
- **1** = This is not present. No evidence.
- **2** = Weak. Some individuals exhibit this, but it is not systemic.
- **3** = Moderate. Present in some teams or contexts but inconsistent.
- **4** = Strong. Most teams exhibit this most of the time.
- **5** = Exceptional. This is a defining organizational trait.

### I1 — Experimentation

**What it means:** Teams know they can run tests. Some experiments will succeed and many will fail, and this is understood and accepted — not punished.

**Diagnostic signals:**
- Teams regularly run A/B tests, prototypes, or spike experiments *before* committing to build
- Failed experiments are discussed openly without blame
- There is a mechanism and time budget for testing ideas quickly and safely
- Leaders reference failed experiments as learning, not waste

**Red flags:** All product work goes directly to engineering. Prototypes are rare or seen as "extra." Leaders ask for results, not learning.

**Score: ___/5**

---

### I2 — Open Minds

**What it means:** Teams know that good ideas can come from anywhere — customers, engineers, data, competitors — and are not always obvious at the outset.

**Diagnostic signals:**
- Ideas from engineers, support, sales, and customers are actively sought and evaluated
- Leaders don't just greenlight ideas that match their own prior beliefs
- The team questions their assumptions rather than defending initial positions
- Counterintuitive ideas get a fair hearing

**Red flags:** All product direction comes top-down. Engineers are told what to build with no opportunity to contribute ideas. Data that contradicts strategy is dismissed.

**Score: ___/5**

---

### I3 — Empowerment (Innovation)

**What it means:** Individuals and teams feel empowered to pursue and try out an idea — they don't need executive approval for every small experiment.

**Diagnostic signals:**
- Teams have dedicated time and budget to explore ideas
- Individuals can prototype something without a six-week approval cycle
- Leaders set outcomes, not prescribe solutions
- Teams feel ownership over discovery, not just delivery

**Red flags:** Every experiment requires sign-off. Teams wait for leadership to greenlight ideas. Product managers act as ticket-takers rather than problem-solvers.

**Score: ___/5**

---

### I4 — Technology Orientation

**What it means:** Teams recognize that true innovation can be inspired by new technology and data analysis, not just by listening to customers. Engineers are involved early in discovery — not handed specs.

**Diagnostic signals:**
- Engineers participate in customer discovery and problem definition
- Technology possibilities inform product direction (not just customer requests)
- Data analysis generates product hypotheses, not just dashboards
- The organization invests in engineer awareness of emerging technology

**Red flags:** Engineers are brought in only after the product is fully specified. Technology is treated as a cost center rather than a source of ideas. Discovery is solely the product manager's job.

**Score: ___/5**

---

### I5 — Business and Customer Savvy Teams

**What it means:** Teams — including developers — have a deep understanding of both the business context (constraints, revenue model, strategy) and the users and customers they are building for.

**Diagnostic signals:**
- Developers can articulate who the customer is and what problem the product solves
- Teams understand revenue, margins, and business constraints relevant to their work
- Teams have direct access to users and customers (not just through product managers)
- Business strategy is communicated broadly, not held only at leadership level

**Red flags:** Engineering teams don't know the customers. Business goals are hidden from teams. Customer access goes only through a few designated gatekeepers. Teams build features without knowing why they matter.

**Score: ___/5**

---

### I6 — Skill-Set and Staff Diversity

**What it means:** Teams appreciate that different skills and backgrounds — especially the combination of engineering, design, and product — contribute to innovative solutions.

**Diagnostic signals:**
- Product, design, and engineering are treated as equally important contributors
- Design is not a cost center or a finishing layer applied after engineering
- Teams include diverse perspectives and this is seen as a strength, not a management challenge
- Hiring reflects deliberate effort to balance and diversify skill sets

**Red flags:** Design is brought in at the end to "make it look good." All team members share the same background. Product managers are the only ones allowed to have product opinions.

**Score: ___/5**

---

### I7 — Discovery Techniques

**What it means:** The mechanisms are in place for ideas to be tested quickly and safely — protecting the brand, revenue, customers, and colleagues from the risk of unvalidated ideas going straight to production.

**Diagnostic signals:**
- Teams have an established set of discovery techniques (user interviews, prototypes, live-data tests)
- There is a shared vocabulary and practice for de-risking ideas before building
- Teams know how to test value risk, usability risk, feasibility risk, and business viability risk
- Experimentation infrastructure (feature flags, analytics, user research access) exists

**Red flags:** "Discovery" means writing a PRD and getting it approved. No shared toolbox for running quick tests. Every idea goes to a full sprint before getting any validation signal.

**Score: ___/5**

---

**Innovation Culture Score: ___/35**

| Range | Label |
|-------|-------|
| 28–35 | Strong innovation culture |
| 18–27 | Moderate — some capability, significant gaps |
| 7–17 | Weak innovation culture |

---

## Step 2: Score the Execution Culture Attributes

Use the same 1–5 scale.

### E1 — Urgency

**What it means:** People feel like they are operating in a high-stakes environment where slow movement has real consequences. This is not manufactured stress — it is a genuine sense that speed matters.

**Diagnostic signals:**
- Teams default to "what's the fastest way to learn or ship this?" not "what's the safest schedule?"
- Leaders convey why urgency matters without manufacturing false crises
- Blockers are removed fast; people don't wait weeks for decisions
- Teams feel the market and competitive pressure, not just internal process

**Red flags:** Teams estimate generous timelines with large buffers by default. Slow velocity is normalized. Urgency is manufactured as pressure rather than genuinely felt. No one feels consequences of delay.

**Score: ___/5**

---

### E2 — High-Integrity Commitments

**What it means:** Teams understand the value of commitments and insist on making them with integrity — meaning they commit to outcomes they genuinely believe are achievable, and they flag risk early rather than hiding it.

**Diagnostic signals:**
- Teams push back on unrealistic timelines and negotiate rather than just accept
- When teams commit, they mean it — commitments are not routinely broken
- Teams surface risks and blockers proactively, not on the day of the deadline
- Commitments are tracked and treated as genuine obligations, not aspirational goals

**Red flags:** Teams agree to everything asked of them, then miss most of it. Leadership sets dates without team input. Slipped commitments are consistently explained away. There is no culture of accountability for missing what was promised.

**Score: ___/5**

---

### E3 — Empowerment (Execution)

**What it means:** Teams feel they have the tools, resources, and permission to do whatever is necessary to meet their commitments — they are not blocked by bureaucracy when trying to deliver.

**Diagnostic signals:**
- Teams can make architectural decisions without committee approval
- Necessary tools, environments, and infrastructure are available
- Teams can resolve cross-team dependencies without escalating to leadership
- Blockers are cleared quickly; people don't feel like they need permission to act

**Red flags:** Teams routinely blocked waiting for approvals. Engineers can't deploy without a week-long release process. Simple decisions require escalation. Teams feel helpless in the face of cross-team dependencies.

**Score: ___/5**

---

### E4 — Accountability

**What it means:** People and teams feel a deep responsibility to meet their commitments. Accountability has consequences — not necessarily being fired, but consequences to reputation among peers when commitments are broken or avoided.

**Diagnostic signals:**
- Missed commitments are discussed honestly in retrospectives, not minimized
- There is peer pressure (constructive) to follow through on what was promised
- Leaders model accountability — they own failures as well as successes
- Repeated misses have real consequences for reputation and trust

**Red flags:** Missed commitments are consistently blamed on external factors. No one is ever held responsible. Poor performers are tolerated indefinitely. Accountability is treated as a management concept, not a team value.

**Score: ___/5**

---

### E5 — Collaboration

**What it means:** While team autonomy and empowerment are important, teams understand they must work together to accomplish the biggest and most meaningful objectives.

**Diagnostic signals:**
- Teams proactively share dependencies and coordinate across team boundaries
- There is a spirit of helping other teams unblock — not hoarding resources
- Leaders model cross-functional collaboration at the top
- Teams celebrate joint wins, not just individual team outcomes

**Red flags:** Teams optimize only for their own roadmap. Cross-team work is seen as a burden. Dependencies are discovered late. There is strong "silo" behavior. Teams blame each other for failures.

**Score: ___/5**

---

### E6 — Results Orientation

**What it means:** The focus is on outcomes — did this work actually move the needle for the customer and the business? — not outputs (did we ship the feature on time?).

**Diagnostic signals:**
- Teams track and review the actual impact of shipped work
- Product success is measured by business and customer outcomes, not delivery metrics
- Leaders ask "did it work?" not just "did it ship?"
- Teams feel embarrassed by features that shipped but had no impact

**Red flags:** Sprint velocity is the primary productivity metric. Teams are praised for shipping regardless of whether it worked. No post-launch reviews or outcome measurement. Features are never removed even when they clearly don't work.

**Score: ___/5**

---

### E7 — Recognition

**What it means:** Teams take their cues from what is rewarded and what is accepted. Recognition should reinforce both innovation (trying and learning) and execution (delivering on commitments) — not just one at the expense of the other.

**Diagnostic signals:**
- Teams that ship hard commitments are recognized and celebrated
- Teams that run smart experiments and learn — even when the result is "no" — are also recognized
- Missing commitments is not casually excused in ways that normalize it
- Recognition is consistent with the stated values of the organization

**Red flags:** Only the team with the most exciting new idea gets recognized. Execution teams feel invisible. Or conversely: only on-time delivery is celebrated and no one is recognized for discovery work. Recognition is random and disconnected from what the company says it values.

**Score: ___/5**

> **Fast-acting lever:** E7 (Recognition) is the highest-leverage culture attribute to change quickly. Leaders control recognition directly and immediately — no organizational restructuring required. If the assessment reveals a gap between stated values and what is actually celebrated, adjusting recognition patterns (in all-hands meetings, team updates, manager behavior) produces a visible cultural signal within weeks. Other attributes (E4 Accountability, I3 Empowerment) take quarters to shift. Start with E7 if you need early momentum.

---

**Execution Culture Score: ___/35**

| Range | Label |
|-------|-------|
| 28–35 | Strong execution culture |
| 18–27 | Moderate — some capability, significant gaps |
| 7–17 | Weak execution culture |

---

## Step 3: Plot the 2x2 Diagnostic Grid

Use the two dimension scores to place the organization in one of four quadrants.

```
                    EXECUTION CULTURE
                 Weak (7–17)    Strong (28–35)
               ┌──────────────┬──────────────┐
  Strong       │              │              │
  (28–35)      │  DREAMERS    │  ELITE       │
               │              │              │
INNOVATION     │ High idea    │ Amazon,      │
CULTURE        │ volume, low  │ Google,      │
               │ delivery.    │ Netflix.     │
               │ Chaos risk.  │ Rare.        │
               ├──────────────┼──────────────┤
  Weak         │              │              │
  (7–17)       │  STALLED     │  FACTORIES   │
               │              │              │
               │ Weak both.   │ Ship fast,   │
               │ Usually      │ wrong things.│
               │ legacy cos.  │ Feature      │
               │              │ factory risk.│
               └──────────────┴──────────────┘
```

### Quadrant Profiles

**ELITE (also: PIONEERS) — Strong Innovation + Strong Execution**
The rarest quadrant. These organizations have cracked both discovery and delivery. They innovate consistently and ship reliably. Examples: Amazon, Google (historically), Netflix. Behavioral signature: teams simultaneously run discovery experiments AND ship reliable commitments without tension between the two. Post-mortems happen for both failed experiments and missed deliveries. Note: these are often intense work environments. The combination of urgency, accountability, and experimentation creates pressure. Not everyone thrives here.

**DREAMERS — Strong Innovation + Weak Execution**
Strong ideation, weak delivery. The organization has good instincts and can generate interesting ideas, but struggles to ship them in a coherent and timely way. Common in early-stage startups and creative agencies. Behavioral signature: the backlog is full of half-validated ideas; commitments slip regularly; teams celebrate the idea more than the outcome. The risk: good ideas die in the delivery bottleneck, or ship so late the market has moved on.

**FACTORIES — Weak Innovation + Strong Execution**
The most common trap for established companies. Efficient at delivering what is asked of them, but the wrong things are being asked. Feature factories. Velocity is high, but the roadmap is driven by the loudest stakeholders rather than validated customer problems. Teams feel like order-takers. Behavioral signature: engineers are handed specs, not problems; discovery means writing a PRD; teams are evaluated on delivery metrics, not customer outcomes. Innovation capacity has atrophied.

**STALLED (also: DECLINING) — Weak Innovation + Weak Execution**
Often older companies that lost their product instincts long ago but have a strong brand or customer base to lean on. Behavioral signature: low urgency, low curiosity, low accountability — teams ship slowly AND the shipped work doesn't move metrics. The hardest to turn around because neither capability is present. Requires significant leadership change and culture investment.

---

## Step 4: Identify the Highest-Leverage Gaps

From the 14 individual attribute scores, identify the three lowest scores. These are the highest-leverage improvement opportunities.

### Prioritization Logic

- If you are in the **FACTORIES** quadrant: Innovation gaps are the priority. Look at I1 (Experimentation), I3 (Empowerment), I7 (Discovery Techniques) first.
- If you are in the **DREAMERS** quadrant: Execution gaps are the priority. Look at E2 (High-Integrity Commitments), E4 (Accountability), E6 (Results Orientation) first.
- If you are in the **STALLED** quadrant: Start with E3 (Execution Empowerment) and I3 (Innovation Empowerment) — both depend on teams feeling like they can actually act.
- If you are in the **ELITE** quadrant: Focus on sustaining. Look at which attributes dropped since last assessment and investigate root causes before they compound.

---

## Step 5: Produce the Assessment Output

Deliver a structured report with the following sections:

### 1. Culture Scores Summary

| Attribute | Score |
|-----------|-------|
| I1 — Experimentation | /5 |
| I2 — Open Minds | /5 |
| I3 — Empowerment (Innovation) | /5 |
| I4 — Technology Orientation | /5 |
| I5 — Business & Customer Savvy | /5 |
| I6 — Skill-Set Diversity | /5 |
| I7 — Discovery Techniques | /5 |
| **Innovation Total** | **/35** |
| E1 — Urgency | /5 |
| E2 — High-Integrity Commitments | /5 |
| E3 — Empowerment (Execution) | /5 |
| E4 — Accountability | /5 |
| E5 — Collaboration | /5 |
| E6 — Results Orientation | /5 |
| E7 — Recognition | /5 |
| **Execution Total** | **/35** |

### 2. Quadrant Placement

State clearly which quadrant the organization is in and what that means for the improvement agenda.

### 3. Top Three Gaps

For each of the three lowest-scoring attributes:
- What is missing (specific behavioral evidence)
- Why it matters for the organization's goals
- One concrete first action to start closing the gap

### 4. Strengths to Protect

Identify 2–3 attributes that scored highest. These represent existing cultural assets that improvement efforts should not inadvertently erode.

### 5. Recommended Focus for the Next 90 Days

A single-sentence framing of the most important cultural shift to make, given quadrant position and the specific gap pattern identified.

---

## Anti-Patterns: Culture Change Theater

When organizations attempt to improve product culture, they frequently adopt surface-level practices that mimic the behaviors of high-performing cultures without addressing the underlying conditions. These anti-patterns produce the appearance of change while the actual culture stays the same. Flag them when assessing improvement plans.

**Cargo cult innovation** — Running hackathons, design sprints, or "innovation days" without actually empowering teams to pursue validated ideas afterward. The hallmark: ideas generated in innovation events are never resourced or followed up. Teams learn quickly that the event is theater; it doesn't change what gets built. A team that can run an experiment every quarter but cannot greenlight any result scores low on I3 (Empowerment) regardless of how many hackathons it hosts.

**Process theater** — Adopting Agile ceremonies (stand-ups, retrospectives, sprint planning) without product discovery. Teams run two-week sprints and hold retrospectives, but the work going into the sprints was handed to them as a feature list. Discovery — the work of figuring out what to build — never happens. The ceremonies create the appearance of an empowered, modern team. The actual work model is waterfall with shorter release cycles. Scores low on I7 (Discovery Techniques) and I3 (Empowerment) despite high ceremony adoption.

**Values-recognition gap** — The company posts its values on the wall ("customer obsession," "move fast," "own the outcome") but recognizes and rewards the opposite (shipping on time, avoiding visible failure, deferring to leadership). This is the most reliable diagnostic signal that E7 (Recognition) is broken: ask teams what behaviors actually get people promoted or praised, then compare to stated values.

---

## Reference

See `references/culture-attribute-definitions.md` for the full definitions of all 14 attributes as described by Cagan.

---

## References

- Cagan, Marty. *INSPIRED: How to Create Tech Products Customers Love*, 2nd ed. Wiley, 2018. Chapter 67.

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Inspired How To Create Tech Products by Unknown.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/culture-attribute-definitions.md
# Culture Attribute Definitions

Source: INSPIRED by Marty Cagan, Chapter 67 — "Establishing a Strong Product Culture"

---

## Innovation Culture Attributes

Cagan's framing: "What does it really mean to have a strong innovation culture?"

### I1 — Experimentation
"Culture of experimentation — teams know they can run tests; some will succeed and many will fail, and this is acceptable and understood."

### I2 — Open Minds
"Culture of open minds — teams know that good ideas can come from anywhere and aren't always obvious at the outset."

### I3 — Empowerment (Innovation)
"Culture of empowerment — individuals and teams feel empowered to be able to try out an idea."

### I4 — Technology Orientation
"Culture of technology — teams realize that true innovation can be inspired by new technology and analysis of data, as well as by customers."

### I5 — Business and Customer Savvy Teams
"Culture of business- and customer-savvy teams — teams, including developers, have a deep understanding of the business needs and constraints, and understanding of (and access to) the users and customers."

### I6 — Skill-Set and Staff Diversity
"Culture of skill-set and staff diversity — teams appreciate that different skills and backgrounds contribute to innovative solutions — especially engineering, design, and product."

### I7 — Discovery Techniques
"Culture of discovery techniques — the mechanisms are in place for ideas to be tested out quickly and safely (protecting brand, revenue, customers, and colleagues)."

---

## Execution Culture Attributes

Cagan's framing: "What does it really mean to have a strong execution culture?"

### E1 — Urgency
"Culture of urgency — people feel like they are in wartime, and that if they don't find a way to move fast, then bad things could happen."

### E2 — High-Integrity Commitments
"Culture of high-integrity commitments — teams understand the need for (and power of) commitments, but they also insist on high-integrity commitments."

### E3 — Empowerment (Execution)
"Culture of empowerment — teams feel as though they have the tools, resources, and permission to do whatever is necessary to meet their commitments."

### E4 — Accountability
"Culture of accountability — people and teams feel a deep responsibility to meet their commitments. Accountability also implies consequences — not necessarily being terminated, except in extreme and repeated situations, but more likely consequences to their reputations among their peers."

### E5 — Collaboration
"Culture of collaboration — while team autonomy and empowerment is important, teams understand their even higher need to work together to accomplish many of the biggest and most meaningful objectives."

### E6 — Results Orientation
"Culture of results — is the focus on output or is the focus on results?"

### E7 — Recognition
"Culture of recognition — teams often take their cues from what is rewarded and what is accepted. Is it just the team that comes up with the great new idea that gets rewarded, or the team that delivered on a brutally tough commitment? And what is the message if missing a commitment is seen as easily excusable?"

---

## The 2x2 Grid

Cagan describes four quadrant profiles based on the two dimensions:

- **Strong both:** Amazon is cited as the best example of consistent innovation and execution strength. Also Google, Netflix. Noted as rare. Also noted as "not for the faint of heart" — strong execution cultures tend to be intense work environments.
- **Strong execution / weak innovation:** Many established companies. Good at delivering, but not innovating. Feature factory risk.
- **Strong innovation / weak execution:** Some companies are strong at innovation and "just okay" at execution.
- **Weak both:** "A depressing number of companies are poor at both innovation and execution — usually older companies that lost their product mojo a long time ago, but still have a strong brand and customer base to lean on."

Cagan's call to action: "Assess yourself along these dimensions of innovation and execution, and then ask yourselves where you would like to be, or think you need to be, as a team or company."

---
name: discovery-prototype-selection
description: "Select the right prototype type and fidelity level for any discovery risk. Use when deciding what kind of prototype to build, when choosing between a feasibility spike, user prototype, live-data prototype, or Wizard of Oz prototype, or when someone asks 'what prototype should we build?' Also use when prototyping for usability testing, when validating a technical approach before building, when building a simulation for stakeholder alignment, or when an AI/ML feature needs pre-model validation. Maps the active risk (feasibility/usability/value/viability) to one of four prototype types and determines fidelity. Includes anti-pattern warnings for ambush estimation and prototype-as-value-proof confusion. Best triggered after product-discovery-risk-assessment. For executing usability or value tests after the prototype, use value-testing-technique-selection."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/discovery-prototype-selection
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [45, 46, 47, 48, 49, 55]
tags: [product-management, product-discovery, prototyping]
depends-on: [product-discovery-risk-assessment]
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Risk assessment output from product-discovery-risk-assessment, or description of the risk being addressed"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Document-based product management environment"
discovery:
  goal: "Select the right prototype type and fidelity for the active risk, then guide its creation"
  tasks:
    - "Identify which risk is being addressed (feasibility/usability/value/viability)"
    - "Select the matching prototype type"
    - "Determine correct fidelity level for the testing purpose"
    - "Identify who creates the prototype and what constraints apply"
    - "Flag anti-patterns before creation begins"
  audience:
    roles: [product-manager, product-designer, tech-lead, startup-founder]
    experience: any
  when_to_use:
    triggers:
      - "Risk assessment has identified prototyping as a required technique"
      - "Deciding which prototype approach to use for a discovery question"
      - "Team is about to build a prototype and needs to align on type and fidelity"
      - "Evaluating whether to use a user prototype, feasibility spike, or live-data experiment"
    prerequisites:
      - "product-discovery-risk-assessment completed (or risk explicitly identified)"
    not_for:
      - "Executing usability tests (prototype is an input to testing, not the test itself)"
      - "Value testing — user prototypes do not validate value; use value-testing techniques after prototyping"
      - "Delivery work — feasibility prototypes are discovery code, not production code"
  environment:
    codebase_required: false
    codebase_helpful: true
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: ""
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Discovery Prototype Selection

## When to Use

Apply this skill when a risk assessment has identified prototyping as a needed technique, or when the team needs to decide which prototype approach to use. This skill answers three questions:

1. Which prototype type matches the risk being addressed?
2. What fidelity level is appropriate for the testing purpose?
3. Who creates it, and what constraints apply?

Run this before building any prototype. The wrong prototype type wastes significant time — a user prototype cannot answer a feasibility question, and a feasibility prototype cannot answer a usability question.

## Governing Principles

Five principles apply to all prototype types. Violating any of them is a common source of wasted effort.

**Principle 1 — Cost of learning, not cost of building.** The overarching purpose of any prototype is to learn something at a much lower cost in time and effort than building a product. All forms of prototype should require at least an order of magnitude less time and effort than the eventual product. If a prototype is taking as long as shipping would, it has become delivery work.

**Principle 2 — Creation forces depth.** Creating a prototype forces the team to think through a problem at a substantially deeper level than talking about it or writing a document. This is why the act of creating a prototype so often exposes major issues otherwise left uncovered until much later. Do not skip prototyping in favor of documents or meetings.

**Principle 3 — Shared understanding tool.** A prototype is a powerful tool for team collaboration and stakeholder alignment. Members of the product team and business partners can all experience the prototype to develop shared understanding. Use prototypes in stakeholder reviews, not just user tests.

**Principle 4 — No single correct fidelity.** There is no such thing as one appropriate level of fidelity. The right level depends entirely on the testing purpose. Lower fidelity is faster and cheaper than higher fidelity. Only do higher fidelity when the testing purpose requires it.

**Principle 5 — Prototypes are disposable.** The primary purpose of a prototype is to address product risks in discovery. The prototype itself is not the product. Feasibility prototypes are throwaway code. User prototypes are simulations. Live-data prototypes are not commercially shippable. Treat all of them as disposable.

> **Critical warning — Prototype does not equal value validation.** A user prototype — even a high-fidelity one that 15 users say they "love" — does not validate value. User prototypes test usability and comprehension. They cannot prove purchase intent, retention, or behavioral change. People say all kinds of things when looking at a prototype and then do something completely different when real money or real effort is required. If the team needs to validate value, use a dedicated value-testing technique (demand validation, fake door test, live-data prototype with real behavior measurement) after — not instead of — usability testing. This is one of the most common and expensive mistakes in product discovery.

## Process

### Step 1: Identify the Risk Being Addressed

Read the risk assessment output. Determine which risk the prototype is meant to address:

- **Feasibility risk** — Can the team build this at all? (algorithm, performance, scalability, unfamiliar technology, third-party integration, legacy system, cross-team dependency)
- **Usability risk** — Can users figure out how to use this? (workflow complexity, novel interaction, multi-step process, error-prone operations)
- **Value risk (qualitative)** — Do users understand and respond to the value proposition when they see it? (distinct from demand validation — this tests comprehension and perceived value)
- **Viability risk** — Does this work for the business? (requires stakeholder review using prototype as communication tool)

**WHY:** Each risk requires a different prototype type. Mismatching the prototype to the risk produces invalid signal. A user prototype cannot tell you if an algorithm will work. A feasibility prototype cannot tell you if a workflow is learnable.

If multiple risks are present, select the prototype type that addresses the highest-priority risk first. Run multiple prototypes in sequence if necessary — do not try to address all risks with one prototype.

### Step 2: Select the Prototype Type

Use this decision table:

| Risk Being Addressed | Prototype Type | Creator | Output |
|---|---|---|---|
| Feasibility | Feasibility prototype | Engineer(s) | Working code demonstrating the approach |
| Usability | User prototype | Designer | Simulation (interactive wireframe to high-fidelity mock) |
| Value (qualitative, perceived) | User prototype (high fidelity) | Designer | Realistic simulation for qualitative testing |
| Value (quantitative, behavioral) | Live-data prototype | Engineer(s) | Limited real implementation collecting analytics |
| Automation / AI / ML viability + UX simultaneously | Hybrid prototype — Wizard of Oz | Designer + Engineer | Human operator simulates the automated behavior behind a realistic UI |
| Stakeholder alignment | User prototype | Designer | Communication artifact showing what will be built |

**Wizard of Oz prototype (Hybrid variant for AI/ML features):** When the team is validating whether an AI- or automation-powered feature would be valuable and usable before the model or automation exists, a human operator manually performs the automated action in real time while the user interacts with a realistic front-end. The user does not know a human is behind the curtain. This technique answers both value and usability questions for features that would be difficult or slow to build as live-data prototypes (because the model doesn't exist yet). Constraint: only works at very small scale — one session at a time, manually operated. Never use for quantitative validation.

See `references/prototype-type-details.md` for full descriptions of each type, their limitations, and canonical use cases.

### Step 3: Determine Fidelity

For user prototypes, fidelity is the primary variable. Apply this fidelity rule:

| Testing Purpose | Required Fidelity | Rationale |
|---|---|---|
| Value testing (qualitative: does the user perceive value?) | High | Must feel realistic; if users can tell it is fake, their reactions are not valid. People say all kinds of things about low-fi prototypes and then do something different. |
| Usability testing (can they complete the workflow?) | Low to medium acceptable | Information architecture and workflow are testable even without visual polish. |
| Demand validation (will they buy or sign up?) | Live-data or fake door | A user prototype cannot prove purchase behavior. Use live-data prototype or a fake door (demand test). |
| Stakeholder communication | Medium to high | Stakeholders need to experience the product concept clearly. |
| Team alignment / internal exploration | Low | Speed matters more than realism for internal thinking. |

**WHY:** Fidelity is a cost dial. High-fidelity user prototypes take significantly more time to create. Only spend that time when the testing purpose actually requires realism. For usability testing, a low-fidelity prototype is often more than adequate and faster to iterate.

For feasibility prototypes, fidelity is irrelevant — they are code with no user interface, no error handling, and no polish. Write just enough code to answer the feasibility question.

For live-data prototypes, include only the instrumentation needed for the specific use cases being measured. Do not build full analytics infrastructure.

### Step 4: Confirm Creator and Constraints

**Feasibility prototype:**
- Created by: one or more engineers (not designers, not product managers)
- Typical time: one to two days for most questions; longer for major new technology (machine learning, novel algorithms)
- Constraint: this is discovery code — throwaway. No productization judgment from the product manager. If engineers need to productize, they must be given full delivery time.

**User prototype:**
- Created by: designer (primary); some designers prefer to hand-code high-fidelity prototypes — acceptable if fast and treated as disposable
- Tools: standard prototyping tools (Figma, Framer, etc.) or hand-coded
- Constraint: this is a simulation. There is nothing behind the curtain. No real data, no real transactions. Do not show user prototype results as proof of value.

**Live-data prototype:**
- Created by: engineer(s) — designers cannot create this
- Typical scope: 5–10% of eventual productization effort
- Constraint: not commercially shippable. Explicitly communicate this to executives and stakeholders. The product manager does not decide when this is "good enough" — that judgment belongs to the engineers when they productize.

**Hybrid prototype:**
- Created by: designer (front-end simulation) + engineer or team member operating the backend manually
- Constraint: not scalable — never send significant traffic to a Wizard of Oz prototype. Its value is qualitative learning, not quantitative proof.

### Step 5: Check Anti-Patterns Before Proceeding

Before creating a feasibility prototype, check for these two anti-patterns:

**Anti-pattern: Ambush estimation.** Demanding that engineers provide time or effort estimates in a planning meeting, without giving them time to investigate, produces conservative and inflated answers. Engineers put on the spot without investigation time will give answers designed to make the questioner go away. The correct question is not "Can you do this?" but "What is the best way to do this and how long would it take?" — and only after giving engineers time to investigate. If the answer is a feasibility prototype, encourage them to proceed.

**Anti-pattern: Feasibility-averse product management.** Product managers who hate any idea that requires engineering investigation systematically kill the most innovative product ideas. Many of the best product ideas are based on approaches that are only now possible — which means new technology and investigation time. When engineers say they need a day or two to investigate, treat it as an opportunity, not a liability. Engineers given even a day or two often come back not only with answers to the feasibility question but also with better ways to solve the problem.

Before creating a user prototype, check for this anti-pattern:

**Anti-pattern: Prototype-as-validation confusion.** Showing a high-fidelity user prototype to 10–15 people who say they love it does not validate value. People say all kinds of things and then do something different. A user prototype is not good for proving anything — including whether a product will sell. Use separate value testing techniques (demand validation, quantitative value testing) after usability is confirmed. The user prototype is the input to usability testing and stakeholder alignment, not the output of value validation.

### Step 6: Document the Prototype Plan

Write a brief prototype plan (one page or less) capturing:

```
# Prototype Plan: [Feature / Product Name]

## Risk Being Addressed
[Feasibility / Usability / Value-qualitative / Viability]

## Prototype Type Selected
[Feasibility / User / Live-Data / Hybrid]
Rationale: [one sentence]

## Fidelity Level (for user prototypes)
[Low / Medium / High]
Rationale: [testing purpose requires X]

## Creator
[Engineer(s) / Designer / Both]
Estimated time: [X days]

## What Question This Prototype Answers
[Specific, testable question — e.g., "Can we achieve sub-200ms response time with this algorithm?" or "Can a new user complete account setup without help?"]

## What This Prototype Cannot Answer
[List what will NOT be learned — important for setting expectations]

## Anti-Pattern Check
[ ] No ambush estimation applied to engineers
[ ] Team understands this prototype does not validate value
[ ] Prototype is scoped to just enough to answer the question
[ ] Prototype is treated as disposable

## Next Step After Prototype
[Usability test / Feasibility go/no-go decision / Quantitative value test / Stakeholder review]
```

## Outputs

- Prototype plan document (per template above)
- Prototype artifact (created by engineer or designer per type)
- Anti-pattern check completed and documented

## Key Principles Summary

| Principle | What It Means in Practice |
|---|---|
| Learn at fraction of cost | If prototype takes as long as shipping, it has become delivery |
| Creation forces depth | Build the prototype even when discussion feels sufficient |
| Shared understanding | Use prototypes in stakeholder reviews, not just user tests |
| Right fidelity, not one fidelity | Value testing → high fi; usability → low/medium fi acceptable |
| Prototypes are disposable | Discovery code is not production code; simulations are not products |

## References

- `references/prototype-type-details.md` — Full descriptions of all four prototype types, canonical use cases, limitations, and creation guidance
- `references/fidelity-decision-guide.md` — Fidelity selection decision tree with examples across product types
- `references/feasibility-testing-questions.md` — The 10 feasibility questions engineers answer in discovery (Ch55) and how to structure engineer-led investigation

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

Install related skills from ClawhHub:
- `clawhub install bookforge-product-discovery-risk-assessment`

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/feasibility-testing-questions.md
# Feasibility Testing Questions

Source: INSPIRED by Marty Cagan, Chapter 55 (Testing Feasibility)

## The 10 Feasibility Questions Engineers Answer in Discovery

When engineers validate feasibility in discovery, they are trying to answer a set of related questions about whether and how the team can build a proposed solution:

1. **Do we know how to build this?** — Does the technical approach exist and is it understood?
2. **Do we have the skills on the team to build this?** — Are the required engineering capabilities present?
3. **Do we have enough time to build this?** — Within acceptable constraints, can this be delivered?
4. **Do we need any architectural changes to build this?** — Will this require significant platform or infrastructure changes?
5. **Do we have on hand all the components we need to build this?** — Are required libraries, services, and building blocks available?
6. **Do we understand the dependencies involved in building this?** — Are cross-team or cross-system dependencies identified and manageable?
7. **Will the performance be acceptable?** — Will the solution meet latency, throughput, or response time requirements?
8. **Will it scale to the levels we need?** — Can the solution handle the expected load?
9. **Do we have the infrastructure necessary to test and run this?** — Are the required environments and tooling available?
10. **Can we afford the cost to provision this?** — Are the operational costs (compute, storage, API costs, etc.) acceptable?

Most of the time, engineers will review product ideas in discovery and quickly say "No problem" — because most work is not all that new, and engineers have typically built similar things before.

Feasibility investigation is needed when one or more of these questions cannot be answered quickly.

---

## How to Structure Engineer-Led Feasibility Investigation

**The right question to ask:** Not "Can you do this?" but "What is the best way to do this, and how long would it take?" The first question invites a binary yes/no that puts engineers on the spot. The second question opens an investigation and invites engineering judgment.

**Give engineers time to investigate.** Holding a planning meeting and demanding instant estimates on ideas engineers have not had time to consider will produce conservative, inflated answers designed to make the questioner go away. Ambush estimation is a named anti-pattern (see main skill).

**Engineers who have been following discovery will estimate better.** If engineers have been present during discovery — watching users try prototypes, understanding the problems being solved — they will have already been thinking about feasibility for some time. Their estimates will be more accurate because they have context. This is another reason why engineers belong in discovery, not just delivery.

**When engineers say they need a feasibility prototype:** First consider whether the idea is potentially worth the necessary investigation time in discovery. If so, encourage engineers to proceed. The feasibility prototype answers the question; the product manager then decides whether to pursue the approach.

**What engineers produce:** A feasibility prototype — throwaway code that answers the specific feasibility question. No user interface, no error handling, no productization work. Just enough code to demonstrate whether the approach is viable.

---

## Feasibility Anti-Patterns

### Anti-pattern: Ambush Estimation

**What it looks like:** The product manager presents a list of ideas at a weekly planning meeting and asks engineers to estimate them in time or story points on the spot.

**Why it fails:** Engineers put on the spot without investigation time give conservative answers partly designed to make the questioner go away. The estimate is not a real estimate — it is a defensive answer. The team then makes decisions based on inflated numbers, systematically undervaluing complex but high-impact ideas.

**Correct approach:** Ask engineers "What is the best way to do this and how long would it take?" — and give them time to actually investigate before expecting an answer. If investigation requires a feasibility prototype, support that.

### Anti-pattern: Feasibility-Averse Product Management

**What it looks like:** The product manager refuses or avoids any product idea that engineers say requires time to investigate. The product manager treats "needs investigation" as equivalent to "too risky" and filters out these ideas systematically.

**Why it fails:** Many of the best product ideas are based on approaches that are only now possible — which means new technology that engineers need time to learn and evaluate. A product manager who avoids all such ideas systematically kills innovation. The most innovative opportunities are frequently the ones that require investigation because they are genuinely new.

**Three reasons to embrace feasibility investigation:**
1. Many best product ideas are based on newly possible technology — which by definition requires investigation time.
2. Engineers given even one or two days to investigate often return not just with feasibility answers but with better ways to solve the problem.
3. Feasibility investigation is often highly motivating for engineers — it gives them opportunity to learn and shine.

**Correct approach:** When engineers say they need time to investigate, treat it as an opportunity signal, not a risk signal. Evaluate whether the idea is worth the investigation time. If yes, encourage investigation.

FILE:references/fidelity-decision-guide.md
# Fidelity Decision Guide

Source: INSPIRED by Marty Cagan, Chapters 45 and 47

## Core Principle

There is no such thing as one appropriate level of fidelity for a prototype. Fidelity primarily refers to how realistic the prototype looks. The principle is to create the right level of fidelity for the intended purpose, knowing that lower fidelity is faster and cheaper than higher fidelity — so only do higher fidelity when you need to.

## Decision Tree

**What is the testing purpose?**

### 1. Value testing (qualitative) — "Does the user perceive value when they see this?"

Required fidelity: **High**

Why: Value perception depends on realism. If users can tell the prototype is fake — through low-quality visuals, placeholder data, or missing interactions — their reactions are not valid signal. People react to what they actually see and experience. A low-fidelity prototype triggers "this doesn't look real" responses that contaminate the value signal. High fidelity is required so users can genuinely assess whether they would want this product.

Warning: Even high-fidelity user prototypes cannot prove purchase behavior. They test perceived value — "this seems useful" — not behavioral value — "I will pay money for this." Do not mistake positive reactions to a high-fidelity prototype for validated demand.

### 2. Usability testing — "Can the user complete the workflow without help?"

Acceptable fidelity: **Low to medium**

Why: Usability testing is primarily about information architecture, workflow sequencing, and interaction clarity — not visual design. A low-fidelity prototype (interactive wireframe) is often more than adequate for identifying where users get stuck, what labels confuse them, or where the workflow breaks down. Moving to high fidelity before resolving major usability issues wastes time on polish that may be discarded.

Exception: If the usability question involves visual design specifically (e.g., "is the call-to-action button visible?"), medium to high fidelity may be needed.

Low-fidelity prototypes do not capture:
- The impact of visual design on user confidence
- Differences caused by actual data (vs. placeholder content)
- The impact of visual hierarchy on attention

If those dimensions matter for the usability question, increase fidelity accordingly.

### 3. Demand validation — "Will users buy or sign up for this?"

Required approach: **Live-data prototype or fake door (demand test) — not a user prototype**

Why: A user prototype is a simulation. It cannot generate real behavioral data. Showing a user prototype to users and asking "would you buy this?" produces stated preference, not revealed preference. People say all kinds of things and then do something different. Demand validation requires users to actually take an action with real consequences — visiting a real landing page, attempting a real sign-up, or clicking a real "buy" button. A live-data prototype or demand-testing technique is the right tool for this, not a user prototype at any fidelity level.

### 4. Stakeholder communication — "Does leadership understand and support what we are building?"

Acceptable fidelity: **Medium to high**

Why: Stakeholders and business partners need to experience the product concept clearly enough to make decisions. A low-fidelity wireframe often fails to communicate the vision — stakeholders struggle to project what the finished product will look and feel like. Medium to high fidelity bridges this gap. The prototype does not need to be pixel-perfect, but it needs to be representative enough that stakeholders can give informed feedback and alignment.

### 5. Internal team alignment — "Are we all thinking about the same thing?"

Acceptable fidelity: **Low**

Why: For internal team thinking, speed matters more than realism. Creating a prototype (even a low-fidelity one) forces the team to think through the problem at a substantially deeper level than talking about it. Low-fidelity prototypes expose major issues that would otherwise remain hidden in conversations. Create quickly; iterate quickly.

---

## Fidelity by Prototype Type

| Prototype Type | Fidelity Concept | Notes |
|---|---|---|
| Feasibility | Not applicable | It is code, not a UI simulation |
| User (low) | Interactive wireframe | Fast; tests workflow, not visual design |
| User (medium) | Styled but not pixel-perfect | Balances speed and realism |
| User (high) | Looks and feels real | Required for value testing |
| Live-data | Actual implementation | Real data, limited scope, real users |
| Hybrid / Wizard of Oz | High visual fidelity + human backend | Looks real; backend is manual |

---

## Common Fidelity Mistakes

**Starting with high fidelity when low would suffice.** Teams that jump to high-fidelity prototypes for early usability testing spend time on polish before resolving fundamental workflow issues. Iterate at low fidelity until the workflow is sound, then increase fidelity for value testing.

**Using low fidelity for value testing.** Showing users a wireframe and asking if they value the concept produces unreliable signal. Users cannot properly evaluate value through placeholder-filled sketches.

**Treating any prototype fidelity as proof of demand.** The fidelity level of a user prototype does not change its fundamental limitation: it cannot prove purchase behavior. This is a category error, not a fidelity error.

FILE:references/prototype-type-details.md
# Prototype Type Details

Source: INSPIRED by Marty Cagan, Chapters 46–49

## Type 1: Feasibility Prototype (Ch46)

**What it is:** Working code written by one or more engineers to answer a specific technical question. It is not a user interface, not a product, and not productization-ready.

**When to use:** When engineers identify significant feasibility risk in the discovery process. Common triggers:
- Algorithm concerns (can we make this work at all?)
- Performance concerns (will it be fast enough?)
- Scalability concerns (will it hold up under load?)
- Fault tolerance concerns
- Use of a technology the team has not used before
- Use of a third-party component or service the team has not used before
- Use of a legacy system the team has not used before
- Dependency on new or related changes by other teams

**Who creates it:** Engineers only. Product managers and designers do not create feasibility prototypes.

**Fidelity:** None in the UI sense. It is code — throwaway code. No user interface, no error handling, no analytics, none of the work required for productization. Just enough code to answer the specific feasibility question.

**Typical time:** One to two days for most questions. Significantly longer for major new technology (machine learning, novel algorithms, major architectural changes).

**Key constraint — disposability:** Feasibility prototypes are intended to be throwaway code. It is normal and expected to be quick and dirty. The product manager does not judge when this code is "good enough" for production — that judgment belongs to engineers during productization, and they must be given full time to do delivery work properly.

**Key constraint — discovery framing:** Feasibility prototype work is discovery work, not delivery work. It is done as part of deciding whether to even pursue a particular approach. This distinction matters for team planning and morale.

---

## Type 2: User Prototype (Ch47)

**What it is:** A simulation. Smoke and mirrors. There is nothing behind the curtain. If you have a user prototype of an e-commerce site and enter credit card information, you will not actually be buying anything.

**When to use:** Usability testing, qualitative value testing, stakeholder alignment, team exploration of workflow.

**Who creates it:** Designers (primary). Some designers prefer to hand-code high-fidelity user prototypes, which is acceptable as long as they are fast and the prototype is treated as disposable.

**Fidelity spectrum:**

*Low-fidelity user prototype:* Does not look real — essentially an interactive wireframe. Useful for internal team thinking and testing information architecture and workflow. Does not capture the impact of visual design or differences caused by actual data. Faster and cheaper than high fidelity.

*High-fidelity user prototype:* Looks and feels very real. Data appears realistic (though it is not real or live). With good high-fidelity prototypes, you need to look closely to see it is not real. Required when testing value perception — users must experience the product concept as realistic for their reactions to be valid signal.

**Tools:** Standard prototyping tools developed for designers. Your designer almost certainly already has a preferred tool.

**Key limitation — cannot prove value:** The big limitation of a user prototype is that it is not good for proving anything, including whether a product will sell. Where many novice product practitioners go sideways is when they create a high-fidelity user prototype, put it in front of 10–15 people who all say they love it, and think they have validated their product. People say all kinds of things and then do something different. Better value testing techniques exist — use them for demand validation.

**Key use — communication:** A user prototype is one of the most important communication tools in product discovery. It enables stakeholders, engineers, and business partners to experience the product concept and develop shared understanding.

---

## Type 3: Live-Data Prototype (Ch48)

**What it is:** A very limited real implementation designed to collect actual usage data. It is not a simulation — real users use it for real work, generating real analytics. But it is substantially smaller and lower quality than the eventual product.

**When to use:** When you need actual usage data to address a major risk, and a user prototype simulation is insufficient. Canonical use cases:
- Search relevance (does this ranking algorithm actually surface better results?)
- Game dynamics (do users actually engage with this mechanic?)
- Social features (do users actually connect and interact as hypothesized?)
- Product funnel optimization (where do users actually drop off?)

**Who creates it:** Engineers only — designers cannot create live-data prototypes. This is real code.

**What it excludes by design:** All the work normally required for productization:
- Full set of use cases
- Automated tests
- Full analytics instrumentation (only the specific use cases being measured)
- Internationalization and localization
- Performance and scalability work
- SEO work
- Error handling and edge cases

**Typical scope:** 5–10% of the eventual delivery productization effort.

**Key constraint — not shippable:** A live-data prototype is not commercially shippable. It is not ready for prime time and cannot run a business on it. If live-data tests go well and the team decides to productize, engineers must be given full delivery time. It is not acceptable for a product manager to tell engineers that the live-data prototype is "good enough." That judgment does not belong to the product manager.

**Key constraint — stakeholder communication:** Executives and key stakeholders must understand the limitations of the live-data prototype explicitly. Managing this expectation is the product manager's responsibility.

**Speed:** Modern tooling makes live-data prototypes achievable in a couple of days to a week. Iteration cycles are fast once the prototype exists.

---

## Type 4: Hybrid Prototype (Ch49)

**What it is:** A combination of elements from user prototypes, feasibility prototypes, and live-data prototypes. The most common and powerful hybrid is the Wizard of Oz prototype.

**Wizard of Oz prototype:** Combines the front-end user experience of a high-fidelity user prototype with an actual person behind the scenes performing manually what would ultimately be handled by automation. From the user's perspective, it looks and behaves like a real product. Behind the scenes, it is a human (often the product manager or another team member) performing the manual work.

**When to use:** When you need to test the user experience of an automated system before the automation exists. Most powerful for:
- Automated chat or messaging systems
- Recommendation engines
- Any feature that will ultimately be algorithm-driven but where the interaction design matters now

**Example:** You want to build an automated 24/7 chat support system. Build a simple chat interface (user prototype front-end), but behind the scenes your customer service team (or you) manually receives the requests and composes responses. Users experience a realistic interaction. You learn what questions they ask, how they phrase them, and what responses satisfy them — all before writing any automation code.

**Key constraint — not scalable:** A Wizard of Oz prototype is absolutely not scalable. Never send significant amounts of traffic to one. Its value is qualitative learning, not quantitative proof.

**Key principle — build things that don't scale:** Hybrid prototypes embody the "build things that don't scale" philosophy of product discovery. By being a little clever, you can quickly create tools that let the team learn very quickly. The learning is mainly qualitative, but that is often where the biggest insights come from.

**Evolution path:** Wizard of Oz prototypes often evolve into live-data prototypes as the team begins to experiment with system-generated responses and algorithm-based approaches.

---
name: discovery-framing-technique-selection
description: "Select and execute the right discovery framing technique before building. Use when value risk is High and the underlying problem is not yet clearly defined, when a team is about to start discovery without a shared problem statement, when someone asks 'how should we frame this discovery effort?', or when starting any non-trivial feature, redesign, or new product effort. Also use for: writing an opportunity assessment, writing a customer letter (press release alternative), completing a startup canvas for a new business, or constructing a story map to scope discovery. Determines effort size (typical/large/new-product), selects the matching technique, and produces the framing document. Best triggered after product-discovery-risk-assessment. For specific testing techniques, use value-testing-technique-selection. For prototype selection, use discovery-prototype-selection."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/discovery-framing-technique-selection
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [35, 36, 37, 38]
tags: [product-management, product-discovery, discovery-framing]
depends-on: [product-discovery-risk-assessment]
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Product idea, feature proposal, initiative description, or risk assessment output from product-discovery-risk-assessment"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Document-based product management environment"
discovery:
  goal: "Produce a framing document that aligns the full product team on the problem before discovery begins"
  tasks:
    - "Classify the effort by size and type"
    - "Select the appropriate framing technique"
    - "Execute the selected technique step by step"
    - "Produce the framing document using the matching output template"
    - "Optionally construct a story map to scope discovery planning"
  audience:
    roles: [product-manager, product-leader, startup-founder, tech-lead]
    experience: any
  when_to_use:
    triggers:
      - "Starting product discovery and the underlying problem is not clearly defined"
      - "Value risk is High in the risk assessment from product-discovery-risk-assessment"
      - "Team is about to begin discovery work without a shared problem statement"
      - "Beginning any feature, redesign, or new product effort"
      - "Need to align team and stakeholders on what problem we are solving before ideating solutions"
    prerequisites:
      - "product-discovery-risk-assessment completed, or at minimum a product idea / initiative description is available"
    not_for:
      - "Executing prototype, testing, or ideation techniques (use downstream skills)"
      - "Post-build retrospectives or delivery planning"
      - "Efforts where the problem is already well-defined and team is aligned"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: ""
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Discovery Framing Technique Selection

## When to Use

Apply this skill at the start of any product discovery effort, specifically when:
- Value risk is High and the problem is ambiguous or handed to you as a solution without a clear problem statement
- The team lacks a shared understanding of what problem they are solving
- You are about to assign discovery tasks and need a common frame first

This skill produces a **framing document** — not a solution, not a prototype. Framing clarifies the problem space so all subsequent discovery work is aimed at the right target.

Do NOT skip framing. Teams that skip directly to prototyping or building are, by definition, solving a problem they have not clearly defined.

## Context and Input Gathering

Before selecting a technique, collect:

1. **Initiative description** — What has been proposed? Feature, redesign, or entirely new product/business?
2. **Business objective** — What OKR or company goal does this serve?
3. **Known customer problem** — What pain or job-to-be-done is this addressing?
4. **Target customer** — Which user or buyer persona is primary?
5. **Scope signals** — How many distinct business objectives are involved? Is there an existing product and business model, or is this a new product/business?

If a risk assessment document from `product-discovery-risk-assessment` exists, read it — the "Dependencies for Downstream Skills" section will confirm whether framing is needed and why.

## Process

### Step 1: Classify the Effort by Size

Apply this decision tree to determine effort size:

**Question A: Is this effort aimed at creating an entirely new product or entering a new business?**
- Yes → **New Product / New Business** effort → use **Startup Canvas**

**Question B (if A = No): Does this effort involve multiple business objectives, multiple customer problems, or affect both existing and new customers simultaneously?**
- Yes → **Large Effort** (e.g., redesign, platform shift) → use **Customer Letter**

**Question C (if A and B = No): Is this a typical feature, improvement, or single-objective initiative?**
- Yes → **Typical-to-Medium Effort** → use **Opportunity Assessment**

**WHY:** The framing technique must match the scope of the effort. An opportunity assessment answers four questions in minutes — sufficient for most product work. But a redesign with multiple objectives cannot be adequately framed in four questions; the customer letter forces the team to work through the complexity. A new product requires validating business model risks that don't exist for established products; only the startup canvas covers those dimensions. Using the wrong technique for the scope produces either under-framed (missed objectives) or over-engineered (wasted effort) framing.

**Assert:** You have classified the effort as one of: Typical-to-Medium, Large, or New Product / New Business.

### Step 2: Execute the Selected Technique

Follow the section below that matches your effort classification. Skip the other two sections.

---

#### Technique A: Opportunity Assessment (Typical-to-Medium Efforts)

**Use when:** Single feature, improvement, or single-objective initiative. Most product work falls here.

**Time required:** Minutes to one hour. This is intentionally lightweight.

**Execution:**

Answer these four questions precisely. Do not write essays — each answer should be one to three sentences.

**Question 1 — Business Objective (Objective)**
What business objective does this work address? Your answer must map to at least one of your team's assigned OKRs or top-level company objectives. If the work cannot be tied to any assigned objective, stop: clarify with leadership before proceeding.

*WHY:* Product work that cannot be connected to an assigned business objective is not prioritized work — it is speculative. Framing forces this connection explicitly before any discovery time is spent.

**Question 2 — Key Results (Key Results)**
How will you know if you have succeeded? State at least one measurable outcome. Example: "Reduce 30-day churn by 15%" or "Increase trial-to-paid conversion by 10 percentage points." A 1% improvement and a 20% improvement are very different success thresholds — define this now so the team knows what discovery evidence they are looking for.

*WHY:* Without a stated measure of success, the team cannot evaluate discovery findings or know when the problem is solved. Key results set the bar that discovery work must clear.

**Question 3 — Customer Problem (Customer Problem)**
What problem will this solve for customers? State the customer pain, not the product feature. If this addresses internal users, note that — but still tie it back to end-customer benefit where possible.

*WHY:* Teams default to feature enumeration. This question forces the pivot from output thinking ("we will build X") to outcome thinking ("customers currently struggle with Y"). The customer problem statement is the anchor for all downstream prototype and testing work.

**Question 4 — Target Market (Target Market)**
Which type of customer or user is the primary beneficiary? Be specific: a user persona, a customer segment, or a job-to-be-done context. "Everyone" is not an acceptable answer — products that try to please everyone please no one.

*WHY:* Target market definition determines who you recruit for discovery testing and which customer insights are signal versus noise. Lack of specificity causes teams to collect contradictory feedback and prototype for multiple incompatible mental models simultaneously.

**After answering all four questions:** Share the completed opportunity assessment with the full product team (product manager, designer, engineer) and key stakeholders before beginning discovery. Every team member must understand the answers before discovery work starts.

**Output:** Use the Opportunity Assessment template in the Outputs section.

---

#### Technique B: Customer Letter (Large Efforts)

**Use when:** Multiple business objectives, multiple customer problems, redesigns, or efforts that must serve both existing and new customers.

**Time required:** Several hours to one day. This is a more demanding technique.

**Execution:**

Write two imagined documents — a customer letter and a CEO response — set in the future after the product or redesign has launched successfully.

**Part 1 — The Customer Letter**

Write a letter from a specific, well-defined customer persona (use a real persona if one exists, or name a hypothetical representative customer) to the company's CEO. The letter must:

- Be written in the voice of the customer — their language, their problems, their frame of reference
- Explain what the customer's life or work was like before the product/redesign (the pain)
- Explain how the new product/redesign changed or improved their life (the benefit)
- Be specific about what changed — not vague praise ("it's so much better!") but concrete outcomes ("I used to spend two hours reconciling invoices each week; now it takes ten minutes")
- Address the primary customer benefit, not a list of features

*WHY:* Writing in the customer's voice prevents the team from defaulting to feature enumeration. The customer does not care about your architecture decisions or your internal roadmap; they care about whether their problem is solved. The letter format creates empathy — when the team reads a letter from a real-seeming customer describing real pain, they understand the problem viscerally, not abstractly. This is qualitatively different from a bullet-point list of requirements.

**Part 2 — The CEO Response**

Write an imagined congratulatory response from the CEO to the product team, explaining:

- How this product/redesign has helped the business (in business terms: revenue, retention, market position, customer satisfaction)
- Why the company's investment in this effort was worthwhile
- What the business outcome has been

*WHY:* The CEO response makes the business case explicit. It forces the product manager to think through what "success" looks like from the company's perspective — not just the customer's. This surfaces business viability considerations early: if you cannot write a plausible CEO response, the business case is not yet clear.

**After writing both documents:** Review with the product team and key stakeholders. If colleagues cannot get excited about the customer letter, the framing has more work to do, or the effort should be reconsidered.

**Output:** Use the Customer Letter template in the Outputs section.

---

#### Technique C: Startup Canvas (New Product / New Business)

**Use when:** Entirely new product, early-stage startup, or enterprise initiative to enter a new business that does not share the existing product's distribution, monetization, or customer base.

**Time required:** One to several days. This is the most comprehensive framing technique.

**Execution:**

Complete all nine cells of the canvas. Do not skip cells — each represents a risk that must be surfaced, not deferred.

**Critical warning:** The most common failure mode when using a canvas is spending disproportionate time on business model risks (monetization, channels, cost structure) while leaving solution risk underspecified. Solution risk — discovering a compelling solution that customers will choose to buy — is the primary risk for most new products. It must be addressed directly in discovery, not delegated to engineers after the canvas is complete.

Complete each cell:

**1. Problem**
State the top one to three customer problems you are solving. Be specific about who experiences them and how painful they are. Do not describe your solution here.

**2. Customer Segments**
Who are the target customers? Which segment is the most important early adopter? Distinguish between users (who interact with the product) and buyers (who pay for it) if different.

**3. Unique Value Proposition**
What is the single, clear, compelling reason a customer will choose your product over all alternatives (including doing nothing)? This is a headline, not a feature list. Note: to get someone to switch to a new product, it must be demonstrably and substantially better than existing alternatives — comparable is not sufficient.

**4. Solution**
Describe the solution at the concept level — enough to validate against the problem, not enough to specify engineering. This cell is intentionally lightweight: the solution will be refined through discovery. The startup canvas is not the place to lock in a solution.

**5. Channels**
How will you reach customers and deliver the product to them? Specify distribution and go-to-market channels. If these are unknown, that is a risk to flag.

**6. Revenue Streams**
How will this product make money? Pricing model, transaction type, and revenue expectations. If monetization is uncertain, note it — this is a risk to validate.

**7. Cost Structure**
What are the major costs to build, deliver, and support this product? Are there cost thresholds that would make the business unviable?

**8. Key Metrics**
What numbers will you track to know if the product is succeeding? Select metrics that reflect actual customer value, not just usage volume.

**9. Unfair Advantage**
What does your team or company have that competitors cannot easily replicate? This is honest — if you have no unfair advantage at this stage, leave it blank and note this as a strategic risk.

**After completing the canvas:** Share with the product team, relevant stakeholders, and advisors. Use it as a living document — update it as discovery progresses. The canvas is a starting map, not a contract.

**Output:** Use the Startup Canvas template in the Outputs section.

---

### Step 3: Construct a Story Map (Optional — Planning Complement)

A story map is a two-dimensional visualization of a product's user experience. Use it alongside any framing technique when the effort involves multiple user activities or when you need to scope discovery work across a complex system. It is especially useful for large efforts and new product discovery.

**When to build a story map:**
- The framing involves multiple distinct user activities
- You need to scope discovery into releases or phases
- The team needs a shared visual of what the system does before prototyping begins

**How to construct:**

**Horizontal axis — User Activities (left to right, time-ordered)**
List the major activities a user performs with the product. Order them as a user would encounter them, left to right. For a checkout system: browse → select → configure → pay → confirm → track. These are the column headers.

*WHY:* Horizontal ordering reflects the user's experience over time, not a product feature taxonomy. This prevents organizing the map around engineering modules (which have no inherent temporal order) and keeps the team anchored to user journeys.

**Vertical axis — Tasks (top to bottom, critical to optional)**
Under each activity, list the specific user tasks that make up that activity. Place critical tasks near the top, optional or edge-case tasks lower. There is no fixed number — add as many tasks as are relevant.

*WHY:* Vertical ordering enables release planning. Drawing a horizontal "release line" across the map at any vertical position defines a release: everything above the line is in; everything below is deferred. This is fundamentally better than a flat backlog, where there is no natural release boundary and prioritization requires arbitrary judgment.

**Draw the release line**
After populating the map, draw a release line that defines the minimum viable release — the row that, if delivered, provides meaningful value to the target user. Everything above that line is in scope for the first release. Everything below is deferred.

**Keep it current**
As discovery progresses and you receive feedback from prototype testing, update the story map to reflect what you learn. When discovery transitions to delivery, the tasks above the release line move directly into the product backlog with full context intact.

**Assert:** If a story map was built, it includes: at least three user activities on the horizontal axis, tasks ranked by criticality on the vertical axis, and a visible release line.

### Step 4: Share and Validate Alignment

Regardless of which technique was used:

1. Share the framing document with the full product team (product manager, designer, engineer) before any discovery work begins.
2. Confirm every team member can answer: What problem are we solving? For whom? How will we know we succeeded?
3. Share with key stakeholders to confirm the business objective and success measures are correct.
4. If stakeholders or team members cannot get aligned around the framing document after one revision, escalate — this is a signal of a deeper organizational misalignment that discovery cannot resolve.

**Assert:** Framing document has been reviewed by the product team and at least one key stakeholder before discovery activities begin.

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| Initiative description | Yes | What is being proposed — feature, redesign, or new product |
| Risk assessment output | Recommended | Output from product-discovery-risk-assessment, confirms framing is needed |
| Business objectives / OKRs | Yes | The team's assigned objectives for this period |
| Customer personas | Recommended | Existing persona definitions for the target customer |
| Existing business model context | For Technique C | Revenue model, channels, cost structure if it exists |

## Outputs

### Output Template A: Opportunity Assessment

```
# Opportunity Assessment: [Initiative Name]

Date: [YYYY-MM-DD]
Author: [Product Manager Name]
Status: Draft / Reviewed / Approved

## Business Objective
[Which assigned OKR or company objective does this address? One to two sentences.]

## Key Results
[How will we measure success? State at least one specific, measurable outcome.]
Example: Reduce 30-day churn rate from X% to Y% / Increase trial-to-paid conversion by Z points

## Customer Problem
[What problem does this solve for customers? State the pain, not the feature.]

## Target Market
[Which specific user or customer segment is the primary beneficiary?]

## Distribution
Share with: [Names of product team members + key stakeholders]
Reviewed by: [ ]
```

### Output Template B: Customer Letter

```
# Customer Letter: [Initiative Name]

Date: [YYYY-MM-DD]
Author: [Product Manager Name]
Customer Persona: [Name of persona or representative customer archetype]

---

## Letter from Customer to CEO

Dear [CEO Name],

I wanted to write and tell you how much [product/redesign name] has changed [my work / my life].

Before [product/redesign], I used to [describe the pain — specific, concrete, in the customer's voice].
This meant [consequence of the pain — time lost, money wasted, frustration, etc.].

Now, [describe what changed — specific outcomes, not feature lists].
[Optional: specific time/money/effort saved, or qualitative change in experience.]

I [recommend this / have told my colleagues / renewed our subscription] because [specific reason].

Thank you,
[Customer Name]
[Customer Title / Context]

---

## CEO Response to Product Team

Team,

I wanted to share this letter we received from [customer name / customer segment].

This is exactly what we were aiming for with [initiative name]. The work you did has [business outcome: improved retention / driven X new customers / expanded into Y market / improved NPS by Z points].

[One to two sentences on why this mattered to the business — revenue, competitive position, mission.]

Well done.
[CEO Name]

---

## Internal Notes
Business objectives addressed: [list]
Success measures: [list — what we will track to know this worked]
Target market: [specific segment this letter represents]
Share with: [product team + key stakeholders]
Reviewed by: [ ]
```

### Output Template C: Startup Canvas

```
# Startup Canvas: [Product / Business Name]

Date: [YYYY-MM-DD]
Author: [Product Manager / Founder]
Status: Draft / Version N

| Cell | Content |
|------|---------|
| Problem | [Top 1-3 customer problems. Who has them. How painful.] |
| Customer Segments | [Primary target segment. Early adopter profile. User vs. buyer distinction.] |
| Unique Value Proposition | [Single clear reason customers will choose this over all alternatives, including inaction.] |
| Solution | [Concept-level description. Not an engineering spec. Subject to change through discovery.] |
| Channels | [How you reach and deliver to customers.] |
| Revenue Streams | [Pricing model, transaction type, revenue expectations.] |
| Cost Structure | [Major costs to build, deliver, support.] |
| Key Metrics | [What you will track to know the product is succeeding.] |
| Unfair Advantage | [What competitors cannot easily replicate. Honest — blank if none yet.] |

## Primary Risk: Solution Risk
[Describe what a compelling solution looks like. How will you discover it? What does
"demonstrably and substantially better than alternatives" mean in this specific context?]

## Discovery Priority
1. Solution risk (value risk) — must be resolved first
2. [Next risk in priority order]
3. ...

## Living Document Log
| Version | Date | What Changed | Why |
|---------|------|-------------|-----|

Share with: [product team + stakeholders + advisors]
Reviewed by: [ ]
```

### Output Template D: Story Map (Complement to Any Technique)

```
# Story Map: [Initiative Name]

Date: [YYYY-MM-DD]
Version: [N]

## User Activities (horizontal — left to right, time-ordered)
| Activity 1 | Activity 2 | Activity 3 | Activity 4 | ... |
|-----------|-----------|-----------|-----------|-----|

## Tasks by Activity (vertical — critical at top, optional below)

### [Activity 1]
- [Critical task 1]
- [Critical task 2]
---- RELEASE LINE ----
- [Optional task 1]
- [Optional task 2]

### [Activity 2]
- [Critical task 1]
- [Critical task 2]
---- RELEASE LINE ----
- [Optional task 1]

[Continue for each activity]

## Release Scope
**Release 1 (above line):** [Summary of what ships in first release]
**Deferred (below line):** [Summary of what is explicitly deferred]

## Change Log
| Date | What Changed | Discovery Signal That Prompted It |
|------|-------------|----------------------------------|
```

## Key Principles

1. **Framing is not optional.** Every product effort, regardless of size, must be framed before discovery begins. The technique scales — the need does not disappear.
2. **Effort size determines technique.** Opportunity assessment for typical work. Customer letter for large multi-objective work. Startup canvas for new products. Applying the wrong technique produces either under-framing or wasted effort.
3. **The framing document defines what discovery must prove.** Key results and customer problem statements set the success threshold. Discovery evidence either clears this bar or it does not.
4. **Framing is a team activity, not a PM artifact.** The product manager authors the document, but every team member must understand and be aligned with the answers before discovery begins.
5. **Solution risk is primary.** For startup canvas use: do not spend most of your time on business model risks while leaving solution risk underspecified. A compelling solution unlocks all other risks; an elegant business model with no compelling solution is worthless.
6. **Customer letter beats press release.** Writing in the customer's voice creates empathy the team can feel, not just understand. If the team cannot get excited about the customer letter, the framing has more work to do.
7. **Story maps are living documents.** Update them as discovery produces learning. When discovery transitions to delivery, the story map becomes the backlog source of truth.

## Examples

### Example 1: Opportunity Assessment for a B2B Feature

**Initiative:** Add bulk export functionality to a project management tool.

**Effort classification:** Typical — single feature, single objective.

**Opportunity Assessment:**
- Business Objective: Reduce trial-to-paid churn (maps to OKR: "Improve 30-day retention from 42% to 55%")
- Key Results: Reduce cancellation reason "missing export" from 18% of churn responses to below 5%
- Customer Problem: Enterprise users cannot extract project data for executive reporting without manually copying rows — a two-hour-per-month task that creates frustration and support tickets
- Target Market: Enterprise trial users managing 10+ projects with executive reporting obligations

### Example 2: Customer Letter for a Redesign

**Initiative:** Redesign mobile onboarding for a consumer finance app (multiple objectives: reduce drop-off, improve feature discovery, differentiate from competitors).

**Effort classification:** Large — multiple objectives, both existing and new customers affected.

**Customer letter written from persona:** "Maria, a 28-year-old first-time investor, writing six months after the redesign launched."

The letter describes: confusion with the original seven-step onboarding, almost deleting the app, then returning after a friend recommended it post-redesign. Now completes onboarding in under three minutes, discovered portfolio tracking on day one, has referred two friends.

CEO response acknowledges: 41% improvement in onboarding completion, 23% increase in feature discovery within first week, highest App Store rating in company history.

### Example 3: Startup Canvas for a New Product

**Initiative:** A B2B startup building an AI-powered contract review tool for small law firms.

**Effort classification:** New product / new business.

**Canvas note on solution risk:** "We have filled in all nine cells, but the most important work is discovering whether we can build a contract review experience that is demonstrably faster and more accurate than a junior associate. That is the solution risk that all other canvas cells depend on. We will spend the first four weeks of discovery exclusively on this."

## References

- `references/framing-technique-comparison.md` — Side-by-side comparison of all three framing techniques with selection criteria and tradeoffs
- `references/opportunity-assessment-examples.md` — Worked examples of opportunity assessments across different product types
- `references/customer-letter-guide.md` — Detailed guidance on writing the customer letter and CEO response, including common failure modes
- `references/startup-canvas-guide.md` — Full startup canvas guidance with risk prioritization and the "biggest risk" warning
- `references/story-map-guide.md` — Step-by-step story map construction, release line drawing, and backlog transition guidance

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

Install related skills from ClawhHub:
- `clawhub install bookforge-product-discovery-risk-assessment`

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/framing-technique-comparison.md
# Framing Technique Comparison

## Selection at a Glance

| Criterion | Opportunity Assessment | Customer Letter | Startup Canvas |
|-----------|----------------------|-----------------|----------------|
| Effort size | Typical to medium | Large | New product / new business |
| Time to complete | Minutes to 1 hour | Several hours to 1 day | 1 to several days |
| Business objectives | Single | Multiple | All unknown or unproven |
| Customer problems | Single | Multiple | All unknown or unproven |
| Business model | Existing, established | Existing, established | Unknown or unproven |
| Key output | 4-question document | Customer letter + CEO response | 9-cell canvas |
| Primary risk addressed | Problem clarity | Multi-objective alignment | Solution + business model |
| Best for | Feature work, improvements | Redesigns, platform shifts | Startups, new business units |

## Why Effort Size Is the Primary Selection Criterion

Framing technique selection is not about preference — it is about matching the technique's scope to the effort's complexity. Using an opportunity assessment for a major redesign produces under-framing: four questions cannot capture multiple competing objectives. Using a startup canvas for a single feature produces over-engineering: the team spends days on business model cells that do not change.

The cost of under-framing is higher. A team that begins discovery with insufficient framing will discover, mid-discovery, that different team members had different assumptions about the problem scope. This requires restarting framing during discovery — far more expensive than spending a day on a customer letter upfront.

## Common Selection Errors

**Error 1: Using opportunity assessment for a redesign.**
Redesigns almost always have multiple objectives (improve existing-customer experience AND attract new customers). Four questions will not surface the tension between these objectives. Use customer letter.

**Error 2: Using startup canvas for a new feature in an established product.**
Once you have an existing product and business, most canvas cells (channels, revenue, cost structure) are already defined and do not change with a new feature. Using a canvas here wastes time on cells that produce no new information. Use opportunity assessment or customer letter depending on scope.

**Error 3: Skipping framing because the team "already knows" the problem.**
Teams that are confident they know the problem are precisely the teams that benefit most from framing. Writing down the answers forces explicit commitments — and often reveals that different team members have different assumptions.

FILE:references/story-map-guide.md
# Story Map Guide

## Origin and Purpose

Story maps were created by Jeff Patton (documented in *User Story Mapping*, O'Reilly, 2014) to solve a fundamental problem with flat backlogs: a prioritized list of stories has no context. You cannot tell from a flat backlog how one story relates to another, what a meaningful release looks like, or how the system grows over time.

A story map restores the two dimensions that a flat backlog strips away: the user experience over time (horizontal) and the level of detail/criticality (vertical).

## Construction Reference

### Horizontal Axis: User Activities

User activities are the major things a user does with a product. They are higher-level than user stories. Examples:

- For an e-commerce product: Browse → Search → Select → Configure → Checkout → Track → Return
- For a project management tool: Create project → Add tasks → Assign work → Track progress → Report
- For a finance app: Onboard → Connect accounts → View balances → Categorize transactions → Set budgets → Review reports

Rules:
- Order activities left to right as a user would encounter them
- Use verb + noun format (activity, not feature)
- Aim for 5–12 activities; more than 15 suggests you are operating at task level, not activity level
- Activities are the stable backbone of the map — they change infrequently

### Vertical Axis: Tasks Under Each Activity

Under each activity, list the specific tasks a user performs to accomplish that activity. Tasks are roughly equivalent to user stories in granularity.

Rules:
- Place the most critical tasks near the top (critical = must exist for the product to be functional)
- Place optional, edge-case, or enhancement tasks lower
- There is no required number of tasks per activity
- Tasks can be added as discovery progresses — the map grows as you learn

### The Release Line

Drawing a horizontal line across the map at any vertical position defines a release:
- Everything above the line: in scope for this release
- Everything below the line: explicitly deferred

This is fundamentally better than backlog prioritization because:
- The release is defined by user experience completeness, not arbitrary priority numbers
- Every team member can see at a glance what ships and what does not
- Deferred items are acknowledged, not forgotten

Draw the release line to define the minimum release that delivers meaningful value to the target user — not the minimum to call it "done" internally.

### Keeping the Map Current

Update the story map after every significant discovery finding:
- Prototype testing reveals an activity you did not model → add it
- Customer interviews reveal a task you thought was critical is actually optional → move it below the line
- Engineering feasibility spike reveals a critical task is infeasible in release 1 → move below the line with a note

When discovery transitions to delivery: tasks above the release line move into the product backlog as user stories, with the full map as context.

## When a Story Map Is and Is Not Needed

**Use a story map when:**
- The effort involves 5 or more distinct user activities
- You need to scope discovery into phases or releases
- The team needs a shared visual of the system before prototyping begins
- Multiple team members have different mental models of the user experience

**Skip a story map when:**
- The effort is a single focused feature within one well-understood activity
- The opportunity assessment framing is sufficient and the team is already aligned on scope
- The team has extensive existing context and a story map would duplicate knowledge already shared

---
name: customer-discovery-program
description: "Design a customer discovery program to achieve product-market fit for a significant new product or market expansion. Use when launching a new product, entering a new market segment, redesigning a product for a different customer segment, or when someone asks 'how do we find product-market fit?', 'how do we get reference customers?', or 'are we stuck in a sales-driven fragmentation spiral?' Also use when the team is unsure if they have achieved product-market fit, when scaling sales feels premature, or when checking whether the Sean Ellis test applies. Produces a complete program plan: single target market definition, recruitment criteria for 6 reference customers, co-development relationship structure, and product-market fit definition by product type (B2B, platform/API, consumer, internal). Not for small features or minor improvements — use value-testing-technique-selection for those."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/customer-discovery-program
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [39]
tags: [product-management, product-market-fit, customer-development]
depends-on: [product-discovery-risk-assessment]
execution:
  tier: 1
  mode: plan-only
  inputs:
    - type: document
      description: "Product idea, initiative description, or opportunity brief for a significant new product or market expansion"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Document-based product management environment"
discovery:
  goal: "Design a complete customer discovery program plan that generates reference customers in parallel with product development"
  tasks:
    - "Identify the single target market for the program"
    - "Define recruitment criteria for 6-8 prospective reference customers"
    - "Structure the co-development relationship and program rules"
    - "Set product-market fit definition appropriate for the product type"
    - "Diagnose whether the sales-driven fragmentation spiral is present"
    - "Produce the full program plan document"
  audience:
    roles: [product-manager, startup-founder, product-leader]
    experience: any
  when_to_use:
    triggers:
      - "Launching a new product or business line"
      - "Taking an existing product to a new market or geography"
      - "Redesigning a product for a different customer segment"
      - "Determining whether the team has achieved product-market fit"
      - "Breaking out of a sales-driven fragmentation spiral"
    prerequisites: []
    not_for:
      - "Small features or minor improvements to existing products"
      - "Products already past product-market fit with an established customer base"
      - "Executing discovery techniques (use technique-specific downstream skills)"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: ""
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Customer Discovery Program

## When to Use

Apply this skill when the team is launching a significant new product, entering a new target market, or redesigning a product — and needs to achieve product-market fit before scaling sales and marketing.

This skill produces a **program plan**, not a discovery execution log. The output is a structured document the PM uses to recruit, co-develop with, and validate a set of reference customers in parallel with building the product.

Do NOT use this skill for:
- Small features or minor product improvements (overhead is too high)
- Products already past product-market fit
- Executing specific discovery techniques (see downstream technique skills)

The program takes substantial PM effort over multiple months. It is also the single best leading indicator of future product success.

## Context and Input Gathering

Before designing the program, collect:

1. **Product initiative description** — What is being built? One paragraph minimum.
2. **Product type** — B2B (selling to businesses), platform/API (selling to developers), internal tools (employees are users), or consumer (direct-to-consumer).
3. **Target market** — Which customer segment, vertical, or geography is the primary target? If multiple segments are under consideration, list them — the plan will force a choice.
4. **Current customer/prospect relationships** — Are there existing customers, active prospects, or is the team starting from zero?
5. **Company stage** — Early-stage startup (limited cash) or established company with an existing sales organization?
6. **Sales organization involvement** — Is a sales team already pursuing deals? If so, describe recent deal patterns.

If a product brief, opportunity assessment, or risk assessment from `product-discovery-risk-assessment` exists, read it before proceeding.

## Diagnosing the Sales-Driven Fragmentation Spiral

Before designing the program, check whether the team is already in the fragmentation spiral. This is the primary motivation for the program in established companies.

### The 5-Stage Fragmentation Spiral

**Stage 1 — Weak product:** The product does not yet strongly solve the target customer's problem. Customer acquisition costs are high because marketing must work hard to attract prospects who are not already sold.

**Stage 2 — Sales creativity:** To hit quota, the sales organization gets creative. They lengthen the sales pitch, offer heavy discounts, and negotiate custom terms to close deals. Sales cycles grow longer. Margin shrinks.

**Stage 3 — Requirements capture:** Sales starts bringing individual deal requirements to the PM as the condition for closing the next big customer. Each new deal has slightly different needs.

**Stage 4 — Product fragmentation:** The PM, under pressure, implements the requirements from the latest set of deals. The product accumulates feature combinations that work for specific customers but create complexity that makes the product worse for everyone.

**Stage 5 — Weaker product:** The accumulated complexity makes the core product harder to use and position. The cycle repeats. The team complains about working at a "sales-driven company."

**WHY this matters:** The spiral is self-reinforcing. Diagnosing it explains why the team is under pressure to take one-off requirements. The customer discovery program is the escape because it builds a strong product before sales scales — eliminating the root cause rather than managing the symptoms.

### Spiral Diagnosis Checklist

Mark each symptom as Present / Absent:

| Symptom | Status |
|---------|--------|
| Marketing requires high spend to generate qualified leads | |
| Sales cycles are lengthening | |
| PM receives feature requests that are framed as "deal requirements" | |
| Product has features that were built for one or two customers but rarely used broadly | |
| Win/loss analysis shows losses due to feature gaps vs. competitors | |
| Customer success team reports frequent escalations from frustrated customers | |

**If 3+ symptoms are present:** the spiral is active. The program is urgent. Do NOT let sales scale until reference customers are established.

**If 0-2 symptoms present:** the team is pre-spiral or in early stages. The program is preventive.

## Process

### Step 1: Define the Single Target Market

Choose exactly one target market for this program. The program fails if customers are drawn from two or three different segments.

**Market definition options:**
- By vertical (e.g., financial services, manufacturing, healthcare)
- By company size (e.g., enterprise >1,000 employees; mid-market 100-999)
- By geography (e.g., United States first, then Germany, then Brazil)
- By job function (e.g., engineering leaders at software companies)

**WHY single market:** Six reference customers from two or three different markets will not give you focus. The product will be pulled in multiple directions, which is how fragmentation starts. Six from one segment gives the sales team a clear, replicable motion: "We've helped six companies like yours."

**Decision rule:** If the team is debating two markets, pick the one where the pain is most acute and the PM has the most existing access to real customers. Market expansion comes after the first set of six is complete.

**Output of this step:** One sentence defining the target market: [Segment] + [Geography/Size qualifier if applicable].

### Step 2: Define Recruitment Criteria

Recruit 6-8 prospective reference customers to allow for 1-2 who drop out or prove to be a poor fit. The target is to end with exactly 6.

**Required criteria (all must be present):**

| Criterion | Description | Why It Matters |
|-----------|-------------|----------------|
| Acute pain | The customer feels the problem acutely — near-desperate for a solution. They have tried alternatives and those alternatives have failed or are insufficient. | Customers who feel pain moderately will not engage deeply with co-development. They'll participate passively and give polite feedback, not honest signal. |
| Time and people available | The customer has staff who can spend real time with the product team: testing early prototypes, giving feedback, running the product in their environment. | Co-development requires genuine collaboration. A customer who is "interested" but cannot show up to working sessions is not a reference customer candidate. |
| From the single target market | The customer must be from the defined target market — not an adjacent segment or personal contact who happens to be interested. | Mixing segments destroys the focus the program is designed to create. |
| Willing to serve as public reference | The customer, if the product works for them, is willing to be named publicly by marketing. | A reference customer who cannot be named publicly provides no sales collateral value. Coordinate with the customer's marketing organization before confirming. |

**Preferred criteria (strongly preferred, not required):**

| Criterion | Description |
|-----------|-------------|
| Marquee name | Well-recognized brand in the target market. A marquee reference is more valuable to sales than five unknown names combined. |
| Not a technologist | Screen out customers who are primarily interested in the technology itself rather than the business problem. Technologists distort feedback toward technical features rather than business value. |

**Sources for candidates:** Existing customer base, active prospect pipeline, inbound leads who inquired but did not buy, and introductions from the product marketing manager.

**Recruitment signal test:** If the team cannot find even 4-5 prospective customers willing to participate, this is a demand validation failure. The problem may not be as important as assumed. Reconsider the initiative before proceeding.

**Recruitment coordinator:** The PM leads recruitment in tight collaboration with the product marketing manager. The product marketing manager coordinates reference permissions and helps convert reference customers into sales collateral.

### Step 3: Structure the Co-Development Relationship

The relationship is a **development partnership**, not a consulting engagement or a custom development contract.

**Explain to each prospective member:**
- The goal is a general product that can be sold to many companies — not a custom solution built for them alone
- The PM will dive deep with each of the six customers to find a single solution that works well for all six — not implement every feature that all six request
- The customer gets genuine input into the product direction and real access to early prototypes and versions
- The customer gets the product before general release, live and validated in their environment before public launch
- The customer agrees to buy and serve as a public reference **if** the resulting product works for them

**Program rules:**

| Rule | Rationale |
|------|-----------|
| Do not charge customers in advance | Paying in advance changes the relationship from partnership to vendor/client. The PM is not a custom development shop. (Exception: early-stage startups with limited cash may use escrow.) |
| Cap program at 6-8 members | Sales organizations will pressure the PM to add more. More than 8 is unmanageable and produces unfocused signal. Customers who want early access but are not right for the program can join a separate early-release program without the co-development commitment. |
| Release to program members before general release | Reference customers must be live and happy before the general release. They stand up for the product at launch. |
| Treat members as colleagues | Share context openly. The PM will show prototypes, ask detailed questions, test early versions in their environment. These relationships often last many years. |

**The PM's job in this relationship:** Find a single solution that works well for all 6 customers. This requires deep understanding of each customer's underlying problem — not surface-level feature comparison across all 6. Listing all features that all 6 request and implementing them produces a fragmented product.

### Step 4: Define Product-Market Fit for This Product Type

Select the appropriate product-market fit definition based on product type.

**B2B (Selling to businesses):**
- Product-market fit = 6 reference customers in the target market who are:
  - Active (running the product in production, not trial or prototype)
  - Paying real money (not given away or deeply discounted)
  - Willing to recommend voluntarily and sincerely to peers

**Platform / API (Selling to developers):**
- Product-market fit = 6 reference **applications** built on the platform
- Work with development teams (engineers and product managers) at partner companies, not business buyers
- Focus on successful applications created with the platform, not just developers who signed up

**Internal tools (Customer-enabling tools for employees):**
- Product-market fit = 6-8 influential internal employees who:
  - Regard themselves as thought leaders among their peers
  - Genuinely believe the tool is great
  - Actively recommend it to colleagues voluntarily
- These are internal "references" rather than paying customers — no payment criterion

**Consumer (Direct-to-consumer products):**
- Primary metric: 10-50 engaged consumers who are actively using the product and loving it
- Supplementary metric: **Sean Ellis test** — survey active users who have experienced core value: "How would you feel if you could no longer use this product?" Target: **>40% responding "very disappointed"**
- Sean Ellis survey mechanics: survey only users who have used the product recently (at least twice), have reached the core value of the product per analytics, and are from the target market — not all registered users
- Consumer products must supplement the small reference group with broader testing on users who have not been exposed to the product, since individual consumers do not carry the sales collateral weight that B2B references do

**WHY the B2B definition is more practical than the Sean Ellis test for business products:** Six named reference customers in a specific market give sales a concrete, replicable proof point. The Sean Ellis test is subjective and sample-dependent for B2B; the reference customer definition is binary and verifiable.

**Declaring product-market fit:** When the program reaches the PMF definition for the product type, declare it. PMF does not mean the product is finished — continuous improvement continues. But PMF enables aggressive and effective selling to the rest of that target market.

### Step 5: Set the Pre-Launch Gate

Do not launch broadly — do not turn on the sales or marketing machine — until the PMF definition is met.

**Pre-launch gate criteria (B2B):**

| Gate | Status |
|------|--------|
| 6 reference customers active in production | |
| All 6 paying (or escrow committed for early-stage) | |
| All 6 willing to be named publicly (marketing permission confirmed) | |
| All 6 live and happy before general release date | |
| Product marketing has converted at least 2-3 into sales collateral (case study, quote, or logo) | |

**WHY do not launch early:** Without reference customers, the sales team does not know where the real product-market fit is. With quota pressure, they will sell to any customer they can close — which recreates the fragmentation spiral. Reference customers give sales a clear target profile and social proof for that profile.

### Step 6: Produce the Program Plan Document

Write a structured program plan document (see Outputs section).

## Outputs

### Output Template: Customer Discovery Program Plan

```
# Customer Discovery Program Plan: [Product/Initiative Name]

## Initiative Summary
[One paragraph: what is being built and why]

## Product Type
[ ] B2B  [ ] Platform/API  [ ] Internal tools  [ ] Consumer

## Spiral Diagnosis
[Present / Pre-spiral — list active symptoms if present]

## Single Target Market
[One sentence: segment + qualifier]

## Product-Market Fit Definition
[B2B: 6 reference customers active, paying, willing to recommend]
[Consumer: 10-50 engaged users + >40% "very disappointed" on Sean Ellis]
[Platform: 6 reference applications]
[Internal: 6-8 influential internal users who recommend to peers]

## Recruitment Plan

### Target count
Recruit [6-8] prospective members to end with 6.

### Candidate sources
- [Source 1: existing customers / prospects / inbound / introductions]
- [Source 2]
- [Source 3]

### Recruitment criteria checklist (per candidate)
- [ ] Feels the problem acutely / near-desperate
- [ ] Has time and people to collaborate
- [ ] From the single target market
- [ ] Willing to serve as public reference (marketing permission coordinated)
- [ ] Screened: not primarily a technologist
- [ ] Preferred: marquee brand name

### Candidates under consideration
| Candidate | Source | Pain Level | Marquee? | Status |
|-----------|--------|------------|----------|--------|
| [Name/Company] | | High/Med/Low | Y/N | Prospecting/Confirmed/Declined |

## Co-Development Relationship Structure
- Payment: [not in advance / escrow arrangement for early-stage]
- Program size cap: [6-8 members]
- Commitment from customer: test early prototypes, give real feedback, buy if product works, serve as public reference
- Commitment from product team: genuine input to product direction, pre-release access, product that works for them specifically
- Coordination: PM leads; product marketing manager handles reference permissions and collateral

## Timeline
| Phase | Duration | Activities |
|-------|----------|-----------|
| Recruitment | [weeks] | Identify candidates, qualify, confirm |
| Early co-development | [weeks] | Prototypes, early versions, deep qualitative work |
| Production validation | [weeks] | Full product in reference customer environment |
| PMF declaration | [date target] | All 6 criteria met |
| General launch | [date target] | Reference customers live; sales/marketing enabled |

## Pre-Launch Gate
- [ ] 6 reference customers active in production
- [ ] All 6 paying (or escrow committed)
- [ ] All 6 with marketing permission confirmed
- [ ] All 6 live and happy before launch date
- [ ] 2-3 converted to sales collateral by product marketing

## Risks and Contingencies
| Risk | Mitigation |
|------|-----------|
| Cannot recruit 4-5 candidates | Demand validation failure — reconsider initiative |
| Sales pressure to add more than 8 | Direct oversubscribed prospects to early-release program (no co-development commitment) |
| Customer requests custom feature not useful for all 6 | PM finds generalized solution — not the specific request; explain general product framing |
| Spiral symptoms accelerating | Do not scale sales until gate is met; present spiral diagnosis to leadership |
```

## Key Principles

1. **Reference customers are the single best leading indicator of product success.** They are more predictive than any internal metric or survey result because they represent real commitment: real money, real production usage, real willingness to recommend.

2. **Develop reference customers in parallel with the product.** The program is not a post-launch validation exercise. The PM discovers and develops reference customers at the same time as discovering and developing the product.

3. **Single target market is non-negotiable.** The program's value comes from focus. Mixed segments produce mixed signal and a product that half-solves multiple problems.

4. **The PM's job is one solution for all six, not a union of all requests.** Building every feature that all six customers request produces a fragmented product. The PM dives deep with each customer to understand the underlying problem, then finds a single solution that works for all.

5. **Do not charge in advance.** Payment in advance changes the relationship from partnership to vendor contract. The customer should buy because the product works — not because they already paid.

6. **The spiral escape requires a gate.** The only way to break the sales-driven fragmentation spiral is to refuse to scale sales before the PMF gate is met. This requires leadership alignment — the gate must be a shared commitment, not just a PM preference.

7. **Recruitment difficulty is a demand signal.** If the PM cannot find 4-5 prospective customers willing to participate, the problem is probably not important enough to build a business around.

8. **Product marketing is a co-owner of the program.** The product marketing manager coordinates reference permissions, keeps the program running smoothly under sales pressure, and converts reference customers into sales collateral. They must be involved from the start.

## Product Type Variants Summary

| Dimension | B2B | Platform/API | Internal Tools | Consumer |
|-----------|-----|--------------|----------------|----------|
| PMF definition | 6 reference customers | 6 reference applications | 6-8 influential internal users | 10-50 loving users + >40% Ellis |
| Who you work with | Business buyers + their users | Engineering teams at partner companies | Internal employees (thought leaders) | Individual consumers |
| Payment criterion | Yes — real money | Typically yes | No — internal | Usually no (at program stage) |
| Reference type | Named company + logo | Named application | Colleague referral | User testimonial / press |
| Sean Ellis test | Optional supplement | Optional | Not applicable | Primary metric |

## References

- `references/sales-driven-spiral.md` — Full 5-stage spiral mechanics, spiral recovery case patterns, and escalation language for leadership alignment
- `references/recruitment-screening-guide.md` — Detailed interview questions and scoring rubric for screening prospective reference customer candidates
- `references/pmf-definitions.md` — Complete product-market fit definitions per product type, Sean Ellis survey instrument, and B2B reference customer criteria checklist
- `references/program-rules-rationale.md` — Detailed rationale for each program rule (payment, cap, release timing) and objection handling for sales pressure

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

Install related skills from ClawhHub:
- `clawhub install bookforge-product-discovery-risk-assessment`

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

---
name: business-viability-stakeholder-testing
description: "Test whether a product solution is viable for the business before building. Use when business viability risk is Medium or High, when multiple internal functions (legal, sales, finance, marketing) may have constraints on a proposed solution, when someone asks 'will this work for our business?', 'do we have stakeholder buy-in?', or 'does legal/finance/sales need to review this?' Also use when a proposed solution would change pricing, go-to-market motion, or support model, or when you need documented cross-functional sign-off before committing engineering resources. Identifies all stakeholders who can veto launch across 8 domains, conducts 1:1 preview sessions with high-fidelity prototypes, and resolves disagreements with evidence rather than opinions. Produces a structured viability sign-off document. Not for customer value testing — use value-testing-technique-selection. Not for product-market fit — use customer-discovery-program."
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/inspired-how-to-create-tech-products/skills/business-viability-stakeholder-testing
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: published
source-books:
  - id: inspired-how-to-create-tech-products
    title: "INSPIRED: How to Create Tech Products Customers Love"
    authors: ["Marty Cagan"]
    chapters: [31, 56, 61]
tags: [product-management, stakeholder-management, business-viability]
depends-on: [product-discovery-risk-assessment]
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Product solution description or high-fidelity prototype, plus a brief on the company's business model, go-to-market motion, and any known stakeholder concerns"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Document-based product management environment"
discovery:
  goal: "Confirm that a proposed product solution works for the business across all relevant dimensions before the team commits to building it"
  tasks:
    - "Identify which of the 8 stakeholder domains apply and who holds veto power"
    - "Map concern categories for each relevant stakeholder domain"
    - "Plan and conduct 1:1 stakeholder preview sessions using high-fidelity prototypes"
    - "Resolve any stakeholder objections with evidence rather than authority"
    - "Produce a viability sign-off document capturing status across all domains"
  audience:
    roles: [product-manager, product-leader, startup-founder]
    experience: any
  when_to_use:
    triggers:
      - "Business viability risk is scored Medium or High in the product discovery risk assessment"
      - "Multiple internal functions (legal, finance, sales, marketing) may have constraints on a proposed solution"
      - "A proposed solution would change the go-to-market motion, pricing model, or support model"
      - "You need documented cross-functional sign-off before committing engineering resources"
      - "A senior stakeholder or executive has unaddressed concerns about a proposed direction"
    prerequisites:
      - "product-discovery-risk-assessment completed — viability risk must be identified as Medium or High"
      - "A high-fidelity prototype or detailed solution description exists to show stakeholders"
    not_for:
      - "User testing or usability validation (different technique — user drives; see discovery-prototype-selection)"
      - "Value testing with customers (different goal — viability testing is internal, not customer-facing)"
      - "Feasibility testing (engineer-led technical spikes — different risk type)"
      - "Post-build review meetings or retrospectives"
  environment:
    codebase_required: false
    codebase_helpful: false
    works_offline: true
  quality:
    scores:
      with_skill: 0
      baseline: 0
      delta: 0
    tested_at: ""
    eval_count: 0
    assertion_count: 0
    iterations_needed: 0
---

# Business Viability Stakeholder Testing

## When to Use

Apply this skill when your product discovery risk assessment has flagged business viability as Medium or High risk. This means the proposed solution may conflict with the constraints of internal functions that have power to block launch.

This skill produces a structured viability sign-off — confirmation that the solution works for the business across all relevant dimensions — before the team commits to building.

Do NOT use this skill for customer-facing validation (user testing, demand validation). Those address value and usability risk. This skill addresses the internal business dimension: will finance, legal, sales, marketing, and executive stakeholders support this solution?

## Context and Input Gathering

Before running this process, collect:

1. **Solution description** — What is the proposed product or feature? Sufficient detail to expose constraints (not a vague concept).
2. **High-fidelity prototype** — Stakeholders need to see actual proposed screens, workflows, and wording. Presentations and slide decks are not sufficient.
3. **Business model context** — Revenue model, pricing structure, distribution channels, existing partner agreements, brand positioning.
4. **Known concerns** — Any constraints already surfaced (legal has flagged X; sales team worried about Y).
5. **Stakeholder map** — Who in this organization holds authority over each relevant domain?

If no high-fidelity prototype yet exists, this process should be deferred until one does. Showing presentations to stakeholders produces false sign-off — they agree to something they have not actually seen.

## Process

### Step 1: Identify Relevant Stakeholder Domains

A stakeholder is any person who can veto your work or prevent launch. Work through the 8 standard domains and determine which apply to this solution:

| Domain | Veto Test |
|--------|-----------|
| Marketing | Could this solution affect brand promise, go-to-market channels, or market positioning? |
| Sales | Could this change what the sales force is asked to sell, or how they sell it? |
| Customer Success | Could this change the support burden, onboarding model, or customer-facing service model? |
| Finance | Could this affect unit economics, provisioning costs, pricing model, or investor reporting? |
| Legal | Does this touch privacy, compliance, intellectual property, or competitive constraints? |
| Business Development | Does this interact with existing partner agreements or external relationships? |
| Security | Does this introduce new data exposure, access control changes, or security surface area? |
| Executive (CEO/COO/GM) | Is there overall business risk, or does this require executive-level trust and endorsement? |

Mark each domain as: **Applicable** (must engage), **Monitor** (low concern, check briefly), or **Not applicable**.

**WHY:** The worst outcome is discovering post-build that launch is blocked by a constraint you did not surface. Every domain in the applicable list represents a potential launch blocker. Skipping any applicable domain is not a time saving — it is a liability that compounds if discovered after the team has built.

Full concern details for each domain: `references/stakeholder-domain-concerns.md`

### Step 2: Map Specific Concerns Per Domain

For each applicable domain, identify the specific concern categories that apply to this solution. This is not a generic checklist — it requires judgment about what the proposed solution actually touches.

**Marketing concerns to check:**
- Brand consistency — does the solution fit within the brand promise customers expect from this company?
- Go-to-market channel impact — does the solution require a different distribution or marketing channel?
- Messaging and differentiation — does it conflict with current positioning or market segment strategy?

**Sales concerns to check:**
- Channel capability — can the existing sales force sell this? Does it require different skills, relationships, or deal cycles?
- Price point alignment — is this priced for the sales motion the team is equipped for?
- Sales cycle impact — does this lengthen, shorten, or restructure the sales process?

**Customer success concerns to check:**
- Support burden — does this create new categories of customer questions or failure modes?
- Onboarding complexity — can customers be successfully onboarded at current staffing levels and model (high-touch vs. low-touch)?

**Finance concerns to check:**
- Unit economics — can the company afford to build, provision, and operate this at scale?
- Pricing model viability — does the proposed pricing generate sufficient margin?
- Reporting and investor relations — are there financial disclosures or reporting constraints?

**Legal concerns to check:**
- Privacy — does the solution collect, store, or transmit user data in ways that create regulatory exposure?
- Regulatory compliance — are there industry-specific regulations that apply (GDPR, HIPAA, SOC 2, etc.)?
- Intellectual property — does the solution use third-party technology, content, or IP in ways that require agreements?
- Competitive constraints — do any existing agreements limit competitive positioning?

**Business development concerns to check:**
- Existing partner agreements — does the solution violate commitments or constraints in current partner contracts?
- Partner alignment — does the solution affect the value delivered through key distribution or integration partners?

**Security concerns to check:**
- Data protection — what new data does this solution handle and how is it protected?
- Access control — does this introduce new permission boundaries or authentication requirements?
- Security review requirements — does this trigger mandatory security review processes in this organization?

**Executive concerns to check:**
- Overall business risk — does the CEO/COO/GM have unresolved concerns about this direction?
- Trust in product manager — does the executive believe the PM understands the business constraints and is managing them?

**WHY:** Mapping specific concerns (not just domains) before stakeholder conversations ensures you enter each meeting informed. It also lets you structure the prototype walkthrough to specifically address the concerns most relevant to that stakeholder — which is more efficient and more likely to surface real objections.

### Step 3: Build 1:1 Stakeholder Relationships Before Preview Sessions

Before scheduling preview sessions, ensure you have an ongoing relationship with each key stakeholder:

- Meet regularly with key stakeholders (target: half an hour weekly or every two weeks per stakeholder)
- Understand their constraints by listening first — ask what they worry about, what constraints they operate under, what makes their work harder
- Share product learnings openly and continuously — after every user test or customer visit, brief relevant stakeholders on what you learned
- Share credit — ensure stakeholders see the product as a shared success, not the product manager's solo effort

**WHY:** Stakeholders who trust the product manager give latitude for better solutions. Stakeholders who do not trust the product manager escalate or attempt to control the product. Trust is built through demonstrated competence and genuine concern for their constraints — not through status updates. A stakeholder encountered cold in a group meeting will protect themselves; a stakeholder who knows and trusts you will collaborate.

The target is 2-3 hours per week total across all key stakeholders, not a one-time review.

### Step 4: Conduct 1:1 Preview Sessions with High-Fidelity Prototypes

Schedule individual meetings with each applicable stakeholder. Do not aggregate into a group meeting.

**Session format:**
1. Remind the stakeholder of the product goal and the specific risk you are testing
2. Walk them through the high-fidelity prototype (PM drives — this is a walkthrough, not a user test)
3. Explicitly invite them to raise concerns — give them every chance to spot problems
4. Listen without defensiveness; capture every concern
5. Do not negotiate in the meeting — acknowledge concerns and commit to following up with evidence

**Critical rules for these sessions:**

Use a **high-fidelity prototype, not a presentation.** A lawyer needs to see the actual proposed screens and wording. A marketing leader needs to see the actual product design. A security leader needs to see exactly what the product does with data. Slide decks are too ambiguous to test viability — stakeholders will agree to something they have not actually seen, then object when they see the real product.

Conduct **1:1 meetings, not group sessions.** Group meetings produce design-by-committee dynamics and mediocre results. In a group setting, stakeholders perform for each other rather than engage with the actual constraints. Individual sessions give each stakeholder space to raise concerns without political pressure.

**WHY behind the walkthrough format:** The purpose of a stakeholder preview session is different from a user test and different from a demo:
- **User test** — user drives the prototype; goal is to test usability and value with real users
- **Product demo** — PM drives, goal is to sell or persuade (evangelism context)
- **Stakeholder walkthrough** — PM drives, goal is to give the stakeholder every opportunity to identify problems before build

Full taxonomy and technique comparison: `references/prototype-review-taxonomy.md`

### Step 5: Resolve Disagreements with Data, Not Opinion

When a stakeholder raises an objection:

1. **Do not resolve by seniority** — the fact that a stakeholder is more senior does not make their opinion correct. This is a common trap that produces bad outcomes and erodes product team credibility.
2. **Do not resolve by PM authority** — asserting product authority does not address the constraint.
3. **Resolve by running a test** — quickly generate evidence relevant to the disagreement. Move the conversation from competing opinions to shared data.

Practical approaches:
- Run a targeted user test to test the disputed design assumption
- Model the disputed economics with finance (cost per unit, provisioning cost at scale)
- Get a legal opinion in writing rather than debating legal risk in the room
- Run a limited market test to answer the marketing or sales concern empirically

**WHY:** Stakeholders who lose opinion battles feel disrespected and disengage. Stakeholders who are shown evidence that neither party's original intuition was fully right become collaborative. Discovery exists specifically to generate this kind of evidence at low cost — use it to resolve disagreements before they become political.

### Step 6: Produce the Viability Sign-Off Document

After completing all stakeholder sessions, produce a structured document capturing the outcome.

```
# Business Viability Sign-Off: [Product/Feature Name]

## Solution Summary
[One paragraph: what is being proposed]

## Prototype Version Used
[Version/date of high-fidelity prototype shown to stakeholders]

## Stakeholder Domain Review

| Domain | Applicable | Stakeholder | Session Date | Status | Open Items |
|--------|-----------|-------------|--------------|--------|------------|
| Marketing | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | [Any unresolved items] |
| Sales | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |
| Customer Success | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |
| Finance | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |
| Legal | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |
| Business Development | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |
| Security | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |
| Executive | Yes/No | [Name] | [Date] | Cleared / Conditional / Blocked | |

## Unresolved Items and Resolution Plan
[For any domain with status Conditional or Blocked: what is the specific issue, what evidence is needed to resolve it, and who owns resolution?]

## Decision
[ ] All applicable domains cleared — proceed to build
[ ] Conditional clearance — proceed with the following constraints: [list]
[ ] Blocked — do not proceed; revisit solution design

## Constraints Carried Forward
[Any constraints stakeholders confirmed that must be respected in the build — e.g., "must not expose PII to the LLM API per legal review", "pricing must not undercut enterprise tier per sales leadership"]
```

## PM Evangelism During Viability Testing

Stakeholder preview sessions are both a testing activity and an evangelism activity. These 10 practices build the organizational support that makes viability testing effective:

1. **Use the prototype** — not slides, not words. The prototype makes the solution concrete for everyone who cannot visualize from a description.
2. **Share the customer pain** — bring engineers and stakeholders to customer visits so they experience the problem directly. People who have seen the pain are more willing to accept solutions that address it.
3. **Connect to the product vision** — show stakeholders how this solution fits into the larger product direction and company strategy.
4. **Share learnings after every test** — distribute what you learned from user tests and customer sessions. Include what failed, not just what worked.
5. **Share credit generously** — ensure stakeholders see the product as a collective achievement. When things go wrong, step forward and take responsibility.
6. **Learn to give great demos** — a product demo is a persuasion tool, not training and not a user test. Develop this skill for customer and executive contexts.
7. **Build 1:1 relationships before group meetings** — never let a group meeting be the first time a stakeholder engages with your thinking. Individual relationships make group conversations productive.
8. **Be genuinely excited** — if you are not genuinely excited about what you are working on, that is a signal about the work or your role. Forced enthusiasm is detectable and counterproductive.
9. **Show enthusiasm visibly** — enthusiasm is contagious. People follow genuine energy. Make yours visible.
10. **Spend face time** — you cannot build trust through email. Regular in-person or video time with your designer, engineers, and key stakeholders is a direct investment in team velocity.

**WHY:** Business viability testing requires stakeholder trust to work. Stakeholders who trust the product manager surface real concerns early. Stakeholders who distrust the product manager either withhold concerns until too late or attempt to control the product. Evangelism practices build the trust that makes stakeholders collaborative.

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| Product solution description | Yes | What is being proposed in sufficient detail to expose constraints |
| High-fidelity prototype | Yes | Stakeholders need to see actual screens/wording — not slides |
| Business model context | Yes | Revenue model, pricing, distribution channels, partner agreements |
| Stakeholder map | Yes | Who holds authority over each applicable domain |
| Risk assessment output | Yes | From product-discovery-risk-assessment — confirms viability risk is Medium/High |
| Known stakeholder concerns | Recommended | Any constraints already identified before sessions begin |

## Outputs

- Stakeholder domain review table (completed, with status per domain)
- Viability sign-off document (structured output from Step 6)
- Constraints carried forward list (binding constraints the build must respect)
- Open items and resolution plan (for any Conditional or Blocked domains)

## Key Principles

1. **Never show finished solutions** — preview during discovery, before build. The most common and costly stakeholder management mistake is showing a completed product at review, only to discover a launch-blocking constraint that requires rework.
2. **High-fidelity prototypes, not presentations** — presentations are too ambiguous for viability testing. Lawyers need to see the actual wording. Marketers need to see the actual design. Executives need to see the actual product behavior.
3. **1:1 sessions, not group reviews** — group meetings produce design by committee. Individual sessions surface real constraints without political dynamics.
4. **Resolve with data, not opinion or seniority** — when a PM opinion conflicts with a stakeholder opinion, run a test. The stakeholder is usually more senior; the answer is not to concede but to generate evidence.
5. **The product manager owns viability** — not legal, not finance, not the CEO. It is the PM's job to understand every applicable constraint and bring that knowledge into the product team before build.
6. **Trust is the precondition** — stakeholders who trust the PM give latitude and surface concerns early. Stakeholders who distrust the PM escalate or attempt to control. Trust is built through demonstrated competence and genuine care for stakeholder constraints.

## Examples

### Example: Freemium Tier for Enterprise Security Product

**Scenario:** A security product team wants to launch a freemium tier. Sales is worried about cannibalization of enterprise deals. Legal has compliance concerns for free-tier users. The CEO wants to see unit economics before committing.

**Step 1 — Applicable domains:**
- Sales: Yes — freemium changes what the sales force sells and potentially undercuts their pipeline
- Legal: Yes — free-tier users may be subject to different compliance obligations (data retention, audit logging)
- Finance: Yes — CEO wants unit economics; provisioning costs for free-tier users must be modeled
- Marketing: Yes — freemium tier affects brand positioning (enterprise premium vs. broad access)
- Customer Success: Yes — free-tier users may generate high support volume at low revenue
- Security: Monitor — freemium may change data isolation requirements
- Business Development: Not applicable (no partner agreements affected)
- Executive: Yes — CEO has explicitly flagged concern

**Step 2 — Specific concerns mapped:**
- Sales: Can sales still close enterprise deals if prospects start on free tier? Does free-tier cap the deal size?
- Legal: Do free-tier users get the same data processing agreements? Are audit logs required for free users in regulated industries?
- Finance: What is the cost to provision each free-tier user? At what conversion rate is the tier profitable?
- CEO: What is the strategic bet — growth via free acquisition or revenue protection?

**Step 3 — Relationship preparation:** PM has standing weekly check-ins with sales leadership and CFO. Legal is a new relationship — PM schedules introductory meeting before the preview session to understand their review process.

**Step 4 — Sessions:**
- Sales leadership: walkthrough of free-tier feature set vs. enterprise feature set using high-fidelity prototype. Sales leader identifies that free tier must not include the SSO feature (enterprise differentiator).
- Legal: walkthrough of free user sign-up flow and data handling screens. Legal identifies that audit log exemption for free users requires explicit terms of service language.
- Finance: co-model unit economics using current infrastructure cost data. Finance clears at 5% conversion rate assumption.
- CEO: walkthrough of full tier structure. CEO clears with constraint: free tier must have a hard cap of 5 users per account.

**Step 5 — No opinion conflicts in this case** — all concerns resolved with data and concrete design decisions.

**Step 6 — Sign-off document:**
- Sales: Cleared — constraint: SSO excluded from free tier
- Legal: Cleared — constraint: audit log exemption requires specific ToS language
- Finance: Cleared — at 5% conversion rate assumption; monitor if below 3%
- Marketing: Cleared — positioning as "try before you buy" consistent with enterprise brand
- Customer Success: Conditional — support volume model must be revisited if free-tier adoption exceeds 10,000 users/month
- Security: Monitor — no new concerns surfaced
- CEO: Cleared — constraint: 5-user hard cap per free account

**Decision:** Conditional clearance — proceed with constraints listed above.

## Anti-Patterns

- **Scheduling a group review meeting with all stakeholders** — produces design by committee, political dynamics, and superficial sign-off. Individual sessions surface real constraints.
- **Using a slide deck presentation** — stakeholders agree to abstractions and object to the real product. High-fidelity prototype is required.
- **Waiting until after build to show stakeholders** — the most common failure mode. Discovery is the time for viability testing, not post-build review.
- **Resolving disagreements by invoking seniority or PM authority** — generates resentment and suppresses legitimate constraints. Run a test instead.
- **Treating all viability stakeholders as equal** — apply the veto test. Only engage domains with real launch-blocking authority. Do not create bureaucracy by including everyone who has an opinion.
- **Conflating walkthrough with user test** — in a user test, the user drives and the PM observes. In a stakeholder walkthrough, the PM drives and gives the stakeholder every opportunity to spot problems. These are different techniques with different purposes.

## References

- `references/stakeholder-domain-concerns.md` — Detailed concern categories for all 8 stakeholder domains with specific questions to ask and signals to look for
- `references/prototype-review-taxonomy.md` — Full comparison of user test vs. product demo vs. stakeholder walkthrough: who drives, what the purpose is, and when to use each
- `references/pm-evangelism-practices.md` — Elaboration of all 10 evangelism practices with application guidance for stakeholder management contexts

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.

## Related BookForge Skills

Install related skills from ClawhHub:
- `clawhub install bookforge-product-discovery-risk-assessment`

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/pm-evangelism-practices.md
# PM Evangelism Practices

10 practices for product managers to build organizational support — "selling the dream" — across teams, stakeholders, executives, and investors. Evangelism is a core PM responsibility, not a soft skill addendum. It is the mechanism by which the product team gets the latitude to build the best possible solutions.

Source: INSPIRED, Ch. 31 (Product Evangelism, pp.151-153)

---

## Why Evangelism Matters

Product evangelism is "selling the dream" — helping people imagine the future and inspiring them to help create it. Without it, product efforts get derailed before they see the light of day. Even if the product ships, it withers without organizational belief behind it.

Evangelism is especially critical in larger companies, where products must navigate internal politics, competing priorities, and stakeholders who have the power to block or undermine progress. It is also a precondition for effective business viability testing: stakeholders who trust the product manager surface constraints early and collaboratively; stakeholders who do not trust the PM escalate or attempt to control.

---

## The 10 Practices

### 1. Use a Prototype

When communicating what you are building, use a prototype — not user stories, not slide decks, not verbal descriptions.

User stories and backlogs make it nearly impossible for most people to see the big picture or understand how the pieces hang together. A prototype lets people see the forest and the trees simultaneously. It makes abstract ideas concrete enough to inspire genuine reactions.

**Application to viability testing:** Prototypes are the required medium for stakeholder walkthrough sessions. They are not optional.

---

### 2. Share the Pain

Show the team and stakeholders the customer pain you are addressing — do not just describe it.

The most effective technique is bringing engineers, designers, and key stakeholders to actual customer visits and meetings. For most people, witnessing a customer struggle or articulate frustration is qualitatively different from reading a summary of customer feedback. The emotional reality of the problem motivates better solutions and more committed teams.

**Application to viability testing:** When a stakeholder is uncertain about the value of a proposed solution, showing them the customer pain directly (or sharing video from user research sessions) is more persuasive than data alone.

---

### 3. Share the Vision

Demonstrate that you have a clear, coherent understanding of the product vision, product strategy, and product principles. Show how the work you are proposing contributes to that vision and is consistent with the principles.

People follow vision. When stakeholders understand where the product is headed and see how each decision fits that direction, they invest. When they cannot see the connection, they question and resist.

**Application to viability testing:** Framing a stakeholder session with the product vision ("here is what we are trying to accomplish and why this fits that direction") before showing the prototype creates context that makes the session more productive.

---

### 4. Share Learnings Generously

After every user test or customer visit, share what you learned — including what did not work, not just what did.

Teams that hoard discovery learnings create information asymmetry that breeds distrust. Teams that share openly build a shared understanding of the customer and the problem. Stakeholders who know what you have learned trust you to make decisions they cannot second-guess.

**Application to viability testing:** Continuously sharing test learnings means stakeholders are not encountering your thinking for the first time in a preview session. They are building on an ongoing conversation.

---

### 5. Share Credit Generously

Ensure the team views the product as theirs, not just the product manager's. When things go well, attribute success to the collective.

When things go wrong, step forward and take responsibility yourself. Show the team you are learning from mistakes as well. This earns respect and creates psychological safety for honest collaboration.

**Application to viability testing:** Stakeholders who feel their input shaped the solution are more committed to making it succeed. Crediting a finance leader for identifying the unit economics constraint that improved the solution turns a potential blocker into an advocate.

---

### 6. Learn to Give Great Demos

A product demo is a persuasion tool — not training, not a user test. Giving a great demo is a specific skill that requires practice and deliberate development.

A great demo:
- Shows the most compelling value as quickly as possible
- Does not teach the audience how to use the product (that is training)
- Does not ask the audience to interact with the product (that is a user test)
- Tells a story — a before/after narrative of the customer's world

**Application to viability testing:** The stakeholder walkthrough is not a demo. But the ability to give great demos matters for evangelical conversations with executives and customers that build organizational support for the product direction.

---

### 7. Do Your Homework

Become the undisputed expert on your users, your customers, your market, your competitors, and your business. Your team and stakeholders will follow you if they believe you know what you are talking about.

This credibility is not optional. It is the foundation of the trust that gives you latitude. A stakeholder who doubts your customer knowledge will second-guess your product decisions. A stakeholder who believes you know the customer better than anyone will defer to your judgment.

**Application to viability testing:** An executive can assess very quickly whether a product manager has done their homework. Walking into a CEO session having already identified and addressed the relevant stakeholder concerns demonstrates the competence that earns trust.

---

### 8. Be Genuinely Excited

If you are not genuinely excited about what you are working on, that is a signal — either about the work or about your role. Address it, rather than performing enthusiasm you do not feel.

Sincere excitement is detectable and motivating. Performed enthusiasm is also detectable and does the opposite — it signals that even the product manager does not really believe in what they are building.

**Application to viability testing:** Stakeholders respond to genuine belief. When a PM walks into a stakeholder session with real conviction about the value of what is being proposed, the session starts from a different place than when the PM is going through motions.

---

### 9. Learn to Show Enthusiasm

Genuine excitement is necessary but not sufficient — you also have to make it visible. Many product managers are genuinely excited but culturally conditioned to suppress visible enthusiasm, which reads as indifference.

Enthusiasm is contagious. It changes the energy of a room. It gives people permission to be excited as well.

**Application to viability testing:** The difference between a stakeholder who leaves a preview session as a cautious approver and one who leaves as an active advocate often comes down to whether the PM's genuine belief in the solution was visible.

---

### 10. Spend Face Time

You cannot build the trust that underpins effective stakeholder relationships through email, Slack, or status reports. Regular in-person or video face time — even brief — is essential.

If the team is not co-located, make the effort to travel for face time at least every few months. The investment pays off in team motivation and velocity. For stakeholders, a weekly 30-minute coffee or lunch is the recommended cadence.

**Application to viability testing:** The target for stakeholder engagement is 2-3 hours per week total across all key stakeholders — not a burst of activity before a launch review. Relationships built through ongoing face time make preview sessions collaborative rather than adversarial.

---

## Evangelism and Company Scale

At startups, the founder or CEO typically owns evangelism with customers and investors. Product managers at startups may be called on to help.

At midsize to large companies, product marketing typically handles evangelism with customers and the sales force. The product manager's evangelism responsibility focuses primarily on the internal team — engineers, designers, and stakeholders. The best thing a PM can do for customers is build a great product; the evangelism work that enables that is internal.

Even in large companies, the product manager may be called on for evangelism in high-value customer conversations and key partnerships. The demo and evangelism skills are always relevant.

FILE:references/prototype-review-taxonomy.md
# Prototype Review Taxonomy

Three distinct techniques for "showing a prototype." Each has a different purpose, a different driver, and different success criteria. Using the wrong technique for the situation produces misleading results.

Source: INSPIRED, Ch. 56 sidebar "User Test versus Product Demo versus Walkthrough" (p.281)

---

## The Three Techniques

| Dimension | User Test | Product Demo | Stakeholder Walkthrough |
|-----------|-----------|-------------|------------------------|
| **Who drives** | User drives | PM drives | PM drives |
| **Purpose** | Test usability and value | Sell or persuade | Surface problems and constraints |
| **What it is** | A testing technique | A persuasion tool | A review and discovery technique |
| **Audience** | Real target users or customers | Prospective customers, prospects, executives (evangelism) | Internal stakeholders with veto authority |
| **Success signal** | User can complete tasks without help; verbalizes genuine value | Audience understands and wants what is being proposed | Stakeholder surfaces real constraints; PM learns what must change |
| **Failure signal** | User cannot complete tasks or does not see value | Audience is confused or unconvinced | Stakeholder gives polite approval without engaging; real concerns surface post-build |

---

## User Test

**What it is:** A qualitative testing technique where the target user or customer interacts with the prototype to complete a scenario or task. The PM and designer observe without guiding.

**Who drives:** The user drives. The PM facilitates but does not demonstrate, explain, or guide.

**Purpose:** To test whether the solution is usable and valuable. The PM is looking for:
- Can the user figure out how to use this without help?
- Does the user understand what the product does and why it is valuable to them?
- Where does the user get stuck, confused, or make incorrect assumptions?

**When to use:** When usability risk or value risk is being validated. This is part of testing usability and value with customers — distinct from business viability testing.

**What it is NOT:**
- It is not training (the PM does not teach the user)
- It is not a demo (the PM does not drive or show off features)
- It is not a stakeholder review (internal business constraints are not the focus)

**Critical technique note:** If the PM helps the user during a user test — even by pointing or explaining — the test is invalidated. The user's confusion is the data. Do not resolve their confusion during the session.

---

## Product Demo

**What it is:** A scripted presentation of the product or prototype, driven by the PM or product marketing, intended to show the value of what is being built.

**Who drives:** The PM (or product marketing) drives.

**Purpose:** To sell, persuade, or evangelize. The PM is trying to:
- Show the audience what the product can do
- Make the value proposition clear and compelling
- Create excitement or buy-in (with customers, prospects, or internal stakeholders)

**When to use:**
- With high-value customers or prospects who need to understand product direction
- With senior executives who need to see the vision, not just hear about it
- For internal evangelism — helping engineers, designers, and other stakeholders see the whole picture

**What it is NOT:**
- It is not a user test — the audience is not being tested
- It is not a walkthrough — the goal is persuasion, not problem-finding
- It is not training — the goal is to show value, not teach usage

**Critical note:** A demo is a persuasion tool. Get very good at it. This is a skill that pays off in customer relationships and executive alignment. A demo should be rehearsed, scripted for key moments, and timed to show the most compelling value quickly.

---

## Stakeholder Walkthrough

**What it is:** A structured 1:1 review session where the PM walks through the high-fidelity prototype with a specific stakeholder, giving the stakeholder every opportunity to identify problems or raise concerns.

**Who drives:** The PM drives (unlike a user test).

**Purpose:** To surface business viability constraints before build. The PM is trying to:
- Show the stakeholder what is being proposed in sufficient fidelity to trigger real reactions
- Give the stakeholder a genuine opportunity to raise every concern they have
- Learn what must change before the solution can be launched

**When to use:** During business viability testing, with each applicable stakeholder domain (marketing, sales, legal, finance, etc.). Always 1:1, never in a group setting.

**What it is NOT:**
- It is not a demo — the goal is not persuasion; it is problem-finding
- It is not a user test — the stakeholder is not a target user; they are a business constraint holder
- It is not a presentation — slides are too abstract to surface real constraints; the actual prototype is required

**Critical notes:**
1. **Invite concerns explicitly.** Tell the stakeholder: "I want you to tell me everything you see as a problem. Your concerns are exactly what I need." Do not present as if seeking approval.
2. **Do not negotiate in the session.** When a concern is raised, acknowledge it and commit to resolving it — do not defend the current design in the moment.
3. **Use high-fidelity prototypes, not presentations.** A lawyer needs to see the actual screen wording to assess legal exposure. A marketing leader needs to see the actual design to assess brand fit. Presentations are too abstract.
4. **1:1 only.** Group sessions produce committee dynamics. Stakeholders in a group perform for each other and withhold concerns that might make them look obstructionist. Individual sessions produce honest engagement.

---

## Choosing the Right Technique

| Situation | Technique to Use |
|-----------|-----------------|
| Validating whether users can use the product | User test |
| Validating whether users see genuine value | User test |
| Presenting the product to a key customer or prospect | Product demo |
| Helping engineers or non-product stakeholders see the vision | Product demo |
| Checking whether a marketing leader sees brand concerns | Stakeholder walkthrough |
| Checking whether legal sees compliance exposure | Stakeholder walkthrough |
| Checking whether sales can sell this | Stakeholder walkthrough |
| Getting executive sign-off before committing to build | Stakeholder walkthrough |

---

## Common Mistakes

**Running a group walkthrough instead of 1:1 sessions:** Produces design-by-committee results. Stakeholders in groups anchor to each other's opinions rather than engaging with their own constraints. One person's political concern poisons the group's ability to think clearly.

**Using a presentation for a stakeholder walkthrough:** The lawyer agrees to a concept but objects to the actual screen wording. The marketing leader agrees to the idea but is uncomfortable with the visual design. The executive agrees to the direction but is surprised by the actual experience. All of these are predictable failures from using presentations instead of prototypes.

**Running a user test as a demo:** You are explaining the product to the user instead of observing them interact with it. This invalidates the test data and wastes the session.

**Running a demo as a user test:** You present features to the user and conclude they "get it" because they nodded along. User tests require the user to drive — nodding during a demo is not validation.

FILE:references/stakeholder-domain-concerns.md
# Stakeholder Domain Concerns

Detailed concern categories for each of the 8 stakeholder domains used in business viability testing. For each domain: who typically holds authority, what they care about, specific concern signals to look for, and the right questions to ask in a preview session.

Source: INSPIRED, Ch. 56 (Testing Business Viability, pp.277-281)

---

## 1. Marketing

**Who holds authority:** Head of Marketing, VP Marketing, Product Marketing lead

**What marketing cares about:**
- Enabling sales through effective positioning and messaging
- Protecting and enhancing the company's brand and reputation
- Market competitiveness and differentiation
- Go-to-market channel effectiveness

**Specific concern signals:**
- Solution falls outside the company's established brand promise (the range of things customers expect from this company)
- Solution requires a different go-to-market channel than what currently exists (e.g., direct sales product sold through PLG/self-serve, or vice versa)
- Solution messaging conflicts with current product positioning or market segment strategy
- Solution could undermine differentiation by commoditizing a premium feature
- Solution requires marketing campaigns the company does not have budget or capability for

**Questions to ask in the preview session:**
- "Does this fit within the brand promise our customers expect from us?"
- "Would this require changes to our current go-to-market motion?"
- "Does this conflict with any current marketing programs or positioning commitments?"
- "Is there anything here that would be difficult to message or that could confuse existing customers?"

---

## 2. Sales

**Who holds authority:** VP Sales, Sales leadership, Head of Sales Engineering

**What sales cares about:**
- Channel capability — the sales force can only sell what it is equipped to sell
- Price point alignment — high-touch direct sales requires high-value price points to justify the cost of sale
- Skill and knowledge requirements — new product types may require sales skills the team does not have

**Specific concern signals:**
- Solution requires sales to explain a new paradigm or technology category the sales force is not trained on
- Solution is priced at a point incompatible with the existing sales model (e.g., low-ACV product requiring high-touch enterprise sales)
- Solution competes with or cannibalizes existing deals or product lines the sales force is currently selling
- Solution requires different buyer relationships (e.g., selling to engineering rather than business executives)
- Solution changes deal structure (e.g., introducing usage-based pricing when the sales team sells annual contracts)

**Questions to ask in the preview session:**
- "Can your sales force sell this with the skills and relationships they currently have?"
- "Is the price point compatible with your sales motion?"
- "Does this create any conflict with deals you are currently working?"
- "What would you need to train your team to sell this effectively?"

---

## 3. Customer Success

**Who holds authority:** Head of Customer Success, VP Customer Success

**What customer success cares about:**
- Alignment between product complexity and the company's service model (high-touch vs. low-touch)
- Support burden — new features create new categories of customer questions and failure modes
- Onboarding scalability — can customers be successfully onboarded at current staffing levels?

**Specific concern signals:**
- Solution introduces a complex workflow that will generate high support volume
- Solution requires configuration or setup that customers cannot do without hand-holding
- Solution changes the onboarding model (e.g., self-serve product with a complex enterprise feature that requires human setup)
- Solution affects SLA commitments to existing customers
- New user segment (e.g., free-tier users) will need support at a volume the team cannot sustain

**Questions to ask in the preview session:**
- "Would this change the volume or nature of support requests you receive?"
- "Can customers be successfully onboarded without additional staffing?"
- "Is this consistent with our high-touch / low-touch service model?"
- "Are there any aspects of this that would be hard for customers to self-serve?"

**Note:** In companies with a high-touch service model, customer success teams are exceptionally helpful for product insights and prototype testing — they have deep knowledge of customer failure patterns.

---

## 4. Finance

**Who holds authority:** CFO, Head of Finance, Business Analytics

**What finance cares about:**
- Unit economics — can the company afford to build, sell, and operate the product at scale?
- Pricing model viability — does the pricing generate sufficient gross margin?
- Provisioning costs — infrastructure, licensing, or operational costs per unit
- Reporting and compliance — does the solution affect financial reporting, investor relations, or financial controls?

**Specific concern signals:**
- Solution relies on a third-party service (e.g., LLM API, data provider) with uncertain or high per-unit costs
- Solution pricing does not generate sufficient margin to cover provisioning and support costs
- Solution introduces a new pricing model (usage-based, freemium, consumption) that requires finance modeling
- Solution creates a new product line that changes revenue recognition accounting
- Investor relations concern — solution affects metrics investors track or creates financial disclosure requirements

**Questions to ask in the preview session:**
- "Can we model the unit economics together? What assumptions should we use for provisioning costs?"
- "At what scale does this become profitable, and is that realistic?"
- "Are there any financial reporting or compliance implications I should be aware of?"
- "Is the pricing model compatible with how we recognize revenue?"

---

## 5. Legal

**Who holds authority:** General Counsel, Legal team, Compliance team

**What legal cares about:**
- Privacy — data collection, storage, and transmission practices that create regulatory exposure
- Regulatory compliance — industry-specific regulations (GDPR, HIPAA, CCPA, SOC 2, PCI-DSS, etc.)
- Intellectual property — use of third-party IP, open source license compliance, patent exposure
- Competitive constraints — existing agreements that limit competitive positioning or market entry
- Contractual obligations — commitments to enterprise customers in existing contracts

**Specific concern signals:**
- Solution collects or processes personal data in new ways
- Solution transmits user data to third parties (APIs, analytics, LLMs)
- Solution enters a regulated industry segment (healthcare, finance, government)
- Solution uses open source components with restrictive licenses
- Solution could be construed as competing with a strategic partner protected by agreement

**Questions to ask in the preview session:**
- "Are there any privacy concerns with how this solution handles user data?"
- "Does this create any regulatory compliance requirements I should understand?"
- "Are there any IP constraints with the technology or content we are proposing to use?"
- "Are there existing customer contracts that this could violate?"
- "What specific language, screens, or data flows should I make sure are reviewed before we build?"

**Practical note:** Legal needs to see the actual proposed screens, wording, and data flows — not a description. Presentations are too abstract for legal review.

---

## 6. Business Development

**Who holds authority:** VP Business Development, Head of Partnerships, Strategic Alliances lead

**What business development cares about:**
- Existing partner agreements — contracts with commitments and constraints that the company must honor
- Partner alignment — whether the solution affects value delivered to or through key partners
- Competitive boundaries — whether the solution violates exclusivity or non-compete provisions in partner agreements

**Specific concern signals:**
- Solution integrates with or competes against a product covered by an existing partnership agreement
- Solution changes the data or value exchanged with a key distribution partner
- Solution enters a market segment covered by a partner exclusivity arrangement
- Solution changes API terms or access in ways that affect existing integration partners

**Questions to ask in the preview session:**
- "Are there any existing partner agreements that constrain what we can build here?"
- "Does this affect any of our key partner relationships?"
- "Are there commitments in existing contracts that we need to honor in the design?"

---

## 7. Security

**Who holds authority:** Chief Information Security Officer, Head of Security Engineering, Security Lead

**What security cares about:**
- Data protection — what new data the solution handles and how it is secured
- Access control — new permission boundaries or authentication requirements
- Attack surface — whether the solution introduces new vulnerability exposure
- Compliance with security standards — SOC 2, ISO 27001, penetration testing requirements

**Specific concern signals:**
- Solution stores or transmits sensitive user or enterprise data
- Solution introduces new API endpoints or integrations with external services
- Solution changes user authentication or authorization model
- Solution handles payment data, health data, or government-regulated data categories
- Solution is customer-facing infrastructure with new exposure to external attack

**Questions to ask in the preview session:**
- "What data will this solution handle, and does that create any security concerns?"
- "Does this change our authentication or access control model in any way?"
- "Are there security review requirements that we need to schedule before launch?"
- "Is there anything here that would require a penetration test or security audit?"

**Note:** Security is often considered part of the engineering organization rather than an independent stakeholder, but the issues are significant enough to warrant explicit, early engagement for any solution touching sensitive data or external exposure.

---

## 8. Executive (CEO/COO/GM)

**Who holds authority:** Chief Executive Officer, Chief Operating Officer, General Manager of the business unit

**What executives care about:**
- Overall business risk — whether the solution could harm the company's revenue, reputation, employees, or customers
- Strategic alignment — whether the solution fits the company's direction and priorities
- Trust in the product manager — whether the PM understands the business well enough to be trusted with this decision
- Cross-functional coordination — whether all relevant constraints have been identified and managed

**Specific concern signals:**
- PM has not engaged all relevant stakeholder domains before seeking executive sign-off
- Solution represents a significant strategic departure that has not been discussed at the leadership level
- Executive has unresolved concerns that subordinates have not been able to resolve
- Executive is unaware of the discovery approach and needs context on why they are being shown a prototype rather than a finished product

**Questions to ask in the preview session:**
- "Are there business risks in this direction that I should be thinking about?"
- "Does this align with where you want to take the company in this area?"
- "Are there constraints I may have missed in my stakeholder conversations?"
- "Are you comfortable with the approach we are taking, given what you have seen?"

**Critical note:** Executives assess product managers quickly. An executive will rapidly determine whether the PM has done the homework — understands the users, the market, the technology, and the business. If the PM demonstrates this competence, the executive gives latitude. If not, the executive attempts to control the product. The preview session is as much a credibility moment as a constraint-gathering exercise.

---
name: social-proof-optimizer
description: Optimize social proof strategy using uncertainty and similarity conditions. Use this skill when designing testimonials, reviews, user counts, case studies, social validation signals, trust badges, FOMO messaging, herd behavior cues, peer influence copy, bystander effect awareness, landing page trust signals, customer stories, social media proof, community size claims, star ratings, product popularity indicators, referral social proof, expert endorsements, or any persuasion element that relies on others' behavior to guide decisions. Also use when auditing social proof for manufactured or fake signals, evaluating whether current testimonials are credible, detecting pluralistic ignorance in a group context, or designing a defense against manipulated social evidence.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/influence-psychology-of-persuasion/skills/social-proof-optimizer
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: influence-psychology-of-persuasion
    title: "Influence: The Psychology of Persuasion"
    authors: ["Robert B. Cialdini"]
    chapters: [4]
tags: [persuasion, social-proof, testimonials, reviews, trust-signals, landing-page, FOMO, herd-behavior, peer-influence, social-validation, bystander-effect, manufactured-proof, copywriting, conversion]
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Marketing asset, landing page copy, campaign plan, or social proof inventory — the content or strategy to be optimized"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Any agent environment. Document set preferred: landing pages, testimonial strategies, ad copy, social media campaigns."
---

# Social Proof Optimizer

## When to Use

You are designing, auditing, or improving how a product, service, or campaign uses evidence of others' behavior to influence decisions. Typical triggers:

- Writing or auditing landing page copy that includes testimonials, user counts, or reviews
- Designing a testimonial collection strategy
- Evaluating whether existing social proof is credible and well-placed
- Building a social media campaign that leverages peer influence or community behavior
- Detecting whether social proof signals in a competitor or partner's materials are manufactured
- Planning a content strategy that uses case studies or customer stories as trust signals
- Responding to a situation where bystander inaction is a risk (emergency, low-engagement community)

Before starting, identify the **mode**:
- **Application** — you are designing or improving social proof
- **Defense** — you are evaluating whether social proof is genuine or being manufactured against you
- **Both** — apply and audit in the same pass

---

## Context & Input Gathering

### Required Context (must have — ask if missing)

- **The target audience:** Who is being influenced — their demographics, experience level, and relationship to the decision
  → Check prompt for: audience description, customer persona, target market
  → Ask if missing: "Who is the primary audience for this social proof? (e.g., first-time buyers, enterprise decision-makers, existing customers considering an upgrade)"

- **The decision or action being influenced:** What you want the audience to do after seeing the social proof
  → Check prompt for: conversion goal, CTA, desired behavior
  → Ask if missing: "What specific action should the social proof motivate? (e.g., sign up, purchase, request a demo, share content)"

- **Current social proof inventory:** What testimonials, reviews, user counts, or social signals already exist
  → Check environment for: existing copy, testimonial docs, review excerpts, landing page files
  → If unavailable: proceed with design-from-scratch approach

### Observable Context (gather from environment)

- **Existing copy structure:** Read landing page or campaign docs to identify where social proof currently appears
- **Audience similarity signals:** Look for customer demographics in existing testimonials to assess similarity gap
- **Proof type already in use:** Categorize what kind of social proof is already deployed (numbers, quotes, logos, media mentions)

### Default Assumptions

- If no audience defined → assume a cold prospect with moderate uncertainty (highest-stakes scenario)
- If no current proof inventory → assume starting from scratch
- If mode not specified → run both Application and Defense passes

---

## Process

### Step 1: Assess Uncertainty Level

**ACTION:** Score the audience's uncertainty about the decision on a 1–5 scale. Use the observable signals below to assign the score.

**WHY:** Social proof operates most powerfully under uncertainty. When people are unsure of the correct action, they look to others for behavioral cues — this is the mechanism that makes social proof effective. When the audience already has high confidence (low uncertainty), social proof adds little. When uncertainty is high, social proof can be the primary driver of behavior. Matching proof intensity to uncertainty level prevents over-engineering low-uncertainty contexts and under-investing in high-uncertainty ones.

| Score | Uncertainty signals | Social proof impact |
|---|---|---|
| 1 | Expert audience, familiar decision, established habit | Low — they trust their own judgment |
| 2 | Some familiarity, minor doubts | Moderate — proof provides reassurance |
| 3 | Mixed familiarity, real alternatives exist | Significant — proof tips the balance |
| 4 | Unfamiliar category, high stakes, first-time decision | High — proof is a primary cue |
| 5 | New category, complex product, ambiguous outcomes | Dominant — proof is the main decision driver |

**IF uncertainty score ≥ 3** → social proof is a primary lever; invest in all three design dimensions (placement, type, similarity)
**IF uncertainty score ≤ 2** → social proof is supplementary; focus on proof quality over quantity

---

### Step 2: Evaluate Similarity Match

**ACTION:** Assess how closely the social proof sources (testimonial givers, review authors, case study subjects) resemble the target audience.

**WHY:** Social proof operates most powerfully when we observe people similar to ourselves. Similarity triggers the inference "if someone like me found this valuable / made this choice / got this result, it's probably right for me too." Dissimilar proof sources create a gap — the audience notices that the person in the testimonial is not like them and discounts the evidence. The wallet-return experiment illustrates this precisely: 70% of wallets were returned when the previous finder was similar; only 33% when dissimilar. A 2x difference from a single similarity variable.

Evaluate similarity on three dimensions:

| Dimension | High similarity | Low similarity |
|---|---|---|
| **Demographics** | Same age, role, industry, company size as target audience | Different life stage, job function, or context |
| **Problem** | Faced the exact same challenge, pain point, or decision | Different problem, adjacent use case |
| **Outcome expectation** | Seeking the same result or benefit | Pursuing different goals |

**Similarity score:**
- 3/3 match → high-similarity proof (most powerful)
- 2/3 match → moderate-similarity (still useful, note the gap)
- 1/3 or 0/3 match → low-similarity (significant credibility risk)

**IF similarity score is low** → flag as a critical gap; recommend collecting new proof from similar sources before launch; or add context that bridges the gap ("We work with early-stage founders — here's what they say")

---

### Step 3: Identify the Social Proof Sub-Type

**ACTION:** Based on the context, choose the appropriate sub-type of social proof. Match the sub-type to the situation rather than defaulting to testimonials.

**WHY:** Not all social proof works the same way. The mechanism differs by sub-type, and using the wrong one produces weak or counterproductive results. Manufactured proof (even when widely used) carries significant credibility risk if detected — the defense section explains why.

**Three sub-types:**

**Pure social proof** — everyone is uncertain and looking to each other. Effect: behaviors cascade. The bystander effect is the dark version (all waiting for someone else to act); viral adoption is the positive version. Use when: launching into an ambiguous or new category where the proof comes from the sheer number of adopters (user counts, "X,000 companies use this," trending signals).

**Competitive social proof** — demand creates desire. Scarcity or high demand signals quality because "others want it." Use when: the product has genuine high demand or limited availability. Research finding: cookies described as scarce due to demand were rated highest quality, above simply scarce cookies. The demand signal itself carries proof.

**Manufactured social proof** — seeding initial behavior to trigger authentic cascades. Use when: launching cold, with no initial user base (salted tip jars, seeded audiences, pre-loaded review platforms). This is ethically complex — see Step 5 (Defense).

---

### Step 4: Design the Social Proof Strategy

**ACTION:** Specify placement, format, source, and framing for each proof element. Use the optimization checklist.

**WHY:** Even excellent proof fails if placed wrong (buried below the fold), formatted poorly (wall of text vs. scannable), or missing critical similarity signals (no job title, company size, or name). The goal is maximum signal efficiency: each proof element should score on uncertainty reduction AND similarity activation simultaneously.

**Optimization checklist:**

**Placement — where to put proof:**
- Immediately before or beside the primary call to action (highest-uncertainty moment)
- Adjacent to the feature that addresses the audience's biggest objection
- At the top of the page for high-uncertainty audiences (score 4–5) who need proof before they'll read anything else
- At the bottom for lower-uncertainty audiences (score 1–2) who need facts first, then confirmation

**Format — how to present proof:**
- Quote + photo + name + role/company → most credible combination
- Specific outcome over vague praise ("Cut churn by 23% in 60 days" vs. "Amazing product!")
- Numbers when available (user counts, percentage improvements, time savings)
- Video testimonials for high-stakes decisions (enterprise sales, high-ticket products)
- Case study format (problem → process → result) for B2B or complex decisions

**Source selection — who should give the proof:**
- Match demographics to target audience (role, company size, industry, experience level)
- Prioritize sources with the same problem and desired outcome
- Feature multiple similar sources rather than one impressive but dissimilar source (a well-known brand testimonial from an enterprise client means nothing to a solo founder audience)

**Framing — how to contextualize proof:**
- State the similarity explicitly: "From a B2B founder in year 2, just like you..."
- Describe the situation before the outcome: "Before [Product], I was spending 8 hours per week on X"
- Aggregate when individual proof is sparse: "Join 12,000 marketers who..."

---

### Step 5: Check for Manufactured Proof Risks

**ACTION:** Review all planned social proof elements against the authenticity test. Flag anything that fails.

**WHY:** Manufactured proof — canned laughter, salted tip jars, seeded review platforms, planted converts, paid "unrehearsed" testimonials — works precisely because it exploits the automatic nature of social proof. But when audiences detect fakery, the effect reverses completely: the exposure destroys trust and signals that the product could not generate real social proof on its own. The operational claque (Italian opera house hired applauders) worked for centuries partly because the fakery was openly acknowledged. Modern audiences are not so forgiving.

**Authenticity test — for each proof element, ask:**

1. Is this testimonial from a real customer who used the product without any pre-arrangement or compensation?
2. Is the quoted outcome accurately representative — not cherry-picked from the 99th percentile?
3. Is the user count / "X people use this" figure current and verifiable?
4. Are star ratings from a platform the audience trusts and where fake reviews would be detectable?
5. Is any "trending" or "most popular" signal reflecting actual usage, not manufactured demand?

**IF any answer is "no"** → classify as manufactured proof; assess risk level:
- High risk: direct fabrication (actors as customers, fake reviews) — do not use
- Medium risk: cherry-picked outlier results shown without context — add "typical results" disclaimer
- Low risk: selective presentation (showing only positive reviews) — acceptable if representative sample exists; flagged as confirmation bias, not fraud

---

### Step 6: Apply Devictimizing Protocol (Emergency / Low-Engagement Contexts)

**ACTION:** If the context involves a real emergency, a dormant community, or a situation where "bystander apathy" is harming a goal, apply the devictimizing protocol.

**WHY:** In ambiguous group situations, pluralistic ignorance takes hold: everyone looks to others for behavioral cues, sees everyone appearing calm, and concludes nothing is wrong — even when something is very wrong. This produces collective inaction in genuine emergencies, and in business contexts, produces low engagement in communities or campaigns where everyone waits for someone else to go first. The single most effective counter is to break the diffusion of responsibility: identify one specific person, assign a specific task, remove their uncertainty about both the need and their role.

**The protocol:**

In emergencies (physical or urgent digital):
> "You — [identifying detail, e.g., 'in the blue jacket', 'with the red icon'] — call 911 / contact support / take this specific action."

In community or campaign contexts (engagement, participation):
> Identify the first mover explicitly. Name them. Give them a concrete task. Once the first person acts, the cascade follows — social proof of action then works in your favor.

This applies to: cold email campaigns where no one replies first, community launches where everyone waits, product launches where no one wants to be the first buyer, low-response surveys or polls.

---

### Step 7: Defense — Evaluate Incoming Social Proof

**ACTION:** Assess whether social proof being used on you or in your competitive environment is genuine or manufactured. Apply the classification framework.

**WHY:** Social proof is automatic — it triggers before conscious analysis. The defense is not to distrust all social proof (genuine proof is valid and valuable information) but to correctly classify each piece. Once you identify manufactured proof, its claim on your behavior disappears. The automatic pilot should be disengaged only when the data it's receiving is corrupted.

**Two situations that corrupt social proof data:**

**Situation 1 — Deliberate falsification:** Canned responses, hired actors, seeded reviews, planted converts. Detection signals:
- Testimonials with no identifying details (no name, company, role, photo)
- "User count" with no third-party verification
- Reviews that appeared suddenly in large batches
- Reactions that feel performed rather than spontaneous
- Extreme uniformity of praise (no negative details in any testimonial)

**Situation 2 — Innocent error cascade:** Pluralistic ignorance, freeway lane-switching, racetrack betting cascades. No one is lying; everyone is following others who are following others, all assuming the crowd knows something they don't. Detection signals:
- Everyone seems to be doing the same thing with no clear initiator
- The behavior began with an ambiguous trigger (one person changed lanes, one person left the party, one person sold a stock)
- Checking the underlying facts directly reveals no actual signal

**Response:**
- Deliberate falsification → disengage automatic pilot; evaluate the underlying product independently; consider active counterattack (do not purchase products using phony testimonials; where appropriate, call out the practice)
- Innocent cascade → check the objective facts directly rather than reading others' behavior; introduce independent information into the group

---

## Outputs

**For Application mode**, produce a **Social Proof Optimization Plan:**

```
## Social Proof Optimization Plan

**Audience:** [Who they are, role, company size, experience level]
**Decision being influenced:** [Specific action]
**Uncertainty score:** [1–5] — [key signals that drove this score]
**Mode:** Application / Defense / Both

### Similarity Assessment
- Current proof similarity: [High / Moderate / Low]
- Gaps identified: [Which dimensions are mismatched]
- Recommended sources: [Who should give proof for maximum similarity]

### Sub-Type Selection
- Sub-type: [Pure / Competitive / Manufactured (flagged)]
- Rationale: [Why this sub-type fits the context]

### Proof Elements
| Element | Format | Source type | Placement | Similarity score |
|---------|--------|-------------|-----------|-----------------|
| [Testimonial 1] | Quote + photo + name + role | [Customer type] | [Location] | [H/M/L] |
| [User count] | Number + context | [Verified platform] | [Location] | [N/A] |

### Authenticity Flags
- [Element]: [Pass / Flag — reason]

### Devictimizing Actions (if applicable)
- [Specific first-mover prompt or engagement protocol]
```

**For Defense mode**, produce a **Social Proof Audit:**

```
## Social Proof Audit

**Source audited:** [Product / competitor / campaign]
**Proof elements reviewed:** [List]

### Classification
| Proof element | Type | Genuine / Manufactured / Uncertain | Evidence |
|---|---|---|---|
| [Element] | [Testimonial / Count / Rating] | [Classification] | [Why] |

### Automatic Pilot Status
- Recommended: Engage / Disengage / Verify independently
- Rationale: [Key evidence]
```

---

## Examples

**Scenario: Landing page for B2B project management tool targeting solo founders**

Trigger: "Our landing page has testimonials from enterprise companies. Conversion is low for our actual market (solo founders, 1–10 person teams). Help us fix the social proof."

Process:
- Uncertainty score: 4 (first-time SaaS tool purchase, unfamiliar category for non-technical founders)
- Similarity assessment: 0/3 — enterprise testimonials share no demographic, problem, or outcome similarity with solo founders
- Sub-type: Pure social proof (user count + quote format)
- Gap: No current proof from similar audience; enterprise logos are actively working against conversion
- Design: Replace enterprise logos with 3–5 testimonials from solo founders citing specific outcomes ("Went from missing deadlines weekly to shipping on time for 4 months straight — Sarah, freelance designer"); add aggregate user count segmented by company size ("Used by 4,200 solo founders and small teams")
- Placement: Primary testimonials above the fold; secondary use-case proof beside the pricing CTA

Output: Social Proof Optimization Plan with replacement testimonial brief, collection outreach template, and placement diagram.

---

**Scenario: SaaS product launch — zero users, cold start**

Trigger: "We're launching next month. We have no users yet. What social proof strategy do we use?"

Process:
- Uncertainty score: 5 (brand new product, unknown team, new category positioning)
- Similarity assessment: N/A — no existing proof to assess
- Sub-type: Consider competitive social proof (waitlist demand signal) + pure social proof (beta users)
- Strategy: Run a small closed beta (20–50 users) from target audience; collect detailed testimonials during beta; use waitlist count as launch-day social signal ("847 people on the waitlist — now open"); feature beta users prominently with full identifying details
- Devictimizing: For the launch email, name one beta user and their result in the subject line to establish the first public social proof anchor; others follow

Output: Pre-launch proof collection protocol, beta user testimonial interview guide, launch email framework with specific first-mover framing.

---

**Scenario: Auditing a competitor's product page**

Trigger: "A competitor's landing page has 47 five-star testimonials, all from the last 30 days, no names or photos, and claims '10,000 customers.' Should I trust this as a signal of product quality?"

Process:
- Defense mode
- Deliberate falsification signals: no identifying details (no name, role, company), batch appearance (47 in 30 days), unverifiable user count
- Classification: manufactured proof (high confidence)
- Automatic pilot: disengage
- Response: evaluate competitor product on independent signals (third-party review platforms, LinkedIn mentions, press coverage); the social proof data is corrupted and carries no information about product quality

Output: Social Proof Audit classifying each element; recommendation to evaluate via G2/Capterra/LinkedIn instead.

---

## Key Principles

- **Uncertainty activates social proof; similarity determines whose proof counts.** These two conditions must both be present for maximum effect. High uncertainty without similar sources = weak effect. Similar sources in a low-uncertainty context = unnecessary. Design for both simultaneously.

- **Specificity is the proxy for authenticity.** Vague praise ("great product!") triggers suspicion because genuine customers mention specifics. A testimonial naming a concrete outcome, timeframe, or before/after detail is both more credible and more persuasive. Specific proof does double duty: it proves authenticity and reduces audience uncertainty about outcomes.

- **The first mover breaks the cascade; after that, social proof runs itself.** In cold-start contexts, the devictimizing protocol — naming one person, giving a specific task — is the highest-leverage intervention. Once one person acts visibly, the "everyone else is waiting" dynamic reverses.

- **Manufactured proof is high-risk, not just unethical.** Audiences trained on media detect canned responses, overly uniform praise, and missing detail. When detected, the effect reverses: the product is marked as one that could not generate genuine proof. The loss in credibility exceeds any short-term lift from the manufactured signal.

- **The automatic pilot should be disengaged selectively, not permanently.** Most social proof is genuine and valuable — refusing all social evidence produces poor decisions and social friction. The skill is learning to identify corrupted data (deliberate falsification or innocent cascade) and checking the underlying facts only when the data source is suspect.

---

## References

- For detailed case studies (bystander effect research, Werther effect data, Jonestown analysis, wallet return experiment): [references/case-studies.md](references/case-studies.md)
- For the full authenticity scoring rubric and manufactured proof taxonomy: [references/proof-authenticity-rubric.md](references/proof-authenticity-rubric.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Influence: The Psychology of Persuasion by Robert B. Cialdini.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/case-studies.md
# Social Proof Case Studies
## Source: Influence: The Psychology of Persuasion, Chapter 4

This file provides detailed analysis of the primary case studies cited in the social-proof-optimizer skill. Read this file when the agent needs to explain the research basis for a recommendation or when a user challenges the underlying evidence.

---

## Bystander Effect: Latané and Darley Research Series

**Core finding:** The probability that any single bystander helps an emergency victim decreases as the number of bystanders increases, despite the intuition that more people means more help.

**Key statistics:**
- Single bystander present: **85% help rate**
- Five bystanders present: **31% help rate**
- Lone bystander in smoke-leak experiment: **75% report the leak**
- Three-person groups in smoke-leak experiment: **38% report the leak**
- Three-person groups with two confederates coached to ignore smoke: **10% report the leak**
- Toronto study, single bystander: **90% emergency aid rate**
- Toronto study, bystander with two passive others present: **16% aid rate**

**Mechanism (two factors):**
1. Diffusion of responsibility — with multiple bystanders, personal responsibility is reduced ("someone else will help")
2. Pluralistic ignorance — everyone looks to others for behavioral cues; everyone else appears calm; everyone concludes it must not be an emergency; the appearance of calm feeds back into itself

**Why pluralistic ignorance is strongest among strangers:** We prefer to appear sophisticated and unruffled in public. With strangers, we cannot read their genuine reactions. We therefore interpret their surface calm as actual calm, not as performed calm.

**Business application:** In any group context where you want one person to act (buy, sign up, reply, engage), diffusion of responsibility and pluralistic ignorance suppress action. The devictimizing protocol directly disrupts both: naming one person eliminates diffusion; giving a specific task eliminates their uncertainty about what action is needed.

---

## Devictimizing Protocol: The Author's Car Accident

**Context:** Cialdini was involved in a serious automobile collision at a busy intersection. Both drivers were injured. Multiple cars stopped at a traffic light; drivers watched but no one helped.

**What happened:** Applying the research in real time, Cialdini pointed directly at individual drivers — "Call the police" (first driver), "Pull over, we need help" (second and third drivers). All responded immediately.

**Why it worked:**
- Each driver was transformed from a bystander in a crowd into a named individual with a specific assignment
- Uncertainty about their responsibility was eliminated (they were directly assigned)
- Uncertainty about what to do was eliminated (specific task given)
- Once the first two cars stopped, social proof cascaded — other drivers entering the intersection saw cars stopped and pulled over as well

**Takeaway:** The social proof mechanism, once initiated in the correct direction, runs on its own. The intervention only needs to start the cascade; it does not need to maintain it.

---

## Wallet Return Experiment (Columbia University)

**Design:** Wallets containing $2.00 cash, a $26.30 check, and identifying information for the owner were placed throughout midtown Manhattan. Each wallet also contained a letter indicating a previous finder had tried to return it. The key variable: letters written in standard English (finder appears to be a typical American) vs. broken English (finder appears to be a recently arrived foreigner).

**Result:**
- Wallet returned when first finder appeared **similar** (standard English): **70%**
- Wallet returned when first finder appeared **dissimilar** (broken English): **33%**

**Mechanism:** People follow the lead of similar others most readily. The behavior of a dissimilar other provides weaker social evidence about what the correct behavior is for "someone like me."

**Business implication:** This is the direct empirical basis for the similarity dimension in Step 2 of the skill. A 2x difference in compliance from a single variable (similarity of the social proof source) is not a minor adjustment — it is the primary lever. An enterprise testimonial on a small-business landing page is not neutral; it actively suppresses conversion by providing social evidence from a dissimilar other.

---

## Werther Effect: David Phillips Research

**Named after:** Johann von Goethe's 1774 novel "The Sorrows of Young Werther," in which the hero commits suicide. The book triggered copycat suicides across Europe; authorities in several countries banned it.

**Modern research (Phillips, using US data 1947–1968):**
- Within two months after every front-page suicide story, an average of **58 more people than usual killed themselves**
- The increase occurs primarily in regions where the story was highly publicized; areas without coverage show no comparable increase
- The wider the coverage, the greater the subsequent death toll
- Critically specific: pure suicides produce single-fatality crashes; suicide-plus-murder stories produce multiple-fatality crashes

**Mechanism:** People who identify with the suicide victim — particularly those similar in age, demographic, and circumstance — find the idea of suicide more legitimate after reading the story. Social proof operates on what constitutes "appropriate action for someone like me."

**Fatal crash specificity after publicized suicides:**
- When the suicide victim is young, subsequent single-car crashes involve young drivers
- When the suicide victim is older, subsequent crashes involve older drivers
- Average crash fatality count is **more than three times greater** in the week following a front-page suicide story vs. the week prior
- Victims of car crashes following suicide stories die **four times faster** than normal (consistent with deliberate action rather than distracted driving)

**For the social proof optimizer:** This is the most extreme illustration of the similarity condition. Social proof of the most drastic action (suicide) propagates specifically along demographic similarity lines. The principle extends to all behaviors: the proof is most influential when the source closely resembles the observer. Conversely, designing proof from dissimilar sources not only fails to persuade — it may provide active evidence that "people like me don't do this."

---

## Jonestown: The Deliberate Engineering of Social Proof Conditions

**Event:** November 18, 1978. 910 members of the People's Temple died by poisoning in Jonestown, Guyana — the largest mass suicide in modern history.

**Standard explanations and their limits:** The charisma of Jim Jones, the dependency and poverty of the membership, the cult's quasi-religious structure. Cialdini finds these insufficient: the world has many charismatic cult leaders with dependent memberships; Jonestown was unique.

**The decisive variable (per Dr. Louis Jolyon West, UCLA chairman of psychiatry and biobehavioral sciences):** "This wouldn't have happened in California. But they lived in total alienation from the rest of the world in a jungle situation in a hostile country."

**Jones's two strategic moves:**
1. **Manufactured uncertainty:** Relocation to Guyana — an alien environment where members knew nothing of local customs, social norms, or what constituted correct behavior. Social uncertainty was maximized.
2. **Manufactured exclusive similarity:** In a country with no similar others — no Americans, no familiar community members — the only similar people were other People's Temple members. Jones became the exclusive definer of what similar others believed.

**The result:** When Jones issued the death command, members faced maximum uncertainty (they didn't know what was appropriate in this alien context) and could only look to similar others (each other) for behavioral guidance. Those who complied first — likely the most fanatically obedient members — created social proof for the rest. Others watching saw calm compliance; by the pluralistic ignorance mechanism, they interpreted this as confirmation that compliance was correct. The cascade followed.

**For the social proof optimizer:** This is the proof-of-concept for why the two conditions (uncertainty + similarity) are not just amplifiers but weapons. Deliberately maximizing both conditions enables a single leader to convert a following into a herd. For marketers: the same mechanism explains why launching a product into a new category (maximum uncertainty) and providing testimonials from highly similar users (exclusive similarity pool) is the most powerful legitimate application of social proof.

---

## Manufactured Social Proof: Historical and Modern Examples

**Salted tip jars:** Bartenders place a few bills in the tip jar before service begins. Arriving customers see "evidence" that others tip folding money. The social proof signal produces conforming behavior even when the signal was artificially initialized.

**Church collection baskets:** Ushers salt collection baskets with bills before passing them. The mechanism and effect are identical to the tip jar.

**Billy Graham crusade preparation:** An Arizona State University research team that infiltrated the Billy Graham organization documented advance preparations before his visits. Advance teams rehearsed six thousand individuals to come forward at his altar call at specified times to create the appearance of a spontaneous mass conversion. Graham would arrive to find what appeared to be an organic mass response.

**Discotheque waiting lines (1970s):** Certain club owners created visible lines outside their venues when there was plenty of room inside. The line became social proof of desirability.

**Italian opera claque (1820–present):** Sauton and Porcher founded L'Assurance des Succès Dramatiques, leasing themselves and employees as professional applauders. The enterprise grew into an institutionalized system. Published rates from the London Musical Times: "For applause on entrance, if a gentleman 25 lire / if a lady 15 lire / Ordinary applause during performance, each 10 lire / Wild enthusiasm — a special sum to be arranged." The claque operated openly for over a century, which itself illustrates a key point: audiences were manipulated even when they knew the manipulation existed.

**Racetrack betting manipulation:** A high-roller places a large bet on an inferior horse, making it the early favorite on the tote board. Uncertain bettors read the odds, assume the early favorite was selected based on inside knowledge, and follow. The high-roller then bets heavily on their preferred horse at favorable odds — the "new favorite" has pushed those odds down. The manufactured social proof enriched the manipulator at the crowd's expense.

**Modern equivalent:** Hiring actors for "unrehearsed interview" testimonial ads. The situations are staged, the participants are actors, the dialogue is prewritten — yet the format mimics organic social proof. Cialdini's assessment: "It is amazing how bald-faced these 'unrehearsed interview' commercials can be."

**Key insight from the claque:** Social proof can be effective even when openly manufactured — because the automatic compliance reflex fires before the conscious evaluation of authenticity completes. This is also why detection and conscious disengagement is the only reliable defense.

---

## Phobia Treatment via Social Proof (Albert Bandura)

**Study design:** Nursery-school children severely afraid of dogs were shown films of a peer playing happily with a dog. 

**Results after four days of 20-minute daily film viewing:**
- 67% of treated children willing to climb into a playpen with a dog and remain there while everyone else left the room
- Effect persisted at one-month follow-up; children were more willing to interact with dogs than before

**Key finding for social proof design:** Film (social proof via recorded peers) was as effective as live demonstration. And the most effective films showed multiple different children with the dog, not a single child. The principle of social proof works best when the evidence comes from "a lot of other people" — breadth of similar exemplars strengthens the signal.

**Business application:** Multiple testimonials from a variety of similar sources outperform a single exceptional case study. Variety in the proof pool signals broad adoption, not cherry-picked outliers.

FILE:references/proof-authenticity-rubric.md
# Proof Authenticity Rubric
## Source: Influence: The Psychology of Persuasion, Chapter 4

Use this rubric when running Step 5 (Check for Manufactured Proof Risks) or Step 7 (Defense — Evaluate Incoming Social Proof) in the social-proof-optimizer skill.

---

## Authenticity Scoring Rubric

Score each proof element on 5 dimensions. Total score determines classification.

| Dimension | 2 — Authentic | 1 — Uncertain | 0 — Suspect |
|---|---|---|---|
| **Identification** | Full name, photo, role, company visible | Partial ID (first name only, or role without company) | No identifying details; anonymous |
| **Specificity** | Concrete outcome, timeframe, or before/after detail | General positive sentiment with some context | Pure vague praise ("amazing," "best ever") |
| **Source verifiability** | Verifiable via third-party platform (LinkedIn, G2, Capterra, App Store) | Partially verifiable (name exists, company exists, not directly linked) | Cannot be independently verified |
| **Temporal distribution** | Reviews/testimonials accumulated over time, organic distribution | Some clustering, mostly organic | Large batch appearing suddenly (50+ in 30 days) |
| **Consistency range** | Mix of strong positive, moderate positive, and constructive negative | Mostly positive with rare negative | 100% uniformly glowing; no specifics; no negatives |

**Scoring:**
- 9–10: High authenticity — use with confidence
- 6–8: Moderate authenticity — use with transparency (add "typical results" note if needed)
- 3–5: Low authenticity — risk flag; verify independently before using
- 0–2: Manufactured proof — do not use; high credibility risk if exposed

---

## Manufactured Proof Taxonomy

### Level 1 — Direct fabrication (highest risk)
Definition: Proof that does not correspond to any real customer experience.

Examples:
- Actors playing customers in "unrehearsed" interview ads
- Purchased review packages (Fiverr, Trustpilot manipulation services)
- AI-generated testimonials placed on the site
- Planted converts at events (Billy Graham model)

Risk: Criminal fraud exposure (FTC regulations), complete brand destruction if exposed. Do not use.

### Level 2 — Coerced or incentivized proof (high risk)
Definition: Proof from real customers, but obtained under conditions that compromise honest representation.

Examples:
- Reviews obtained via "leave a 5-star review for a discount" programs without disclosure
- Testimonials from customers who were threatened with loss of account if they didn't provide positive feedback
- Reviews from employees or founders' personal networks without disclosure

Risk: FTC violation (undisclosed material connection), legal exposure, audience trust destruction when exposed. Requires mandatory disclosure to be legal; still ethically problematic.

### Level 3 — Cherry-picked outlier results (medium risk)
Definition: Proof from real customers reporting real outcomes, but the outcomes are not representative.

Examples:
- "Made $47,000 in 30 days" testimonial when the median customer makes $200
- Case study featuring 300% growth company when typical customer sees 15% growth
- Highlighting only 5-star reviews while suppressing 1-star reviews that contain valid complaints

Risk: FTC "typical results" requirement, audience trust erosion when customers compare promised vs. actual outcomes. Requires "results not typical" or "average customer sees X%" disclosure.

### Level 4 — Selective presentation (low risk)
Definition: Proof from real customers reporting real representative outcomes, but only positive cases are featured.

Examples:
- Testimonial page showing all happy customers (no unhappy customers appear)
- Case studies featuring only successful implementations
- User counts that include churned users

Risk: Confirmation bias in presentation, not fraud. Acceptable marketing practice. Mitigate by ensuring featured cases are representative, not extreme outliers.

### Level 5 — Seeded initial proof (context-dependent)
Definition: Artificially initializing social proof to trigger authentic cascades.

Examples:
- Salting tip jars or collection baskets
- Inviting friends/family to be first buyers or reviewers
- Using waitlist count as launch-day proof (if the waitlist is real)
- Giving product to influencers for genuine usage-based reviews (disclosed)

Risk: Low if transparent about the source; high if the seeding is misrepresented as organic behavior.

---

## Defense Detection Checklist

When evaluating social proof used by a competitor, partner, or product you are considering:

### Signs of deliberate falsification
- [ ] No name, photo, or identifying detail on any testimonial
- [ ] All reviews appeared within a short window (30 days or less for large volume)
- [ ] 100% positive ratings with no constructive feedback on any platform
- [ ] "Testimonial" subjects use stock photography or generic avatars
- [ ] User count is unverifiable and has no third-party corroboration
- [ ] Staged or scripted quality to quoted language
- [ ] No presence of these customers on professional networks (LinkedIn)

### Signs of innocent cascade (pluralistic ignorance)
- [ ] Everyone in a group is doing the same thing with no clear information advantage
- [ ] The behavior started with an ambiguous trigger (one person switched, one person sold)
- [ ] Asking participants why they are doing it produces "everyone else is" answers
- [ ] Direct investigation of the underlying facts shows no actual signal

### Response protocol
- Deliberate falsification confirmed → disengage automatic pilot; evaluate underlying product via independent channels; do not factor the social proof into your decision
- Innocent cascade identified → check the objective facts directly; introduce independent information; do not join the cascade until you have verified the underlying basis
- Uncertain → weight social proof at 50% of normal; prioritize independent verification

---

## FTC Compliance Notes (US Context)

The Federal Trade Commission requires disclosure of material connections in testimonials:
- Employees and contractors must disclose their relationship
- Compensated testimonials require disclosure ("Paid partnership," "#ad")
- Free products given in exchange for reviews require disclosure
- Results testimonials must reflect typical customer outcomes, or provide a "typical results" disclosure

Source: FTC Guides Concerning Use of Endorsements and Testimonials in Advertising (16 CFR Part 255). These rules apply to online testimonials, social media posts, and influencer content.

Non-US contexts have similar or stricter requirements (EU, UK ASA). When operating internationally, confirm local disclosure requirements before using any incentivized testimonial.

---
name: scarcity-framing-strategist
description: >
  Design and evaluate scarcity framing for offers, products, and campaigns using psychological
  research on loss aversion and reactance. Use this skill whenever the user is working on
  limited-time offers, limited quantity messaging, flash sales, countdown timers, early access
  programs, waitlists, stock level indicators, exclusive content, limited edition launches,
  deadline-driven promotions, FOMO-based copy, urgency messaging, or any persuasion tactic
  involving scarcity or exclusivity. Also use when the user needs to DEFEND against scarcity
  pressure they may be experiencing — to distinguish genuine scarcity from manufactured urgency.
  Covers both application (designing effective scarcity) and defense (recognizing when scarcity
  is being weaponized against you).
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/influence-psychology-of-persuasion/skills/scarcity-framing-strategist
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: influence-psychology-of-persuasion
    title: "Influence: The Psychology of Persuasion"
    authors: ["Robert B. Cialdini"]
    chapters: [7]
    pages: "178-203"
tags:
  - scarcity
  - urgency
  - limited-time
  - limited-quantity
  - exclusive
  - FOMO
  - deadline
  - countdown
  - stock-levels
  - flash-sale
  - early-access
  - waitlist
  - limited-edition
  - psychological-reactance
  - loss-aversion
  - persuasion
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Pricing page, promotional copy, product listing, campaign brief, or offer description to analyze or create"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Any agent environment. Works with document context (pricing pages, ad copy, promotional materials) or direct user description."
tags: [marketing-psychology]
---

# Scarcity Framing Strategist

## When to Use

You are in one of two modes:

**APPLICATION mode:** The user wants to add, strengthen, or audit scarcity framing in an offer, product launch, promotional campaign, pricing page, or marketing message. They have something to sell and want to increase urgency or desire.

**DEFENSE mode:** The user feels pressure to buy something and wants to evaluate whether the scarcity is genuine — or needs to understand how scarcity is being used against them.

Before starting, determine the mode. If the user provides copy or a brief, default to APPLICATION. If they describe a situation where they feel rushed to decide, default to DEFENSE.

**Preconditions for APPLICATION mode:**
- An offer or product exists (even conceptually)
- The user can describe who the audience is and what action they want that audience to take
- An ethical check must pass before any scarcity framing is deployed (Step 6)

## Context

### Required Context (must have before proceeding)

- **What is being offered:** Product, service, content, or access. The nature of the offer determines which scarcity types are plausible.
  → Check prompt or attached documents for: product name, offer description, pricing page
  → If missing, ask: "What is the product or offer you want to apply scarcity framing to?"

- **The desired audience action:** Purchase, sign-up, upgrade, download, claim, register.
  → Check for: call-to-action text, conversion goal, campaign objective
  → If missing, ask: "What specific action do you want the audience to take?"

- **Is the scarcity real or can it be made real:** This affects ethical integrity and legal compliance.
  → If the user says "just make it sound scarce" without a real constraint → the ethical check in Step 6 must resolve this before proceeding

### Observable Context (gather from environment if available)

- **Existing copy or page:** If a document is provided, read it to understand the current messaging, tone, and any existing urgency signals
  → Look for: countdown timers, "only X left" text, "offer ends" language, waitlist mentions
  → If none found: note that scarcity signals are absent (this is your baseline)

- **Product category context:** Physical product (genuine inventory), digital product (artificial scarcity only), subscription (deadline-driven), event (natural deadline)
  → Infer from product description — this determines which scarcity types are credible

### Default Assumptions

- If no audience is specified → assume general consumer audience, moderately skeptical
- If no existing copy is provided → work from the user's verbal description
- If scarcity type is not specified → proceed through the classification steps to identify the most appropriate type

## Process

### Step 1: Classify the Scarcity by Mechanism

**ACTION:** Identify which of the three mechanism types applies to this offer. More than one can apply simultaneously.

**WHY:** Each mechanism type works through a different psychological lever. Mismatching the mechanism to the message creates cognitive dissonance (e.g., claiming a "limited number" for a digital download is transparent and damages trust). Getting the mechanism right makes the framing credible and therefore effective.

The three types by mechanism:

1. **Limited number** — A finite supply exists or can be created. The offer ends when units run out.
   - Natural fit: physical products, seats at an event, slots in a cohort, beta invites, consultation spots
   - Signal phrases: "only N left," "fewer than X remain," "selling out fast," stock indicators, progress bars

2. **Deadline** — Access to the offer ends at a specific time, regardless of remaining inventory.
   - Natural fit: promotional pricing, early-bird discounts, enrollment windows, seasonal sales, launch offers
   - Signal phrases: "offer ends [date/time]," "expires tonight," "closes Friday," countdown timers

3. **Exclusive information** — The offer or the knowledge that this opportunity exists is not publicly available. The audience has access to information others do not.
   - Natural fit: subscriber-only deals, early access, private beta, insider pricing, pre-announcement access
   - Signal phrases: "only for members," "not publicly advertised," "exclusive to this list," "available before the public launch"
   - This is the most powerful amplifier (see the Double Whammy in Step 3)

**IF** multiple types apply → proceed through all three; they stack

**IF** none apply naturally → assess whether any can be legitimately created (limited cohort size, an enrollment deadline, a subscriber-exclusive pricing window)

### Step 2: Classify the Scarcity by Origin

**ACTION:** Determine how this scarcity came to be. The origin changes the psychological potency and the credibility of the signal.

**WHY:** Research using cookie studies (Worchel et al.) established a clear hierarchy of emotional impact by origin. The goal is to match the copy to whichever origin type is most credible for this offer — and to frame the messaging to activate the highest-potency origin type possible.

The three types by origin, in ascending order of potency:

| Origin Type | What It Is | Relative Effect | Example |
|---|---|---|---|
| **Constant scarcity** | Always been rare; no change in availability | Moderate | "We only ever produce 100 of these per year" |
| **Newly scarce** | Previously abundant, now limited — a transition just occurred | Stronger | "We're reducing our cohort from 500 to 50 starting next cycle" |
| **Demand-driven scarcity** | Scarce because others want it — social competition is active | Strongest | "We only have 12 spots left because 340 people applied this week" |

The key insight: **loss from abundance produces stronger reactance than deprivation from birth.** A product that just became harder to get triggers more desire than one that has always been hard to get. And when others are competing for the same resource, the competitive element adds a second layer of urgency beyond the scarcity itself.

**IF** newly scarce is genuine → lead with the before/after transition: "We used to offer this to everyone — starting [date] we're limiting it to [constraint]"

**IF** demand-driven is genuine → make the competition visible: show application counts, waitlist numbers, or simultaneous interest signals

### Step 3: Stack the Optimal Conditions (The Double Whammy)

**ACTION:** Evaluate whether the offer qualifies for the highest-potency stacking formula. Apply as many amplifiers as are credible for this specific offer.

**WHY:** A beef import study (Cialdini, Chapter 7) demonstrated that scarcity signals compound rather than simply add. Standard pitch: baseline. Adding future scarcity information: 2x purchase rate. Adding that the scarcity information is itself exclusive (not publicly available): 6x purchase rate. The mechanism is double reactance — the audience is reacting to the scarcity of the product AND the scarcity of the information about the scarcity.

The Double Whammy formula requires two simultaneous conditions:
1. The product/offer is (or will become) scarce
2. The knowledge of that scarcity is itself not widely available — the audience is receiving insider information

**Optimal conditions hierarchy (apply all that are true):**

- **Condition 1 — Newly scarce:** The availability is changing, not static. Frame the before/after.
- **Condition 2 — Demand-driven:** Others are competing for the same resource. Show the competition.
- **Condition 3 — Exclusive information:** The audience knows about this before the general public. They have insider access to the scarcity signal itself.

**The maximum-potency message stacks all three:** "We're moving to an application-only model starting next month [newly scarce]. We already have 200 applicants for 20 spots [demand-driven]. I'm telling you this before we announce it publicly [exclusive information]."

**IF** only one condition applies → use it honestly; do not fabricate the others
**IF** two conditions apply → stack them; the compounding effect still applies
**IF** all three apply → use the full Double Whammy framing

For the full evidence base and message templates by condition combination, see [references/optimal-conditions-evidence.md](references/optimal-conditions-evidence.md).

### Step 4: Add the Competition Amplifier (if applicable)

**ACTION:** Assess whether direct, visible competition for the resource can be legitimately introduced or surfaced.

**WHY:** Research on demand-driven scarcity (Worchel cookie study) found that cookies made scarce through social demand were rated most desirable of all — more than constant scarcity or newly scarce. This is the competition amplifier: the feeling of being in direct competition for a limited resource has physically motivating properties. The Poseidon Adventure auction (CBS, 1973) demonstrates the extreme version: Barry Diller paid $3.3 million for a single TV showing — exceeding the previous record of $2 million — because an open competitive bidding format created genuine rivalry among ABC, CBS, and NBC. Robert Wood (CBS) admitted: "Logic goes right out the window." Buyers at bargain sales exhibit the same pattern — they scramble for merchandise they would otherwise disdain.

The competition amplifier works when:
- Multiple parties can be shown to want the same resource
- The competition is real (visible) or can be made real (simultaneous interest)
- The audience is aware they could lose to a competitor

**Tactics for surfacing real competition:**
- Show live or recent demand signals: "X people are viewing this right now," application counts, waitlist size
- Disclose competing bids or interest: "We've had 3 other inquiries about this slot"
- Use simultaneous appointment scheduling (multiple prospects aware of each other's interest)
- Real-time inventory depletion indicators

**Ethical constraint:** Competition must be real or genuinely inferable. Fabricating competing bids or false "X people viewing" numbers is deceptive and legally risky.

**IF** competition signals are available and real → surface them explicitly
**IF** not applicable (no competition exists) → skip; do not fabricate

### Step 5: Write the Scarcity Framing

**ACTION:** Draft the scarcity-framed message, signal, or copy using the classification outputs from Steps 1-4.

**WHY:** The specific wording determines whether the scarcity is perceived as credible and relevant or as a manipulative tactic. Credibility comes from specificity (exact numbers, specific dates, named reasons), from the framing matching the mechanism type, and from the origin story being coherent. Vague scarcity ("limited availability!") is less effective than specific scarcity ("We have 7 spots remaining in the April cohort; 340 people applied for the last one").

**Message construction principles:**

1. **Name the specific constraint.** "Only 5 left" beats "limited stock." "Enrollment closes March 31" beats "limited time."
2. **Give the constraint a reason.** Unexplained scarcity feels manufactured. "We cap cohort size at 20 to maintain the live-session quality" is more credible than "only 20 spots."
3. **For newly scarce:** state the before/after explicitly. Show that something changed.
4. **For demand-driven:** show the evidence of demand. Numbers, rates, or named competitors.
5. **For exclusive information:** open with the insider framing before disclosing the scarcity. "Before this goes public..." or "I'm sharing this with [segment] first..."
6. **Match the message register to the channel.** A countdown timer on a pricing page, "Only 3 left" on a product listing, and a plain-text email saying "I wanted to reach out before we open this publicly" are all valid implementations — the format varies but the structure holds.

### Step 6: Run the Ethical Check

**ACTION:** Before finalizing any scarcity framing, verify that it meets the ethical threshold. This step is mandatory and blocks deployment if it fails.

**WHY:** Psychological reactance is a genuine cognitive mechanism — it bypasses rational deliberation. Deliberately triggering it with false signals causes real harm to the people on the receiving end (they make decisions they would not otherwise make, often at cost to themselves). The boiler-room scam in Chapter 7 (Daniel Gulban case) shows the extreme: manufactured scarcity and deadline pressure caused an 81-year-old retiree to wire $18,000 to fraudsters. Beyond harm: false scarcity is legally actionable in most jurisdictions (FTC guidelines, consumer protection laws), and when detected it permanently destroys credibility.

**Ethical check — all three must pass:**

1. **Is the scarcity constraint real?** The limited number, deadline, or exclusive information must actually exist. If the deadline resets, if there is no actual inventory limit, if the "exclusive" information is published elsewhere — it fails this check.

2. **Would the audience agree this is a fair constraint?** "We cap group sizes for quality" is fair. "We're shutting down the page at midnight but it will be back tomorrow" is manufactured. Ask: if the audience knew the full truth, would they feel they were being given an honest signal or deceived?

3. **Is the offer itself genuinely valuable?** Scarcity framing should amplify a real offer, not dress up a bad one. If the product is only desirable because it seems scarce — and would be worthless if freely available — that is a signal the offer itself needs work, not the framing.

**IF** any check fails → do not deploy the scarcity framing as written. Return to Steps 1-5 and find a legitimate constraint or restructure the offer until one exists.

**IF** the user asks to fabricate scarcity → explain the harm mechanism (reactance bypasses rational choice), the legal risk (FTC/consumer protection), and the trust destruction risk, then offer to help design a legitimate constraint instead.

### Step 7: Defense Protocol — Two-Stage Arousal Check

**ACTION:** When the user (or when the output will be read by someone) needs to evaluate scarcity pressure being applied to them, run the two-stage defense.

**WHY:** Scarcity triggers a physical arousal response — blood pressure rises, focus narrows, cognitive processes narrow, emotions intensify. Robert Wood's "logic goes right out the window" quote captures this precisely. The arousal itself is the problem: it is designed to prevent rational evaluation. A person who knows about the scarcity principle is not protected from it by that knowledge alone, because the arousal suppresses the cognitive faculties that would apply that knowledge. The defense must therefore use the arousal itself as a signal, rather than trying to reason through it.

**Stage 1 — Use arousal as a warning signal, not a decision driver:**
- When you feel urgency, time pressure, or competitive anxiety about an opportunity → stop. This sensation is physiological data, not information about the offer's value.
- The rising sense of "I need to act now before I lose it" is the signal TO PAUSE, not to proceed.
- Ask: "Would I have wanted this before I learned it was scarce?" If the answer is no — the scarcity created the desire, not the underlying offer.

**Stage 2 — Ask the utility question:**
- "Do I want this thing for its utility (to use it, experience it, benefit from it) — or for possession (to have it, to not lose it to someone else)?"
- If the answer is utility → scarcity is relevant information. Use the limited availability to calibrate how much you'd pay and decide based on that.
- If the answer is possession → the scarcity signal is the entire source of desire. The scarce cookies in the research tasted no better than the abundant ones. Scarce things do not function better, taste better, or provide more value because of their limited availability.

**KEY INSIGHT:** The joy is in experiencing a scarce commodity — not merely possessing it. If you want to consume it, scarcity tells you something real about price. If you want to own it, scarcity has hijacked your desire.

## Inputs

- An offer, product, or campaign to apply scarcity framing to (from user or provided documents)
- Alternatively: a compliance situation the user is evaluating (for defense mode)

## Outputs

**APPLICATION mode produces:**
- Scarcity type classification (by mechanism and by origin)
- Optimal conditions assessment (which of the three amplifiers apply)
- Competition amplifier recommendation (if applicable)
- Drafted scarcity-framed copy or messaging
- Ethical check result (pass/fail with reasoning)

**DEFENSE mode produces:**
- Analysis of scarcity type being applied (mechanism and origin)
- Assessment of whether the scarcity is genuine or manufactured
- Two-stage arousal check walkthrough
- Recommendation: proceed, pause, or decline

## Key Principles

- **Specificity creates credibility** — "Only 5 left" is verifiable. "Limited availability" is not. Specific numbers, dates, and reasons make scarcity feel real rather than manufactured. Vague urgency signals that the scarcity is tactical rather than genuine, and skeptical audiences dismiss it.

- **Origin determines potency** — Newly scarce beats constantly scarce; demand-driven beats newly scarce. The reason is psychological reactance: people react most strongly to freedoms they had and are losing, not freedoms they never had. Frame scarcity around transitions and competition, not around static limitation.

- **Exclusive information compounds scarcity** — The Double Whammy works because it creates reactance on two levels simultaneously: the audience wants the scarce product AND they want to act on exclusive information before it becomes public. This 6x multiplier is available only when the scarcity signal itself is not widely distributed.

- **Arousal is a symptom, not a directive** — The physical urgency that scarcity produces is a compliance mechanism, not useful information about an offer's value. For ethical application: be aware that you are triggering this mechanism. For defense: treat the arousal as a warning to pause, not a reason to act.

- **Established freedoms produce stronger reactance than never-held ones** — (Brehm's reactance theory.) This is why taking away something previously available always outperforms announcing limited availability on something new. Structure offers to create and then constrain access, rather than simply announcing scarcity from the start.

- **The ethical floor is non-negotiable** — False scarcity is both harmful (bypasses rational choice in the audience) and self-defeating (once detected, it permanently destroys trust and triggers the backlash effect — audiences react against the persuader, not just the tactic).

## Examples

**Scenario: SaaS product adding urgency to annual plan page**
Trigger: "Our annual plan page converts poorly. Can we add some urgency?"
Process: Read pricing page — no scarcity signals present. Classified as deadline type (annual pricing can have an enrollment window) + potentially demand-driven (if waitlist or usage data exists). Checked: company confirmed they renew annual pricing annually in January. Created a legitimate deadline constraint: annual pricing closes for new subscribers at end of Q1. Surfaced demand signal: "2,400 teams upgraded last January." Ethical check: passed (deadline is real, demand data is real). Drafted copy: "Annual pricing is available through March 31. 2,400 teams locked in last January — this cohort closes in [X days]."
Output: Two-sentence urgency block with countdown to March 31. Mechanism: deadline. Origin: newly scarce (the window is closing). Effect: genuine deadline + demand evidence, no fabrication.

**Scenario: E-commerce product with genuine low stock**
Trigger: "We have 8 units left of a popular jacket. What's the best way to communicate this?"
Process: Mechanism type: limited number (genuine). Origin type: demand-driven (sold down from abundant to scarce because customers bought it). Optimal conditions: newly scarce (transition from full stock) + demand-driven (sold because others wanted it). Competition amplifier: show sales velocity. Ethical check: passed (8 units is real). Drafted: "Only 8 left — this jacket sold out completely last season. 47 people purchased in the last 7 days."
Output: Product listing badge + short copy block. Stacks newly scarce + demand-driven + specific number. Does not fabricate. The copy explains WHY it is scarce (others bought it), which activates the competition frame.

**Scenario: User evaluating a high-pressure sales call**
Trigger: "A consultant told me their rate goes up 40% next week and there's only one spot left in their retainer. I feel like I need to decide today. Should I?"
Process: Defense mode. Classified: mechanism = limited number + deadline (simultaneous). Origin = constant or possibly manufactured. Ran Stage 1: identified the physical urgency as a warning signal — the user is experiencing arousal-driven pressure. Ran Stage 2: user described wanting the consulting engagement for the utility (business outcomes), not possession. Key question: "Was this consultant someone you wanted to hire before you learned about the price increase and the one slot?" User: "Not really — I found them through a referral and had one intro call." Assessment: the scarcity framing was the primary driver of desire, not the underlying value.
Output: Recommendation to pause, request written details, and evaluate the consultant's track record against alternatives before the artificial deadline. Noted: legitimate consultants with genuine demand do fill up — the test is whether the value case holds independent of the urgency.

## References

- For optimal conditions evidence and message templates by condition combination, see [references/optimal-conditions-evidence.md](references/optimal-conditions-evidence.md)
- For the reactance mechanism and case studies (Kennesaw firearms, Dade County phosphates, jury study), see [references/reactance-mechanism.md](references/reactance-mechanism.md)
- For the competition amplifier case studies (Poseidon auction, Richard's car technique, feeding frenzy pattern), see [references/competition-amplifier-cases.md](references/competition-amplifier-cases.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Influence: The Psychology of Persuasion by Robert B. Cialdini.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/competition-amplifier-cases.md
# Competition Amplifier Case Studies

Source: Cialdini, *Influence: The Psychology of Persuasion*, Chapter 7, pp. 197-202

## The Core Finding (Cookie Study, Demand-Driven Condition)

Among all scarcity types tested by Worchel et al., cookies made scarce through social demand were rated most desirable — even more than cookies that were newly scarce due to error or supply change.

**The mechanism:** Competition for a limited resource compounds the scarcity effect. It is not just that the item is hard to get — others are actively trying to get it too. The threat of loss to a rival is added to the basic loss of availability.

**Cialdini's observation:** "The feeling of being in competition for scarce resources has powerfully motivating properties. The ardor of an indifferent lover surges with the appearance of a rival."

## Case Study: The Poseidon Adventure Auction (1973)

**Situation:** First time a major motion picture was offered to commercial TV networks in an open competitive auction. Three networks (ABC, CBS, NBC) competed simultaneously.

**Deal terms:** ABC (Barry Diller, vice president of prime-time programming) paid $3.3 million for a single television showing of *The Poseidon Adventure*.
- Previous record: $2 million for *Patton* (one-time movie showing)
- ABC accounting projected the $3.3M deal would lose the company $1 million
- NBC vice president Bill Storke stated publicly: "There's no way they can get their money back, no way at all."

**Diller's response after winning:** He announced ABC would never again enter an auction situation. This was stated in language that sounded like it had "escaped only from between clenched teeth."

**Robert Wood (CBS Television president, who nearly won):**
> "We were very rational at the start. We priced the movie out, in terms of what it could bring in for us, then allowed a certain value on top of that for exploitation. But then the bidding started. ABC opened with two million. I came back with two point four. ABC went to two point eight. And the fever of the thing caught us. Like a guy who had lost his mind, I kept bidding. Finally, I went to three point two; and there came a moment when I said to myself, 'Good grief, if I get it, what the heck am I going to do with it?' When ABC finally topped me, my main feeling was relief. It's been very educational."

**The smiling man:** Robert Wood, who had lost, was smiling when he made his "very educational" statement. The winner (Diller) was not smiling. This inversion — losers behaving like winners and vice versa — is a reliable signal that competition-for-scarce-resources dynamics have taken over from rational valuation.

**The lesson:** When a combination of scarcity plus competition for that scarcity is present, "extreme caution is advised" — this is what Cialdini calls "the devilish construction of scarcity plus rivalry."

## Case Study: Richard's Car Technique

**Source:** The author's brother Richard, who worked his way through college selling used cars part-time.

**Method:** Richard bought used cars privately on weekends and resold them the following weekend at a profit. He used the following technique to manufacture visible competition:

1. Placed a Sunday newspaper ad to generate buyer interest
2. Gave each interested prospect an appointment — **the same appointment time**
3. If 6 people were interested, all 6 were scheduled for, say, 2:00 PM on Sunday

**What happened:** The first prospect to arrive would begin a normal, unhurried examination of the car. Then — the second prospect would drive up.

> "The availability of the car to either prospect suddenly became limited by the presence of the other."

The first buyer's behavior would shift immediately: leisurely assessment became a now-or-never rush. The buyer often asserted priority ("I was here first"). Even if they did not, Richard would introduce the scarcity: "Excuse me, but this other gentleman was here before you. So can I ask you to wait on the other side of the driveway for a few minutes until he's finished?"

**If conditions alone were insufficient:** A third 2:00 PM appointment would arrive. According to Richard, stacked-up competition was "usually too much for the first prospect to bear" — they either agreed to Richard's price or left. If they left, the second buyer experienced the same dynamic.

**What the buyers failed to recognize:** Their increased desire had nothing to do with the car's merits. The competition created emotional arousal that prevented them from thinking straight — and from remembering they wanted the car to drive, not merely to have.

## The Feeding Frenzy Pattern

**Animal parallel:** Commercial fishermen use this mechanism intentionally. They scatter loose "chum" bait to a school of fish. In the competition for food, the fish become agitated, lose perspective, and "bite ferociously at anything — including bare metal hooks."

**Retail parallel:** Department stores use "loss leaders" (a few items at unprofitable prices, heavily advertised) to create crowds. In the rush to grab the deals, the group becomes agitated and nearly blinded by the adversarial nature of the situation. "Humans and fish alike lose perspective on what they want and begin striking at whatever is being contested."

**The tuna on dry deck:** Cialdini notes that "the tuna flapping on a dry deck with only a bare hook in its mouth shares the what-hit-me bewilderment of the shopper arriving home with only a load of department-store bilge."

## The "Goosing 'Em Off the Fence" Realtor Technique

A realtor trying to sell a house to a "fence-sitting" prospect will sometimes call the prospect with news of another potential buyer who has seen the house and is returning to discuss terms.

The competing buyer is typically described as an outsider with money: "an out-of-state investor buying for tax purposes" or "a physician and his wife moving into town."

**Effect:** "The thought of losing out to a rival frequently turns a buyer from hesitant to zealous."

**Application constraint:** When the competing buyer is wholly fabricated, this tactic is deceptive. When real interest exists — even if not yet committed — surfacing it transparently is a legitimate signal. The ethical line is between disclosing genuine competing interest and inventing phantom competitors.

## Practical Signals That Competition Is Active

Deploy the competition amplifier when any of the following are genuinely true:

| Signal | How to surface it |
|---|---|
| Multiple people are actively viewing or considering | "X people are viewing this right now" (real-time) |
| Others have inquired about the same slot/unit | "We've had 3 other inquiries about this spot this week" |
| Recent purchase velocity is high | "47 people purchased in the last 7 days" |
| Waitlist has formed | "230 people are on the waitlist for this cohort" |
| Application volume exceeds capacity | "We received 340 applications for 20 spots" |
| Simultaneous interest is visible | Multiple prospects present at the same time (Richard's technique) |

**The non-negotiable constraint:** All competition signals must be real. Fabricated competing buyers, inflated "X viewing" numbers, and invented applications are deceptive, legally risky, and — when detected — permanently destroy trust and trigger the exact reactance response you were trying to harness, now directed against you.

FILE:references/optimal-conditions-evidence.md
# Optimal Conditions Evidence

Source: Cialdini, *Influence: The Psychology of Persuasion*, Chapter 7, pp. 192-197

## The Cookie Study (Worchel, 1975)

**Researcher:** Stephen Worchel and team  
**Method:** Consumer preference study. Participants given chocolate-chip cookies from a jar, asked to taste and rate quality.

**Condition A — Constant scarcity:** Jar always contained 2 cookies.  
**Condition B — Abundant supply:** Jar contained 10 cookies.  
**Condition C — Newly scarce:** Jar started with 10 cookies, then replaced with a jar of 2 mid-study.  
**Condition D — Demand-driven scarcity:** Jar of 10 reduced to 2 because other participants needed them.

**Results:**
- Constant scarcity (Condition A) > Abundance (Condition B): moderate effect — scarce cookies rated more desirable, more attractive as a consumer item, more costly
- Newly scarce (Condition C) > Constant scarcity (Condition A): stronger — the drop from abundance produced a decidedly more positive reaction
- Demand-driven scarcity (Condition D) > Newly scarce (Condition C): strongest — cookies made less available through social demand were rated most desirable of all

**Critical finding:** The cookies were identical. The scarcity did not change their flavor, quality, or nutritional value. The increased desire was entirely psychological.

**Hierarchy confirmed:**
```
Demand-driven > Newly scarce > Constant scarcity > Abundant
```

## The Beef Import Study (Double Whammy)

**Researcher:** Graduate student and businessman conducting a study using his beef import company's sales staff  
**Context:** Salespeople phoned supermarket and retail food outlet buyers as usual and asked for purchase orders.

**Three conditions:**

| Condition | What the buyer heard | Purchase amount (relative) |
|---|---|---|
| Standard | Standard sales pitch only | Baseline (1x) |
| Scarcity info | Standard pitch + imported beef supply likely to be scarce in coming months | ~2x baseline |
| Scarcity + exclusive info | Standard pitch + scarcity info + "this information came from exclusive contacts and is not publicly available" | ~6x baseline |

**The mechanism (Double Whammy):** Two simultaneous reactance triggers:
1. The product itself is becoming scarce (reactance trigger 1)
2. The information about the scarcity is itself exclusive (reactance trigger 2)

**Quote from Cialdini:** "The news carrying the scarcity information was itself scarce, which made it especially persuasive."

**Theory basis:** Timothy Brock and Howard Fromkin's "commodity theory" of persuasion — information that is exclusive (not freely available) is more persuasive because it is itself a scarce resource.

## Message Templates by Condition Combination

### Constant scarcity only
```
"We only ever produce [N] of these [unit period]. 
This isn't a promotional limit — it's a production constraint."
```

### Newly scarce
```
"Until [date/event], we offered [X]. Starting [when], 
we're limiting [the offer] to [new constraint] because [reason].
This is a permanent change, not a temporary sale."
```

### Demand-driven scarcity
```
"We have [N] remaining. [Number] people [purchased/applied/signed up] 
in the last [timeframe]. At this pace, [projection of when it runs out]."
```

### Newly scarce + demand-driven
```
"We reduced our [cohort/production/availability] from [old number] to [new number] 
starting this cycle. We already have [demand signal] for the [new total] spots available."
```

### Full Double Whammy (all three conditions)
```
"I'm reaching out to [segment/list] before this becomes public:
Starting [date], [the offer] is moving to [constraint — e.g., application-only, 
reduced availability]. We've already had [demand signal] from the people who 
heard about this early. Once we announce it publicly, [projected consequence]."
```

**Key construction rule:** Always give the constraint a reason. "We're capping cohort size at 20 because the live-session format requires small groups" is credible. "Only 20 spots!" is not.

## The Information Scarcity Extension

Cialdini extends the scarcity principle to information itself (pp. 189-192):

- Information need not be censored to gain value from scarcity — it only needs to be scarce
- Exclusive information is more persuasive than identical information that is widely available
- This applies to business intelligence, insider access, pre-announcements, and subscriber-only content

**Practical implication:** If you can legitimately say "I'm sharing this with [segment] before the public announcement," the information scarcity multiplier applies independently of whether the product itself is scarce.

FILE:references/reactance-mechanism.md
# Psychological Reactance Mechanism

Source: Cialdini, *Influence: The Psychology of Persuasion*, Chapter 7, pp. 183-201

## The Core Mechanism (Brehm's Reactance Theory)

**Developed by:** Jack Brehm  
**Central claim:** Whenever free choice is limited or threatened, the need to retain our freedoms makes us desire them — and the goods and services associated with them — significantly more than previously. So when increasing scarcity (or anything else) interferes with our prior access to some item, we will react against the interference by wanting and trying to possess the item more than before.

**Why "react against":** The term reactance describes that the response is directed AT the restriction, not just toward the item. People do not simply want what they cannot have — they want to push back against the constraint itself.

**Critical asymmetry:** Established freedoms produce stronger reactance than freedoms never held. It is more dangerous (from a control perspective) to have given a freedom for a while than never to have given it at all. This is why:
- Taking away an offer that was previously available produces more urgency than announcing a new limited offer
- Price increases on existing products produce more resistance than high launch prices
- Newly scarce items are more desirable than constantly scarce ones (see cookie study)

## Two Sources of Scarcity's Power

1. **Heuristic accuracy:** Things that are difficult to possess are often better than things that are easy to possess. Scarcity is usually a reliable (if imperfect) signal of quality and value. We are correct, in general, to assign more value to rare things. This is an "enlightened weakness."

2. **Reactance (the secondary source):** As opportunities become less available, we lose freedoms we already have — and we hate to lose those freedoms. This is unique to the scarcity principle among the weapons of influence.

## Case Studies

### The Terrible Twos (Child Development)
- Psychological reactance emerges strongly at approximately age two — coinciding with children's first full recognition of themselves as autonomous individuals
- Virginia-based study: boys averaging 24 months given two equally attractive toys separated by a barrier. When the barrier was small (not a real obstacle), no preference for either toy. When the barrier was large (blocking access), boys went to the obstructed toy three times faster.
- The pattern is not random — it is the first expression of the freedom/control recognition that follows humans through their lives

### Kennesaw, Georgia Firearms Law
- Kennesaw, GA enacted a law requiring every adult to own a gun and ammunition, under penalty of fine
- Reactance theory prediction: the law restricts an established freedom (not to own a gun), so those whose freedom was being restricted would resist
- Actual result: firearms sales increased sharply in the weeks following passage — but interview analysis revealed the buyers were mostly out-of-town visitors, not town residents. The residents whose freedom was being restricted were massively noncompliant.
- The freedom to choose was being constrained, so the desire to exercise that choice (whether to own a gun or not) intensified

### Dade County Phosphate Detergent Ban
- Miami/Dade County banned laundry and cleaning products containing phosphates
- Two observed reactions: (1) open smuggling — "soap caravans" to neighboring counties, families reportedly hoarding twenty-year supplies; (2) attitude shift — Miami residents rated phosphate detergents as gentler, more effective, better on stains, and even believed they poured more easily than Tampa residents (not subject to the ban)
- Key finding: the attitude shift happened without the banned products being used. People did not assess the restricted item — they simply desired and believed in it more because it was restricted.
- "We just assume [restricted things] are better because we desire them more."

### University of North Carolina Censorship Study
- Students learned a speech opposing co-ed dorms would be banned
- Result: without ever hearing the speech, they became more sympathetic to its argument
- The ban made the information more persuasive, not less

### Chicago Jury Study (University of Chicago Law School)
- Experimental juries heard a case involving a driver with or without liability insurance
- When the driver said he was insured AND a judge ruled that evidence inadmissible: jurors awarded on average $46,000 — $13,000 MORE than when they knew he was insured and no censorship occurred
- Being told NOT to use information caused jurors to use it more heavily
- "Even proper, official censorship in a courtroom setting creates problems for the censor."

## The Romeo and Juliet Effect

- Study of 140 Colorado couples: parental interference in romantic relationships was linked to greater love and desire for marriage, not less
- As parental interference intensified, so did the love experience; when interference weakened, romantic feelings cooled
- Shakespeare placed Romeo and Juliet at ages 15 and 13 — adolescence is peak reactance age
- Virginia Slims cigarette campaign ("you've come a long way, baby"): framed smoking as freedom from old restrictions → teenage girls were the only demographic to show increased smoking rates during the campaign's run

## Defense Application

**The physiological reality:** When scarcity pressure activates, it produces a physical arousal response: blood pressure rises, focus narrows, cognitive processes narrow, emotional intensity increases. CBS Television president Robert Wood, after the Poseidon auction: "You get caught up in the mania of the thing, the acceleration of it. Logic goes right out the window."

**The paradox of knowing:** Knowing about the scarcity principle is NOT sufficient protection, because the principle works through emotional arousal that suppresses the cognitive faculties that would apply that knowledge. You can know you are being manipulated and still be manipulated.

**The two-stage defense (see SKILL.md Step 7):**
1. Use the rising arousal itself as a stop signal — it marks the moment to pause, not proceed
2. Ask the utility question: do I want this for use or for possession? The scarce cookies tasted the same.

---
name: reciprocity-strategy-designer
description: Design reciprocity-based persuasion strategies and detect when reciprocity is being used against you. Use this skill when planning give and take strategies, creating lead magnets or free value offers, designing favor-first or value-first outreach, building gift-based marketing campaigns, crafting free samples or free trials, writing content marketing that creates obligation, designing negotiation openings, planning door-in-the-face or rejection-then-retreat sequences, structuring concession-based selling, responding to unsolicited gifts or favors before a pitch, evaluating whether a gift creates obligation, planning reciprocal concessions in negotiation, or defending against manipulation through uninvited debts.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/influence-psychology-of-persuasion/skills/reciprocity-strategy-designer
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
source-books:
  - id: influence-psychology-of-persuasion
    title: "Influence: The Psychology of Persuasion"
    authors: ["Robert B. Cialdini"]
    chapters: [2]
tags: [persuasion, reciprocity, negotiation, marketing, sales, influence, lead-magnet, door-in-the-face]
depends-on: []
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Persuasion scenario or campaign plan — a description of what you're trying to achieve and with whom"
  tools-required: [Read, Write]
  tools-optional: []
  mcps-required: []
  environment: "Any agent environment. Document set preferred: marketing campaigns, sales sequences, negotiation plans."
---

# Reciprocity Strategy Designer

## When to Use

You are planning how to influence someone's decision, build compliance, or defend against unwanted influence. Typical triggers:

- Designing a content marketing, lead magnet, or free trial offer
- Writing a cold email or outreach sequence that leads with value
- Planning a negotiation opening position
- Building a sales sequence that uses concessions
- Receiving an unsolicited gift or favor before a pitch — and wondering how to respond
- Detecting a pattern where gifts precede requests in a pitch you are receiving

Before starting, identify:
- **What outcome do you want?** (A specific commitment, a sale, an agreement, a behavior change)
- **Who is the target?** (Individual, group, existing relationship or cold contact)
- **What mode applies?** Application (you are designing a strategy) or Defense (you are detecting and resisting)

---

## Context

### Required Context

- The persuasion goal: what specific action or agreement do you want
- The target profile: who they are and what they value
- The relationship stage: cold contact, warm prospect, established relationship, or adversarial negotiation

### Observable Context

Read the provided document or scenario for:
- Existing campaign structure, offer assets, or sales sequence drafts
- Any prior favors or gifts already in play
- The gap between what you currently get and what you want (baseline compliance)

### Default Assumptions

- If no target profile given → assume a cold or low-trust contact (most demanding scenario)
- If no mode specified → run both Application and Defense assessments
- If no existing assets → design from scratch

---

## Process

### Step 1: Identify the Goal and Baseline

**ACTION:** State what specific action or agreement you want, and estimate baseline compliance (would the target agree without any reciprocity strategy?).

**WHY:** Reciprocity strategies are most valuable when baseline compliance is low. If the target would likely agree anyway, reciprocity may be unnecessary. If baseline is near zero, only gift reciprocation with genuine value will move the needle. If baseline is moderate, concession reciprocation may triple compliance (17% → 50% in controlled studies). Knowing your baseline determines which sub-type to use and how large a "gift" or "opening request" is needed.

---

### Step 2: Choose the Reciprocity Sub-Type

**ACTION:** Decide whether to use **gift reciprocation**, **concession reciprocation**, or both.

**WHY:** These are mechanically different. Gift reciprocation works by creating obligation through a prior benefit — the target feels they owe something before any request is made. Concession reciprocation works by framing your actual request as a retreat from a larger one — the target experiences your real ask as a relief and a concession they should match. Mixing both (a gift followed by a retreat request) compounds the effect but requires careful calibration.

| Sub-type | Use when | Mechanism | Risk |
|---|---|---|---|
| **Gift reciprocation** | Cold outreach, marketing, relationship-building, low-trust contexts | Prior benefit creates obligation | Seen as cheap manipulation if transparent |
| **Concession reciprocation** | Negotiation, direct sales, any context with a known ask | Retreat triggers reciprocal concession | Backfires if opening request seems illegitimate |

---

### Step 3A: Design Gift Reciprocation

*Skip to Step 3B if using concession reciprocation only.*

**ACTION:** Design the initial value offering. Specify: what you will give, when, in what form, and how it relates to the eventual ask.

**WHY:** The gift must provide genuine value to create genuine obligation. Transparent manipulation — a token gift with no real benefit — is recognized and rejected, especially by experienced targets. The gift should be calibrated to the ask: a large request requires a meaningful gift; a small ask can be unlocked by a modest unsolicited favor.

**Design checklist:**

1. **What do you give?**
   - Marketing: educational content, free audit, free tool, free sample, insider information
   - Sales: free trial, free consultation, free product sample, referrals, early access
   - Negotiation: useful information, a favor in advance, a concession on a secondary issue

2. **Uninvited > invited.** Do not ask permission to give the gift — deliver it. Unsolicited gifts create stronger obligation than gifts that were requested. (Disabled American Veterans: unsolicited address labels doubled response rate vs. letter alone.)

3. **Personalize.** Generic gifts create weak obligation. Personalized gifts — addressing a specific need of this specific person — create stronger obligation. The closer the gift matches what the target actually values, the stronger the felt debt.

4. **Calibrate size to the ask.** A small gift can generate a disproportionately large return (a $0.10 Coke generated $0.50 in ticket sales — 500% return). You do not need a large gift for a moderate ask. However, the gift must be *genuinely* useful, not merely symbolic.

5. **Control the follow-up timing.** Make the request after the gift is received and acknowledged, not simultaneously. The obligation needs time to register.

---

### Step 3B: Design Concession Reciprocation (Door-in-the-Face)

*Skip to Step 4 if using gift reciprocation only.*

**ACTION:** Design the large initial request, the retreat sequence, and the actual target request.

**WHY:** The rejection-then-retreat technique works because when you retreat from a large request to a smaller one, the target perceives your retreat as a concession. The reciprocity rule triggers an obligation to make a return concession — compliance with your real request. Additionally, the contrast principle makes the real request appear smaller than if you had asked for it directly. Both forces push toward compliance simultaneously.

**Design sequence:**

1. **Define your actual request** (the outcome you want). This is your anchor.

2. **Design the large initial request.** It must be:
   - Clearly larger than your actual request (the target must refuse it)
   - Not so extreme as to appear illegitimate or in bad faith — this triggers backfire (Bar-Ilan research confirms: first demand must be seen as plausible, not outlandish)
   - In the same category as your real request (a retreat from asking for 2 years of volunteering to asking for one day is coherent; a retreat from "buy my $10,000 consulting package" to "buy my $5 ebook" is not)

3. **Make the large request first.** Pause. Accept the refusal without argument.

4. **Retreat visibly.** Frame the retreat as a genuine concession: "I understand. What if we started with just [smaller request] instead?" The target must perceive the retreat as voluntary on your part.

5. **Note the compliance target:** Compliance rates with the real request roughly triple when preceded by rejection-then-retreat (17% → 50% in zoo study). Follow-through rate also nearly doubles (50% → 85%).

**Critical constraint:** If your opening request is so extreme that the target does not believe you were genuinely making it, the tactic backfires. The truly gifted negotiator finds an opening position that is "exaggerated enough to allow for a series of reciprocal concessions that will yield a desirable final offer from the opponent, yet not so outlandish as to be seen as illegitimate."

---

### Step 4: Check Amplifier Conditions

**ACTION:** Review the following conditions that amplify or reduce reciprocity force. Adjust your design accordingly.

**WHY:** The same reciprocity strategy will produce different compliance rates depending on context. These amplifiers are documented mechanisms, not guesses.

| Condition | Effect | Action |
|---|---|---|
| Gift is uninvited | Stronger obligation (target cannot opt out of receiving) | Do not ask permission; deliver the gift |
| Gift is personalized | Stronger obligation (perceived higher value, more thoughtful) | Customize to target's specific situation |
| Gift is preceded by clear refusal of the return | Weakens obligation | Remove any explicit "I expect nothing in return" framing |
| Opening request is plausible | Concession reciprocity works | Calibrate the large ask to the upper range of credibility |
| Target has high awareness of influence tactics | Weakens effect (conscious recognition dampens automaticity) | Increase genuine value; reduce transparency of the sequence |
| Existing relationship | Either amplifies (more trust in the gift) or reduces (felt obligation already high) | Assess prior favor balance before adding more |
| Third-party witness | Amplifies follow-through | Make the agreement in front of others when possible |

---

### Step 5: Evaluate Ethical Boundaries

**ACTION:** Assess whether your strategy provides genuine value or only simulates it to extract compliance.

**WHY:** Reciprocity strategies that deliver real value are ethically sound and build lasting relationships. Strategies that use fake or trivial gifts purely to manufacture obligation are manipulation — they exploit a social rule that exists to promote genuine exchange. Beyond ethics, exploitation is also strategically weak: once detected, it destroys trust, the target resists all future requests, and negative word-of-mouth spreads. The rule's social power is borrowed from a legitimate system; abusing it erodes both the relationship and your reputation.

**Ethical checklist:**
- Does the gift provide genuine, standalone value to the target (independent of whether they comply with your request)?
- Would you offer this gift if you had no subsequent request to make?
- Does your large opening request in rejection-then-retreat represent a real position you would accept?
- Are you concealing material information that would affect the target's decision?

If any answer is "no," redesign to increase genuine value — or reconsider whether this is the right persuasion approach.

---

### Step 6 (Defense): Detect and Resist Reciprocity Exploitation

**ACTION:** Identify whether reciprocity is being used against you. Apply the reframe.

**WHY:** The reciprocity rule is powerful precisely because it operates automatically — it activates before conscious analysis. The defense is not to refuse all gifts (that produces social friction and misses genuine generosity) but to correctly classify what you receive. Once you recognize a "gift" as a compliance device rather than a genuine favor, the rule no longer applies — it says favors should be met with favors, not tricks.

**Detection signals — gift reciprocation being used against you:**

- An unsolicited gift arrives immediately before or during a sales interaction
- The gift is pressed on you when you attempt to refuse it ("No, it's our gift to you, sir")
- The gift is trivial relative to the subsequent ask
- The gift-giver has a clear commercial interest in your compliance
- The pattern repeats: gift → request, gift → request

**Detection signals — concession reciprocation being used against you:**

- An extreme initial offer precedes a "concession" to what they actually wanted
- You feel relieved when they retreat, and grateful
- The final request is larger than you would have agreed to if asked directly
- You feel responsible for having gotten them to concede

**The reframe:**
Once you identify a gift or concession as a compliance tactic, mentally redefine it: "This is a sales device, not a favor." The reciprocity rule now has no claim on you. You may accept the gift (the fire extinguisher, the free inspection, the flower) and decline the request — without guilt or felt obligation.

If you identify a concession as manufactured rather than genuine, define the retreat as a compliance tactic, not a real concession. No obligation to reciprocate arises from a tactic.

**Optional counter-move:** Once you have accepted their gifts under the new definition (as exploitation attempts, not gifts), you are free to accept what they offer and decline their ask entirely. The reciprocity rule itself supports this: exploitation attempts should be exploited in return.

---

## Outputs

For application mode, produce a **Reciprocity Strategy Plan:**

```
## Reciprocity Strategy Plan

**Goal:** [Specific outcome sought]
**Target:** [Who and what they value]
**Sub-type:** Gift reciprocation / Concession reciprocation / Both

### Gift Design (if applicable)
- Gift: [What you offer]
- Delivery method: [Invited or uninvited, personalization approach]
- Timing: [When relative to request]
- Estimated obligation created: [Low/Medium/High, why]

### Concession Sequence (if applicable)
- Large opening request: [What you ask first]
- Legitimacy check: [Why target will view this as genuine, not outrageous]
- Retreat: [What you retreat to — your actual ask]
- Framing language: ["I understand. What if we started with just..."]

### Amplifier Assessment
- [Condition]: [Present/Absent] → [Adjustment made]

### Ethical Assessment
- [Genuine value check result]
- [Any redesign needed]

### Expected Compliance Uplift
- Baseline: [%]
- With strategy: [% range based on comparable evidence]
```

For defense mode, produce a **Reciprocity Defense Assessment:**

```
## Reciprocity Defense Assessment

**Scenario:** [What you received and from whom]
**Sub-type detected:** Gift reciprocation / Concession reciprocation / Both

### Detection Evidence
- [Signal 1]
- [Signal 2]

### Classification
- Genuine favor: Yes / No
- Compliance device: Yes / No / Uncertain

### Recommended Response
- [Accept or decline the gift/concession]
- [Reframe in effect: Yes/No]
- [Obligation to comply: Yes/No]
- [Optional counter-move if exploitation confirmed]
```

---

## Examples

### Example 1: Marketing Lead Magnet Strategy

**Scenario:** A B2B software company wants to convert cold website visitors into demo requests. Current conversion: 3%.

**Trigger:** "We need more demo bookings. Should we add a lead magnet?"

**Process:**
- Goal: demo booking (a 30-minute commitment, moderate ask for a cold visitor)
- Baseline: 3% — very low, cold contact scenario
- Sub-type: gift reciprocation (cold context, no prior relationship to leverage for concession reciprocation)
- Gift design: a free industry benchmark report (genuine standalone value — visitors would read it even if no demo existed), personalized by company size via a brief survey, delivered without asking permission ("Download free — no email required" → captures email after value is consumed)
- Amplifier: uninvited delivery method (no opt-in gate), personalized by segment
- Follow-up: email sequence references the specific data the visitor consumed → request for demo framed as "see how your numbers compare to the benchmark live"
- Ethical check: the report provides genuine value independently; company would publish it even without the lead generation goal

**Output:** Lead magnet strategy doc with gift design, delivery sequence, and expected lift to 8–12% conversion.

---

### Example 2: Negotiation Opening — Salary or Contract

**Scenario:** A freelancer is negotiating a project rate. Their target is $8,000. The client's typical budget is $5,000–$6,000.

**Trigger:** "How should I open my rate negotiation?"

**Process:**
- Goal: $8,000 agreement
- Baseline: ~20% chance of $8,000 if asked directly (client may balk)
- Sub-type: concession reciprocation
- Large opening request: $12,000 (premium package including two rounds of revisions, a strategy session, and a 30-day post-launch support period — genuine, not fictitious)
- Legitimacy check: $12,000 is above market for a standalone project but plausible for the full-scope version; client may well refuse but will not find the number absurd
- Retreat: after client expresses hesitation, offer to strip the post-launch support to reach $8,000 — "I understand. If we remove the 30-day support retainer, I can bring this to $8,000."
- By-products: client feels they negotiated successfully (responsibility), feels satisfied with the outcome (satisfaction) → more likely to follow through and refer

**Expected effect:** Retreat from $12,000 to $8,000 makes $8,000 appear like the client's win. Compliance with real target significantly more likely than direct ask.

---

### Example 3: Sales Email Sequence — Value-First Outreach

**Scenario:** A sales team sends cold outreach emails. Current reply rate: 4%.

**Trigger:** "Help us write a cold email sequence that actually gets responses."

**Process:**
- Goal: discovery call booking
- Sub-type: gift reciprocation (cold email, no prior relationship)
- Email 1: deliver a specific, personalized insight about the prospect's company (a genuine observation about their positioning, a public data point they may have missed) — no ask, just value
- Email 2 (3 days later): build on the insight, offer a second useful observation — still no ask
- Email 3 (5 days later): make the request ("I've shared a couple of observations about [Company]. Would 20 minutes to walk through what I'm seeing be useful?")
- Personalization: each email references something specific to the prospect's company/role — not a template
- Amplifier: genuinely useful insights (not flattery) delivered before any ask — the sequence feels like receiving, not being pitched

**Defense note embedded in sequence design:** Avoid the trap of fake "value" emails that are obviously just preamble to a pitch. Prospects recognize the pattern and classify it as a manipulation tactic, neutralizing the reciprocity effect entirely. The insight in Email 1 must be something the prospect would genuinely appreciate independent of any subsequent ask.

---

## Key Principles

- **Uninvited creates stronger obligation than invited.** Do not ask permission to give; deliver genuine value. The target's inability to opt out of receiving is a feature of the rule, not an ethical violation — provided the gift is genuinely valuable.

- **The retreat must look real.** Concession reciprocation only works when the target believes the opening request was genuine. If it looks like a theatrical setup, the rule is not engaged and the tactic backfires.

- **Both mechanisms fire simultaneously in rejection-then-retreat.** The reciprocity rule (retreat = concession, triggers obligation to concede) and the contrast principle (smaller request appears smaller after larger one) compound each other. This is the most structurally powerful compliance technique documented.

- **Responsibility and satisfaction are the by-products.** Targets of successful rejection-then-retreat feel they influenced the outcome AND feel more satisfied than targets of direct requests — even though they paid more or agreed to more. These by-products increase follow-through and repeat engagement.

- **The defense is classification, not refusal.** Blanket refusal of all gifts produces social friction and misses genuine generosity. The correct defense is accurate identification: genuine favor → accept and reciprocate normally; compliance device → redefine as a sales tactic → no obligation applies.

- **Genuine value is both ethical and strategic.** Transparent manipulation is recognized by experienced targets and destroys trust permanently. Genuine value creates real obligation, builds reputation, and generates the satisfaction and responsibility by-products that produce follow-through.

## References

- [references/reciprocity-mechanics.md](references/reciprocity-mechanics.md) — Detailed mechanics, amplifier conditions, all quantified evidence
- [references/defense-protocol.md](references/defense-protocol.md) — Full defense decision tree, detection signals, reframe tactics

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Influence: The Psychology of Persuasion by Robert B. Cialdini.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/defense-protocol.md
# Defense Protocol: Resisting Reciprocity Exploitation

**Source:** Influence: The Psychology of Persuasion, Chapter 2 — Robert B. Cialdini
**Section:** "How to Say No"

---

## The Core Problem

When a requester employs the reciprocity rule for compliance, they enlist the rule itself as an ally — not just their own persuasive ability. The rule has been deeply conditioned into us since childhood. When it is activated, the feelings of obligation and fairness it produces are genuine psychological forces, not mere social pressure.

Two response options that appear available are actually weak:

1. **Comply** — surrendering to the rule and the requester's manipulation
2. **Refuse to comply** — suffering the psychological burden of obligation and the rule's cultural enforcement (feeling of being a moocher, ingrate, etc.)

Neither is optimal when the rule is being abused.

---

## The Key Insight

"The real opponent is the rule — not the person."

The requester has not actually given you a favor. They have used a compliance device — they have chosen to become a jujitsu warrior who aligns with the sweeping power of reciprocation and then releases that power by providing a first favor or concession. They borrowed the rule's force; they did not generate it.

**The rule says:** favors are to be met with favors.
**The rule does NOT say:** tricks are to be met with favors.

Once you correctly classify what you received, the rule no longer applies to it.

---

## Detection Decision Tree

### Step 1: Was anything given to you before or during the request?

- Yes → proceed to Step 2
- No → standard evaluation; reciprocity defense not needed

### Step 2: Was the gift/concession solicited or unsolicited?

- Unsolicited → higher exploitation signal; proceed to Step 3
- Solicited (you asked for it) → lower exploitation signal; likely genuine exchange

### Step 3: Is there a clear commercial or compliance interest behind the gift?

- Clear commercial interest → strong exploitation signal (fire inspector, Krishna flower, charity address labels, sales consultant "free" consultation before pitch)
- No apparent interest → likely genuine generosity

### Step 4: Was the gift trivial relative to the subsequent ask?

- Trivial gift, large ask → strong exploitation signal
- Proportional gift → lower signal (may still be exploitation if other signals are present)

### Step 5: Was the gift pressed on you when you tried to refuse it?

- Yes ("No, it's our gift to you, sir") → definitive exploitation signal
- No → ambiguous

### Step 6: For concession reciprocation — did the initial request seem extreme or theatrical?

- Yes → likely manufactured concession; retreat is a compliance tactic, not a genuine sacrifice
- No → may be genuine negotiation position

---

## Classification and Response

### Classification: Genuine Favor

**Signals:** Giver has no immediate commercial interest, gift is proportional, gift was not pressed on you when refused, no immediate request followed.

**Response:** Accept the favor. Feel the normal reciprocal obligation. Participate in the "honored network of obligation that has served us so well, both individually and societally, from the dawn of humanity." Plan to return the favor genuinely when the opportunity arises.

**Note:** Blanket refusal of all gifts is ill-advised. Authentic generosity exists and forms the foundation of cooperative society. Refusing genuine gifts creates social friction, isolates you, and is unfair to the giver.

### Classification: Compliance Device

**Signals:** Commercial interest is evident, gift is trivial, gift was pressed on you when refused, request immediately followed the gift, the pattern repeats.

**Response:**
1. Accept what was offered if it is genuinely useful — you are under no obligation to refuse it
2. Mentally redefine it: "This is a sales device, not a favor." Make this redefinition explicit in your own mind
3. Evaluate the subsequent request entirely on its own merits — the gift creates no obligation
4. Decline or accept the request based purely on whether it serves your interests

**Why this works:** The reciprocity rule requires that favors be met with favors. A compliance device is not a favor; it is a trick. You are not refusing to comply with the rule — you are correctly applying it to the actual nature of the exchange.

### Classification: Uncertain

**Response:** Accept with caution. Decline the request based on its own merits for now. If the giver follows up again with another gift-then-request pattern, reclassify as exploitation device.

---

## The Reframe in Practice: Fire Inspector Example

**Scenario:**
- Inspector arrives, introduces himself as working for a local Home Fire Safety Association
- Gives you a free hand extinguisher and performs a free home safety inspection
- Inspects your home, provides useful fire-safety information
- Suggests you purchase an expensive alarm system he represents

**Standard response (without reframe):** You feel obligated — he gave you a fire extinguisher and spent his time inspecting your home. Saying no feels ungrateful. You are likely to buy the alarm or at least feel bad about refusing.

**Reframe application:**
1. Identify the commercial interest: he is selling the alarm system. This was the primary motive for the entire visit.
2. Reclassify: the extinguisher and inspection were not gifts; they were sales devices — costs of customer acquisition paid by the company he represents.
3. Result: "Merely define whatever you have received from the inspector — extinguisher, safety information, hazard inspection — not as gifts, but as sales devices, and you will be free to decline (or accept) his purchase offer without even a tug from the reciprocity rule."

**If he retreats to a smaller request** (names of neighbors): Reclassify the retreat as a compliance tactic, not a genuine concession. No obligation to reciprocate arises.

---

## Optional Counter-Move: Turning the Tables

"Provided you are so inclined, you might even turn his own weapon of influence against him."

Once you have determined that gifts were exploitation devices rather than genuine favors, you are free to accept everything he offers (extinguisher, safety information, inspection) and decline his purchase request. You are not stealing — you have reclassified his gifts as what they actually are: sales costs. Accepting them without purchasing is simply declining to be manipulated.

"The reciprocity rule asserts that if justice is to be done, exploitation attempts should be exploited."

---

## Why Blanket Refusal Fails

A policy of refusing all initial offers and gifts:
1. Fails to distinguish genuine generosity from exploitation
2. Creates social friction and isolation
3. Is unfair to authentic givers
4. Prevents participation in legitimate reciprocal exchange networks that provide real value

**The lesson from Cialdini's colleague's daughter:** She was assigned to give flowers to visitors at a school open house. When she offered a flower to one man, he growled at her. When she extended it again, he demanded to know what she expected in return. When she said "nothing," he accused her of playing a game and walked on. The girl was so hurt she could not continue her assignment. The man's blanket rejection policy caused him to victimize an authentically generous person. Blanket refusal is not a viable defense.

**The viable defense is classification, not refusal.**

---

## Summary: The Defense in One Principle

Accept genuine favors and feel normal obligation.
Redefine compliance devices as sales tactics and feel nothing.

The reciprocity rule is a powerful social mechanism that deserves your respect in legitimate exchange — and your protection when it is weaponized against you. The distinction between the two requires only a moment of honest assessment: "Was this gift given to benefit me, or to obligate me?"

FILE:references/reciprocity-mechanics.md
# Reciprocity Mechanics Reference

**Source:** Influence: The Psychology of Persuasion, Chapter 2 — Robert B. Cialdini

---

## The Reciprocity Rule

"We should try to repay, in kind, what another person has provided us."

The rule is so pervasive that sociologist Alvin Gouldner reports there is no human society that does not subscribe to it. The noted archaeologist Richard Leakey ascribes the essence of what makes us human to this reciprocity system: "We are human because our ancestors learned to share their food and their skills in an honored network of obligation."

The evolutionary function: the rule enabled one individual to give a resource to another without actually losing it — because the obligation to repay guaranteed a future return. This "future orientation inherent in a sense of obligation" made sophisticated systems of aid, gift giving, defense, and trade possible for the first time.

---

## Three Core Properties

### Property 1: The Rule Is Overpowering

The rule can override factors that normally determine compliance — including personal liking of the requester.

**Regan Coke Study (Cornell University, Dennis Regan):**
- Confederate gave subject an unsolicited Coke (~$0.10) during a break; later asked subject to buy raffle tickets ($0.25 each)
- Outcome: Coke recipients bought **twice as many tickets**
- Critical finding: The liking–compliance correlation was completely eliminated in the Coke condition. Subjects who disliked the confederate but received a Coke bought just as many tickets as those who liked him.
- "The rule for reciprocity was so strong that it simply overwhelmed the influence of a factor — liking for the requester — that normally affects the decision to comply."

**Implications:** Even disliked, unwelcome, or strange sources can compel compliance if they have provided a prior favor.

### Property 2: The Rule Enforces Uninvited Debts

The rule does not require that we asked for what we received in order to feel obligated to repay it.

**Disabled American Veterans mailing study:**
- Simple mail appeal → 18% response rate
- Same appeal + unsolicited gummed address labels → 35% response rate (nearly doubled)

**Mechanism:** The social purpose of the rule is to allow one party to *initiate* a reciprocal relationship without fear of loss. This purpose requires that uninvited first favors create obligation. Marcel Mauss (French anthropologist): "There is an obligation to give, an obligation to receive, and an obligation to repay."

**Structural asymmetry:** The person who gives first controls both (a) the form of the initial favor and (b) the form of the debt-canceling return favor they subsequently request. All genuinely free choices belong to the requester. The target's only free choices were to accept or refuse both offers — and both refusals would have required going against powerful cultural conditioning.

**Hare Krishna example:** Flowers given to airport passersby created donation obligation even when the flowers were immediately discarded into the first available trash can. The unwanted gift nonetheless had already engaged the rule.

### Property 3: The Rule Can Trigger Unfair Exchanges

Small initial favors can produce disproportionately large return favors.

**Regan Study numbers:** A $0.10 Coke produced $0.50 in ticket purchases on average — a 500% return on investment.

**Why unequal returns happen:**
1. Indebtedness is psychologically uncomfortable — we are trained since childhood to chafe under obligation
2. Violating the rule incurs social stigma: moocher, ingrate, welsher — labels people go to great lengths to avoid
3. People agree to unequal exchanges to relieve the psychological burden of debt, not because the exchange is materially fair
4. University of Pittsburgh study: people will sometimes *avoid asking for favors they need* if they are not in a position to repay — the psychological cost of incurring obligation outweighs the material benefit of receiving help

---

## Two Sub-Types: Mechanisms Compared

| Dimension | Gift Reciprocation | Concession Reciprocation |
|---|---|---|
| Trigger | Prior benefit creates obligation before any request | Retreat from large request triggers obligation to concede |
| Timing | Gift → (delay) → Request | Large request → Refusal → Retreat to real request |
| Mechanism | Obligation to repay a favor | Obligation to reciprocate a concession |
| Secondary mechanism | None | Contrast principle (real ask appears smaller) |
| By-products | Gratitude, goodwill | Responsibility + satisfaction |
| Best context | Cold contact, marketing, low-trust, relationship-building | Direct negotiation, sales, known asks |
| Risk | Transparent manipulation recognized and rejected | Opening request seen as illegitimate → backfire |
| Defense | Reframe gift as sales tactic → no obligation | Recognize retreat as manufactured → no obligation |

---

## Amplifier Conditions

### Gift Reciprocation Amplifiers

1. **Uninvited > invited:** Obligation to *receive* reduces the target's ability to choose indebtedness. Unsolicited gifts create stronger obligation than gifts the target requested.

2. **Personalized > generic:** The more the gift matches what the target genuinely values, the stronger the felt debt. DAV address labels were individualized, not generic cards.

3. **Size calibration:** The gift does not need to match the ask in size. A small genuine gift can generate a large return. However, the gift must provide real standalone value — a token gift recognized as manipulation creates zero obligation.

4. **First-mover advantage:** The initiating party chooses both the form of gift and the form of return. Structural advantage is built into the rule.

5. **Gift framed as gift, not trade:** Explicitly framing the gift as a trade ("I'm giving you this so you'll give me that") cancels the reciprocity effect — it becomes a commercial exchange, not a gift.

### Concession Reciprocation Amplifiers

1. **Opening request plausibility:** The request must be extreme enough to guarantee refusal, but not so extreme as to appear in bad faith. Bar-Ilan University research confirms: if the first set of demands is seen as unreasonable, the tactic backfires — the retreat is not viewed as a genuine concession.

2. **Visible, voluntary retreat:** The requester must be seen as choosing to retreat, not being forced. The perception of a voluntary sacrifice is what triggers the obligation to make a return sacrifice.

3. **Third-party witness:** Compliance commitment made in front of others dramatically increases follow-through (separate from reciprocity mechanics — social proof and consistency effects compound).

4. **Contrast principle engagement:** The larger the opening request, the smaller the real request appears by comparison. This doubles the compliance force. The contrast principle is always engaged in rejection-then-retreat.

---

## Quantified Evidence Summary

| Study | Design | Finding |
|---|---|---|
| Regan (1971) | Unsolicited Coke → raffle ticket request | 2x compliance; overrides dislike |
| Disabled American Veterans | Mail with/without unsolicited address labels | 18% → 35% response rate |
| Cialdini zoo chaperon study | Direct ask vs. rejection-then-retreat | 17% → 50% compliance (3x) |
| Canadian volunteer follow-through | Verbal agreement + show-up rate | Follow-through: 50% → 85% |
| Blood donation future commitment | Direct vs. rejection-then-retreat | Future commitment: 43% → 84% |
| TV/Stereo salesperson | 3-year → 1-year service contract retreat | 40% → 70% close rate |
| UCLA negotiation study | Extreme stubborn vs. retreating opponent | Retreating opponent: most money AND most compliance AND most satisfaction |
| Billiard table selling down | Start at $3,000 vs. $329 model | Average sale: $550 → $1,000+ |
| Ethiopia-Mexico ($5,000, 1985) | Cultural/generational reciprocity test | Mexico aided Ethiopia in 1935; Ethiopia repaid in 1985 despite extreme need |

---

## The Two By-Products of Concession Reciprocation

**Responsibility:** UCLA negotiation study showed that subjects facing a retreating opponent felt they had personally influenced the final outcome — that they had "produced" the concession — even though the opponent had been instructed to retreat regardless. This felt ownership makes targets significantly more likely to live up to their commitments.

**Satisfaction:** Subjects who dealt with a retreating opponent gave the most money and reported the most satisfaction with the arrangement. An agreement forged through concession exchange feels negotiated, earned, and fair — even when it costs more than a directly negotiated alternative would have.

These two by-products explain the otherwise puzzling finding that rejection-then-retreat targets not only comply at higher rates but also follow through more reliably and are more willing to engage in further agreements.

---

## The Watergate Case Study

G. Gordon Liddy submitted intelligence plans to Mitchell, Magruder, and the CRP in sequence:

1. **Plan 1:** $1 million (call girls, kidnapping squads, chase plane, wiretapping) — rejected
2. **Plan 2:** $500,000 (reduced scope) — rejected
3. **Plan 3:** $250,000 ("bare bones" wiretapping only) — approved

Magruder's retrospective: "After starting at the grandiose sum of $1 million, we thought that probably $250,000 would be an acceptable figure.... We were reluctant to send him away with nothing." Mitchell "signed off on it in the sense of saying, 'Okay, let's give him a quarter of a million dollars and let's see what he can come up with.'"

The one dissenter — Frederick LaRue — was the only participant who had not been present at the first two meetings and was therefore not subject to the reciprocity and contrast forces created by the prior rejections.

**Lesson:** Rejection-then-retreat can work even at the highest levels of political decision-making, and its influence is traceable to specific structural conditions (prior exposure to larger requests).

---
name: persuasion-content-auditor
description: |
  Audit, analyze, review, or score any persuasive content against the 6 principles of influence: reciprocity, commitment and consistency, social proof, liking, authority, and scarcity. Use when someone wants to improve their copy, check their persuasion strategy, evaluate a landing page, review a sales email, audit marketing materials, or find out which influence principles they're using or missing. Triggers on: audit my copy, review my email, is this persuasive, persuasion score, influence check, analyze my landing page, make this more persuasive, improve my conversion rate, CRO review, check my sales page, why isn't this converting, which principles am I using, what's missing from my pitch, evaluate my offer, marketing copy review, persuasion audit, influence framework review, content persuasion analysis. Input: any piece of persuasive content — sales email, landing page, marketing copy, pitch deck, product page, social ad, proposal. Output: scored audit report with per-principle ratings, evidence citations, and specific rewrite recommendations.
model: sonnet
context: 200k
execution:
  tier: 1
  mode: full
  inputs:
    - type: document
      description: "Marketing content to audit — paste directly or provide as file path"
  tools-required: [Read]
  tools-optional: [Write]
  environment: "Works from any context; content can be pasted inline or read from file"
tags: [persuasion]
---

# Persuasion Content Auditor

## When to Use

Use this skill when you have a specific piece of persuasive content that needs evaluation — a landing page, sales email, marketing copy, pitch, proposal, ad copy, or any text intended to move an audience toward an action.

This skill is appropriate when:
- Someone asks whether their content is persuasive enough
- Someone wants to know which influence principles they're applying and which they're missing
- Someone needs specific, actionable rewrites — not generic advice
- Someone is diagnosing why content isn't converting and wants a principled diagnosis

**What makes this skill valuable:** It applies all 6 scientifically validated influence principles simultaneously and scores each independently. Most content uses only 1-2 principles by accident. Intentionally applying all 6 creates compounding persuasive effect — each principle reinforces the others.

**Agent:** Before starting, confirm you have the content to audit. If the user says "audit my landing page" without providing it, ask them to paste the content or provide the file path. Do not proceed without actual content.

## Context & Input Gathering

### Required Context (must have — ask if missing)

- **The content itself:** The actual text or file to audit.
  → Check prompt for: pasted copy, quoted text, file path references
  → Check environment for: .md, .txt, .html files the user may have mentioned
  → If still missing, ask: "Please paste the content you'd like audited, or give me the file path. I'll analyze it against all 6 influence principles."

- **The intended action:** What should the reader do after consuming this content?
  → Check prompt for: CTA mentions, goal statements, "I want them to...", sign up, buy, book, download
  → If still missing, ask: "What action do you want readers to take? (e.g., sign up, buy, schedule a call) — this helps me assess whether the persuasion strategy aligns with the conversion goal."

### Default Assumptions (when context cannot be gathered)

- **Audience:** General adult consumer or B2B professional unless otherwise stated
- **Stage:** Mid-funnel content (audience is aware of the problem, not yet decided on solution)
- **Goal:** Drive a specific conversion action (signup, purchase, inquiry)

### Sufficiency Threshold

PROCEED when: you have the content text AND either the intended action (or a reasonable inference from the content).

## Process

### Step 1: Read and Understand the Content

**ACTION:** Read the entire content in full before beginning any analysis. Note the overall structure, the offer, the audience signals, and the call to action.

**WHY:** Principles interact — a strong reciprocity element early in the piece sets up authority claims later to land harder. Evaluating principles in isolation without understanding the full arc misses compounding effects and sequencing issues.

**IF** content is a file path → use Read to load it
**ELSE** → work directly from the pasted text

### Step 2: Audit Each of the 6 Principles

**ACTION:** For each principle, evaluate: Is it present? How well is it applied? What is the specific evidence from the content?

Work through all 6 in sequence. For each principle, assign a rating and capture the evidence.

**WHY:** Sequential auditing ensures no principle is overlooked. Content creators typically default to whatever persuasion style feels natural to them — often 1-2 principles — and systematically miss the others. A scored checklist surfaces blind spots that intuition misses.

Use the scoring system from [references/audit-rubric.md](references/audit-rubric.md) for detailed criteria. Summary ratings:

| Rating | Meaning |
|--------|---------|
| **Strong (3)** | Principle clearly present and well-executed with amplifiers active |
| **Weak (1)** | Principle present but underexecuted — surface-level, no amplifiers |
| **Missing (0)** | Principle entirely absent |
| **Counterproductive (-1)** | Principle is present but applied in a way that backfires |

**For each principle, document:**
1. Rating (Strong / Weak / Missing / Counterproductive)
2. Evidence — quote specific phrases or elements from the content
3. What amplifiers are present or absent (see rubric)

**Principle 1 — Reciprocity**
Look for: Does the content give something before asking? Free value (content, tools, samples, useful information), a concession structure (large ask reduced to smaller ask), or a favor that creates felt obligation.
- Amplifier check: Is the gift uninvited (stronger) or expected/requested (weaker)? Does it arrive before the ask?
- Counterproductive signal: Taking without giving, leading with demands, making the reader feel extraction is happening

**Principle 2 — Commitment and Consistency**
Look for: Does the content invite small commitments that escalate? Does it ask readers to take a stance, identify with a value, or make a micro-decision that leads naturally to the main ask?
- Amplifier check: Are commitments active (user does something) rather than passive? Written rather than verbal? Public rather than private? Self-attributed ("because you care about X") rather than externally pressured?
- Counterproductive signal: Contradicting earlier commitments, asking for large commitment before small, or implying the reader's past behavior was wrong

**Principle 3 — Social Proof**
Look for: Testimonials, user counts, case studies, ratings, logos, mentions of others using the product. Are they specific (named, detailed, with results) rather than generic?
- Amplifier check: Do the proof examples match the target reader's situation (similarity condition)? Are they deployed where readers feel most uncertain about the decision?
- Counterproductive signal: Vague testimonials, testimonials from dissimilar audiences, manufactured-feeling proof, highlighting others' success in a way that makes the reader feel behind

**Principle 4 — Liking**
Look for: Does the content build rapport? Does it demonstrate shared values, shared identity, familiarity, or compliments to the reader? Does the brand/person behind the content feel warm and relatable?
- 5 factors to check: physical attractiveness/professional polish (visuals), similarity to the reader (shared struggles/values/background), compliments or acknowledgment of the reader's intelligence/good taste, repeated familiar touchpoints, positive associations (aspirational imagery, pleasant scenarios)
- Counterproductive signal: Cold, corporate tone; condescension; overly formal language that creates distance; negative associations (imagery of failure, threat, shame)

**Principle 5 — Authority**
Look for: Credentials, expertise signals, data citations, institutional affiliations, track record evidence, visual markers of professionalism. Does the content establish WHY the source should be trusted on this specific topic?
- 3 symbol types: Titles (credentials, certifications, professional roles), visual/clothes signals (design quality, photography professionalism, brand marks), trappings (media features, client logos, scale signals)
- Amplifier check: Is authority relevant to the domain? Is there a "strategic self-deprecation" move — acknowledging a minor flaw to increase credibility on the major claim?
- Counterproductive signal: Overclaiming credentials, authority from irrelevant domain, boastfulness that triggers skepticism

**Principle 6 — Scarcity**
Look for: Limited quantity language, deadline language, exclusive access framing, or information-scarcity ("only available to X group"). Does the content create urgency that is credible rather than manufactured?
- 3 types: Limited number ("only 12 spots left"), Deadline ("offer ends Friday"), Exclusive information ("only our subscribers know this")
- Amplifier check: Is the scarcity newly introduced (more powerful than constant scarcity)? Is it demand-driven ("because demand is high...") rather than arbitrary? Is there an information-scarcity layer on top of product scarcity (the "double whammy" — 6x effect)?
- Counterproductive signal: Fake urgency the reader can see through, permanent "limited time" offers, scarcity claims that contradict other signals in the content

### Step 3: Calculate Coverage Score

**ACTION:** Sum the 6 principle ratings. Identify how many principles are "Strong" (rating of 3).

**WHY:** Coverage score reveals the overall persuasive architecture at a glance. A piece with 2 strong principles and 4 missing ones is systematically under-persuasive regardless of how well-written the copy is. The goal is not necessarily to maximize all 6 simultaneously — some audiences and contexts call for restraint on certain principles — but missing 4-5 is almost always a problem.

**Coverage Score:**

| Coverage (principles ≥ Weak) | Assessment |
|------------------------------|------------|
| 5-6 principles present | Full-spectrum persuasion — evaluate depth next |
| 3-4 principles present | Partial strategy — identify high-value gaps |
| 1-2 principles present | Thin strategy — significant opportunity |
| 0 principles present | Unpersuasive content — structural rebuild needed |

### Step 4: Identify Top 3 Improvement Opportunities

**ACTION:** Among missing or weak principles, identify the 3 that would create the most impact if added or strengthened. Prioritize based on: (a) ease of implementation, (b) fit with the content type, (c) stage of the funnel.

**WHY:** Not all missing principles have equal value. Scarcity on a thought leadership article would feel manipulative. Reciprocity on a sales email is both easy to add and highly effective. The right improvement recommendations are context-specific, not a generic checklist.

**Selection criteria:**
- For cold/awareness content: Liking and Reciprocity usually have highest ROI (lower commitment ask)
- For decision/conversion content: Social Proof, Scarcity, and Authority usually have highest ROI (reduce friction at decision point)
- For retention/re-engagement: Commitment and Consistency usually has highest ROI (leverages prior investment)

### Step 5: Generate Specific Rewrite Recommendations

**ACTION:** For each of the top 3 opportunities, produce a concrete rewrite. Do not describe what to do — show it.

**WHY:** Generic advice ("add social proof") is useless. Specific rewrites ("Add a testimonial from a [role similar to target audience] who achieved [specific result] in [specific timeframe], placed immediately before the CTA") give the content creator an actionable, near-final version they can implement immediately. Specific examples also demonstrate that you understand their content deeply, not just the framework.

**Format for each rewrite recommendation:**
- **Principle:** which principle this addresses
- **Current state:** what exists now (quote from the content or "absent")
- **Why it matters:** the mechanism — WHY adding this will increase compliance
- **Recommended addition/change:** the actual new copy or structural change
- **Placement:** where in the content this element should appear

### Step 6: Produce the Audit Report

**ACTION:** Compile findings into a structured report following the template below.

**WHY:** A structured report makes findings actionable and shareable. The content creator should be able to hand this to a copywriter or implement it themselves without needing to re-read the analysis.

---

## Output: Persuasion Audit Report

```
## Persuasion Audit Report
**Content:** [title or description of audited piece]
**Date:** [today's date]
**Intended action:** [what the content asks readers to do]

---

### Principle Scores

| Principle | Rating | Score |
|-----------|--------|-------|
| Reciprocity | [Strong/Weak/Missing/Counterproductive] | [3/1/0/-1] |
| Commitment & Consistency | [Strong/Weak/Missing/Counterproductive] | [3/1/0/-1] |
| Social Proof | [Strong/Weak/Missing/Counterproductive] | [3/1/0/-1] |
| Liking | [Strong/Weak/Missing/Counterproductive] | [3/1/0/-1] |
| Authority | [Strong/Weak/Missing/Counterproductive] | [3/1/0/-1] |
| Scarcity | [Strong/Weak/Missing/Counterproductive] | [3/1/0/-1] |
| **Total** | | **/18** |

**Overall Assessment:** [Full-spectrum / Partial / Thin / Unpersuasive]

---

### Per-Principle Analysis

#### 1. Reciprocity — [Rating]
**Evidence:** [specific quotes or elements from the content]
**Amplifiers active:** [list which amplifiers apply]
**Gap:** [what's missing or could be stronger]

#### 2. Commitment & Consistency — [Rating]
**Evidence:** [specific quotes or elements from the content]
**Amplifiers active:** [list which amplifiers apply]
**Gap:** [what's missing or could be stronger]

#### 3. Social Proof — [Rating]
**Evidence:** [specific quotes or elements from the content]
**Amplifiers active:** [list which amplifiers apply]
**Gap:** [what's missing or could be stronger]

#### 4. Liking — [Rating]
**Evidence:** [specific quotes or elements from the content]
**Amplifiers active:** [list which amplifiers apply]
**Gap:** [what's missing or could be stronger]

#### 5. Authority — [Rating]
**Evidence:** [specific quotes or elements from the content]
**Amplifiers active:** [list which amplifiers apply]
**Gap:** [what's missing or could be stronger]

#### 6. Scarcity — [Rating]
**Evidence:** [specific quotes or elements from the content]
**Amplifiers active:** [list which amplifiers apply]
**Gap:** [what's missing or could be stronger]

---

### Top 3 Improvement Opportunities

#### Opportunity 1: [Principle Name]
**Why this has high impact:** [mechanism explanation]
**Current state:** [quote or "absent"]
**Recommended change:**
> [exact copy to add or replace]
**Placement:** [where in the content]

#### Opportunity 2: [Principle Name]
**Why this has high impact:** [mechanism explanation]
**Current state:** [quote or "absent"]
**Recommended change:**
> [exact copy to add or replace]
**Placement:** [where in the content]

#### Opportunity 3: [Principle Name]
**Why this has high impact:** [mechanism explanation]
**Current state:** [quote or "absent"]
**Recommended change:**
> [exact copy to add or replace]
**Placement:** [where in the content]

---

### Summary
[2-3 sentence overall assessment: what's working, what's the biggest gap, what to do first]
```

## Key Principles

- **Score each principle independently before forming an overall view** — WHY: Overall impressions are contaminated by the strongest elements. Systematic per-principle scoring reveals blind spots that impressionistic review misses. A piece can feel polished while being structurally missing 4 principles.

- **Look for counterproductive application, not just presence/absence** — WHY: A poorly applied authority signal (overclaiming, irrelevant credentials) is worse than no authority signal at all. It triggers skepticism that undermines otherwise good elements. Detecting counterproductive usage is as valuable as detecting gaps.

- **Match amplifier conditions to context** — WHY: Amplifiers multiply the effect of each principle, but only when conditions are right. Scarcity from new shortage is more powerful than constant scarcity. Social proof from similar people outperforms proof from dissimilar audiences. Simply "adding" a principle without its amplifiers often underdelivers.

- **Specificity in rewrites beats generic advice** — WHY: "Add social proof" is not actionable. "Add a testimonial from a [specific role] achieving [specific result] in [timeframe], placed before the CTA" can be implemented in 30 minutes. Specific recommendations are the product of this skill, not general observations.

- **Sequencing matters — principles interact** — WHY: Reciprocity given early in a piece makes authority claims land harder later (the reader is already obligated and predisposed to trust). Social proof placed at the decision point reduces cognitive friction precisely when commitment anxiety peaks. The position of each principle within the content arc affects its impact.

## Examples

**Scenario: SaaS signup page audit**
Trigger: "Here's our landing page — why isn't it converting better?"
Process: Agent reads the full page copy. Reciprocity: Missing — page leads immediately with pricing and features, no value-first gift. Commitment: Weak — has a CTA but no micro-commitments (no quiz, no "see if you qualify" step). Social Proof: Strong — has customer logos, testimonials with results, user counts. Liking: Weak — corporate tone, no shared struggles, no warmth. Authority: Strong — founders cited in press, credentials listed. Scarcity: Missing — no deadline or limited access signal.
Output: Score 8/18. Top 3 opportunities: (1) Add a free tool or resource offer above the fold for reciprocity — include specific copy for a "free audit" widget. (2) Add a micro-commitment step before the main CTA — "See if [Product] is right for you" quiz. (3) Add a "beta cohort closing Friday" deadline with demand-driven explanation.

**Scenario: Cold outreach email audit**
Trigger: "My open rates are fine but replies are terrible — can you audit this email?"
Process: Agent reads the email. Reciprocity: Weak — mentions a case study but doesn't lead with it as a gift. Commitment: Missing — no small ask, jumps straight to "schedule a call." Social Proof: Missing — no evidence of results, no similar clients. Liking: Weak — template-feeling language, no demonstrated research into recipient. Authority: Strong — mentions publications and company size. Scarcity: Missing.
Output: Score 5/18. The email establishes authority (who they are) but fails to give value first, build connection, or reduce the friction of a large first ask. Top opportunity: Lead with a specific insight about the recipient's business (liking through demonstrated attention), offer it as a free observation (reciprocity), then ask for a smaller commitment than a call — "Would it be useful if I sent you the full analysis?" builds commitment before scheduling.

**Scenario: B2B proposal document audit**
Trigger: "I keep losing deals at proposal stage — audit this proposal."
Process: Agent reads the proposal. Reciprocity: Strong — includes a free discovery findings section. Commitment: Strong — proposal references agreements made in discovery call ("As you said you needed..."). Social Proof: Weak — includes two testimonials but from different industries. Liking: Strong — personalized language, references shared goals. Authority: Strong — case studies with detailed results. Scarcity: Counterproductive — says "this offer expires in 30 days" but the timeline feels arbitrary and manufactured.
Output: Score 13/18. Strongest proposal areas are authority, liking, and commitment. The scarcity claim is backfiring — it reads as a pressure tactic rather than a genuine constraint, which undermines the trust built elsewhere. Fix: Replace arbitrary deadline with demand-driven scarcity ("We can only take on 2 new clients this quarter due to onboarding capacity") and fix social proof by adding a case study from the prospect's industry.

## References

- For detailed per-principle scoring rubric with amplifier conditions, counterproductive patterns, and evidence checklist, see [references/audit-rubric.md](references/audit-rubric.md)

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Influence Psychology Of Persuasion by Unknown.

## Related BookForge Skills

This skill is standalone. Browse more BookForge skills: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/audit-rubric.md
# Persuasion Audit Rubric

Detailed scoring criteria for each of the 6 influence principles. Used during Step 2 of the persuasion-content-auditor skill.

---

## Scoring System

| Rating | Score | Meaning |
|--------|-------|---------|
| **Strong** | 3 | Principle clearly present, well-executed, with at least one amplifier condition active |
| **Weak** | 1 | Principle present but surface-level — basic signal with no amplifiers, or amplifiers present but execution is thin |
| **Missing** | 0 | Principle entirely absent from the content |
| **Counterproductive** | -1 | Principle present but applied in a way that actively undermines trust or compliance |

Maximum total score: 18 (6 principles × 3 points each)

---

## Principle 1: Reciprocity

**Core mechanism:** People feel psychologically obligated to return favors. When you give something of value before making a request, you create a felt sense of indebtedness that makes compliance more likely — even if the recipient doesn't consciously recognize the trigger. The rule is strong enough to override even dislike for the requester (Cialdini, Ch. 2: Regan experiment — subjects who received a Coke bought twice as many raffle tickets even when they disliked the requester).

**What to look for:**

Strong (3):
- Leads with a genuine gift — free resource, tool, insight, sample, or useful information — before making any ask
- The gift is specific and valuable, not a generic teaser
- Gift is uninvited (proactively given, not requested): uninvited gifts create stronger obligation than invited ones
- Ask follows naturally after value delivery
- Optional: concession structure present (large ask presented first, then reduced to smaller ask — the contrast makes the smaller ask feel like a reciprocal concession)

Weak (1):
- A gift is mentioned but buried, minimal, or clearly instrumental ("here's a free trial... now buy")
- Gift is expected/standard (everyone gives this, so no felt obligation)
- Value delivery is vague ("we'll share insights" rather than delivering actual insights)

Missing (0):
- Content opens with the ask, pricing, or features — no value-first element
- Pure extraction structure: reader gives data/money/time, company gives product only

Counterproductive (-1):
- Content implies the reader owes something without actually giving anything
- Creates resentment by making the exchange feel one-sided
- Positions free content as a bait-and-switch that makes the reader feel manipulated

**Amplifiers:**
- Uninvited > invited (being given something you didn't ask for creates stronger obligation)
- Personalized > generic (a gift tailored to the specific person creates stronger obligation)
- Meaningful > trivial (the value of the gift matters for the strength of obligation)
- Given before ask > given simultaneously or after

**Concession structure (door-in-the-face technique):**
- Present a large request first, get refusal, then present the smaller actual request
- The retreat from the large request is perceived as a concession, triggering reciprocal concession from the prospect
- Example: "Full implementation — $50,000" → "Or, we could start with just the audit for $5,000"

---

## Principle 2: Commitment and Consistency

**Core mechanism:** Once people take a position or make a commitment, they feel internal and external pressure to behave consistently with that commitment. They will adjust their beliefs and actions to align with what they have already done. Written commitments are more powerful than verbal ones because they provide physical evidence of the act. Public commitments are more powerful than private ones because social reputation reinforces consistency pressure (Cialdini, Ch. 3).

**What to look for:**

Strong (3):
- Content invites a small, low-friction commitment before the main ask
- Uses self-labeling language that activates identity consistency ("As someone who cares about X...")
- Written component: asks reader to do something (fill in, sign up, configure, select)
- References earlier stated commitments or agreements from the reader
- The escalation from small to large commitment is logical and natural

Weak (1):
- Has a CTA but no escalation ladder — goes directly to largest ask with no micro-commitment steps
- Uses identity language but it feels generic rather than personalized

Missing (0):
- No small asks, no identity activation, no escalation structure
- Single large ask with no warm-up

Counterproductive (-1):
- Contradicts commitments the reader has already made (implying their past behavior was wrong)
- Forces commitment in a way that feels manipulative or coercive
- Large commitment ask before building any relationship or small commitment

**The 4 amplifier conditions (active commitment is most powerful when all 4 are present):**
1. **Active** — reader does something (vs. passive exposure). Writing, clicking, selecting, replying.
2. **Public** — commitment is visible to others. Public pledges, social shares, testimonials.
3. **Effortful** — the harder the commitment was to make, the more the person values it. Initiation rites, application processes, onboarding friction all increase commitment.
4. **Internally motivated (inner choice)** — the person feels they chose freely, not that they were coerced. Internal attribution ("I did this because I believe in it") is more durable than external attribution ("I did this because of the incentive"). Large rewards and strong threats produce temporary compliance without inner commitment.

**Most powerful combination:** Active + Public + Effortful + Internally motivated
**Weakest form:** Passive + Private + Effortless + Externally pressured

**Content patterns that activate commitment/consistency:**
- Quiz or self-assessment that elicits a stated belief or position
- "Manifesto" or values-alignment statement the reader agrees with
- A "why I care about X" prompt that precedes a related offer
- Application or qualification step before purchase
- "I want to [do X]" button language instead of "Sign up"

---

## Principle 3: Social Proof

**Core mechanism:** In uncertain situations, people look to what others are doing to determine the correct course of action. The greater the uncertainty, and the more similar those others are to the observer, the more powerful the social proof effect. Social proof is not just about volume (1 million users) — it is most powerful when the similarity condition is met: the proof comes from someone who is like me, in my situation, with my constraints (Cialdini, Ch. 4).

**What to look for:**

Strong (3):
- Specific testimonials with names, roles, and concrete results
- Testimonials from audiences similar to the target reader
- Social proof deployed at high-uncertainty decision points (near CTA, near pricing)
- Multiple proof types present: testimonials + numbers + logos + case studies
- Results are specific: "$47k in new revenue in 90 days" > "great ROI"

Weak (1):
- Generic testimonials ("It was amazing! — Happy Customer")
- Proof from dissimilar audiences (enterprise logos on a solopreneur product)
- Proof buried early in the content rather than at decision points
- User counts without context ("10,000 users" without industry context)

Missing (0):
- No testimonials, ratings, case studies, or social validation signals
- No "others are doing this" evidence whatsoever

Counterproductive (-1):
- Proof from irrelevant or dissimilar audiences that makes the target reader feel the product isn't for them
- Highlighting others' massive success in a way that creates inadequacy rather than aspiration
- Fake-feeling testimonials with no specificity (triggers skepticism)
- "Join 10,000 users" when the number is implausibly large for the product

**The 2 optimal conditions (both must be present for maximum effect):**
1. **Uncertainty** — reader is unsure what to do. Social proof is most powerful when the decision is ambiguous or novel.
2. **Similarity** — the people providing proof are like the reader. Same role, same problem, same context.

**Social proof sub-types:**
- **Pure social proof:** Organic testimonials from real users
- **Competitive social proof:** "X is switching from [competitor] to us because..."
- **Manufactured social proof:** Structured testimonial programs, review campaigns — effective but lower trust if perceived as manufactured

**Placement logic:**
- At product/service description: "Here's who else has done this"
- Before pricing: reduce sticker shock with "thousands of companies at this price point"
- After pricing (near CTA): reduce commitment anxiety with "here's what happened for people like you"

---

## Principle 4: Liking

**Core mechanism:** People comply more readily with requests from people they like. Liking is triggered by five distinct factors — each can be engineered independently. The effect is powerful enough that professional selling systems (Tupperware, referral networks) are built around nothing but manufactured liking (Cialdini, Ch. 5).

**What to look for:**

Strong (3):
- Content demonstrably applies 3 or more of the 5 liking factors
- Tone feels warm, personal, and relatable — not corporate or distant
- Shared identity or shared struggle is explicitly named
- Positive associations present (aspirational imagery, pleasant scenarios, aligned values)

Weak (1):
- 1-2 liking factors present but underdeveloped
- Tone is professional but not warm
- Generic "we understand your challenges" language without specificity

Missing (0):
- Cold, transactional, or corporate tone throughout
- No rapport-building, no relatable voice, no shared values language

Counterproductive (-1):
- Condescending tone, complexity signaling that creates distance
- Negative associations: imagery of failure, shame, threat, or inadequacy
- Formal language that creates hierarchy (reader feels talked down to)

**The 5 liking factors:**

1. **Physical attractiveness / professional polish**
   - In text: professional design, clear layout, no typos, quality photography
   - The "halo effect" — one positive characteristic (appearance) causes attribution of other positive traits (competence, honesty, intelligence)
   - Audit signal: Does the piece look like it was made with care?

2. **Similarity**
   - We like people who are like us — same opinions, personality, background, lifestyle
   - Audit signal: Does the content reflect the reader's specific world? Does it name their job title, industry, struggle, or aspiration in a way that feels like the writer knows them?
   - Powerful phrases: "If you're the kind of person who...", "Like most [target audience], you probably..."
   - Manufactured similarity: naming shared values, shared frustrations, shared goals

3. **Compliments**
   - We like those who tell us positive things about ourselves — even when we know the flattery is strategic
   - Audit signal: Does the content acknowledge the reader's intelligence, good taste, or quality in some way? Does it position the reader as someone who "gets it"?
   - Warning: Compliments must feel genuine to avoid triggering manipulation detection

4. **Familiarity and contact**
   - Repeated exposure increases liking — familiarity breeds fondness (not contempt, when the association is neutral or positive)
   - Audit signal for single pieces: Is there a callback to prior content or touchpoints? Does the brand voice feel like a familiar friend?
   - More relevant for email sequences and content series than single-page copy

5. **Association**
   - We like those who are associated with good things — and dislike those associated with bad things
   - Positive association audit: What does this content connect the product/brand to? Aspirational lifestyles, respected institutions, positive outcomes?
   - Negative association audit: Does the content inadvertently associate the product with problems, failures, or negative scenarios?

---

## Principle 5: Authority

**Core mechanism:** People defer to those they perceive as legitimate authorities — especially in domains where they feel uncertain. Authority compliance often operates on autopilot: the mere *symbols* of authority (title, appearance, trappings) trigger deference even when actual expertise is absent. Two questions break the spell: "Is this authority genuinely an expert in this domain?" and "Can we trust them to be truthful?" (Cialdini, Ch. 6).

**What to look for:**

Strong (3):
- Credentials are specific and relevant to the domain being claimed
- Multiple authority types present (titles + media trappings + track record)
- Strategic self-deprecation present: minor flaw acknowledged to increase credibility on major claim
- Data or citations from respected third-party sources (not self-reported only)

Weak (1):
- Authority signals present but generic ("experienced team", "leading company")
- Credentials listed but not connected to the specific claim being made
- Single authority type only

Missing (0):
- No credentials, track record, institutional affiliation, or expert signals whatsoever
- The source of the content is unknown or untrusted by default

Counterproductive (-1):
- Overclaiming — credentials that are obviously exaggerated or irrelevant
- Authority from wrong domain (celebrity endorsement in a technical field)
- Boastfulness that triggers skepticism ("the #1 most innovative company in history")

**The 3 authority symbol types:**

1. **Titles**
   - Job titles, certifications, degrees, professional designations
   - Even partial or informal titles carry weight
   - Must be relevant to the domain to activate authority compliance
   - Audit: Are titles present? Are they specific? Are they relevant to the claim being made?

2. **Clothes / visual signals / appearance**
   - In written content: production quality, design professionalism, photography quality
   - The equivalent of wearing a uniform or tailored suit — signals "this was made by someone serious"
   - Audit: Does the visual presentation signal authority-level production? Or does it look amateur?

3. **Trappings**
   - Associated status signals: luxury car (prestige auto study), media logos, institutional affiliations, awards
   - "As seen in Forbes/NYT/BBC" — publication logos
   - Client logos from recognized brands
   - Awards, rankings, notable associations
   - Audit: What external validation signals are present?

**The two-question filter for authority evaluation:**
1. Is this authority genuinely expert in the specific domain being claimed? (relevant expertise check)
2. Can we expect this authority to be truthful here? (conflict of interest check)

**Strategic self-deprecation:**
- Acknowledging a minor flaw or limitation before making the major claim
- Mechanism: "Anyone willing to admit a small negative must be telling the truth about the large positive"
- Example: "We're not the cheapest option — but our retention rate is 97% after year one"
- Audit: Is there any honest acknowledgment of limitation that makes the overall claims more credible?

---

## Principle 6: Scarcity

**Core mechanism:** Opportunities seem more valuable when their availability is limited. The scarcity principle works through two mechanisms: (1) the mental shortcut that rare = valuable, and (2) psychological reactance — people fight to retain freedoms they feel are being taken away. Newly scarce things are more powerful than always-scarce things. Demand-driven scarcity is more powerful than arbitrary scarcity. Information scarcity amplifies product scarcity by a factor of 6 (Cialdini, Ch. 7 — beef study).

**What to look for:**

Strong (3):
- Scarcity signal is credible and specific (real constraint, not obvious fiction)
- Demand-driven framing present ("because of demand" > arbitrary cutoff)
- Newly introduced scarcity (something that was available is now becoming scarce)
- Double whammy present: product scarcity + information scarcity layer

Weak (1):
- Scarcity signal present but vague or unconvincing ("limited time offer")
- Generic deadline that appears to be permanent or recycles
- Single scarcity type only, no demand-driven framing

Missing (0):
- No urgency, no limitation, no deadline
- The offer appears available indefinitely with no reason to act now

Counterproductive (-1):
- Fake urgency the reader can verify is false (countdown timer that resets, "limited" offer that's always available)
- Scarcity claim that contradicts other signals in the content
- Pressure-tactic framing that triggers reactance rather than desire ("Buy NOW or lose it forever!")
- Arbitrary cutoffs that feel manipulative rather than genuine

**The 3 scarcity types by mechanism:**

1. **Limited number**
   - "Only 12 spots remaining"
   - "We can only take on 3 new clients this quarter"
   - Most effective when: specific number, plausible given the product/service, accompanied by demand explanation
   - Audit: Is there a specific capacity constraint stated? Is it credible?

2. **Deadline**
   - Time-limited offer: "Offer closes Friday"
   - Event-driven deadline: "Registration closes when the cohort is full"
   - Most effective when: deadline is explained, not arbitrary — tied to a real event or process
   - Audit: Is there a specific deadline? Is the reason for the deadline explained?

3. **Exclusive information**
   - "This is only available to our newsletter subscribers"
   - "We haven't made this public yet, but..."
   - Information scarcity: "Only a handful of people know this approach"
   - Most effective: as an amplifier on top of product scarcity, not standalone

**Optimal scarcity conditions (the most powerful combination):**
- Newly scarce (just became limited — not always-been-limited)
- Demand-driven ("because of how many people want this" > "because we decided to limit it")
- Information-scarcity layer present (the scarcity itself is exclusive knowledge)
- All three together produce roughly 6x the buying response vs. standard sales pitch (Cialdini beef study)

**The double whammy:**
- Scarce product + scarce information about the scarcity = maximum persuasive force
- Example: "We have 3 slots opening next month [product scarcity], and I'm only telling our existing clients first before it goes out to our full list [information scarcity]"

**Psychological reactance warning:**
- Scarcity triggers desire, but pressure triggers reactance (desire to resist)
- The line: scarcity should feel like information ("here's the real constraint") not coercion ("you must act NOW")
- Hard deadline language without explanation reads as coercion
- Soft constraint language reads as information: "We're limiting this to 20 because the onboarding process requires personal attention from our team"

---

## Quick Reference: Amplifier Summary

| Principle | Key Amplifiers | Watch For |
|-----------|---------------|-----------|
| Reciprocity | Uninvited > invited; Personalized > generic; Before ask > simultaneous | Gifts that feel like bait |
| Commitment | Active + Public + Effortful + Inner choice (all 4 = max power) | External pressure removing inner attribution |
| Social Proof | Similarity condition; Uncertainty condition; Multiple proof types | Dissimilar audience proof; fake-feeling testimonials |
| Liking | All 5 factors present; Positive associations | Negative imagery; cold corporate tone |
| Authority | Relevant domain; All 3 symbol types; Strategic self-deprecation | Wrong-domain authority; overclaiming |
| Scarcity | Newly scarce; Demand-driven; Double whammy (info + product) | Fake urgency; arbitrary deadlines |

---

## Counterproductive Patterns Checklist

Run this check after scoring to catch active damage:

- [ ] Reciprocity: Does any content make the reader feel extracted from rather than gifted?
- [ ] Commitment: Does any content contradict prior commitments the reader may have made?
- [ ] Social Proof: Is any proof from audiences so dissimilar it excludes the target reader?
- [ ] Liking: Does any language condescend, create distance, or associate with negative scenarios?
- [ ] Authority: Are any credentials overclaimed, irrelevant, or likely to trigger skepticism?
- [ ] Scarcity: Is any urgency claim obviously manufactured or verifiably false?

One counterproductive element can neutralize several well-executed elements. Fix counterproductive applications before optimizing weak ones.

---
name: multi-principle-stacking-planner
description: |
  Design a layered persuasion campaign by combining 2–4 Cialdini influence principles in the right sequence. Use when someone asks "how do I combine influence principles?", "what's the best stacking order for my campaign?", "I want to use reciprocity AND scarcity — in what order?", or "how do I build a multi-touch persuasion sequence?" Also use for: designing a launch funnel that layers social proof onto scarcity, building a sales sequence that converts cold leads to committed buyers, creating an in-person event with maximum compliance architecture, auditing a multi-step campaign for principle interaction errors, planning a persuasion sequence for high-ticket or complex sales. Applies Cialdini's documented stacking patterns (Tupperware, Christmas toy tactic, Good Cop/Bad Cop, Regan override study) plus derived interaction rules — which principles amplify each other, which override each other, and which must be sequenced in a specific order. Covers: principle interaction rules, stacking sequences, contrast amplification, structural amplifiers, and ethical stacking thresholds. Outputs a sequenced campaign plan with WHY reasoning for each layer. Depends on influence-principle-selector (for principle scoring) and all 6 principle skills (for per-principle implementation). Best for experienced marketers, campaign strategists, and sales leaders working on multi-touch sequences, launch funnels, or complex sales architectures.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/influence-psychology-of-persuasion/skills/multi-principle-stacking-planner
metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
depends-on:
  - influence-principle-selector
  - reciprocity-strategy-designer
  - commitment-escalation-architect
  - social-proof-optimizer
  - liking-factor-engineer
  - authority-signal-designer
  - scarcity-framing-strategist
source-books:
  - id: influence-psychology-of-persuasion
    title: "Influence: The Psychology of Persuasion"
    authors: ["Robert B. Cialdini"]
    chapters: [2, 3, 4, 5, 6, 7]
tags: [persuasion, multi-principle, stacking, combining, campaign-strategy, sales-funnel, multi-touch, persuasion-sequence, layered-influence, campaign-architecture, influence-principles, reciprocity, commitment, social-proof, liking, authority, scarcity, contrast, cialdini, compliance-architecture]
execution:
  tier: 1
  mode: hybrid
  inputs:
    - type: document
      description: "Campaign brief, sales funnel plan, multi-touch sequence, or persuasion scenario description — any document describing a multi-step or multi-channel persuasion effort"
  tools-required: [Read, Write]
  tools-optional: [Grep]
  mcps-required: []
  environment: "Document sets — campaign plans, sales funnel specs, multi-touch email sequences, launch plans. Works with any agent environment."
discovery:
  goal: "Design a sequenced multi-principle persuasion campaign that applies documented stacking patterns and interaction rules to compound compliance effect across multiple touchpoints"
  tasks:
    - "Score and select 2–4 principles appropriate for the campaign"
    - "Apply interaction rules to determine which principles amplify, override, or depend on each other"
    - "Design the stacking sequence — which principle fires first, second, third"
    - "Check ethical boundaries — consent, proportionality, real vs. manufactured triggers"
    - "Produce a sequenced campaign plan with per-layer WHY reasoning"
  audience:
    roles: ["marketer", "campaign-strategist", "sales-leader", "product-manager", "growth-lead", "founder"]
    experience: "experienced — audience already understands individual Cialdini principles; this skill adds cross-principle interaction logic"
  triggers:
    - "User has a multi-touch campaign and wants to layer influence principles across touchpoints"
    - "User wants to build a launch funnel with maximum compliance architecture"
    - "User is designing a sales sequence and wants to know the correct principle order"
    - "User has already selected principles and needs help with sequencing and interaction rules"
    - "User wants to audit an existing funnel for stacking errors or missed amplification opportunities"
  not_for:
    - "Selecting which single principle to use — use influence-principle-selector"
    - "Implementing a specific principle in detail — use the dedicated principle skill"
    - "Defending against manipulation — use influence-defense-analyzer"
    - "Single-touchpoint persuasion — this skill adds value when there are 2+ steps or stages"
---

# Multi-Principle Stacking Planner

## When to Use

You have a multi-touch campaign, sales funnel, or persuasion sequence — and you want to layer 2–4 Cialdini principles to compound compliance effect across multiple interactions.

Single-principle strategies are limited. The Tupperware party deploys all six simultaneously. The Christmas toy tactic stacks commitment and scarcity across two months. Good Cop/Bad Cop combines contrast, reciprocity, and liking in a single interrogation session. The compounding happens because principles interact — some amplify each other, some must be sequenced in a specific order, some override each other entirely.

This skill provides the interaction rules and sequencing logic. It does not replace the individual principle skills — it tells you which principles to combine, in what order, and why.

**Do not use this skill if:** You need to select which single principle to use. Use `influence-principle-selector` first, then return here if stacking is warranted.

---

## Context and Input Gathering

Before running the stacking process, collect:

### Required
- **Campaign goals:** What is the desired action at the end of the sequence? (Purchase? Meeting booked? Subscription? Commitment to next step?)
- **Audience profile:** Who is being persuaded? Relationship to them? (Cold lead, warm prospect, existing customer?)
- **Number of touchpoints:** How many interactions or stages does this sequence have?
- **Evidence inventory:** What real evidence do you have? (Genuine testimonials, actual credentials, real scarcity, authentic peer behavior?)

### Important
- **Campaign type:** Launch, ongoing nurture, event, single-session sales conversation, or long sales cycle?
- **Highest-value principles already identified:** If you have run `influence-principle-selector`, bring those scores here.
- **Medium:** Email sequence, event, landing page series, in-person sales, social campaign, or mixed?

### Optional
- **Existing campaign draft:** If auditing an existing sequence, provide the touchpoint plan.
- **Competitor context:** Are you stacking in response to a competitor's persuasion architecture?

If required context is missing, ask before proceeding. Stacking decisions without audience and evidence context produce generic sequences rather than compounding architectures.

---

## Process

### Step 1: Define Campaign Goals and Score Applicable Principles

**Action:** Identify the campaign goal and target action. Score all 6 principles for applicability (1–5 scale). Select the 2–4 highest-scoring principles with real evidence available.

**WHY:** Stacking amplifies whichever principles you choose — but stacking weak principles does not produce strong results. Start with the highest-scoring principles for your specific situation. The 4-principle ceiling is practical: above 4 principles, the sequence becomes unmanageable and each principle receives insufficient development. The Tupperware party achieves all 6 because the format is specifically engineered for it; most campaigns achieve maximum effect with 3–4.

Use the scoring template from `influence-principle-selector` (Step 2) if you have not already scored principles. If scores are already available, bring them directly to Step 2.

**Minimum threshold for inclusion:** Score ≥ 3 (partial fit with real evidence) to include a principle in the stack. Below 3, the principle requires setup investment that exceeds its return in a multi-principle context.

---

### Step 2: Apply Interaction Rules

**Action:** For each pair of selected principles, check the interaction rules from `references/principle-interaction-matrix.md`. Identify: (a) which principles amplify each other, (b) which have sequential dependencies, (c) which override each other.

**WHY:** Principles do not simply add together — they interact. Deploying Scarcity before Commitment is established produces urgency that evaporates when the deadline passes; deploying Commitment first then Scarcity creates durable obligation that persists. Deploying Reciprocity alongside Liking is redundant — Reciprocity overrides Liking entirely for compliance. Knowing the interactions prevents wasted investment and prevents anti-patterns that reduce effect.

Key interaction rules to check for every stack:

**Override check:**
- Reciprocity + Liking → If both selected, Reciprocity makes Liking redundant for compliance. Keep Liking as a structural condition (relationship warmth) rather than a sequential step. Drop it as an active principle if Reciprocity is primary.

**Sequential dependency check:**
- Commitment → Scarcity: Commitment must always precede Scarcity. If both are in the stack, verify Commitment has an activation stage before the Scarcity stage.
- Authority → Social Proof (or other principles): Authority deployed first suppresses skepticism, making all subsequent claims land with less resistance.
- Uncertainty source → Social Proof: Social Proof is most potent after uncertainty is raised. If Social Proof is in the stack, confirm a prior stage creates uncertainty (Authority challenging the status quo, problem framing, or competitor comparison).

**Amplification opportunities:**
- Contrast (not a principle — a framing mechanism): Check whether contrast framing can amplify the primary principle. Present the expensive/negative/extreme anchor before your actual offer. This works for any principle, costs nothing, and is frequently missed.
- Liking as structural amplifier: If any touchpoint passes through a trusted intermediary (referral, partner, existing relationship), mark it as a Liking-amplified touchpoint. Every principle hit through a trusted source achieves higher compliance.

---

### Step 3: Design the Stacking Sequence

**Action:** Order all selected principles into a stacking sequence for the campaign. Assign each principle to a campaign stage or touchpoint. Write the WHY for each placement decision.

**WHY:** Sequencing is where stacking becomes strategy rather than coincidence. The Tupperware party achieves all six principles in a fixed order because the sequence is engineered: value-first (reciprocity) creates obligation before any ask, public commitment amplifies consistency pressure before buying begins, social proof builds during the purchase phase, scarcity closes. A different order would produce lower compliance at each stage.

**Sequence construction rules:**
1. **Reciprocity always opens** in cold or new-relationship contexts. Give before you ask.
2. **Commitment comes before Scarcity.** Scarcity deployed before commitment is established is temporary pressure that resolves when the deadline passes.
3. **Authority opens before technical or performance claims.** Establish credibility before making claims that require expertise.
4. **Social Proof follows uncertainty.** Raise a problem or challenge first; then resolve it with peer evidence.
5. **Scarcity closes.** Scarcity is the urgency mechanism — it motivates action on an already-established desire. Deploying it before desire is established creates pressure without direction.
6. **Contrast is a framing modifier on any stage** — apply it where you need a favorable comparison.

**Output format for this step:**

```
Stage 1 — [Principle]: [What happens at this touchpoint]
  WHY: [Reason this principle comes first]
  
Stage 2 — [Principle]: [What happens at this touchpoint]
  WHY: [Reason for this position; interaction rule applied]
  
Stage 3 — [Principle]: [What happens at this touchpoint]
  WHY: [Reason for this position; what Stage 1 and 2 set up]
  
[Contrast framing: Where contrast amplification applies and why]
```

---

### Step 4: Ethical Boundary Check

**Action:** For each principle in the stack, verify: (a) trigger features are real, (b) the audience has consented to a persuasion context, (c) the intensity is proportionate to the stakes.

**WHY:** Stacking multiplies persuasive force. What is ethical for a single principle can become manipulative when three or four principles are combined at full intensity against an audience that has not consented to a sales context. The proportionality test is the key ethical check for stacking: a warm lead who has engaged across multiple touchpoints can ethically receive a full stack; a cold contact receiving their first message should not.

Run each principle through the three-question test:

| Question | Pass Condition | Fail Condition |
|----------|---------------|----------------|
| Is the trigger feature real? | Genuine scarcity, actual testimonials, real credentials | Manufactured countdown, fake reviews, invented credentials |
| Has the audience consented? | Opted into email, attended event, is in an active sales process | Cold contact, no prior consent, captive audience |
| Is intensity proportionate? | Multi-principle sequence for a considered purchase decision | 3+ principles applied in a single cold outreach touchpoint |

**Practical threshold:** More than 2 principles in a single cold touchpoint is disproportionate. For a full stack (4+ principles), the audience should have taken at least one prior voluntary action (opted in, requested info, attended a session).

Flag any principle that fails any of the three tests. Either revise the trigger to be genuine, reduce the stack intensity for early-stage cold contacts, or remove the principle.

---

### Step 5: Produce the Sequenced Campaign Plan

**Action:** Write the complete stacking plan — campaign goal, selected principles, interaction rules applied, stacking sequence with per-stage WHY, contrast framing opportunities, ethical classification, and next-step implementation pointers.

**WHY:** A documented stacking plan creates alignment across teams, makes the persuasion architecture explicit for review and iteration, and enables handoff to the dedicated principle skills for implementation. The WHY reasoning at each stage is what separates strategic stacking from tactical coincidence — it allows the team to adapt the sequence when a stage underperforms without losing the overall architecture.

**Output format:**

```
## Campaign Stacking Plan: [Campaign Name]

### Goal
[Target action. Audience profile. Number of touchpoints.]

### Selected Principles
[List with scores and evidence available for each]

### Interaction Rules Applied
[Which interactions were identified and how they affected sequencing]

### Stacking Sequence
Stage 1 — [Principle]: [Touchpoint description]
  WHY: [Reason for placement; evidence used]
  
Stage 2 — [Principle]: [Touchpoint description]
  WHY: [Reason for placement; interaction with Stage 1]

[Continue for all stages]

### Contrast Framing
[Where applied; anchor vs. target; expected amplification]

### Ethical Classification
[Pass/Fail for each principle on: real triggers, consent, proportionality]
[Overall assessment: Fair practitioner / Revise before deploying]

### Implementation Pointers
→ [Principle skill] for [stage name]
→ [Principle skill] for [stage name]
```

---

## Inputs / Outputs

### Inputs
- Campaign goal and target action (required)
- Audience profile and relationship type (required)
- Evidence inventory (testimonials, credentials, scarcity data) (required)
- Principle scores from `influence-principle-selector` (recommended; will run inline if absent)
- Existing campaign touchpoint plan (optional — for audit use)

### Outputs
- Selected principle set (2–4 principles with scores and rationale)
- Interaction rules applied to the selected set
- Stacking sequence with per-stage WHY reasoning
- Contrast framing opportunities
- Ethical classification (per principle and overall)
- Implementation pointers to dedicated principle skills

---

## Key Principles

**Stacking compounds, not adds.** Reciprocity + Commitment + Scarcity in the right sequence does not produce 3x the compliance of one principle alone — it produces a compounding architecture where each stage builds the conditions the next stage needs. Commitment makes Scarcity hit harder. Reciprocity creates the obligation Commitment then locks in. The compound effect is what makes Tupperware parties generate $2.5M/day.

**Sequencing is the skill.** Most practitioners know which principles exist. Few know that Commitment must precede Scarcity, or that Authority should open before Social Proof to maximize effect. The order is where the value lives.

**Reciprocity is force-independent.** The Regan study proves that reciprocity obligation persists even when the audience dislikes the requester. This makes it the most reliable opener for cold interactions where no relationship exists — and it makes investing heavily in Liking redundant when Reciprocity is already active.

**Contrast is a free amplifier.** The contrast principle is not one of the six principles — it is a perceptual mechanism that amplifies any principle when applied directionally. Present the expensive anchor before your price. Present the problem before your solution. Present the competitor's limitations before your advantages. It costs nothing and is frequently left on the table.

**Ethical stacking requires proportionality.** A full 6-principle stack is ethical at a Tupperware party where attendees chose to come. It is not ethical in a cold outreach email. The consent and proportionality test governs how many principles you can ethically deploy at each stage of a campaign — more principles are appropriate as the audience has taken more voluntary actions signaling genuine interest.

---

## Examples

### Example 1: SaaS Product Launch Funnel (4-Principle Stack)

**Scenario:** B2B SaaS tool launching to an email list of 3,000 marketing professionals. Seven-day launch window. Real scarcity: founding member pricing ends on day 7. Real social proof: 23 beta customers with documented results. Real authority: founding team credentials. No prior commitment from the list.

**Trigger:** "We have a 7-day launch window and an email list. Design the stacking sequence."

**Process:**
- Step 1: Scores — Authority=5 (real credentials), Social Proof=5 (23 beta results), Scarcity=5 (real deadline), Commitment=3 (no prior, but micro-commitment possible via free demo)
- Step 2: Interactions — Authority should open (suppress skepticism before social proof claims). Social proof needs uncertainty; problem-framing creates it. Commitment precedes Scarcity — add a micro-commitment stage (demo request or waitlist confirmation) before the deadline push.
- Step 3: Sequence — 4 stages over 7 days
- Step 4: All triggers real. List opted in. Proportionate for a purchase decision.

**Output:**
```
## Campaign Stacking Plan: SaaS Launch — Founding Member Pricing

### Goal
Convert list subscribers to paying customers within 7 days.
Audience: 3,000 opted-in marketing professionals. Cold leads — no prior commercial interaction.

### Selected Principles
Authority (5/5) — Founding team credentials + beta results evidence
Social Proof (5/5) — 23 beta customers with measurable results
Commitment (3/5) — Micro-commitment via demo or free trial request
Scarcity (5/5) — Founding member pricing, real 7-day deadline

### Interaction Rules Applied
1. Authority → Social Proof: Authority opens (Day 1) to suppress skepticism;
   Social Proof follows after uncertainty is raised about current approach.
2. Commitment → Scarcity: Demo request (Day 3) creates micro-commitment;
   Day 5-7 scarcity push works against that commitment, not just a cold clock.
3. Contrast: Day 5 email contrasts "current state" (status quo pain) with
   "founding member result" before the pricing offer.

### Stacking Sequence
Day 1 — Authority: "Who we are and why this matters." Founding team story,
  credentials, problem we solved.
  WHY: Cold list has no reason to trust. Credibility must come before claims.

Day 2 — Social Proof: "What 23 marketing teams achieved in the beta."
  3 case studies with specific metrics.
  WHY: Authority (Day 1) created credibility for these claims. Uncertainty
  about current approach (opened in Day 1 problem framing) makes peer results
  compelling.

Day 3 — Commitment: "Want a free demo walkthrough?" Demo request = micro-commitment.
  Responders are now on record as interested.
  WHY: A list subscriber who requests a demo has taken an active step. The
  consistency drive will apply to the purchase decision on Day 5+.

Day 5 — Contrast + Scarcity opening: "Here's what beta customers' results look
  like vs. the status quo — and why founding member pricing closes in 48 hours."
  Contrast frame (before → after) before the deadline.
  WHY: Commitment established on Day 3 means scarcity now works against a prior
  decision, not against nothing. Contrast makes the offer appear favorable after
  the before-after framing.

Day 7 — Scarcity close: "Founding pricing ends tonight." Hard deadline.
  WHY: Desire is established across 4 prior touchpoints. Scarcity now functions
  as urgency on a warm decision, not pressure on a cold one.

### Contrast Framing
Day 5: Present current-state problems (benchmark metrics the audience recognizes
as their own) before presenting the beta result metrics. Contrast anchor = pain;
contrast target = solution. Sequence is directional — anchor first.

### Ethical Classification
Authority: Real credentials. Fair practitioner.
Social Proof: 23 genuine beta customers, real results. Fair practitioner.
Commitment: Demo request is voluntary and genuine. Fair practitioner.
Scarcity: Founding pricing deadline is real. Fair practitioner.
Overall: Full stack is proportionate for a purchase decision from an opted-in list.

### Implementation Pointers
→ authority-signal-designer for Day 1 email credibility architecture
→ social-proof-optimizer for beta case study selection and metrics framing
→ commitment-escalation-architect for demo CTA design
→ scarcity-framing-strategist for Day 5-7 deadline copy
```

---

### Example 2: In-Person Sales Event (Tupperware-Pattern Stack)

**Scenario:** A B2B consultancy hosts a half-day workshop for 20 invited prospects — all warm leads from past conversations. Goal: convert workshop attendees to signed project proposals within 2 weeks.

**Trigger:** "I have a live workshop with warm prospects. How do I design the compliance architecture?"

**Process:**
- Step 1: Warm audience with prior relationship → Liking already high (structural amplifier). Real credentials (authority). Peer participants (social proof potential). Can create commitment during workshop. Reciprocity via workshop value delivery.
- Step 2: Liking is structural (relationship exists — use it as amplifier, not a sequential step). Reciprocity opens (workshop IS the gift). Commitment can be activated during the session. Social proof via peer discussion. Authority via facilitation expertise.

**Output:**
```
## Campaign Stacking Plan: B2B Consultancy Workshop

### Goal
Convert 20 warm prospects to signed proposals within 2 weeks.
Audience: Warm leads — prior conversations, no proposals yet.

### Selected Principles
Reciprocity (5/5) — Workshop is a high-value gift before the sales ask
Commitment (4/5) — Can activate public commitment during the session
Social Proof (4/5) — Peer participants provide real-time social proof of problem
Liking (structural amplifier — pre-existing warm relationships)

### Stacking Sequence
Before workshop — Liking structural setup: Warm personal invitation, not
  generic calendar. Acknowledge the specific prior conversation that led here.
  WHY: Liking amplifies every other principle. Set the relational tone before
  participants arrive.

Workshop opening — Reciprocity: Deliver genuine, immediately usable insight
  in the first 30 minutes. Participants must feel "I already got value" before
  any commercial discussion.
  WHY: Reciprocity creates obligation that persists through the session. The ask
  comes later — the value comes first.

Workshop mid-section — Social Proof: Structured peer discussion of current
  challenges. Participants hear others in the room with the same problems.
  WHY: Peer recognition of shared problems creates social validation. "Others
  like me have this problem" is social proof in the problem space — it amplifies
  urgency for the solution.

Workshop commitment activation: Structured exercise where participants document
  their own problem and write one specific goal they want to achieve. Collected
  on paper (active + written = high commitment quality).
  WHY: A written, active commitment to a goal creates consistency pressure.
  When the proposal addresses exactly that written goal, the participant's
  consistency drive supports a yes.

Post-workshop — Scarcity: Proposal offer is time-bound (specific window) and
  may be capacity-limited (genuine: only 3 new projects in Q2).
  WHY: Commitment established in workshop means scarcity now works against a
  prior decision, not a cold one. Deadline motivates action on already-established
  desire.

### Ethical Classification
All triggers real. Warm audience chose to attend. Workshop value genuine.
Scarcity is real (capacity-limited Q2 slots). Full stack is proportionate.

### Implementation Pointers
→ reciprocity-strategy-designer for workshop content design
→ commitment-escalation-architect for the written exercise format
→ scarcity-framing-strategist for the post-workshop proposal framing
```

---

### Example 3: Campaign Audit — Email Funnel with Stacking Errors

**Scenario:** A 5-email nurture sequence for a $1,200 online course. Current sequence: Email 1 (course overview), Email 2 (discount offer — 30% off expires in 24 hours), Email 3 (testimonials), Email 4 (FAQ), Email 5 (last chance). Conversion rate: 0.4%.

**Trigger:** "Audit this email sequence. What stacking errors are we making?"

**Process:**
- Identify current principles in use: Scarcity (Email 2), Social Proof (Email 3)
- Check sequencing against interaction rules
- Anti-pattern: Scarcity before commitment is established = urgency without obligation. Social Proof after Scarcity = backward sequence (social proof should reduce uncertainty BEFORE urgency is applied)
- Missing: Reciprocity (no value given before ask), Authority, Commitment

**Output:**
```
## Campaign Stacking Audit: 5-Email Course Funnel

### Current State
Email 1: Course overview (no principle active)
Email 2: 24-hour discount (Scarcity — premature)
Email 3: Testimonials (Social Proof — misplaced)
Email 4: FAQ (no principle active)
Email 5: Last chance (Scarcity repeat)

### Stacking Errors Identified

Error 1 — Scarcity before Commitment (Email 2)
The discount fires in Email 2 before any commitment is established.
A subscriber who has read one course overview email has made no commitment.
The 24-hour clock creates urgency that evaporates when it expires — and teaches
the list that deadlines don't matter (they got the same price when it "expired").
FIX: Add a micro-commitment stage before the scarcity stage. (Quiz completion,
free lesson request, explicit "I'm interested" click.)

Error 2 — Social Proof after Scarcity (Email 3)
Testimonials follow the scarcity push, but social proof is most powerful BEFORE
the urgency close. It reduces uncertainty so the audience enters the scarcity
stage with desire already formed.
FIX: Move testimonials to Email 2 or 3, before the scarcity push.

Error 3 — No Reciprocity opener
Email 1 describes the course but gives nothing. No obligation is created.
A free lesson, diagnostic, or high-value piece of content in Email 1 creates
obligation before any ask is made.
FIX: Lead with value. Give a free lesson, worksheet, or high-utility piece of
content before the first commercial message.

### Revised Stacking Sequence
Email 1 — Reciprocity: Free mini-lesson or diagnostic tool. Value before ask.
Email 2 — Authority + Social Proof: Instructor credentials + 3 student results
  with specific outcomes. Reduces uncertainty; builds trust.
Email 3 — Commitment: "What's your biggest X challenge?" CTA or mini-quiz.
  Micro-step creates consistency pressure.
Email 4 — Contrast + Scarcity opening: Before/after framing, then discount
  deadline introduced. Contrast makes discount appear favorable.
Email 5 — Scarcity close: Hard deadline with commitment reference.
  ("You said your goal was X — this is how to achieve it, and pricing ends tonight.")

### Ethical Classification
Free lesson is real. Testimonials are genuine. Discount deadline must be real
(if the offer extends past the deadline, this becomes exploitative scarcity).

### Implementation Pointers
→ reciprocity-strategy-designer for Email 1 value offer design
→ social-proof-optimizer for testimonial selection
→ commitment-escalation-architect for Email 3 micro-commitment design
→ scarcity-framing-strategist for Email 4-5 deadline framing
```

---

## References

| File | Contents |
|------|----------|
| `references/principle-interaction-matrix.md` | Full interaction rules for all 6 principles; documented case studies (Tupperware, Christmas toy, Good Cop/Bad Cop, Regan study); ethical stacking thresholds; 5 stacking sequence templates (cold outreach through full Tupperware-pattern event) |

## License

This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/).
Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — Influence: The Psychology of Persuasion by Robert B. Cialdini.

## Related BookForge Skills

Install related skills from ClawhHub:
- `clawhub install bookforge-influence-principle-selector`
- `clawhub install bookforge-reciprocity-strategy-designer`
- `clawhub install bookforge-commitment-escalation-architect`
- `clawhub install bookforge-social-proof-optimizer`
- `clawhub install bookforge-liking-factor-engineer`
- `clawhub install bookforge-authority-signal-designer`
- `clawhub install bookforge-scarcity-framing-strategist`

Or install the full book set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

FILE:references/principle-interaction-matrix.md
# Principle Interaction Matrix

Source: Influence: The Psychology of Persuasion — Robert B. Cialdini Ph.D.

All interaction rules are derived from documented case studies in the book. Rules labeled with a source case reference the specific experiment or real-world example Cialdini uses to establish the interaction.

---

## Interaction Rules

### Rule 1: Reciprocity Overrides Liking
**Type:** Override (Reciprocity neutralizes Liking as a compliance factor)
**Source case:** Regan Coke study (Ch.2, pp.25-27)
**Mechanism:** Reciprocity obligation persists even when the recipient dislikes the requester. Subjects who received a Coke from "Joe" bought equally many raffle tickets whether they liked or disliked him. Subjects who did NOT receive a favor showed the expected liking-compliance correlation.
**Stacking implication:** Do not double-invest in both Reciprocity and Liking for the same compliance ask. One Coke-level favor is sufficient — additional liking-building adds marginal value when reciprocity is already active. Save Liking investment for contexts where you cannot provide upfront value (e.g., warm referral networks).
**Cold-start advantage:** Because Reciprocity works without relationship, it is the most reliable principle for first contacts.

---

### Rule 2: Commitment Must Precede Scarcity
**Type:** Sequential dependency (Commitment creates the hook; Scarcity provides urgency)
**Source case:** Christmas toy tactic (Ch.3, pp.59-61)
**Mechanism:** Parents who made verbal promises to their children (commitment) bought substitute gifts when the promised toy was unavailable (scarcity). When the toy became available again in January, the original commitment reactivated and drove a second purchase. Scarcity without prior commitment produces urgency but not durable obligation.
**Stacking implication:** Scarcity applied before any commitment is established is one-dimensional urgency. Add a commitment stage first: a micro-commitment (wishlist, waitlist join, verbal statement of interest) creates the consistency pressure that scarcity will then work against.
**Sequence:** [Commitment activation] → [Scarcity introduction] → [Resolution/purchase]

---

### Rule 3: Contrast Is a Directional Amplifier
**Type:** Amplifier (not one of the 6 principles — a perceptual framing mechanism)
**Source case:** Good Cop/Bad Cop (Ch.5, pp.150-152)
**Mechanism:** The contrast principle works by presenting a reference point (anchor) before the target, so the target appears more favorable by comparison. Good Cop seems especially kind BECAUSE Bad Cop was extreme. The direction is critical: the contrast anchor must appear FIRST.
**Stacking implication:** Contrast can amplify any principle. Use contrast framing to make your offer appear better-than-alternative before deploying Reciprocity, Scarcity, or Social Proof. Common applications: (a) present higher price tier before actual offer price, (b) frame status quo problems before solution, (c) present competitor limitations before your advantages.
**Anti-pattern:** Presenting your offer first, then the contrast anchor, activates contrast AGAINST you. Clothing store salespeople are trained to present the expensive item first specifically to avoid this.

---

### Rule 4: Liking Amplifies All Other Principles
**Type:** Structural amplifier
**Source case:** Tupperware party structure (Ch.5, pp.136-138)
**Mechanism:** Frenzer and Davis research: "The strength of that social bond is twice as likely to determine product purchase as is preference for the product itself." The Tupperware party's power comes not from the demonstrator or the product but from the hostess — a friend to every guest. Every other principle (reciprocity, commitment, social proof, scarcity) hits harder when deployed through a trusted relationship rather than a stranger.
**Stacking implication:** If you can deploy principles through a trusted intermediary (a friend, warm referral, known brand, recognized peer), every other principle will achieve higher compliance rates. This is why influencer marketing outperforms direct advertising — Liking is the multiplier in the stack.
**Sequence note:** Liking is a background condition, not a sequential step. Establish it structurally (referral, warm introduction, pre-existing relationship) rather than as a step within the interaction.

---

### Rule 5: Uncertainty Activates Social Proof
**Type:** Conditional amplification
**Source case:** Social proof under uncertainty (Ch.4, pp.125, 132-135)
**Mechanism:** "Social proof is most powerful for those who feel unfamiliar or unsure in a specific situation and who, consequently, must look outside of themselves for evidence of how best to behave there." The less certain the audience, the more weight peer behavior carries.
**Stacking implication:** Any principle that first increases uncertainty will amplify subsequent social proof. Authority challenging the audience's current approach creates uncertainty → Social Proof then resolves it. Problem-agitation-solution frameworks work on this dynamic: agitate the uncertainty, then resolve it with peer evidence.
**Sequence:** [Uncertainty creation] → [Social Proof deployment]
**Counter-application:** If the audience is already highly certain (e.g., expert buyers comparing specifications), social proof is less effective. Use Authority or Commitment instead.

---

### Rule 6: Authority Suppresses Skepticism Before Other Principles
**Type:** Sequential gate
**Source case:** Authority compliance mechanism (Ch.6, multiple)
**Mechanism:** Authority reduces the audience's critical evaluation. A credentialed source causes people to accept claims without independent verification ("click, whirr" to authority symbols). This skepticism-suppression effect means Authority deployed first makes all subsequent principle-activating claims land more cleanly.
**Stacking implication:** When deploying multiple principles, open with Authority if you have credible credentials — it lowers the audience's defenses and makes subsequent Reciprocity, Social Proof, or Scarcity claims receive less scrutiny. In email sequences, lead with credibility before making claims. On landing pages, present credentials before testimonials and offers.
**Sequence:** [Authority establishment] → [Other principles]

---

## Documented Full-Stack Case Studies

### Tupperware Party (All 6 Principles)
**Setting:** Home sales event; hostess-and-guests format.
**Stack sequence:**
1. Reciprocity: Games and prize bag before any selling begins. Everyone has received something before the ask.
2. Commitment: Guests publicly describe benefits they've experienced from their existing Tupperware.
3. Social Proof: Each purchase creates momentum; later buyers see earlier buyers choosing.
4. Liking: Purchase request comes through a friend (hostess), not a stranger salesperson. This is the structural amplifier for all others.
5. Authority: Tupperware demonstrator's product expertise provides credibility.
6. Scarcity: Limited-time party-only offers create urgency to decide now.
**Result:** Tupperware sales exceeded $2.5 million/day at time of writing.
**Ethical classification:** Fair practitioner. Guests chose to attend a known sales event. Products are real. Relationships are genuine.

---

### Good Cop / Bad Cop (3 Principles + Contrast)
**Setting:** Police interrogation. Coercive context — suspect cannot leave.
**Stack sequence:**
1. Contrast: Bad cop establishes extreme negative anchor (threats, rage, hostility).
2. Liking: Good cop builds cooperative relationship, positions as ally against bad cop.
3. Reciprocity: Good cop intervenes on behalf of suspect, spends own money for coffee — creating obligation before the confession request.
**Result:** Frequent confessions, often against the suspect's rational self-interest.
**Ethical classification:** Exploitative. Audience has not consented to the sales context and cannot exit. Coercive conditions.

---

### Christmas Toy Tactic (2 Principles)
**Setting:** Consumer retail, seasonal sales.
**Stack sequence:**
1. Commitment: TV ads prompt children to extract public verbal promises from parents.
2. Scarcity: Manufactured shelf unavailability during Christmas creates gap between commitment and fulfillment.
3. [Substitute purchase]: Parent spends Christmas budget on alternatives.
4. Commitment reactivated: January re-advertising reminds children of unfulfilled promise.
5. Second purchase: Parent buys original toy to maintain consistency with prior promise.
**Result:** Two toy purchases instead of one; manufacturer doubles revenue per household.
**Ethical classification:** Exploitative. Scarcity is manufactured intentionally to force substitute purchases. Parents are not informed of the intentional undersupply.

---

## Ethical Stacking Thresholds

The ethical test for stacking is not the number of principles but the proportionality check:

| Factor | Fair Practitioner | Exploitative Practitioner |
|--------|-------------------|--------------------------|
| Trigger features | All real | Any manufactured |
| Audience consent | Implicitly or explicitly in a sales/persuasion context | No consent; captive or uninformed audience |
| Stakes proportionality | Intensity proportionate to stakes | Extreme force on trivial or harmful decisions |
| Exit options | Audience can walk away | Audience is coerced or trapped |

**Practical rule:** Stacking 3+ principles against someone who has not consented to a sales interaction crosses from persuasion to manipulation. A willing prospect exploring your offer can ethically receive a full stack. A cold contact receiving their first touchpoint should receive 1-2 principles maximum.

---

## Stacking Sequence Templates

### Template A: Cold Outreach (1-2 Principles)
Reciprocity (give value first) → [Ask]
Optional: + Authority (credentials) as opener before the ask

### Template B: Warm Prospect / Lead Nurture (2-3 Principles)
Liking (relationship warmth) + Reciprocity (content value) → [Commitment micro-step] → [Ask]

### Template C: Launch / Limited Offer (3-4 Principles)
[Authority] → Social Proof (early results) → Commitment (waitlist/interest) → Scarcity (close)

### Template D: Multi-Touch Sales Funnel (4-6 Principles)
Reciprocity (lead magnet) → Commitment (micro-step: quiz, download, webinar registration) → Authority (credentials, case studies) → Social Proof (testimonials, social counts) → Contrast (competitor frame) → Scarcity (enrollment deadline)

### Template E: In-Person or Event (Full Tupperware Stack)
Reciprocity (refreshments, gifts) → Liking (host relationship) → Commitment (public testimonials from attendees) → Social Proof (group buying momentum) → Authority (product demonstration expertise) → Scarcity (event-only offer)