We need to ship "you name it"; a pretty common request and situation when working as a product manager or software engineer.
It's a natural tendency. We tend to talk first and more about solutions rather than discussing the underlying problem.
A simple practice to reframe the discussion is to ask Why. Ask it genuinely to grasp what problem we're discussing. To understand what we're trying to solve.
In the early 20th century, Sakichi Toyoda, an inventor working for Toyota, developed a root cause analysis concept. Known as Five Whys, the aim is to detect the root cause of a defect, by iteratively asking Why. In most of the cases, five iterations are enough to reach the root cause.
Since then, the Lean methodologies evangelized the use of this practice. Especially for problem-solving and for improving processes.
I find it very efficient when applied to product management.
First, to avoid to stick with our former solution. We tend to fall in love with a solution quickly. It allows us to step back and to discuss the problem.
Then, it prevents the second trap of staying at the surface of a problem.
We need to dig into the issue, persevering, checking data points, iterating to discover the root cause. Depending on the problem, it may be tricky to separate the causes and the symptoms.
Once we have a good grasp of the problem, we can look for patterns. Does this problem is an industry problem? Does it concern several customers? What is the opportunity? What are the potential outcomes of solving it?
Finally, we can go back thinking about potential solutions and figuring out the different possibilities; and their pros and cons.
In our organizations, we can mix the activities of studying a problem and defining a solution. When doing so, we reinforce the attachment to our former solution and don't give to the problem the time it deserves.
We should fall in love with the problem, not with the solution.
Some practices or processes can support the split of these activities. For instance, write a one-pager talking only about the problem. And then, discussing the potential solutions into a dedicated one-pager.
I'm talking here about pretty big problems. The fine-tuning of an existing solution does not deserve so much effort. We get new learning or data points from the usage of this solution. In this case, small improvements are more a matter of increasing the adoption by enhancing the user experience, or by covering a new scenario.
A product organization will never be able to answer all the problems its users are facing. We work into a constrained system; we need to invest our efforts in solving the right problem with a relevant solution.
Our customers, our teams, our businesses (and our products) deserve it.
It's now time to go back digging into problems. ⛏️