Skip to main content
ClaudeWave
ES, Spanish
Skill755 estrellas del repoactualizado 8d ago

tool-foundation-sprint-differentiation

This Claude Code skill converts a product's morning strategy framework into a committed differentiation strategy during Day 1 afternoon of a Foundation Sprint. Teams score 8-15 candidate differentiators against customer-perceived value, select two core differentiators, plot them on a competitive 2x2 chart, establish decision principles, and produce a signed one-page Mini Manifesto. Use this skill immediately after the Basics framework is approved and before Day 2's Approach Options, but only when the team is genuinely ready to commit to a strategic position rather than ratify pre-chosen directions.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/tool-foundation-sprint-differentiation && cp -r /tmp/tool-foundation-sprint-differentiation/skills/tool-foundation-sprint-differentiation ~/.claude/skills/tool-foundation-sprint-differentiation
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

# Foundation Sprint Differentiation

Day 1 afternoon of a Foundation Sprint. The team converts the morning's Basics frame (customer, problem, advantage, competitors) into a defensible strategic position. The output is a one-page Mini Manifesto that the team and Decider sign as the Day 1 strategic summary.

Family contract: [`docs/reference/skill-families/foundation-sprint-skills-contract.md`](../../docs/reference/skill-families/foundation-sprint-skills-contract.md). This skill is a member of `foundation-sprint-skills`.

## When to Use

- Day 1 afternoon of a Foundation Sprint, immediately after lunch.
- The Basics bundled artifact is signed by the Decider; the customer, problem, advantage, and competitor map are committed.
- The team is ready to commit to a strategic position the product will occupy.

## When NOT to Use

- Basics is unresolved or under negotiation. Differentiation depends on a stable input frame.
- The team has already pre-chosen differentiators and just wants ratification. The skill is built for genuine decision-making; ratification theater wastes the afternoon.
- The team has lost the room: low energy, no Decider, time pressure. Postpone or split into shorter blocks rather than rush.
- This is a follow-up sprint and the existing differentiation still holds. Use Magic Lenses directly with the existing position.

## What This Skill Produces

A single bundled artifact with five sections:

1. **Scored differentiator candidates**: a table of 8-15 candidate differentiators scored on three customer-perceived dimensions (customer pull, team can deliver, hard to copy). The top scorers advance to the 2x2 chart.
2. **Two chosen differentiators**: the two the team commits to as the strategic position.
3. **2x2 differentiation chart**: a customer-perceived chart plotting the chosen differentiators against the competitor set from Basics. The team's product position is named.
4. **Decision principles**: 3-5 principles operationalizing the differentiation. Each principle is a future-product rule ("we will always prefer X over Y").
5. **Mini Manifesto**: a one-page strategic summary written in the team's voice, naming the customer, problem, position, and what the product is NOT.

See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for the Brainshelf example.

## Sequence (150 minutes)

### Step 1: Generate differentiator candidates (15-25 min)

Each team member produces 3-5 candidate differentiators silently. Cluster duplicates, then surface the full set (8-15 candidates is typical). The candidates can be classic (speed, price, simplicity, breadth, depth, trust) or custom (specific to this product or market).

### Step 2: Score candidates (25-40 min)

Score each candidate on three dimensions, 1-5 scale:

- **Customer pull**: would this customer-perceived dimension actually drive a switch?
- **Team can deliver**: can this team build and operate at this dimension competitively?
- **Hard to copy**: how durable is the advantage if a competitor pivots?

Sum the three for a rough score. Top 5-7 candidates advance.

### Step 3: Choose two differentiators (30-45 min via note-and-vote)

The team narrows to two differentiators through `tool-note-and-vote`. The two MUST be observable to the customer (not internal-team values) and deliverable by the team (not aspirational). The Decider supervotes if scoring produces a tie or the team is split.

### Step 4: Plot the 2x2 chart (15-25 min)

Place the two differentiators as the chart axes. Plot the competitor set from Basics (including "do nothing"). Position the product where it can occupy unoccupied space. If the unoccupied position is too far from where competitors cluster, the team may be drifting into a niche that customers don't recognize; if the position overlaps with a strong competitor, the differentiation is not strong enough.

### Step 5: Write decision principles (20-30 min)

Convert the two differentiators into 3-5 operational principles. Examples:

- "Capture is the first-class action. Every other feature waits behind a fast capture path."
- "Private by default. Sharing is opt-in."
- "Surface what's relevant when it matters. Not on a notification schedule."

Principles are NOT marketing copy. They are decision-making rules for future product calls.

### Step 6: Mini Manifesto (15-25 min)

The Decider drafts a one-page Mini Manifesto in the team's voice. Tone is plain, declarative, and direct about what the product is NOT (this is the part teams skip and shouldn't).

## Inference Inputs

| Input | What the skill does with it |
|---|---|
| Basics bundled artifact | Reads target customer (for "customer-perceived" check), problem (for "would this differentiator solve the problem"), advantages (for "can the team deliver"), and competitor map (for chart plotting) |
| Differentiation candidates | If pre-supplied, pre-populates the silent ideation board; otherwise the team generates them in Step 1 |

## Common Pitfalls

- **Marketing-claim differentiators the product cannot deliver.** "Best in class," "AI-powered," "delightful" are not differentiators; they are aspirations. The skill rejects these and prompts for evidence the team can deliver.
- **Differentiators that are not customer-perceived.** "Beautifully architected code" matters to engineers, not customers. The skill enforces a "would a customer notice this in 30 seconds?" check.
- **Generic decision principles.** "Simple" and "fast" do not operationalize anything. Principles must be actionable: "we will choose X over Y."
- **Treating chart, principles, and manifesto as separable artifacts.** The chart positions the product; the principles operationalize the position; the manifesto communicates it. Without coherence, the Day 1 PM output is a pile of decks rather than a strategic summary.
- **Skipping the Mini Manifesto.** Many teams stop after the chart. The manifesto matte
chainSlash Command

Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)

define-hypothesisSkill

Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.

define-jtbd-canvasSkill

Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.

define-opportunity-treeSkill

Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.

define-prioritization-frameworkSkill

Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.

define-problem-statementSkill

Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.

deliver-acceptance-criteriaSkill

Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.

deliver-edge-casesSkill

Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.