You have an idea for a product. You want to talk to people. But where do you start? Most teams skip a step — they don't write down their assumptions before asking questions. That leads to vague conversations and vague conclusions.
What is a research hypothesis?
A research hypothesis isn't a scientific statement you'll prove or disprove. It's also not a feature hypothesis like "adding onboarding will increase activation by 20%." It's simpler than that.
A research hypothesis is a clear statement of what you think is true about a group of people and their problems — written down before you start talking to them. It's your best guess, made explicit.
The point isn't to be right. The point is to have something concrete to test, so your conversations have direction.
Why you should write this down first
Without a hypothesis, you're just "talking to users." That sounds productive, but it often isn't. You ask broad questions, get broad answers, and leave with a vague sense that "people seem interested." That's not research — that's a conversation that makes you feel good without teaching you anything.
A hypothesis forces you to commit to a belief before you test it. This matters because once you've written it down, you can actually be wrong. You can learn something. If you keep your assumptions fuzzy, you'll unconsciously filter everything you hear to confirm what you already believe.
I've seen teams do dozens of interviews and come away with nothing actionable, simply because they never defined what they were trying to learn. And I've seen small teams make confident decisions after five conversations, because they knew exactly what question they were answering.
A simple framework
You don't need a formal template. Just answer two questions:
Who do you think has this problem, and what's the problem?
Why do you think this?
That's it. Write it in plain language, like you'd explain it to a colleague. Here's the format I use:
I think [who] struggles with [problem] because [what I've seen or heard].
The "because" part is important. It makes your reasoning explicit. Did someone tell you about this problem? Did you experience it yourself? Is it a hunch based on something you read? All of these are valid starting points, but they carry different weight.
Examples
B2B example: "I think product managers struggle with structuring discovery interviews, because I've seen them default to leading questions and several have told me they don't have a consistent method."
E-commerce example: "I think first-time buyers abandon checkout when they see shipping costs late in the process. I noticed this myself when shopping, and I've seen it mentioned in reviews."
Early-stage example: "I think freelance designers spend too much time on invoicing. This is a hunch — I haven't validated it yet, but it came up in a few conversations about admin work."
Notice how each one is specific enough to test. You could design interview questions around any of these. Compare that to "I think people find invoicing annoying" — that's too vague to be useful.
From hypothesis to interview questions
A good hypothesis tells you what to ask. If I think product managers struggle with structuring interviews, my conversation should explore that. Not "do you like doing research?" but "walk me through the last interview you ran — how did you prepare?"
The trick is to test the hypothesis without revealing it. You're not asking "do you struggle with structuring interviews?" — that's leading. You're asking about their actual experience and listening for evidence that either supports or contradicts what you believe.
If your hypothesis is right, you'll hear it in their stories. If it's wrong, you'll find out quickly — and that's valuable too.
What makes a hypothesis weak
Too vague: "People have trouble with productivity." This could mean anything. Who specifically? What kind of trouble?
About your solution, not their problem: "People want an AI tool for scheduling." You've jumped ahead. First figure out if scheduling is actually painful, and for whom.
No reasoning: "I think small business owners need better analytics." Why do you think this? What have you seen? Without the "because," you don't know what you're actually testing.
The hypothesis is just the start
Writing a hypothesis doesn't mean you've done the research. It means you're ready to do it well. The real work happens in the conversations — asking the right questions, listening for specific stories, and being willing to update your beliefs based on what you hear.
But if you skip this step, those conversations will be less focused. You'll come away with impressions instead of insights. Take ten minutes to write down what you think is true and why. It makes everything that follows more useful.