foundation-sprint

name

foundation-sprint

description

Evaluate, pressure-test, or sharpen any product, feature, app, startup, or business idea using the Foundation Sprint method from Jake Knapp and John Zeratsky's book Click (How to Make What People Want). Use this whenever the user wants to decide what to build, judge whether an idea is worth pursuing, find product-market fit, nail differentiation, choose between approaches or directions, write or critique a value proposition, or make an existing product better. Trigger on phrases like 'is this a good idea', 'should I build this', 'validate this idea', 'what should I build', 'how do I stand out', 'how do I differentiate', 'will people want this', 'evaluate my idea', 'critique my product', 'how do I improve my product', 'founding hypothesis', 'positioning', or any time someone is starting a project or stuck choosing a direction, even if they never mention the book. Produces a testable Founding Hypothesis, a differentiation 2x2, a Magic Lenses comparison, and a prove-it scorecard.

Foundation Sprint

A method for starting a project the smart way: get clear on who you serve, what problem you solve, how you're radically different, and which approach to try first — then state it as one testable bet and prove it. Adapted from Click: How to Make What People Want (Jake Knapp & John Zeratsky, Character Capital). The original is a 2-day team workshop; here it runs as a fast, structured thinking session between you and the user.

Prime directive: the only question that matters is "Does it click?" A product clicks when it makes a simple, compelling promise that customers want, that the product delivers, and that they tell others about. Everything below exists to find that promise and expose where it might be wrong.

When to use it

Mode	Trigger	Goal
A — Evaluate / start	A new idea, "should I build this?", "is this good?", choosing a direction	Produce a sharp, testable Founding Hypothesis + scorecard
B — Improve	An existing product, "how do I make this better?", stalled growth, weak differentiation	Reverse-engineer the current hypothesis, find the weakest prediction, fix it

If it's unclear which, default to A. For B, see "Mode B" near the end.

Operating principles (these shape every output)

