This is the second post in a series about the importance of having a hypothesis mindset in product development. The two important points I tried to convey in the first post are:
- A hypothesis is an answer to a particular question.
- A hypothesis is testable.
Here, I’ll elaborate on what can happen when hypothesis thinking is not part of a product group’s mindset. My hope is that product team leaders reading this will schedule time into their processes for testing assumptions, especially their own.
When a Stakeholder Makes Assumptions About Customer Wants
A recurring trend I’ve observed working on product teams is that the stakeholder can sometimes act as the customer. Instead of being an advocate for, or a conduit to, the customer, they exert their unverified beliefs and ideas about what the customer wants.
When that happens, members of the product team can get caught up trying to chase what the stakeholder wants. A blurring of stakeholder and customer roles can be risky business. It can lead to building the wrong features and negatively affects user adoption of the product.
An example that comes to my mind happened to me before I joined Atomic. A stakeholder sent me an enhancement request in the form of a user story.
- “As a user, I should find news items directly above the loading bar.”
In this instance, the stakeholder assumed it would be a good idea to display curated news front and center in the application. The stakeholder was sure this feature would save the customer time from having to go to other news sites.
Questioning Stakeholder Assumptions
After doing some quick and dirty user research, I uncovered a significant problem with this assumption. The target audience for the application had strong loyalty to their existing news feed provider(s). When polled, the majority said they would not switch.
Having an experimentation mindset led me to question whether customers would find value in this feature.
Someone on the product team should spend a tremendous amount of time talking to and empathizing with customers. Sometimes, time and budget constraints mean we have to forge ahead and build what we predict the customer will want. Having a hypothesis mindset means we can test our hypothesis even after something is deployed and iterate on what we originally predicted.
In part three of the series, we’ll look at how to create features that actually get used.