When a team sets out to develop a product, they generate a series of hypotheses. In my experience, good teams are explicit about these hypotheses and test them before they invest too much time into a particular product plan. However, more often than not, I see that development teams are not even aware that these hypotheses exist, instead building their products as if they were fact. The problem with this approach is that rarely does a team get all, if any, of these hypotheses right from the get-go. If they don’t first test them, they run the risk of building a product that nobody wants. Let’s take a look at an example to illustrate how this works.
Explicitly Enumerating Product Assumptions as Hypotheses
I have an idea for a Delhi Metro mobile app. DMRC is the local Metro train that runs with-in NCR regions. Riders include daily commuters and occasional train riders. As a daily commuter, I witness a number of problems experienced by occasional riders. They don’t know how to buy tickets, they don’t know how to pay for parking, they don’t know which platform to stand on. They don’t know how to tell what stop they are at.
I suspect that if DMRC tackled some of these problems, they might convert more of these occasional riders into daily commuters, growing their ridership. I’ve often considered building a DMRC mobile app that addresses some of these usability problems.
The app would walk the occasional train rider through each step of the process of riding the train, starting with where to park, how to buy a ticket, updates on when the next train is coming, updates on where you currently are relative to where you want to get off the train. My goal would be to make it as easy as possible to ride the train.
I know how to do all of these things. I’m observing these problems first hand from past 1 year. Should I just get started and build the app? How do I know that occasional riders will want it?
Let’s take a look at some of my assumptions or hypotheses underlying my app idea.
- H1: Occasional train riders will download a DMRC mobile app before they ride the train.
- H2: The problems that occasional train riders experience are big enough that they will remember to use the app they downloaded earlier to help solve their problems.
- H3: The desire to ride the train is great enough that if occasional train riders had help they would ride the train more frequently.
It’s quite possible that occasional train riders don’t anticipate having problems. If they did, they would probably choose to drive rather than take the train. So H1 could be a big hurdle.
H2 may not be as big of a hurdle. It’s possible that if I did download the app and I run into a problem, the problem itself may act as a trigger to remind me I have the app. But that still needs to be tested. It might be easier for me to just ask somebody nearby. Or I might just give up, something I see people do daily.
With H3, if my goal with the app is to help grow DMRC ridership, then I am assuming that the reason people don’t ride the train more often is because it’s hard. This might be part of the problem. But there are a number of other reasons why occasional riders might not take the train more often – the big one being that it is often slower than driving. Even if people had all the help they needed, they might still choose to drive over taking the train because they simply want to get to their destination sooner.
Now I need to find out the solution for testing these hypothesis, till then cheers!