Hypothesis-Driven Development: Stop Guessing, Start Learning
Hypothesis-Driven Development treats new features as experiments, not foregone conclusions. It's used to de-risk major changes by first testing the core assumption with a minimal product. The biggest footgun is writing vague, untestable hypotheses.
WHY IT EXISTS: To combat the massive waste in software development where teams build features based on assumptions, opinions, or the Highest Paid Person's Opinion (HiPPO). It forces a shift from asking "are we building it right?" to the more critical question: "are we building the right thing?"
THE MENTAL MODEL: Think like a scientist, not just a builder. Every new feature is a hypothesis about user behavior. Your job is not just to build the feature, but to design an experiment that proves or disproves the hypothesis as cheaply and quickly as possible. The primary output isn't just code; it's validated learning.
HOW IT WORKS: The process follows a simple loop. First, formulate a clear, testable hypothesis, often in the format: "We believe that [building this feature] for [these people] will achieve [this outcome]. We will know we are right when we see [this measurable signal]." Second, define the smallest experiment you can run to get that signal (the Minimum Viable Product or MVP). Third, run the experiment and collect data. Finally, analyze the results to decide whether to pivot (change the hypothesis), persevere (continue building), or kill the idea.
WHEN TO USE IT: Use HDD when there is high uncertainty about a problem or its solution. It's perfect for new startups finding product-market fit, established companies entering new markets, or for any significant feature where user value is an assumption, not a fact. It is a core practice of the Lean Startup methodology.
WHEN NOT TO USE IT: Don't use it for tasks with low uncertainty. You don't need a hypothesis to fix a critical bug, implement a well-understood industry standard like OAuth, or fulfill a contractual obligation. Overusing it for trivial changes creates unnecessary process overhead.
ONE CANONICAL EXAMPLE: Dropbox's famous MVP. Instead of building a complex file-syncing backend, founder Drew Houston created a simple video demonstrating what the product would do. The hypothesis was that a seamless file-syncing solution was a problem people desperately wanted solved. The experiment was the video and a signup form. The measurable signal was the number of signups. When signups exploded overnight, the hypothesis was validated, justifying the investment to build the full product. They tested the demand before writing a line of production sync code.
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.