Confessions of a Product Manager Lesson 1 — Focus on the problem, not the solution
Previously in “Trust our Developers as Problem Solvers” and “Confessions as a Product Manager” I touched upon focussing on the problem since developers are natural problem solvers. However, I didn’t go into detail about why. There are two sides to this problem, giving information, and receiving information.
Influencing your team
My first lesson in becoming a Product Owner was how to influence a team of smart people to do what you wanted to do. No matter how experienced I was, I am faced with these issues every day. When I started with “what” I wanted, I ended up in long discussions going over the scenarios and the problems we’re trying to solve.
I recently attended a kick-off meeting where I, as an observer, saw the product owner face the same challenges as I did. The PO walked in with a clear idea of the solution, went through a grueling session about the problems and how he got to the solution. The meeting ended positively, where the whole team had left with a clear idea of the problems, but at the same time opened up the possibilities of better solutions.
Starting with “What” creates defensive teams. Starting with “Why” will bring your team on your journey to your solution. In this situation, if the kick-off meeting was to go over the problems the team and the team would have left understanding the problems and less tension for all.
Asking Questions
Not only are you solving problems that already exist, but you also listen to your stakeholders in what to do next. In any request or conversation, you will realize they do not naturally start with “why”. It is our duty as product people to truly understand why they are asking in the first place.
If a customer says, “Where is the documentation?”, do not send them a link to the documentation. Ask “why couldn’t you find the documentation” or “where did you look”. This information is providing you context and knowledge about the problem they face.
If there is a feature request, ask why they need it. Get to the root problem. Why? Our customers know when they have a problem, they do not know if the solution will solve their problem unless they can see or feel it.
What I try to do:
- In feature requests, ask why 5 times. Record the results, this is useful evidence when you decide to pursue this problem.
- Before designing solutions, interview your users and customers about the problems. They know about their pain, problems, and needs. However, they do not know if the solution they suggested will actually have an impact.
Focus on the Problem
Simon Sinek put me on the path of starting with why. I still have a conflict or difficult situations. However, I feel I am equipped with the right knowledge because I focus on the problem. What I do differently now is:
- Start with why when communicating to anyone about the product, feature, story, etc.
- Ask why all the time like a child who is exploring the world.
- Learn everything about the problem. The impact, the user journey, alternatives, any evidence to support it.
