Bring Me Problems, Not Solutions
19 July 2020 ‧ 3 min read
It is an often-repeated piece of management advice to demand that team members “bring solutions, not problems”. The reason for this advice is to empower employees to solve problems they encounter, reduce management bottlenecks, and thereby to improve the overall performance of the team.
In product development teams, however, often the opposite demand is appropriate: bring me problems, not solutions.
At first glance, reversing this advice sounds strange. Aren't empowered product teams what we want? Surely, if asking for solutions empowers the team, then asking for problems must disempower them?
In reality, it's not so simple. Potential product changes are often discussed in the form of feature ideas. These might come from a number of places—customers, team members, executives, etc.… Feature ideas, however, are solutions. Of course, these solutions have an underlying problem, but it is important to explicitly move up to the level of the underlying problem.
Moving up from feature ideas to the level of the problem helps validate and prioritize. Is this really a problem that enough customers face that this is worth doing? Is solving this problem in line with our vision and strategic goals?
A feature idea that gets raised is also only one possible way to solve the underlying problem. If you don't explicitly uncover the problem from a solution idea, you have no way of evaluating if the given idea is even the best way of solving the problem you can come up with. In addition, most ideas fail, but that doesn't invalidate the underlying problems. It is therefore in any case a good idea to define the problem before the solution, in order to be able to try different solution ideas if the first one fails.
Moreover, staying at the solution level can mean that the product team acts reactively instead of proactively. They collect feature ideas coming from all kinds of places (including customers, stakeholders, and their own ideas), then prioritize them with some kind of pseudo-scientific framework, and built what scored the highest. Instead, it would be better to start with the product vision, determine the most important problems to solve on the way to realizing the vision, and then ideate solutions for those problems.
This means that actually moving from the solution (“feature”) level to the problem level is more empowering to the product team. Instead of just being asked to deliver on feature ideas (or, slightly better, to prioritize feature ideas and build the best ones), the team gets asked to solve a strategically important problem with clear link to the product vision. The team is then empowered to autonomously discover the best way to solve that problem, including trying multiple approaches and learning in the process.
As a product leader, you want your teams to be empowered. Empowerment makes teams more intrinsically motivated because they have autonomy and are pursuing a higher-order purpose (solving a problem instead of delivering a feature). It therefore behooves you as a product leader to push for problems, not just solutions in the form of feature ideas.
Now, I will admit that I cheated a bit with the title of this article. Really, bringing problems is good, but bringing problems and solution ideas is better. These solution ideas might get discarded during discovery for better, more effective ideas, but starting with putting some solution ideas on the table ensures that the problem is at least solvable in theory. So really, the saying should go “Bring me problems and solutions”.
I hope you found this article interesting. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.