Hypothesis-Driven Development
Much of what we build is a guess about what will help users or the business. Many of those guesses turn out to be wrong. Hypothesis-driven development makes each guess clear and testable. State what you believe, what you expect to happen, and how you will measure it. Then ship the smallest thing that tests it, and let the evidence decide. Build to learn, not just to ship.
Do not build a big feature just because you are sure it is great. Instead, hypothesis-driven development frames it like this: "We believe X will result in Y; we will know we are right when Z." Then build the smallest version that can confirm or disprove that hypothesis. Measure the outcome and decide whether to continue, change course, or drop it. This turns opinion-based roadmaps into evidence-based ones and avoids spending months on features nobody wanted.
It works well with A/B Testing (a way to test a hypothesis), Feature Flags (to ship experiments safely), Product Analytics (to measure outcomes), and Continuous Improvement (the same loop, applied to the product). In a regulated setting, experiments must still respect privacy, consent, and fairness, and must never weaken compliance controls.
Frame and test the bet
- DoState the hypothesis clearly before building: what you believe, the measurable outcome you expect, and the signal that would confirm or disprove it.
- DoDefine success and failure up front, including the result that would make you stop. Then you cannot later call any outcome a win (see Measuring What Matters).
- DoBuild the smallest thing that can test the hypothesis (an MVP, a prototype, or a flagged experiment) rather than the full feature on faith (see Estimation & Planning).
- DoAdd the tracking you need so you can actually measure the outcome, using analytics that respect privacy (see Product Analytics & Telemetry Privacy).
- DoLet the evidence drive the decision: continue, change course, or drop it. Be willing to drop your own idea when the data says so (see Professional Ethics).
- ConsiderUsing feature flags and A/B tests to run the experiment safely on a small group of users (see Feature Flags, A/B Testing, Deployment Strategies).
// spend a quarter building the full feature because leadership
// "just knows" users want it; ship it; usage is near zero
This is a large, costly bet based on opinion, with no way to learn early. Months are spent before the result arrives, and even then there is no clear signal about why it failed.
// Hypothesis: showing a progress bar in onboarding will raise completion.
// Expect: completion +5%. Test: flag it for 50% of users for 2 weeks.
// Measure completion (privacy-respecting). Result decides rollout.
The bet is clear and can be proven wrong. It is tested cheaply on a small group through a flag, and the decision is based on evidence. The team learns fast and at low cost.
Experiment responsibly
- DoKeep experiments honest. Write down what you will measure before you start, so you cannot pick a flattering result afterwards.
- DoRespect users while experimenting: privacy, consent for tracking, accessibility, and a consistent, honest experience (see Cookies & Consent, Accessibility).
- AvoidThe "we have built so much, we cannot stop now" trap. The point of the experiment was to find out, so respect the result.
- AvoidVanity experiments measured by activity rather than by real outcome or value (see Measuring What Matters).
- NeverExperiment on or weaken a compliance, security, or fairness control. For example, do not A/B test whether to skip a KYC step. These are not things we bet with.
Self-review checklist
- AskWhat exactly do I believe will happen, and how will I measure whether it did?
- AskWhat's the smallest thing I can build to test this?
- AskHave I defined up front what result would make me stop?
- AskDoes this experiment respect privacy/consent and never touch a compliance/security control?