Quick answer
A product hypothesis is a testable statement that predicts how a specific product change will affect a specific user behavior or metric for a segment, why, and by how much within a time frame.
What is a product hypothesis?
A product hypothesis is a testable statement that predicts how a specific change to a product will affect a specific user behavior or business metric, and why. It turns an idea ("let's add templates") into something you can prove wrong: "Because new users do not know how to structure their first project, offering three templates on the empty project screen will raise first-week activation from 42% to 48%."
Writing hypotheses forces teams to state the problem, the expected effect and the metric before building, which makes results easier to read and failures easier to learn from.
The structure of a good product hypothesis
A common template:
We believe that [change] for [user segment] will result in [measurable outcome] because [evidence or insight]. We will know this is true when [metric] moves from [baseline] to [target] within [time frame].
| Part | Purpose | Example |
|---|---|---|
| Change | What you will ship | Three templates on the empty project screen |
| Segment | Who it is for | New accounts in their first week |
| Outcome | The behavior you expect | More accounts set up a first project |
| Reason | Why you expect it | 52% abandon a blank project; chats ask "where do I start?" |
| Metric and target | How you judge it | Activation 42% → 48% in 4 weeks |
Product hypothesis examples
- Onboarding: "Letting users start a lesson before sign-up will raise day-1 retention from 24% to 28%, because 31% of installs leave on the account screen."
- Pricing: "Showing annual prices with the monthly equivalent will raise annual plan share from 18% to 25% among checkout visitors, because exit surveys mention price confusion."
- Feature discovery: "Moving export to the dashboard will raise weekly exporters from 9% to 14%, because paths show most users detour through settings."
- Support: "A proactive chat invitation on the pricing page after 30 seconds will raise demo requests from evaluators by 15%, because pricing-page chats often end in demos."
- Retention: "A weekly progress email will cut month-2 churn from 11% to 9% for users who stopped logging in, because returning users mention forgetting the product."
How to test a product hypothesis
- Record the baseline for the metric and segment.
- Decide the test design: A/B test, staged rollout or before/after with a control segment.
- Set the sample size or time window in advance and the decision rule.
- Ship, measure, and check guardrail metrics (errors, support contacts, revenue).
- Write the result: confirmed, rejected or inconclusive, and what you learned.
Common mistakes
- No baseline or target, so any change can be called a success.
- Hypotheses about features rather than user behavior ("add dark mode" is a task, not a hypothesis).
- Changing several things at once.
- Stopping a test as soon as the numbers look good.
- Discarding rejected hypotheses instead of learning from them.
Testing hypotheses with TapCub
TapCub measures the baseline and the result: funnels, retention, segments and chart annotations for release dates. It does not run A/B tests; use a feature flag or testing tool to split traffic and analyze both groups in TapCub.
Related terms: minimum viable product, statistical power, p-value, guardrail metrics.
Sources
- Gothelf, J. and Seiden, J. (2021). Lean UX, 3rd ed. O'Reilly.
- Kohavi, R. et al. Trustworthy Online Controlled Experiments. Book site.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Product Adoption Consultant
Explores customer onboarding, live conversations, and self-service, turning common usage questions into practical guidance and improvements.