The Founding Hypothesis (Mad Libs Strategy Sentence)
Compress your entire startup strategy into one testable fill-in-the-blank sentence — then go prove it
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 3
- Confidence
- 90%
The single-sentence output of the Foundation Sprint that fuses customer, problem, approach, competition and differentiators into an explicit, testable claim. Framing it as a hypothesis (not a plan) keeps the team focused on validation, and making it explicit lets you interrogate each variable independently.
Origin
Created by Jake Knapp and John Zeratsky as the culminating artifact of the Foundation Sprint; detailed in their 2025 book 'Click.'
Core principles
- 01Every new product already has a founding hypothesis — it's just usually hidden and unspoken, so teammates hold different versions
- 02Making it explicit is what lets you test each variable and find out which are wrong
- 03The sentence lays your strategy bare in a form simple enough to feel silly and powerful enough to guide the whole project
- 04Pair it with a named backup plan so failure feels less scary and pivots are fast
How to run it
- 1
Fill the Mad Libs template
Write: 'If we solve [problem] for [customer] with [approach], they'll choose it over [competitors] because of [differentiator 1] and [differentiator 2].' Pull each blank from the sprint's three phases.
Pro tip Capture it fast, even on paper photographed onto the board, then formalize it.
- 2
Name the backup approach
Add the fallback approach ('or we could build X') so the team can pivot quickly if the primary approach fails in testing.
- 3
Hand it to the design sprints
Feed the hypothesis into back-to-back design sprints, where each sprint identifies the biggest risk to the hypothesis being true and tests it with prototypes and real customers.
Pro tip Treat it as a living document — expect to revise the customer, problem, approach, or differentiation slightly after each sprint.
Watch out Don't mistake the hypothesis for validation — it's the thing you now go test, not proof it will work.
In the wild
After their sprint, Latchet articulated: if we help artisans solve online sales growth with a social sales app (backup: build the full stack), we believe they'll choose it over Shopify and Etsy because our solution is cooperative and easy to use.
→ This single sentence became the basis for their design-sprint scorecards, letting them track exactly which variables were and weren't working week to week.
Common mistakes
Leaving the hypothesis implicit
When the founding hypothesis stays hidden, different teammates carry different versions and it becomes impossible to interrogate or test which variables are right.
Is it for you?
Best for
Founding teams that have completed the basics, differentiation and approach work and need a single shared, testable strategy statement
Not ideal for
Teams that already have clear product-market fit evidence and don't need to formalize an untested claim
From the transcript
“If we solve this problem for this customer uh with this approach, we think they're going to choose it over the competitors because of differentiator…”
“the term hypothesis is a part of this because it's not telling you this will work. It's this is the thing you will now test”
From the episode
Rapidly test and validate any startup idea with the 2-day Foundation Sprint (from the creators of the Design Sprint)
Jake Knapp & John Zeratsky (Character Capital)