This is the third entry in a four-part series on the hypothesis mindset. In previous posts, we learned that product teams that have a hypothesis mindset will state their ideas in a way that can be tested. They also place an emphasis on validating their hypotheses in each phase of product development. This mindset shapes […]
This is the third entry in a four-part series on the hypothesis mindset. In previous posts, we learned that product teams that have a hypothesis mindset will state their ideas in a way that can be tested. They also place an emphasis on validating their hypotheses in each phase of product development. This mindset shapes how a product team will approach building a product or service. Adopting a hypothesis mindset on product teams can mitigate the risk of wasted money developing features that don’t get used.
When importance is placed on forming and testing hypotheses, product teams are more likely to accurately differentiate between what customers say they want and what they will actually use. Teams can use a hypothesis mindset to mitigate the risk of wasting money and development cycles on features that go unused.
Once a project gets underway and multiple sprints are completed, I can usually quantify how much of my project team’s time went into developing a feature. Below is an example of what it costs to develop a small feature on my current project.
Let’s say for this example that Atomic’s average hourly rate is between $150-$199 per hour.
|Role||Time||$ Cost/Hour||$ Cost (rounded)|
|Design||4 hours||150 – 199||600 – 800|
|Development||32 hours||150 – 199||4800 – 6400|
|QA Testing||1.5 hour||>150 – 199||225 – 300|
|Project Management||.5 hours||150 – 199||75 – 200|
Depending on the hourly rate it is going to cost between $5,700-$7,700 to develop a small feature. But that’s just a starting cost.
The true cost of delivering a new feature is far more than what the table above demonstrates. For example, the table does not take into account the cost of end-user testing, launching and supporting the feature, or sunsetting it. Perhaps a more serious cost consideration is the opportunity cost of implementing one feature over something else.
The question a product manager should ask is Is or was this feature worth the actual and opportunity costs? Using a hypothesis mindset, they can then turn this question into a testable statement.
Often, there is a material difference between product features that users say they want and those that actually get used. It’s easy for people to be vocal about things they think they want if asked. Except for their time, it is relatively cheap for users to list things they would like. But it is almost certainly of considerable cost for teams to build and deliver those things.
Creating value does not necessarily mean responding to the most vocal segment of the user population. The value grows out of delivering something that users actually engage with.
A logical place in the product development life cycle to validate customer demand is in the discovery phase. In practice, however, time and budget do not always allow for a full-blown Research, Design, and Planning Phase. But having a hypothesis mindset throughout the product development lifecycle can be almost as effective.
To avoid sinking money and time into developing unused features, it can pay to test assumptions about users. Some quick and cost-effective ways to validate hypotheses include the following:
In the fourth and final part of this series, I’ll discuss the dangers of moving ahead without sufficient data to back decisions. I’ll also lay out strategies teams can use to mitigate risk.
The post The Value of Hypothesis Mindset in Product Development – Part 3: You’ll Develop Features That Get Used appeared first on Atomic Spin.
Source: Atomic Object