Purpose
Turn a promising-but-unproven program idea into a designed learning experiment — one that tests the riskiest assumption cheaply, sets clear thresholds for continue/pivot/kill decisions, and captures what was learned in a reusable format. Prevents the common nonprofit failure mode of scaling an untested intervention or piloting for months without a decision rule.
When to Use
Invoke this skill when the user asks to:
- Design a pilot or test for a new program, service, or intervention
- De-risk a new idea before committing budget or board approval
- Set up success metrics and a decision rule for an experiment
- Test a new operating model, delivery channel, or partnership approach
- Structure a lean/MVP experiment for a program concept
- Figure out the cheapest, fastest way to validate whether an idea will work
Inputs Required
Before starting, collect:
- Program idea: 2–3 sentence description of the new program, intervention, or operating model being tested
- Target population: Who the program is meant to serve, and roughly how many
- Intended outcome: The change the program is supposed to create (behavioral, social, service-access, etc.)
- Riskiest belief: What has to be true for this to work that you're least sure about (if unknown, the skill will identify it)
- Constraints: Timeline, budget available for the test, and staff capacity
- Existing evidence: Any prior data, similar programs, or anecdotes that inform the idea
- Decision context: What decision this experiment is meant to inform (fund it, scale it, pitch to board/funder, kill it)
If the riskiest belief is not provided, identify it in Step 1 and confirm it before proceeding. If budget or timeline is missing, assume a low-cost 6–8 week test and note the assumption.
Instructions
Step 1: Identify the Riskiest Assumption
Every program idea rests on a stack of assumptions. Do not test the whole idea — test the one assumption that, if false, sinks everything.
Categorize the underlying assumptions into four types:
- Desirability: Does the target population actually want or engage with this?
- Feasibility: Can we deliver it with our capacity, skills, and infrastructure?
- Viability: Can it be sustained financially or operationally at scale?
- Effectiveness: Does it actually produce the intended outcome?
Rank the assumptions by two factors: how uncertain it is, and how catastrophic it is if wrong. The riskiest assumption is the one that is both highly uncertain and highly consequential. Name it explicitly — this is what the experiment tests. Everything else is deferred.
Step 2: Write a Falsifiable Hypothesis
Convert the riskiest assumption into a testable statement using this structure:
"We believe that [specific population] will [observable behavior or outcome] when we [specific intervention]. We will know we're right if [measurable signal] reaches [specific threshold] within [timeframe]."
Requirements:
- The hypothesis must be falsifiable — there must be a result that proves it wrong
- Use observable behavior, not intentions ("50 caregivers complete the intake" beats "caregivers are interested")
- State a specific threshold number, not a direction ("40% enrollment," not "high enrollment")
Step 3: Design the Minimum Viable Test
Select the cheapest, fastest test that can produce a real signal. Match the test type to the assumption category:
- For desirability: Concierge test (deliver the service manually to a few people), landing-page/sign-up test, or fake-door test to measure real demand
- For feasibility: Prototype a single delivery cycle with real staff and real participants at small scale
- For viability: Model the unit economics with real cost data from a small run, or test whether a funder/partner will commit
- For effectiveness: Small cohort with a clear before/after measure, ideally with a comparison group if capacity allows
Specify:
- Sample size: The minimum number of participants needed to trust the signal (be honest about statistical limits at pilot scale)
- Duration: How long the test runs
- What's real vs. faked: Which parts are genuinely built and which are simulated manually to save cost
- What you're deliberately NOT building yet
Step 4: Define Success, Pivot, and Kill Metrics
Set three thresholds before running the test — not after, when bias creeps in:
- Success (green): The result that says "continue and invest more." Tie it to the hypothesis threshold.
- Pivot (yellow): The result that says "there's a signal, but the current design is wrong — change one variable and retest."
- Kill (red): The result that says "stop — this assumption is false." State this explicitly; a test with no kill condition is not a test.
Include one leading indicator (early signal visible within days) and one lagging indicator (the true outcome measure), so the team isn't flying blind for weeks.
Step 5: Plan the Learning Capture
Design how insight gets documented so it survives beyond the pilot team:
- Baseline snapshot: What to record before the test starts
- Data collection method: How each metric is captured (survey, observation, admin data, interviews) and who owns it
- Learning log cadence: Weekly check-in questions the team answers during the run
- Decision debrief template: A one-page format capturing the hypothesis, the result vs. thresholds, the decision made (continue/pivot/kill), and the single most important thing learned
Step 6: Produce the One-Page Experiment Brief
Assemble the full experiment into a single scannable brief the team can execute from and a funder or board could review.
Output Format
- Structure: Six labeled sections following the steps, ending with a consolidated one-page experiment brief
- Length: 900–1,300 words
- Format: Structured document — prose for reasoning sections, a metrics table for the success/pivot/kill thresholds, and the final brief as a scannable one-page summary
- Sections: Riskiest Assumption → Falsifiable Hypothesis → Minimum Viable Test → Success/Pivot/Kill Metrics (table) → Learning Capture Plan → One-Page Experiment Brief
- Tone: Practical innovation director — evidence-minded, decisive about scope, honest about what a small pilot can and cannot prove
Quality Checklist
Before delivering output, verify:
- [ ] Exactly one riskiest assumption is named and justified by both uncertainty and consequence
- [ ] The hypothesis is falsifiable and states a specific numeric threshold and timeframe
- [ ] The test type matches the assumption category (desirability, feasibility, viability, or effectiveness)
- [ ] All three metric thresholds are present — success, pivot, AND an explicit kill condition
- [ ] Both a leading and a lagging indicator are specified
- [ ] The one-page brief is genuinely one page and executable without further editing
Notes
- The most common mistake is testing the whole program instead of the single riskiest assumption — resist scope creep in the test design
- At pilot scale, most tests won't reach statistical significance; treat results as directional signal, not proof, and say so plainly to funders
- A kill condition feels uncomfortable to write but is the entire point — it protects the organization's resources and credibility
- Concierge and fake-door tests often reveal in two weeks what a six-month pilot would reveal at 20x the cost
- When results land in the "pivot" zone, change only one variable before retesting, or you won't know what moved the outcome
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills