Hypothesis-Driven Development: Test Your Ideas Before You Build
Hypothesis-Driven Development treats product work as a series of experiments, not a to-do list. You state a testable belief ("If we build X, users will do Y") before writing code. This de-risks new features by validating ideas early.
Why it exists
Many teams build features that fail to deliver value or get used. Hypothesis-Driven Development (HDD) was created to combat this by applying the scientific method to product work. It shifts the focus from shipping features to learning what works, reducing the risk of wasting effort on bad ideas.
The mental model
Treat product development like a series of science experiments, not a to-do list. Instead of a backlog of features, you have a backlog of testable ideas. Each piece of work is an experiment designed to prove or disprove a specific, measurable hypothesis about user behavior. The outcome isn't just a shipped feature, but a clear decision: persevere with the validated idea or pivot to a new one.
How it works
HDD integrates this experimental mindset across the entire product pipeline. You start by framing an idea as a falsifiable hypothesis with clear success metrics. For example: "We believe adding feature X will cause Y% of users to take action Z." Then, you build the minimum required to test this hypothesis, release it to users (often as an A/B test), and measure the results. The data determines the next step, ensuring every development cycle generates learning.
When to use it
Use HDD whenever you face uncertainty. It's ideal for launching new products, exploring new markets, or developing major features where user behavior is unknown. It helps de-risk big bets by forcing you to validate core assumptions with small, cheap experiments before committing significant resources.
When not to use it
HDD is overkill for tasks with low uncertainty. If you're fixing a well-understood bug, making a necessary performance upgrade, or building a feature to satisfy a contractual obligation, the outcome is already known. In these cases, you can just build the thing without a formal hypothesis.
One canonical example
A team believes adding a one-click "Add to Wishlist" button on product cards will increase user engagement. Their hypothesis is: "We believe adding a wishlist button will lead to more return visits. We'll know we're right if users who click it return within 7 days at a 20% higher rate than users who don't." They build the button and run an A/B test. If the metric is met, they persevere and roll it out. If not, they pivot and try a different idea.
Interview question
When is Hypothesis-Driven Development (HDD) most beneficial for a product team?
- a.When the primary goal is to fulfill contractual obligations or regulatory requirements.
- b.When a product team needs to efficiently implement a well-defined list of features.
- c.When exploring new product areas or features where user behavior is uncertain.Correct
- d.When making minor UI tweaks or performance improvements with predictable outcomes.
Why? this is the answer
HDD is designed for situations with high uncertainty, such as exploring new product ideas or features where user behavior is unknown, as stated in the 'When to use it' section. It is explicitly stated as 'overkill' for tasks with low uncertainty, like implementing well-defined features or making predictable improvements.
Just read this? Test yourself on what you have been reading.
Read the original → alexandercowan.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on growth — each one lists the topics its interview covers.
See open roles