From pm-skills
Generates the canonical Founding Hypothesis sentence with assumption scorecard, why-we-believe, and next validation step. Use after Magic Lenses during a Foundation Sprint's Day 2 capstone.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pm-skills:tool-foundation-sprint-founding-hypothesisThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Day 2 end of a Foundation Sprint. The team compresses the full sprint output into a single canonical sentence plus a testable scorecard. This is the artifact the sprint exists to produce; everything before this skill was preparation. Without a ratifiable Founding Hypothesis, the sprint failed.
Family contract: docs/reference/skill-families/foundation-sprint-skills-contract.md. This skill is a member of foundation-sprint-skills.
A single bundled artifact with five sections:
See references/TEMPLATE.md for the canonical template and references/EXAMPLE.md for the Brainshelf example.
If we help [target customer] solve [important problem]
with [approach], they will choose it over [competitors or alternatives]
because our solution is [differentiators].
This template is strict for v0.1.0 (per ratified spec decision). Paraphrase is not accepted. Variations like "Because we help X with Y..." or compressing two slots into one ("solve [problem] with [approach]") are rejected by the skill. The strictness is intentional: forcing the template forces the team to fill every slot specifically.
The five slots are:
| Slot | Source | Discipline check |
|---|---|---|
| target customer | Basics target customer statement | Must be specific (markers, not segments) |
| important problem | Basics important problem statement | Must be painful enough to drive switching |
| approach | Magic Lenses top bet | Must be the top bet, not a softened version |
| competitors or alternatives | Basics competitor map | Must include "do nothing" if it was named there |
| differentiators | Differentiation chosen two | Must be both differentiators, not just one |
If any slot is vague, the skill rejects the hypothesis and prompts for revision.
| Quality | What it means |
|---|---|
| Specific | Names a real customer and a real problem; not "users" and "frustrations" |
| Comparative | Explains what customers choose today, including doing nothing |
| Differentiated | States why this solution should win, not just that it should |
| Testable | Translates into scorecard questions and experiments |
| Simple | A customer can understand the promise quickly |
| Uncomfortable enough to be useful | If nobody disagrees or feels exposed, the hypothesis may be too vague |
The "uncomfortable" quality is the hardest to enforce: teams unconsciously soften the hypothesis to make it ratifiable. The skill counter-acts by asking, in the discussion phase, "Who in this room would push back on this if they weren't on this team?" Silence is a signal that the hypothesis is too safe.
Decompose the hypothesis into 5-7 assumptions (recommended; 3-10 accepted per ratified spec decision). For each:
| Field | What goes here |
|---|---|
| Assumption | One sentence, derived from a specific slot of the hypothesis |
| Why it matters | What would be invalidated if this assumption is wrong |
| Current confidence | High / Medium-high / Medium / Medium-low / Low |
| Best next test | Specific test that would change the confidence level |
The highest-risk assumption (lowest current confidence, highest blast-radius-if-wrong) is the assumption the next validation step (often a Design Sprint) should test first.
The Decider drafts the canonical sentence by filling the 5 slots from prior sprint outputs. The team reviews, identifies vagueness, and revises until each slot is specific. This is the most important 15 minutes of the sprint.
Decompose the hypothesis into 5-7 assumptions. Score each. Identify the highest-risk one.
Bulleted lists, 3-5 each. The team writes both in parallel; the second list (proof-of-wrong) is the test of whether the team is holding the hypothesis with calibration.
The Decider names the next validation step: Design Sprint, customer research, experiment, etc. The recommended test should attack the highest-risk assumption from the scorecard.
The Decider signs. The sprint ends.
The Decider's job during Founding Hypothesis:
Prerequisites: tool-foundation-sprint-magic-lenses. The top bet, backup, and decision rationale are the load-bearing inputs.
The skill inherits the Basics bundled artifact (target customer, important problem, competitors) and the Differentiation bundled artifact (chosen differentiators). All five hypothesis slots are derived from prior sprint outputs.
Next invocation outside the sprint: the recommended next validation step. Most commonly tool-design-sprint-readiness if a Design Sprint is the next test. Sometimes pm-skills:measure-experiment-design or pm-skills:discover-interview-synthesis if a non-sprint test is the right next move.
There is no formal bridge skill between Foundation Sprint and Design Sprint; the transition is narrative content in _workflows/foundation-to-design.md and in both user guides.
This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider ratifies the hypothesis sentence, the scorecard, and the recommended next test. Ratification closes the Foundation Sprint. Without ratification, the sprint output is incomplete and the team did not produce what it set out to produce.
npx claudepluginhub product-on-purpose/pm-skills --plugin pm-skillsActivate for: assumption, hypothesis, assumption map, MVP, minimum viable product, lean startup, what assumptions am I making, test my idea, what could go wrong, assumption risk, validate assumption, kill my idea, stress test, what should I test first, MVP design, MVP scoping, what to build, minimum feature set, success criteria, failure criteria, pivot criteria, build plan, riskiest assumption, leap of faith assumption, critical assumption. NOT for: idea generation (use idea), customer discovery (use discovery), pilot results analysis (use validate).
Generates 3-7 one-page approach summaries during a Foundation Sprint's Day 2 morning, preventing first-idea anchoring. Use after Day 1 is signed and before Magic Lenses.
Guides teams through Jeff Gothelf's Lean UX Canvas v2 to frame business problems, surface assumptions, and define testable hypotheses before building.