Is finding problems to solve really the most important thing a product team can do?

Oct 2

During one of our Hemnet book club sessions, we discussed Marty Cagan’s article on problem space vs solution space. The discussion made me really think: are PMs and product teams focusing so much on problems that they are losing interest in finding the best solution for the customers?

There are plenty of product development books focusing on the problem space, product discovery has never been this hot and many PMs believe that their main job is to identify the right problem to solve. The focus on problems is so extreme that some PMs are even scared to work with solutions, as that should be up to the team.

Thinking back about how I have approached different product problems in my career I realize that I am guilty of falling in love with the problem myself. I disproportionally put time on:

Shifting stakeholder's focus from solutions to problems
Framing the problem
User testing to validate that we solve a real customer problem
Market researching to see how others solved the same problem
Convincing stakeholders on why it is beneficial for the business to solve the problem
Persuading the team on why we should work on solving the problem

If I really take it to the extreme I can say that I spent so much time defining the problem that once I and the team started working on solutions, I almost jumped in bed with the first one. But is it really the problem the most important thing to look at?

If I really take it to the extreme I can say that I spent so much time defining the problem that once I and the team started working on solutions, I almost jumped in bed with the first one.

As much as I think that having a clear problem definition and validate that we are solving a real user problem are necessary steps in product development, I really believe that we should shift the majority of the product team's time, including the PM, to solutions instead. As Marty points out company and product teams fail on execution, rarely on problem definition.

But what is needed to make it happen? It is quite a radical shift in focus and skills and that requires to tackle some challenges:

Overcome the tendency of ”getting it done” but dare to spend time on solutions by comparing and contrasting. The team needs to find a balance of information flow, learnings pace, and success factors. The pressure from stakeholders on delivery will always be really high, but I think that there is a common misconception about having to choose between comparing different solutions and delivery pace. You can do solution discovery and have a fast execution if you accelerate your learning pace. Not everything needs to be a high fidelity prototype, an AB test, or something that requires building time.
Constantly talk to the customers, or as Teresa Torres would say: continuous discovery not to validate or test one solution but to understand customer needs, desire, and pain. This will help with fast and cheap learnings, accelerating the comparing and contrast phase, and helping with execution.
Seeing the PM as part of the team and an asset to help the team find the best solution for the customers' problems. I believe that the era of PM being segregated in the problem space should be over, they can and should help the team finding usable, feasible, and lovable solutions for the customers' problems.
Dare to test outside the current product features portfolio. To keep the position or to gain a position, you need to be disruptive and sometimes disrupt yourself. Testing different solutions is a way of doing it if one dares to go outside the comfort zone.

It is a big shift and it takes relentless focus, but I really think that there is a lot to win for the teams who dare to do it.