A startup has to create knowledge before it creates revenue. You don’t yet know who will buy, what they’ll pay or how you’ll reach them. You have guesses. Hypothesis testing is how you turn those guesses into facts you can build on, one cheap test at a time.
This is the second guide in our customer development series. It covers the thinking: how to write a hypothesis, how to choose which one to test first and how to keep score. The next guide covers which test to run on a small budget.
It’s the same loop you learned in a school science class:
The Lean Startup calls the output of this loop validated learning and treats it as the unit of progress. A feature you shipped is output. A guess you proved or disproved is knowledge.
Every early product rests on five kinds of guesses. Write at least one for each.
| Area | Example hypothesis | What would kill it |
|---|---|---|
| Customer | Owners of small dental clinics handle rescheduling themselves | Most clinics you talk to have a receptionist for it |
| Problem | Rescheduling costs them at least 3 hours a week | People shrug and can’t say how long it takes |
| Solution | A text message with one-tap rebooking would cut that time | People keep phoning anyway in a prototype test |
| Channel | We can reach clinic owners through dental supply newsletters | Nobody clicks, or the wrong people do |
| Price | Clinics will pay $49 a month | Nobody pre-pays, or they only pay at $10 |
The first two rows and the last one deserve the most attention. In CB Insights’ March 2026 study of startups that shut down since 2023, 43% of those with a known reason cited poor product-market fit and 19% cited unit economics that didn’t work. Both start as an untested guess about the customer or the price.
A useful hypothesis names who, what and how you’ll know. Use this template:
We believe [this customer group] [has this problem or will do this]. We’ll know we’re right if [a signal you can count] by [a date]. If we see less than [a number], we change or drop it.
An example, with made-up numbers: “We believe owners of small dental clinics lose at least 3 hours a week to rescheduling. We’ll know we’re right if 7 of 10 owners we interview describe a rescheduling problem from the last week, by 15 November. If fewer than 4 do, we drop this segment.”
Set the pass and fail line before you look at the data. The Scrum Guide Expanded, updated in January 2026, gives the reason: defining how you’ll check value before the work starts avoids bias and wrong readings. Once you see the results, it’s too easy to decide that 3 out of 10 was “promising”.
You can’t test everything at once. Score each hypothesis on two questions:
Test the deadly, cheap ones first. Then the deadly, expensive ones, each broken into the cheapest test that gives a signal. Anything that won’t kill you can wait until after launch.
Technical guesses count too. When Subflare, an AI lead scoring product for B2B teams, came to us, the whole product rested on whether the AI part would work. We tested that one guess in a 2-week test build before the full build. The MVP was later approved for client onboarding.
The same Scrum guide says probes should be small, run in parallel and designed so that failure is survivable and informative. In practice:
Most founders know this pattern. A busy quarter goes by: analytics, design, interviews, one big feature, meetings with stakeholders. You look back and one and a half features shipped, none of them brings money, and the code got harder to change.
The fix is to change what you count. Make “hypotheses tested” a goal for each month or quarter, and count a test whether it passed or failed. A failed test that saves you three months of building is a good result.
This matters more in 2026. In the 2025 DORA report, 90% of respondents said they use AI at work. Writing code is often not the slow part any more. Knowing what to build is.
Knowledge only helps if the team can find it. Keep one shared table, and review it for 15 minutes a week.
| Column | What goes in it |
|---|---|
| Date | When you wrote the hypothesis |
| Hypothesis | The full sentence from the template |
| Test | What you’ll do, and by when |
| Pass and fail line | Written before the test starts |
| Result | The numbers, plus one or two quotes |
| Decision | Keep, change and retest, or drop |
| What we learned | One line anyone in the company can read |
Share the “what we learned” column with everyone, not only the product team. When leaders see the same pattern across several tests, they can change the plan for the whole company instead of one feature.
Our project estimate gives you a first set of hypotheses to put in the log, with a price attached.
It turns your brief into user stories. You confirm what’s in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour.
It also suggests customer groups and gives each one a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand. The unit economics start from five guesses: price a month, margin, months a customer pays, the cost to win a customer and new customers a month. They show how many customers pay for the build and in which month it’s paid back, and you can change any starting number. Each of those five guesses is a line for your log. See what your idea costs to build, then test the guesses that move the payback month most.
Writing down a guess about your customers, product or price, running a small test, and deciding from the result whether to keep, change or drop the guess. It’s how a startup learns before it spends on a full build.
Name the customer group, the behavior or problem, a signal you can count, a date and a fail line. For example: “7 of 10 clinic owners describe a rescheduling problem from the last week; if fewer than 4 do, we drop the segment.”
The one that would kill the business if it’s wrong and is cheap to test. Usually that’s who the customer is and whether the problem hurts enough. Price comes right after.
One to two weeks for most early tests, such as an interview round, a landing page or a prototype test. Set the date before you start so a weak result can’t drag on for a month.
Treat an unclear result as a fail of that version of the hypothesis. Make it narrower, with a smaller group or a sharper signal, and test again.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.