HYPOTHESIS & EXPERIMENT (PART 1): Where to begin?

On my last post, I talked about Hypothesis Drive Development and the benefits of asking yourself if your assumptions about a product or feature are correct before you dive into discovering the solutions and building on those assumptions. On this post, I thought I would talk a little about the high level questions you should be concerned about when building your products and features. If you are interested on more objective content, skip the first few paragraphs.

For some time now we have seen startups and enthusiasts talk about concepts like MVP, Lean, Value Proposition, Business Model canvas in relation to frameworks, mindsets and techniques to improve the understanding of your product before you even go out and built it. This concept seems well accept amongst entrepreneurs and companies from left to right.

So why the need for a post like this one? Well, it seems that everyone agrees on these concepts but when comes to implementation there is still very much we can improve on. As product leaders, designers and engeneers we should I’ll be asking ourselfts should we built something before commiting time and resources to a solution.

And there lies the first challenge I see all the time, on most teams and companies. Everyone is always eager to discover and implement a solution. Every experienced product team will surely back me up on this. From what I have experienced, the reason for that lies in company culture. But we will talk about that in the future.

There are thousends of leaders and speakers that talk about the issue of trying to develop a solution before understanding the problem but I like Dan Olsen’s talk about the subject: https://youtu.be/Bb8DfkBSL_A?t=1028. I recommend you checking that out.

Problem vs Solution

As I breafly discussed on my last post, we are inheretly driven to giving a solution to a problem we don’t know enough about. Without going in to deep, here are some of the reasons I have found for this:

1. Eagerness to getting things done.
2. Lack of company culture.
3. Lack of tecniques on how to discover and prioritize problems.
4. Trying to impress your boss (this one is really sad =])
5. Personal or leadership biases twords an idea
6. Eagerness to code/build (for engeneers)

Using Dan Olsen’s youtube talk example to illustrate the product/solution dilema, he talks about a use case of a space pen; a pen that can write in space. I don’t know if it’s a true case but the story goes that NASA was looking for a way for pens to work in space. Apperently normal pens don’t work is space because of no gravity; I don’t know, never been there =] . So this company develops a pen and spends 1 million dollars in R&D. The “problem” they were trying to solve was pen’s do work in space.

Olsen goes on to explain that when posed with the same dilema, the russian space program refraimed the problem by asking: “how can we write in space”. By reframing the problem, the solution had a ZERO R&D cost. They used a pencil.

So before you rush into an idea about your product and feature, ask yourself if the idea is a solution or if it has a root problem. Better yet, force yourself to document the relationship between a solution you develop and the root problem that the solution tries to solve.

How to find the root problem for a solution?

First of all, you don’t normally know if your idea is a solution or a problem. So don’t take the following lightly: DOCUMENT (MAP) THE RELATIONSHIP BETWEEN PROBLEM AND SOLUTION. Make a habbit of this.

Second, and the easiest part as it turns out, try to find the root problem by using the 5 whys framework. Simply putting it, it consists of continually asking ‘why are you going to solve said problem’. Normally you’ll get to the root reason way before you hit the 5 whys mark. So, if you think you have a problem like creating a pen that can write in space, ask why are you going to solve that problem. The answer maybe: because I need to document something in space. What magically happens is that your initial problem becomes one of multiple solutions to the real problem. Another solution to this problem could be: a audio log hardware/software that automatically translates speech to text. That way, you don’t even have to write stuff down. There’s a MIRO board for as the image bellow shows. Check it out at https://miro.com/templates/5-whys/

Third, do this collaboratively. You will always be biased to your own ideas and solutions. If you did not come up with the solution, it is still valid to get outside opinion and collaboration. I can’t stress this enough. When testing hypothesis, in every level of product discovery, you can’t look inwards only. Get outside validation.

One last note about problem versus solution: sometimes, even if you discover a problem/solution scenario by yourself and present it to your manager or stakeholder, you may be turned down by the outcome. This happened very recently to me. So here’s a tip: doing discovery collaboratively using a tool like MIRO and having your colleagues or stakeholders participate in discovery will likely lead them to reflect on these scenarios by them selves and exceed the chances for consensus.

Another way of looking on a negative response from your stakeholders (remember, they may be the one sponsoring the “wrong” solution) is that there maybe forces at play and scenarios you don’t know about. That’s why they are the stakeholders and leaders. Sometime, you have to trust your leaders even when the evidence points the other way.