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.
Development Cost
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.
Features Users Say They Want vs. Actual Demand
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.
Methods for Quick Testing of Hypotheses
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:
- Use readily available testing apps for quick-and-dirty customer surveys.
- Pay an agency or service to test for you.
- Use your own product, otherwise known as “dogfooding.”
- Ask users to perform tasks using low-fidelity prototypes.
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.