Hypothesis-driven development is a proven approach that helps make sure you’re building the right product that delivers the right results – for you and your users. In this article, we break down how we use this method at Sonin to move fast, reduce risk, and create an unparalleled competitive advantage for our clients.
When you’re building a digital product, the honest truth is that no one knows for sure whether a feature is going to add value. And within that uncertainty, it’s often the loudest voice that wins the argument or the most seemingly urgent issue that gets all the attention.
In many cases, product planning becomes a long and drawn-out conversation since everyone has an opinion and no one wants to waste time on the wrong thing. But all this does is delay how soon you can get an idea into your users’ hands and learn whether it works or not.
That’s why at Sonin, we take a much faster and more scientific approach to deciding the features that are worth focusing on: hypothesis-driven development.
What is Hypothesis-Driven Development?
Hypothesis-driven development is an approach to app development that’s based on your team making educated and well-documented assumptions to test before you commit to building anything.
Doing this reduces the risk of spending your team’s valuable time and resources building the wrong feature that doesn’t help you or your users achieve their goals.
Why Should You Use It?
Everyone that’s been involved in a planning session knows the pitfalls too well. You can have all the right people in the room and still waste time having the wrong conversations.
When you do make a decision and run with it, it’s not until you’ve launched that you start collecting data. Whether an iteration works or not becomes too subjective – people start adding asterisks to successes and failures based on their beliefs – when it should be a matter of fact.
The benefit of hypothesis-driven development over basing decisions on hunches, guesses, and beliefs is that it’s scientific in its approach. There’s no space for subjectivity – only objective learning and discovery. It’s a faster route to finding your product-market fit.
To discuss your businesses’ approach to Hypothesis Driven Development, speak to our experts today.
How Hypothesis-Driven Development Works
At Sonin, we use hypotheses followed by focused design sprints to take the guesswork out of prioritising your product roadmap.
Identify Your Core Focus
It all starts with your core focus – the key number or overarching goal that best represents the value you want to create as a company. Each of your departments can have its own metrics and scorecards but your core focus sits above them all. It unites everyone in your company behind a shared direction.
Agree Your Priorities
We begin by defining all the different problems we’re trying to solve and listing the desired outcomes we want to achieve. We work hard to get to the root of each problem and uncover the real desired outcome behind each goal by continually asking “why.” This makes sure everyone in the room is on the same page and prevents people from wasting time trying to solve surface issues.
Once we have the full (often overwhelming at first) picture of all the problems we’re faced with and all the outcomes we’re supposed to help achieve, we get to work prioritising them. This is where having the alignment of a single metric – your core focus – proves so useful. Every pain point and every desired outcome is measured by how much it hinders or helps that key metric or overarching goal.
With our approach, your decisions don’t get dictated by how important a problem seems to a single department or how recent an example someone can bring up. Strategy is choosing what not to do. When there are a million different things you could be tackling, this offers a clear-cut answer to the question: “What should we be focusing on right now?”
Is Hypothesis Driven Development on your agenda?
Create Scientific Hypothesis
When we’ve chosen a problem to tackle or a desired outcome to support, we work with our clients to create a scientific hypothesis. We use a proven formula for covering what we want to achieve as a business and where that intersects with what our users want to achieve.
We start with the business outcome and then the user persona and their problem or desired outcome. Only once we have this context do we include the feature or proposed solution.
“We believe we can achieve [prioritised business outcome] if when [action] a user is able to [goal] so they can achieve [desired outcome] by [proposed solution]. We will have the confidence to proceed when we observe [measurable signs].”
This formula takes the best of the traditional job story framework: When [action], I want to [goal], so that I can [desired outcome]. But it also incorporates your business objectives and a definitive measurement of whether your solution has proven your hypothesis right or wrong.
Test Your Hypothesis
Armed with a hypothesis, we use focused design sprints to create prototype solutions super fast with minimal effort. We then test these solutions with real users for instant feedback. This can be through one-on-one user testing, in groups, or out in the field.
From this, we gather a mix of qualitative feedback from trends in users’ comments. We combine this with quantitative feedback on whether the proposed solution made a difference to the metric we’re measuring. We’ve used this exact process to find proven solutions for the critical challenges facing our clients.
Build or Burn, Repeat.
If your hypothesis is proved right and it solves a problem or helps a user achieve a desired outcome, then you can move into production. And you can do so with the confidence that the resource required to build it is worth allocating.
On the other hand, if your idea falls short of solving your users’ problem then you’ve only spent a few days on it. You will have learnt definitively what doesn’t work which you can use to inform your decisions and how you prioritise future ideas.
In either case, the investment and risk are minimal and a key learning is guaranteed. With every cycle of hypothesis-driven development, you understand more about what makes your users tick.
“The benefit of hypothesis-driven development over basing decisions on hunches, guesses, and beliefs is that it’s scientific in its approach. There’s no space for subjectivity – only objective learning and discovery. It’s a faster route to finding your product-market fit.”
Let’s build the right product, together.
Creating Cost-Effective Success
Each testing cycle will have its own metric you’re tracking. One hypothesis might be measured by the time it takes to complete a key action. Another might simply be whether an action is a success or not. But throughout every hypothesis-driven development cycle, there is a constant measurement that you should be tracking.
The more hypotheses you can test and the faster you can get at testing them, the lower it will cost you to ship successful features – features that add real value to your users and deliver results for your business.
This is called the cost to deliver a successful feature. And by taking a hypothesis-driven approach, you can drastically reduce the average amount of time and resources it takes to add a successful feature to your app.
But to deliver successful features thick, fast, and cheap it all starts with alignment. Alignment on the outcomes your business wants, alignment on what your users are trying to achieve, and alignment on the problems getting in the way.
Our Discovery Workshops are designed to create that alignment within your team. We work closely with you to define your core focus and your most-important priorities. Our team of digital product experts then help you ideate solutions which we take away to test with real users for lightning-fast feedback.
Our approach to digital product development helps you to prove the need for new features before you build them. It allows you to move fast, reduces your level of risk, and offers an unparalleled advantage over your competition.