Skip to main content
ClaudeWave
EN, English
Skill755 repo starsupdated 8d ago

tool-foundation-sprint-basics

Foundation Sprint Basics is the Day 1 morning decision-making session where a product team makes four explicit, bundled choices: target customer, important problem to solve, team competitive advantage, and what customers currently do instead. Use this skill after the sprint brief is approved and the team has sufficient customer knowledge to commit to a coherent strategic frame that feeds directly into Day 1 afternoon differentiation work.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/tool-foundation-sprint-basics && cp -r /tmp/tool-foundation-sprint-basics/skills/tool-foundation-sprint-basics ~/.claude/skills/tool-foundation-sprint-basics
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

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

# Foundation Sprint Basics

Day 1 morning of a Foundation Sprint. The team makes four foundational choices explicit: who the product is for, what important problem it solves, why this team has a right to win, and what customers do today instead. The output is one coherent strategic frame, not four separable decisions.

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 morning of a Foundation Sprint, after the brief is signed.
- The team has sufficient customer and market knowledge (per readiness verdict) to make informed choices.
- Each of the four sub-decisions is open or contested; the team has not pre-aligned on any of them.
- The Decider is in the room and ready to sign off on the bundled output before lunch.

## When NOT to Use

- The team lacks enough customer knowledge to choose a target customer or name an important problem. Run customer research or problem framing first; revisit when readiness criterion 3 passes.
- The team has already committed to a specific customer-problem pair and just wants to validate it. Use a lighter validation tool; Basics is for genuine decision-making, not ratification theater.
- Day 1 morning has slipped into afternoon. Differentiation depends on Basics being complete; if Basics did not produce a coherent frame by lunch, do not start Differentiation. Reframe or postpone.

## What This Skill Produces

A single bundled artifact with five sections:

1. **Target customer statement**: a specific, named customer with markers (demographic, behavioral, contextual).
2. **Important problem statement**: a customer-perceived pain strong enough to drive switching from alternatives.
3. **Team advantage inventory**: the capabilities, insights, relationships, data, and timing edges that make this team credible against the problem.
4. **Competitor and alternative map**: direct competitors, substitute workflows, manual workarounds, internal tools, and the strongest baseline of all: doing nothing.
5. **Note-and-Vote trace**: a record of how each sub-decision was made, including alternatives considered and Decider rationale.

The artifact is treated as one coherent output, not four separate ones. The team signs off on the bundled frame, not on the components in isolation. See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for the Brainshelf example.

## The Four Sub-Decisions

Each sub-decision uses `tool-note-and-vote` (the silent ideation + voting + Decider supervote protocol). The skill structures the sequence but the decision protocol is the standalone note-and-vote tool.

### 1. Target customer (25-35 minutes)

The team produces 3-7 candidate customer descriptions through silent ideation, then votes, then the Decider supervotes one. The chosen customer MUST be specific (not "SaaS PMs" but "PMs at Series-B SaaS companies between 20 and 100 engineers"). The skill rejects vague segments and prompts the team to add markers until the description names someone the team can recognize.

### 2. Important problem (20-30 minutes)

The team names 3-7 candidate pains the chosen customer experiences. Vote, then Decider supervote. The chosen problem MUST be painful enough to drive switching from current behavior (including doing nothing). Mild annoyances are not Important Problems; the skill enforces this by asking explicitly: "What does the customer currently do, and why would they leave it for our solution?"

### 3. Team advantage inventory (20-30 minutes)

The team enumerates its specific edges: capabilities, insights, relationships, data, technology, distribution, timing. Vote to surface the top 2-3 (multi-vote), Decider confirms. The skill rejects generic advantages ("great team," "passionate") and prompts for specific evidence ("Sam previously built X at Y company"; "Riley has a 12k-member network in our target segment").

### 4. Competitor and alternative map (20-30 minutes)

The team maps the full alternative space: direct competitors, substitute workflows, manual workarounds, internal tools, and "do nothing." For each, the team notes what customers use it for and why people leave (or stay). The skill enforces inclusion of "do nothing" as a competitor; many teams forget that inertia is often the strongest alternative.

## Inference Inputs

| Input | What the skill does with it |
|---|---|
| Sprint brief | Reads the Decision Target to scope which customers and problems are in-scope; out-of-scope candidates are flagged before voting |
| Customer/market context packet | Pre-populates the silent ideation board with previously-surfaced candidates so the team doesn't reinvent them |
| Competitor knowledge | Pre-populates the alternative map with already-known competitors; the team adds and discusses rather than starts cold |
| Team advantage notes | Surfaces the team's existing self-assessment; voting refines and prioritizes |

## Common Pitfalls

- **Vague customer.** "SaaS PMs" or "readers" is not a target customer. The skill prompts for markers until the team can name a specific person archetype.
- **Mild-annoyance problems mistaken for painful ones.** If the customer would not switch from doing nothing or from a paid alternative, the problem is not painful enough. The skill tests this explicitly.
- **Generic team advantages.** "Great engineers" is not an advantage; "Sam built the original Pocket sync engine and knows offline-first patterns" is. The skill rejects unspecific advantages and prompts for evidence.
- **Ignoring "do nothing" as a competitor.** The most common oversight. Many teams skip it because they think of competitors as named products; the skill forces inclusion.
- **Treating the four sub-decisions as separable.** A target customer whose important problem
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.