This is the last post in a four-part part series about the benefits of adopting a hypothesis mindset in product development. I chose this topic because the most common constraints I run into on a project are budget and time. The client’s answer to managing these constraints is usually to eliminate or shorten the time spent in the Research, Design, & Planning Phase. In an ideal world, there would be adequate time at the beginning of a project for experimentation in the form of customer research. Normally, the start of a project is when the product team engages most heavily in developing new ideas and testing them with customers. But when budget and time are in short supply, product teams can at least adopt a hypothesis mindset to channel the customer’s voice into development.
In the first part of this series, I explain what a hypothesis is and how it can be used in product development. To recap, having a hypothesis mindset means that the team thinks about the development of a new product as a series of experiments.
In the second part of this series, I addressed the risk that one stakeholder can influence a product’s direction and outcome. A lone stakeholder can dictate product direction when the customer’s voice isn’t present. This can lead to some very costly decisions if the stakeholder doesn’t truly understand where customers find value. Testing the stakeholder’s assumptions throughout the product life cycle can help validate the course or correct it.
Developing features that don’t get used is the third risk that can be mitigated with a hypothesis mindset. Product managers are often measured on how accurately they can predict customers’ behavior. Their desired outcome is for customers to buy and repeatedly use a product and to say good things about it. A product team should embrace the idea that they are building tiny experiments. These experiments will help them predict features customers will actually use.
Hypothesis-Driven Mindset: Tune into the Customer’s Voice
Below are my final observations about product teams that don’t think in terms of making and testing their belief statements.
- Teams blow through the budget before completing critical path features.
- They lack sufficient data to back decisions.
When time and budget are especially constrained, teams can still channel the customer’s voice into what they build. Promote some or all of these as norms on your project to adopt a hypothesis mindset.
- Observe users.
- Conduct experiments.
- Ask questions and make product hypotheses.
- Test hypotheses and iterate.
Projects that don’t spend much time in the RDP phase can still channel the customer’s voice in the design and delivery phases. They can do that by adopting a hypothesis mindset throughout the product lifecycle.