Unpacking hypothesis-driven development

If you ever had to take science classes in university or high school, you’d be familiar with the concept of educated guesses. Before an experiment, you were likely asked to come up with an assumption that could be tested – a scientific hypothesis. The basic idea of a hypothesis is that there is no pre-determined outcome – and is usually shrouded in uncertainty.

If we see building technology solutions as experiments to learn what customers want and what is good for a business, we can similarly treat any of these programmes as a series of experiments. A sequence of hypotheses, working towards a sequence of goals. The hypothesis is the building block in the scientific method, and should be in agile development too.

In modern agile-inspired approaches, teams need to deliver newer, better, and more robust features to customers in increasingly shorter timeframes. The work being carried out is usually determined by a product owner and often assumed as “proven” before testing it with real users. These features frequently accumulate into mammoth applications where the full breadth of functionality is not utilised, or the application is not user friendly – or more severely – the solution doesn’t truly solve problems for customers.

To facilitate learning what actually solves problems, hypotheses should be considered and documented for every feature being built to create clarity in purpose. Engineering teams should experiment early and often, receive feedback from customers, and make data-driven decisions based on the findings from every experiment.

Establish hypotheses that can teach you things
Clear and predetermined requirements are only valuable when several possible solutions have already been tested and validated. However, when you are exploring an initiative with a high-level of uncertainty (which most digital projects are), using atomic hypotheses to guide what features development teams build will ultimately result in building the right thing as you continually adapt away from failed experiments and towards the successful ones.

To form a useful hypothesis, focus on pieces of functionality from a user’s perspective. How will they interact with the solution, and what fundamental problem is it solving for the user? Ensure that these pieces of the solution are small enough to develop within a sprint, and be tested with real-world users directly after that sprint. This will allow you to focus on what works, and parking or discarding the rest. Keep in mind that the larger the feature, the more effort and cost is involved in maintaining, testing, and working around the feature.

Use technology to validate (or invalidate) your hypothesis
Once you have an agreed-upon hypothesis in place, you’ll need to iteratively prove or disprove it throughout the development phases using the tools at your disposal. These validations can be as simple as workshops or focus groups, or may take a little more user research against prototypes to find a conclusive result. In some instances, it’s worth building a proof of concept to pilot in the market (or pilot as a feature within a larger system).

An effective step towards validation is having smaller, cross-functional teams that are able to complete the full cycle themselves, internally. Any requirement to ‘hand off’ work into other teams for research and feedback will put the brakes on the experiment as context is lost and priorities aren’t shared. Cross-functional teams include engineers, designers, and analysts – a multi-skilled team allows searching for, manifesting and learning viable ideas quickly.

Adapt your solution via a series of experiments
Let’s consider an example where a business’ sign-up rate for their eCommerce platform is surprisingly low given the large volume of visitors they receive. To understand the product take-up problem given that marketing seems to be working, they’d need to lay down several hypotheses which can be tested.
1. Hypothesis 1: Users are getting fatigued by sign-up form capture taking too long and losing interest. Experiment: Cut sign-up requirements to the bare minimum needed to transact, and allowing users to finish their profile at a later stage.
2. Hypothesis 2: The product is too expensive, so although there is huge interest in it, a low percentage of consumers are willing to spend the money. Experiment: Offer a slightly cheaper version of the product, with several cut-back features, and measure take-up.
3. Hypothesis 3: There is a lack of trust in the product, and visitors are unwilling to sign up (or provide personal details) until they have experienced it. Experiment: Dramatically lower the barrier to entry by allowing guest-transacting and only requiring users to register once they’ve completely taken up the product.

With these experiments in play (albeit pilot versions, with potentially a small customer base) the business can go revisit each hypothesis to establish whether any or all of them were true or false, and then further invest in the solutions which have proven demonstrably more effective at driving product uptake. This process can repeat as the product evolves.

Testing atomic ideas quickly is advantageous in finding better solutions for businesses , and should be utilised as often as possible. This approach works well with agile-based development due to the short release cycles and ability to adapt quickly.

In hypothesis-driven development, every major feature is an experiment, and every experiment must start with an educated guess. Your goal should be to establish a clear hypothesis for each initiative, and then focus engineering efforts to prove or disprove it. This way, you’ll build products that ultimately succeed in delivering against a clear and measurable user or business goal.