Why do you exist? Do you matter? Does anyone care? What’s your purpose? Why are you here?
No, you’re not 17 again and going through a crippling existential crisis. You’re a product manager who’s trying to understand the ‘why your product matters’, if it even does at all.
In the product world, you’ve likely come across the idea of writing a hypothesis for the problem(s) that your proposed product is trying to solve. By using a hypothesis, you can not only expose your own unsurfaced assumptions but also come to terms with what assumptions need to be confirmed in order to make your product a viable solution for the struggling masses who have to deal with the problem in the first place. I’ll sometimes view my product hypothesis partially through the lens of ‘an assumption that needs to be proven/disproven.’
I know I just told you that you weren’t a pimpled face, 17-year-old punk-kid again, but apparently I want to give you flashbacks. Something you likely learned in grade-school science class was the definition for a hypothesis… something like: ‘a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.” You are trying to explain a phenomenon based on the evidence you have today, but you’re not done yet. You’re using that initial explanation as a start point to prove or disprove your suppositions or proposed explanations with supporting evidence.
Regardless of the format you use to write the hypothesis, your hypothesis needs to be testable. Testable doesn’t mean “right”. It means a few question marks exist, surrounding the entire existence of your hypothesis. This means we need to understand how to ask those questions. We need to understand why we ask those questions. We need to understand that our hypothesis exists because questions exist.
You’re probably checking the title of this post now. Talking about how we ask questions may seem unrelated to your product’s hypothesis. After all, a hypothesis asserts a potential thought and somewhat evidence-based reason to explain some phenomenon. A hypothesis, while admittedly not the answer, assumes some form of understanding. Even if that understanding hasn’t been proven to be true.
We don’t write down our hypothesis because we know the answer. We do so because questions exist.
Every great hypothesis needs to encompass a few things. But in the broadest sense, your hypothesis needs to be provable or disprovable. Don’t be afraid if your hypothesis is wrong. In fact, it’s likely going to be wrong in some combination of circumstances and situations.
Your hypothesis will change over time. Just like that 17-year-old, you had to go through the mental evolutionary progression, shaped in the times fate imprisoned you to reside in, so does your product concept. Simply the use of a hypothesis is questioning your product’s purpose, you’re assuming you don’t have all the answers. Good, you’re growing.
A good hypothesis will expose more questions than answers. As we know, some questions are difficult to answer. Others cannot be answered at all. But some can. Why are some questions answerable while others are not? The first thing to look at is the question itself. An approach you can take when building your hypothesis is to ask yourself, “what questions do I want the answers to?”
Build a hypothesis that asks questions.
Let’s walk through a couple of great temples used today in the product world.
I believe that <this outcome>
Will be achieved if <this audience>
Attains <this benefit>
Using <this solution>
I (personally) have no issue with the spirit of this standard hypothesis template. I get what’s trying to be achieved here. A statement that gives you a starting point to your investigation by defining an outcome for your target audience benefiting them from a hypothesized solution. The decisive language is what I, personally, have a hard time running with. I am certainly more comfortable with the placeholder <fill in the blank> text the template offers for me to frame my statement.
To me, a hypothesis is there to ask questions, not answer them. Here’s what I’ve tried over the years to find a more suitable template for my product hypothesis purposes.
First, ‘I believe’ is a strong statement. It may be easier to say for some than others. I, for one, have a difficult time filling in the rest of the template because I’m truly not sure if I do believe anything. I assume some things. I understand some things (contrary to what my wife would tell you). I observe things and form patterns of behavior based on how observations affect me. But believe? That’s too strong for me.
I’ll personally modify the start of my hypothesis to start with “What it” rather than “I believe”. It may be something silly that I do, stemming from my own insecurities and uncertainties, but I think it provides me some benefits with my positioning.
“What if” implores the writer, reader, or listener to think about the possibilities. It asks the question rather than stating your position. It provides insecure, little-ole me with the flexibility to abandon my position if there is appropriate evidence to disprove my hypothesis is exposed.
So, what if <this outcome> will be achieved if <this audience> attains <this benefit> using <this solution>?
If <this cause exists>, then <this effect happens>, because of <this reason>.
Ah, cause and effect. Another thing you probably learned in grade-school science classes, not to mention social studies. I’m a fan of cause and effect statements as they get to the core of physical, social and mental phenomena. It also provides a concise yet logical structure for the reader to assert an explanation.
The ‘If, then, because‘ statement helps to translate your hypothesis to another key audience, your technical team. The challenge here, again, is to ensure we’re communicating our hypothesis as something that has yet to be proven (at least until it is). From the days of pascal and the before times; developers have been using ‘if, then’ statements to formulate a step 1 relationship to a step 2 and on and on and on… Now I’m not a developer, so I’ve enlisted the help of my dev team to give honest feedback on their honest gut reaction to ‘if, then, because’ hypotheses. For some of them, ‘if, then’ is a standard. It’s a law. We fall into the same trap of asserting a truth. We can benefit from ‘what if’ again to open the dialog, or at least the understanding that what we’re proposing is not a hard rule.
So, what if <this cause exists>, then <this effect happens>, because of <this reason>?
A hypothesis is a starting point for your discovery and exploration around a problem space. It’s not the end. We don’t write down our hypotheses because we know the answer. We do so because we know questions exist.