Product hypothesis template: how to write one (with examples)
Short answer
A product hypothesis is a testable belief about a product change: who it is for, what it should change in their behavior, and how the team will know. A simple template: The team believes [belief, based on evidence]. If [change] is built for [audience], then [expected outcome]. This is measured by [metric]. The team will know it worked when [success rule], within [time limit]. Validate it with the cheapest method that can prove it wrong, such as a fake door, a prototype test or an A/B test.
Key takeaways
- A product hypothesis has seven parts: belief, change, audience, expected outcome, metric, how the team will know, and how long.
- It is not a user story. A story describes what to build; a hypothesis describes what the build should prove.
- Validate with the cheapest method that can prove the belief wrong. Fake doors and prototypes come before full builds.
- Write the success rule and the time limit before any work starts, so the result can’t be argued into a win later.
- A false hypothesis is a good outcome if it was cheap. It saved the cost of building the wrong thing.
What is a product hypothesis?
A product hypothesis is a short, testable belief about how a product change will change user behavior, and how that change will be measured. It sits between the problem and the build. Instead of “build saved searches”, the team writes down why saved searches should matter, for whom, and what number would show it was worth building.
The idea comes from lean product work: treat each feature as a bet, and find the cheapest way to learn whether the bet is right before spending months on it. Scaled Agile describes the minimum viable product in the same spirit, as an early and minimal version of a solution used to prove or disprove a hypothesis. For the broader idea of hypothesis statements, including the SAFe epic format, see hypothesis statement examples.
What should a product hypothesis template include?
Seven parts: belief, change, audience, expected outcome, metric, how the team will know, and how long. Each one closes a gap that otherwise turns into an argument after launch.
- Belief. What the team thinks is true about users, and the evidence behind it. Interviews, support tickets, usage data, sales calls.
- Change. The feature, flow or offer that will be built or changed.
- Audience. The users it is for. New accounts, power users, a plan tier, a market.
- Expected outcome. The behavior that should change, in plain words.
- Metric. One primary metric for the outcome, plus a guardrail that must not get worse.
- How the team will know. The success rule: the minimum change in the metric that counts as a win, and what happens if it doesn’t arrive.
- How long. A time limit or sample size. Without one, a hypothesis can stay “still being validated” forever.
Copy this template
Belief: The team believes [what is true about users], because [evidence].
Change: If [feature, flow or offer] is built or changed
Audience: for [which users],
Expected outcome: then [behavior that will change].
Metric: Measured by [primary metric], with [guardrail] not getting worse.
How the team will know: It worked if [primary metric] reaches [minimum change]. If not, [what happens next].
How long: Judged after [time limit or sample size], using [validation method].
Some teams prefer the shorter “We believe that [change] for [audience] will achieve [outcome]. We will know this is true when we see [metric]” form. It carries most of the same parts. I like to add the time limit and the guardrail, because those are the two parts teams skip most often.
How is a product hypothesis different from an A/B test hypothesis and a user story?
A product hypothesis says what a change should prove. An A/B test hypothesis is one way to prove it. A user story says what to build. They work together, but they answer different questions.
| Product hypothesis | A/B test hypothesis | User story | |
|---|---|---|---|
| Question it answers | Is this worth building, and for whom? | Does this version beat the current one? | What should be built, and why does the user want it? |
| Typical form | Belief, change, audience, outcome, metric, success rule, time limit | Because [evidence], changing [element] for [audience] will move [metric] | As a [user], I want [action], so that [benefit] |
| Scope | A feature, flow, offer or product bet | One change on a page or flow | One piece of work for a sprint |
| How it is checked | Any validation method: fake door, prototype, concierge, A/B test | A controlled split test with a planned sample | Acceptance criteria: does it work as described? |
| Can it be false? | Yes, and that is the point | Yes, it can lose or come out flat | Not really. It is done or not done |
| Owner | Product manager or growth lead | Experiment owner, designer or CRO lead | Product owner with the delivery team |
A practical flow: write the product hypothesis first, pick a validation method, and only then write user stories for what needs to be built. If the method is an A/B test, write the test hypothesis with my A/B test hypothesis template.
How do you validate a product hypothesis?
Use the cheapest method that can prove the belief wrong, then move to more expensive methods only as confidence grows. Five common methods:
- Fake door test. Add a button, menu item or plan option for a feature that doesn’t exist yet, and count how many people try to use it. Optimizely describes it as advertising a feature before it exists to gauge demand, and treats fake door and painted door as two names for the same method. When someone clicks, tell them right away the feature isn’t ready and offer a waitlist, so nobody feels tricked.
- Painted door test. The same idea, often used for something bigger than one feature: a landing page, sales page or ad for a product that isn’t built yet, measuring sign-ups or waitlist joins. Amplitude notes the main weakness: people may sign up out of curiosity, which can make demand look stronger than it is.
- Prototype test. Put a clickable prototype in front of a small number of target users and watch them try real tasks. It answers “can people use this and do they get it?”, not “will enough people pay for it?”.
- Concierge test. Deliver the outcome by hand to a few real customers who know it is manual, before building any automation. It shows whether people value the result enough to keep using or paying for it, and what the eventual product needs to do.
- A/B test. Build the change, show it to a random share of users and compare it with the current version on the agreed metric. It is the strongest evidence for impact, and the most expensive. See A/B test sample size for whether there is enough traffic.
| Method | Best for proving | Cost to run | Watch out for |
|---|---|---|---|
| Fake door | Demand for a feature inside an existing product | Low | Frustrated users if the follow-up message is poor |
| Painted door | Demand for a new product or offer | Low | Curiosity sign-ups that overstate demand |
| Prototype test | Usability and understanding | Low to medium | Small samples, says little about volume or revenue |
| Concierge | That the outcome is valuable enough to pay for or keep using | Medium, mostly people’s time | Doesn’t scale, and hand delivery can feel better than the product will |
| A/B test | Real impact on a business metric | High: build, QA and traffic | Needs enough traffic and a planned sample size |
What do good product hypotheses look like? 5 examples
Here are five example product hypotheses written with the template. They are made-up examples to show the format, not results.
Example
1. Saved searches (marketplace). Say the team believes returning buyers repeat the same search several times a week, because search logs show the same filters used again and again by the same accounts. If saved searches with email alerts are built for logged-in returning buyers, then they will come back more often and buy sooner. Measured by repeat purchase rate within 30 days, with email unsubscribe rate as a guardrail. It worked if repeat purchase rate rises by at least 5%. Judged by an A/B test after the planned sample, run in full weeks.
2. Annual plan nudge (SaaS). Say the team believes monthly customers would switch to annual billing if the saving were shown at the right time, because cancellation surveys mention price more than any other reason. If an annual plan offer with the yearly saving is shown in the billing page for monthly customers after their third payment, then more will switch. Measured by switches to annual, with refund requests as a guardrail. It worked if at least 4% of eligible customers switch within six weeks. Validated first with a fake door on the billing page, then an A/B test.
3. Team invite in onboarding (B2B product). Say the team believes accounts with two or more users stick around longer, because retention data shows a clear gap between single-user and multi-user accounts. If inviting a teammate becomes a step in onboarding for new workspace owners, then more accounts will have a second user in week one. Measured by the share of new accounts with a second active user in seven days, with onboarding completion as a guardrail. It worked if that share rises by at least 10%, judged over four weeks of sign-ups.
4. Subscribe and save (ecommerce). Say the team believes customers who buy the same consumable product every month would subscribe for a small discount, because order data shows many repeat orders at regular gaps. If subscribe and save is offered on product pages for repeat-purchase products, then more first orders will turn into subscriptions. Measured by revenue per visitor, with average order value as a guardrail. It worked if revenue per visitor rises by at least 3%. Validated first with a painted door option on the product page that leads to a waitlist, then an A/B test.
5. Done-for-you setup (SaaS). Say the team believes small businesses churn because setup is too hard, not because the product lacks features, because churn interviews keep describing an unfinished setup. If setup is done by hand for new small business accounts that ask for help, then more will reach first value and stay past the first month. Measured by first-month retention for those accounts, with support hours per account tracked. It worked if retention for helped accounts beats similar unhelped accounts by a clear margin over eight weeks. Validated with a concierge test before any setup automation is built.
Each one names the evidence, the audience and a metric close to money, and each picks a validation method that fits the size of the bet. Once you have a list like this, rank it with ICE prioritization.
How do I use product hypotheses as a Growth Product Manager?
I write one before any design or ticket exists, and I use it to decide how much to build. After six years of designing for A/B tests, and with CXL certifications in Conversion Optimization and Ecommerce Marketing, I have learned that the hypothesis is where most of the value of a test is decided.
- I start from evidence, not from a feature request. If nobody can fill in the belief and the evidence behind it, the idea goes back to research.
- I pick the metric with the people who will judge the result. Agreeing on the metric and guardrail up front saves the argument afterwards.
- I match the method to the risk. A cheap, reversible change can go straight to an A/B test. A large or uncertain one gets a fake door, a prototype or a concierge test first.
- I keep a time limit. When it runs out, the hypothesis is called true, false or inconclusive, and the next step is written down.
- I log every result, including the losers. A false hypothesis tells the team where not to spend, and often points to the next better idea. Flat results count too; see what to do when an A/B test is flat.
When a hypothesis proves true, I check the effect in money terms with metrics like revenue per visitor, not just clicks or sign-ups.
What are common product hypothesis mistakes?
Most weak product hypotheses fail in one of five ways.
- Writing it after the build. Then it describes what happened instead of predicting it, and any result looks like a win.
- No audience. “Users” hides the fact that the change may help one group and hurt another.
- A vanity metric. Clicks and page views can rise while retention and revenue stay flat.
- No time limit. The hypothesis stays open forever and nobody has to call it false.
- The most expensive method first. Building the full feature to test demand that a fake door could have tested in days.
If you want help writing product hypotheses and turning them into tests, see A/B testing or book a call.
FAQ
What is a product hypothesis?
It is a testable belief about how a product change will change user behavior, for which users, and how that change will be measured. It names the evidence, the change, the audience, the expected outcome, the metric, the success rule and a time limit.
What is the difference between a product hypothesis and a user story?
A user story describes what to build and why a user wants it, and it is checked with acceptance criteria. A product hypothesis describes what the build should prove, and it can turn out to be false. The hypothesis usually comes first, then the stories.
What is the difference between a fake door test and a painted door test?
They are usually two names for the same method: offering something that doesn’t exist yet to measure interest. Some teams use fake door for a button or option inside an existing product and painted door for a landing page or ad for a new product.
Do you need an A/B test to validate a product hypothesis?
No. An A/B test gives the strongest evidence of impact, but it is also the most expensive. Fake doors, painted doors, prototype tests and concierge tests can prove a belief wrong much sooner and more cheaply.
Sources
I’m George (Djordje) Peric, a CRO designer, CXL certified in Conversion Optimization and Ecommerce Marketing. I design websites, landing pages, funnels and ads, and A/B test them.