How to write a startup hypothesis: turn a fuzzy idea into testable hypotheses

"I think people would like an app for X" is a vibe. No amount of research can confirm or kill it, because it doesn't commit to anything specific enough to be wrong about.

A useful startup hypothesis is falsifiable: there's a real, plausible outcome where the evidence says no. If you can't picture that outcome, what you've written is a hope, and you still need to turn it into a hypothesis.

Why one big hypothesis fails you

If you bundle everything into "is this a good idea," you can't act on the result. When the answer comes back weak, you won't know whether the problem isn't real, the price is wrong, the segment is off, or your solution just isn't better than the status quo. Each of those calls for a completely different next step.

Split the idea into separate claims and you learn which part is working.

The five things worth testing separately

• Problem: does the target segment actually experience this problem, and does it hurt enough to act on?
• Willingness to pay: would they pay, and how does that compare with what they already spend on workarounds?
• Behavior: would they actually change what they do, beyond saying they'd like to?
• Solution fit: does your specific approach handle the problem better than what they use now?
• Market: is the segment big enough, and is it the right segment to start with at all?

An idea can fail on one and pass the others. "Real problem, but wrong price point" calls for a pricing experiment, while "no real problem" is a reason to stop, and a single bundled hypothesis can't tell you which one you're looking at. For weak and strong examples in each area, plus how to validate or kill each one, see startup hypothesis examples.

What a well-formed hypothesis looks like

A good hypothesis is one where every clause can be checked against what a respondent reports.

Weak

Freelancers need better invoicing.

Nothing here can be wrong. "Freelancers" covers everyone, "better" is undefined, and nobody has measured "need."

Strong

Freelance designers who invoice five or more clients a month currently lose at least two hours a month chasing late payments, and would pay $15 a month for automated payment reminders.

This version names the segment, a specific behavior, a magnitude, and a price point. Real answers can confirm or contradict every clause, and every clause could turn out to be false.

A template you can reuse

[Specific segment] currently [does specific behavior / uses specific workaround] to handle [problem], which costs them [magnitude in time or money]. They would [specific adoption action] and pay [price] for [your approach].

Fill every bracket. If you can't fill one, that's the part of your idea you haven't thought through yet.

Write the failure condition first

Before you finalize a hypothesis, write down the result that would prove it false. Nothing forces you to be specific faster.

For the invoicing example, it might be: "Fewer than half of respondents report losing meaningful time to late payments, or nobody currently pays for anything adjacent." That's a "no" you can actually write down. If the research shows it, you've learned something concrete, which beats a vague bad feeling.

If you can't write a plausible failure condition, the hypothesis is still too vague. Go back and add a number.

Rank hypotheses by risk and test the riskiest first

You won't have time to test all five claims exhaustively in the first round. Rank them by how much of the idea depends on each one and how unsure you are about it.

For most ideas, test the problem hypothesis first, because if the problem isn't real the other four don't matter. Willingness to pay usually comes second. Solution fit is often better left until later, once you know the problem is worth solving. In that order, a bad first round kills the idea cheaply, before you've run five rounds.

Common questions

How many hypotheses should one idea have?

Three to five is typical, one for each dimension that carries real risk. With ten, you're probably restating the same claim in different words. With one, it's still bundled.

What's the difference between a hypothesis and an assumption?

An assumption is something you take for granted, often without noticing. A hypothesis is an assumption you've made explicit, specific, and testable. Turning assumptions into hypotheses is most of the work.

Do I need statistics to test a hypothesis?

No. With 10 to 20 qualified respondents you're checking whether a clear pattern is there or not, and statistical significance doesn't come into it. "Nine of twelve described the problem unprompted" is a strong signal at that scale.

What if a hypothesis is confirmed but I still feel unsure?

That usually means there's a hypothesis you haven't written down yet. Ask yourself what else would have to be true for the idea to work, and make that the next test.

Turn your idea into hypotheses automatically

Hypothis takes a raw idea description and produces a falsifiable hypothesis set like this, covering problem, willingness to pay, behavior, solution fit, and market, with each one specific enough for real research to confirm or kill. Then it builds the research round to test them and scores each one against the responses. It's free during early access. See how it works or read how to validate a startup idea end to end.