It is easy to lose sight of the OUTCOME in a fast pace environment, especially if you have an existing product with lots of feature requests. A good product manager will ask the right questions and will focus on solving the right problem.
Similarly, a good engineer or a team should be able to ask the right questions to uncover the root cause for a problem, but without a clear process in place, people tend to forget. Strategy consulting firms, such as McKinsey, always start by defining the problem, then structuring the problem. The Hypotheses tree or the issue tree is one way of doing that.
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einstein
As with the five whys, navigating the tree is not easy, and it depends on how you frame the questions at each why. One simple way is to ask why at each branch. To keep it clean and effective, follow the MECE model: The tree should be Mutually Exclusive and collectively exhaustive.
Here are some ideas to make your first try a successful one:
- Ask why at each node. Here are some ways on how to ask why:
- Use a binary tree, only two branches at each node.
- Limit your self to three levels at the beginning. Trust me, this was hard for a lot of teams I worked with.
- I call this variation of the hypothesis tree the 3WhysTree
Asking why is an art, and a bit of experience too
The way you ask why will determine how you navigate the problem. Imagine you are building a new Google Docs feature: Publish to Medium. You can ask the “why” in many ways:
- Why Publish to Medium is important to our users? → This will help you understand the motivation behind building this feature, while this:
- Why do we care about Publish to Medium? → Helps you understand why you want to build this feature or
- Why do people prefer to write in Google Docs before publishing to Medium? → This like the first one, but taking a different path in understanding your users.
There is no right path or answer, but I prefer to use the MECE model so that the branches don’t overlap at some point which makes it messy instead of MECE.
In one of the products I was working on, a team took a feature request from the customer, let’s call it SOMETHING, multiple customers actually with a good number of upvotes. The UX team along with the product managers did good work in coming up with a better way of doing SOMETHING. In less than 10 minutes, I constructed a 3WhyTree with the product manager and I discovered my mistake, I didn’t ask him, or her, about the problem we are trying to solve before we started the research. Customers will ask for features based on what they need, our job, as product managers, is to understand what are they trying to solve? What is the real problem here? If I did this quick exercise before we started the research, I could’ve saved the team a lot of time. We ended up not working on that feature due to lack of information, unfortunately.
The hypothesis tree or some variation of it will help you uncover those problems early on, especially if it became of how you approach problems in general, first define the problem, then structure it before diving into more details.
Problems that are not well defined
Some of the problems are not well defined, and it is hard to define or structure them. In that case, I would not spend a lot of time structuring the problem, but I will create a list of hypotheses and go validate them (design thinking).