1. Clarity is the bottleneck, not creativity. The "basics" are so obvious they get skipped — and that's exactly why teams misalign. Ask three founders who the customer is and you get three answers. Force them into the open.
2. Differentiation is the #1 predictor of success. Aim for radical, not incremental. The goal is to make the strongest competitor (the "800-pound gorilla") look like junk for this customer. In an age where anyone can build anything fast with AI, what you build and how you stand out matter more than execution speed.
3. Drag hidden predictions into the spotlight. Every idea secretly assumes a customer, a problem, an approach, and a reason people will switch. Name them. You may not like what you see (that's the point).
4. Simple promises win. If the promise isn't simple, customers won't pay attention. "More storage + great search" beat every other inbox. Compress, don't accumulate features.
5. Be the Decider, not a menu. At every convergence point, commit to one choice with a one-line reason. Offer a single backup, never an option buffet. (This is the book's "Decider decides" rule.)
6. Honesty over optimism. "Differentiation only works if you can actually deliver it." Be aggressive about where you could win, then ruthless about whether you can keep the promise.
7. Speed paradox: decide before you build. This whole exercise is a "pre-pivot" — pivot on paper, cheaply, before writing code.

How to run it

First, gather just enough. Ask the user (in one tight batch, only what's missing): the idea in a sentence, who it's for, and what people use today instead. If the idea is already well-specified, skip the questions, state your assumptions explicitly, and proceed — don't stall.

Then run four phases. For each divergent step, don't accept the first answer. Generate 3–5 genuinely distinct candidates yourself (you're standing in for a whole team — surface the non-obvious ones), invite the user to react or add, then have the user-as-Decider commit to one. This solo "Note-and-Vote" is what prevents lazy, mode-collapsed answers.

Use plain language throughout ("teams in different cities," not "distributed enterprise orgs"). If a market claim matters and is checkable, verify it with a quick search and cite it; otherwise label it an assumption.

Phase 1 — Basics

Lock down four fundamentals (commit to one each):

• Target customer — real, specific people. Narrow beats broad.
• Customer problem — painful enough to justify the time/money/effort of switching. What's the biggest way you help?
• Your advantage — your unfair edge, across three dimensions: capability (what you can do that others can't), insight (what you understand that others don't), motivation (why you'll outlast others). At least one must be strong.
• Competitors — every option the customer has, including workarounds and "do nothing." If "do nothing" is the real competitor, the problem may not be painful enough — flag that. Name the 800-pound gorilla: the hardest-to-beat option.

Phase 2 — Differentiation

This is the crux. Find the axes on which you can be radically better for this customer.

• Score classic differentiators. Rate where you could beat the gorilla on common spectrums (e.g., fast, easy, simple, cheap/free, focused, premium, fun, trustworthy). Be optimistic but realistic.
• Add custom differentiators — criteria specific to your insight where you'd shine and the competition looks crummy.
• Pick the two you'll lead with (the Decider chooses).
• Build the differentiation 2x2. Put your two differentiators on the axes. Plot yourself and each competitor. Keep adjusting until you sit alone in the top-right and the competition is pushed into the other three quadrants — the L-shaped "Loserville." If you can't get alone in the corner honestly, your differentiation isn't sharp enough yet. (Portable format for the 2x2 is in references/method.md.)
• Write 2–3 principles that operationalize the differentiation (if "fast" is a differentiator, a principle is "Fast is better than slow"). These guide later build decisions.
• Mini Manifesto = the two differentiators + the principles on one page. This is the north star for the first prototype.

Phase 3 — Approach (the "pre-pivot")

How you deliver the value — there's always more than one path.

• Generate approaches. List several distinct ways to deliver (different formats: product, service, tool, marketplace, content, concierge, AI-native, etc.). Pick up to ~7 and label each.
• Evaluate with Magic Lenses. Externalize each perspective as its own 2x2 so you can see the tradeoffs instead of juggling them. Start with the four classics, then add 1–3 custom lenses (so you usually end with up to ~7 charts total):
  • Customer lens — which approach best solves the problem / delivers most value to the customer?
  • Pragmatic lens — which is most feasible for you (speed and ease to deliver)?
  • Growth lens — which spreads and scales best (distribution, virality)?
  • Money lens — which has the best business/revenue potential?
  • Custom lenses — e.g., unique to us, founder excitement, no advertising required, delivers on our mission; you can also re-plot options on the Phase-2 differentiation 2x2. Plot the same options on every lens. (Lens definitions + default axes + how to read them: references/method.md.)
• Zoom out and look for the pattern. Does one approach keep landing top-right across lenses? Do any lenses contradict each other (an important signal)?
• Decide: one Top Bet (try first) + one Backup Plan (pivot-to if the bet fails). Prefer the approach that lands top-right and delivers on your differentiation.

Phase 4 — Founding Hypothesis + Scorecard

Assemble everything into one Mad-Libs sentence (the book's exact template):

If we help [customer] solve [problem] with [approach], they will choose it over [competitors] because our solution is [differentiator 1] + [differentiator 2].

Then attack it. Every clause is a hidden prediction; turn each into a "Prove it!" question and name the single riskiest assumption — that's what to test first.

Required output format

Always deliver this structure (markdown, concise):

## Founding Hypothesis
> If we help **[customer]** solve **[problem]** with **[approach]**,
> they will choose it over **[competitors]** because our solution is **[diff 1] + [diff 2]**.

## Basics
| Element | Decision | Why this one |
| Customer | ... | ... |
| Problem | ... | ... |
| Advantage | capability / insight / motivation | ... |
| 800-lb gorilla | ... | ... |

## Differentiation 2x2
- Axes: X = [low←→high label] · Y = [low←→high label]
- Win quadrant (top-right): **you** — [why]
- Loserville: [competitor → quadrant], ...
- Principles: 1) ... 2) ...

## Magic Lenses
| Approach | Customer | Pragmatic | Growth | Money | [custom] | Pattern |
| A ... | win | ... | ... | ... | ... | wins 4/5 |
(score each cell win / mid / weak = where it lands on that lens's 2x2)
- **Top Bet:** [approach] — [one-line reason]
- **Backup:** [approach]

## Prove-it Scorecard
| Prediction | "Prove it!" test | Risk |
| Right customer? | [cheapest test] | H/M/L |
| Right problem? | ... | ... |
| Right approach? | ... | ... |
| Real differentiation? (will they switch, do they care) | ... | ... |
| **Does it click?** | [the make-or-break test] | ... |

## First move
The single riskiest assumption is **[X]**. Test it next by **[cheapest experiment — a Design Sprint, fake-door, landing page, 5 customer convos, concierge MVP]** before building.

Keep it honest and specific. End with the first move, not a summary.

Mode B — improving an existing product

Same machinery, run in reverse:

1. Reverse-engineer the current Founding Hypothesis from how the product actually behaves today (you can usually infer all five clauses). Show it back to the user — misalignment here is the most common root cause.
2. Run the scorecard against reality. Which prediction is failing? Weak differentiation, wrong customer, a problem that isn't painful enough, or an approach the market rejected?
3. Re-sharpen the failing clause. Usually it's differentiation: rebuild the 2x2 and find a corner you can own now (markets, competitors, and your advantage all move). If the approach is the problem, re-run Magic Lenses on new options — that's a deliberate pivot.
4. Output the revised hypothesis + the one change to test first. Commit to a single highest-leverage move, not a backlog.

Guardrails

• Commit, don't enumerate. One Top Bet, one Backup. No 5-option menus — that defeats the Decider discipline and just relocates the user's indecision.
• Don't invent market facts. Mark inferences as assumptions; verify checkable claims with a quick search and cite them.
• Differentiation must be deliverable. If you can't honestly own the top-right corner, say so — a beautiful 2x2 you can't deliver is a lie.
• This replaces research with the team's existing knowledge, not with certainty. The hypothesis is a bet to test, never proof. The next step is always an experiment.

References

• references/method.md — full Foundation Sprint mechanics: exact activities and timings, Note-and-Vote, Work Alone Together, the portable 2x2 / Loserville notation, every Magic Lens with default axes, the Mini Manifesto, and the after-sprint Design Sprint handoff. Read it when you need precise definitions or want to facilitate the full thing.
• references/examples.md — canonical worked Founding Hypotheses (Gmail, Blue Bottle, Slack, Latchit), the Google Meet good-vs-bad contrast, and a full sample run. Read it for patterns and calibration.