Hypothesis Driven Development

How do you transform a Product Vision into an effective backlog?

You’ve nailed the vision building workshop, your customers and stakeholders are engaged and excited. All you need to do now is to make the thing!  The first step is to build a backlog, but what goes in?

Transforming your vision for a product or feature set into a prioritised backlog can be a daunting task. There are various tools and techniques available that can help you do just that such as: Story Mapping, MoSCoW, team planning and if Hypothesis Driven Development techniques aren’t part of your toolkit, they definitely should be.

Hypothesis-Driven Development (HDD) fits nicely between that big vision and individual user stories. Typically a small number of user stories make up a single hypothesis but let’s not worry about that. Most importantly HDD is an outcome driven technique that is both specific and testable.

Form your product hypothesis by clearly stating your intended outcome for the user of the product, and, importantly, how you’ll measure when this outcome is achieved.  The format is simple;

I believe [target market] will [do this action/use this solution] for [this reason] and I will know its successful when [outcome is achieved]

What I like about HDD is that it is extracted away slightly from the functional aspect and really humanises the process.

Let’s take an example and work it through. Imagine we work for a CRM software company, and through a vision building workshop, we have identified that we want to help sales reps manage their sales pipeline more effectively.

I believe [that sales reps will use a sales funnel] to [better understand at what stage of the sales cycle they are losing sales] and I will know when it’s successful when [I see sales conversions improve].

This is really explicit, we are taking a hypothesis, discussing who will use it and why, and assigning unambiguous metrics which are testable.

Testing hypotheses are key to HDD. A solid hypothesis will help build out the backlog but to be agile we need to follow-up, measure, learn and adapt. This tool helps us do that. So if you don’t come back and test this hypothesis how will you know if you are building the right things?

If your hypothesis worked great, how do we improve? If we were wrong and sales conversions didn’t improve, then we need to question it (inspect and adapt); why didn’t sales improve? Was the feature too complicated, not engaging, did we implement badly, was it poorly positioned in through the product messaging? Do sales reps really want to be told how to improve? The answer are … well, you don’t know unless you come back and validate!

HDD is a great tool, easy to use – no software required, a spreadsheet will do. Don’t feel you have to be too rigid, I changed a few words to make it flow like replacing ‘for’ with ‘to’ etc.  It’s the essence you want, who’s it for, how will they use it and how will you test if it has been successful.

Go to the profile of Marc Fulner

Marc Fulner

Head of Product @CrowdControlHQ — I’m Passionate about Product, Tech, Agile and UX.


Write a comment