Uncertainty is one of the biggest challenges of modern product development. Most often, there are more question marks than answers available.
This fact forces us to work in an environment of ambiguity and unpredictability.
Instead of combatting this, we should embrace the circumstances and use tools and solutions that excel in ambiguity. One of these tools is a hypothesis-driven approach to development.
As the name suggests, hypothesis-driven development is an approach that focuses development efforts around, you guessed it, hypotheses.
To make this example more tangible, let’s compare it to two other common development approaches: feature-driven and outcome-driven.
In feature-driven development, we prioritize our work and effort based on specific features we planned and decided on upfront. The underlying goal here is predictability.
In outcome-driven development, the priorities are dictated not by specific features but by broader outcomes we want to achieve. This approach helps us maximize the value generated.
When it comes to hypothesis-driven development, the development effort is focused first and foremost on validating the most pressing hypotheses the team has. The goal is to maximize learning speed over all else.
There are numerous benefits of a hypothesis-driven approach to development, but the main ones include:
Hypothesis-driven development maximizes the amount of knowledge the team acquires with each release.
After all, if all you do is test hypotheses, each test must bring you some insight:
Hypothesis-driven development centers the whole prioritization and development process around learning.
Instead of designing specific features or focusing on big, multi-release outcomes, a hypothesis-driven approach forces you to focus on minimum viable solutions (MVPs).
After all, the primary thing you are aiming for is hypothesis validation. It often doesn’t require scalability, perfect user experience, and fully-fledged features.
By definition, hypothesis-driven development forces you to truly focus on MVPs and avoid overcomplicating.
In hypothesis-driven development, each release focuses on testing a particular assumption. That test then brings you new data points, which help you formulate and prioritize next hypotheses.
That’s truly a data-driven development loop that leaves little room for HiPPOs (the highest-paid person in the room’s opinion).
Let’s take a look at what hypothesis-driven development looks like in practice. On a high level, it consists of four steps:
The first step is to list all hypotheses you are interested in.
Everything you wish to know about your users and market, as well as things you believe you know but don’t have tangible evidence to support, is a form of a hypothesis.
At this stage, I’m not a big fan of robust hypotheses such as, “We believe that if <we do something> then <something will happen> because <some user action>.”
To have such robust hypotheses, you need a solid enough understanding of your users, and if you do have it, then odds are you don’t need hypothesis-driven development anymore.
Instead, I prefer simpler statements that are closer to assumptions than hypotheses, such as:
The next step in hypothesis-driven development is to prioritize all assumptions and hypotheses you have. This will create your product backlog:
There are various prioritization frameworks and approaches out there, so choose whichever you prefer. I personally prioritize assumptions based on two main criteria:
Your priorities, however, might differ depending on your current context.
Hypothesis-driven development is centered around the idea of MVPs — that is, the smallest possible releases that will help you gather enough information to validate whether a given hypothesis is true.
User experience, maintainability, and product excellence are secondary.
The last step is to launch the MVP and validate whether the actual impact and consequent user behavior validate or invalidate the initial hypothesis.
The success isn’t measured by whether the hypothesis turned out to be accurate, but by how many new insights and learnings you captured during the process.
Based on the experiment, revisit your current list of assumptions, and, if needed, adjust the priority list.
Although hypothesis-driven development comes with great benefits, it’s not all wine and roses.
Let’s take a look at a few core challenges that come with a hypothesis-focused approach.
Focusing on validating hypotheses and underlying MVP mindset comes at a cost. Robust product experience and great UX often require polishes, optimizations, and iterations, which go against speed-focused hypothesis-driven development.
You can’t optimize for both learning and quality simultaneously.
Although hypothesis-driven development is great for gathering initial learnings, eventually, you need to start developing a focused and sustainable long-term product strategy. That’s where outcome-driven development shines.
There’s an infinite amount of explorations you can do, but at some point, you must flip the switch and narrow down your focus around particular outcomes.
Teams that embrace a hypothesis-driven approach often fall into the trap of an “MVP only” approach. However, shipping an actual prototype is not the only way to validate an assumption or hypothesis.
You can utilize tools such as user interviews, usability tests, market research, or willingness to pay (WTP) experiments to validate most of your doubts.
There’s a thin line between being MVP-focused in development and overusing MVPs as a validation tool.
As you’ve most likely noticed, a hypothesis-driven development isn’t a multi-tool solution that can be used in every context.
On the contrary, its challenges make it an unsuitable development strategy for many companies.
As a rule of thumb, hypothesis-driven development works best in early-stage products with a high dose of ambiguity. Focusing on hypotheses helps bring enough clarity for the product team to understand where even to focus:
But once you discover your product-market fit and have a solid idea for your long-term strategy, it’s often better to shift into more outcome-focused development. You should still optimize for learning, but it should no longer be the primary focus of your development effort.
While at it, you might also consider feature-driven development as a next step. However, that works only under particular circumstances where predictability is more important than the impact itself — for example, B2B companies delivering custom solutions for their clients or products focused on compliance.
Hypothesis-driven development can be a powerful learning-maximization tool. Its focus on MVP, continuous learning process, and inherent data-driven approach to decision-making are great tools for reducing uncertainty and discovering a path forward in ambiguous settings.
Honestly, the whole process doesn’t differ much from other development processes. The primary difference is that backlog and priories focus on hypotheses rather than features or outcomes.
Start by listing your assumptions, prioritizing them as you would any other backlog, and working your way top-to-bottom by shipping MVPs and adjusting priorities as you learn more about your market and users.
However, since hypothesis-driven development often lacks long-term cohesiveness, focus, and sustainable product experience, it’s rarely a good long-term approach to product development.
I tend to stick to outcome-driven and feature-driven approaches most of the time and resort to hypothesis-driven development if the ambiguity in a particular area is so hard that it becomes challenging to plan sensibly.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
