Nothing Matters More Than “Why”
AI generated image from Magic Media created by Canva
As we grow our product management teams, opening new roles in the organization, a common question I get from recruiters and those on the interview panel is “what are you looking for in a great PM?”. I do not think this question has a definitive answer, as different roles within Product require different skills. For example, when hiring a technical product manager for a hardware manufacturer a key criteria would likely be extensive experience in the installation or repair of the product, possibly looking to excellent customer support technicians. A product owner needs expertise in backlog management and team communication and motivation. And a senior leader in product would need managerial time along with a successful track record of delivering similar products to market.
However, there is one common trait that I look for in any interview for a product manager. I strive to find individuals that are curious. Curiosity is the desire to learn, the hunger to understand. A great product manager is one that asks “why”, and asks it often. “Why” is seen as the refrain of toddlers trying to make sense of the world, born out of natural curiosity. This question was fundamental to every one’s development into a functional human in society, and great PMs are ones that never lost that zest to learn, to understand, to ask “why”.
Why “Why”?
Do you have one of “those” friends? The one where no matter the topic you discuss, they have a story to share or explanation to disclose? These know-it-alls have lost their curiosity and instead think the power is in knowing the answer. They view conversations as moments to share their knowledge, instead of listening, learning, and growing. In the PM domain, these people often jump to a solution at the first mention of a customer challenge. Brainstorming and ideation are positive traits, but when the first idea becomes stuck in the PMs head as THE solution then this trait becomes a deficit. These PMs end up solving for a symptom rather then curing the underlying disease. Let’s talk through an example:
You are working at a video game development team, and you just launched your new game to glowing reviews. However, you notice an active social website where users share tips about the game has a growing conversation around the difficulty of the final boss battle. Given this information you decide you over-tuned the battle and push your team to reduce the health of the final boss to alleviate these concerns. As you ship the patch you watch the forums for the positive reply from the community for the quick response from your team.
However, what you see surprises you. While the discourse on the final battle has slowed, now people are complaining about the penultimate battle. How could this be an issue now when it wasn’t before the patch? You only changed the final boss’s maximum health, which would not affect the previous boss battle? What happened?
Now, you are curious. At first you assumed you knew how to fix the issue because you assumed you knew the core problem. The feedback on the difficulty of the final battle was the symptom of the problem, not the disease. After spending the time to talk to users, review feedback, and analyze gameplay you realize only a small number of people were discovering the final weapon power-up. Fixing this issue made the final power-up more discoverable which in turn made both the penultimate and the final battles easier. Congratulations, by asking why you found (and fixed) the root cause.
Avoid the Assumption Trap
Ultimately, asking “why” avoids the dangers of assumption. Digging into the true request from a user, customer, sales engineer, account manager, etc. will set you apart in product management.
Do not fall into the assumption trap.
The core function of Product Management is to be the constant and consistent voice of their users in the product development process. PMs are the SME (subject matter experts) of the user’s experience. This deep understanding of our user, and how our user solves problems with our technology (or with other competing technologies) empowers us to build the roadmap to best address core customer needs. However, it is exactly this understanding that can lead us to the assumption trap. Being the voice of the customer requires you listen to the customer. Being a SME does not mean you always have an answer, but rather you know how to get the answer. And you do that by asking “why”.
In Product Management, a delicate balance we need to maintain is listening to our users while not doing what our users say. This may seem like a paradox, but what I mean by this is that your users are providing key information to make your product great, but listening is an active ability. You cannot merely take the first comment from a user and run, you need to ask more questions to hunt for the core problem and develop strategies to address it. You need to understand the why. Let’s revisit the previous example:
User: “I’m having a really hard time with this boss. You made it way too hard, and you need to change the health or damage output.”
PM: “Those are good suggestions, thanks for sharing you challenges. Can we go back to the fight for a minute? What level are you when you get this fight? What weapons do you have equipped?”
User: “I am level 25 and using the [insert cool name here] weapon.”
PM: “Have you tried the fight with [insert cool name here] + [awesome upgrade] weapon?”
User: “Wait, what are you talking about?”
Our role in PM is to convey the right customer priorities to the development team but not to dictate or decide the best implementation. It is easy to jump to the “how” when talking about an issue because you’ve researched, discussed, and evaluated other product’s implementations. After all, you are the SME. But, when we in product get too deep into the “how” we fall into the assumption trap:
We remove the development team’s ability to discuss and evaluate the solution. We become dictator, not the voice of the user’s challenge.
We erode the trust of our team by not allowing them to contribute and enhance the solution with their expertise.
We erode the trust of our users by releasing updates that do not fix their problems, making if feel like we are not listening.
We waste time building answers to symptoms, not curing the underlying disease.
It is easy to fall into the trap of a roadmap of answers, instead of a roadmap of problems. We do not want to provide a list of ways to solve the problem, as this leads to the issues listed above. We need to provide the prioritized list of user challenges, and we need to ensure we explain those problems in a way that shares that user’s pain to anyone reading the issue. In the roadmap item we can share ways the user gets around the issue, the way competitors have solved the problem, or even our own recommendations, but the key is we do not say “we build this to solve it” before we’ve worked through the why and collaborated with our development team.
The best features are developed by teams that work together to find innovative and differentiated solutions to user problems. The best products are ones that solve core problems, not symptoms of the challenges. There is a bias you should constantly be aware of when you have your own “solution in your head”. The best Product Managers are open to constructive conversations, they are curious, and they always ask “why”. They don’t have all the answers…they have all the questions.