Three questions to get to the heart of any stakeholder request.
If you’re in a role where you need to understand the motivations behind stakeholders (customers, users, project sponsors) requests, and sort out how to help people achieve their goals (or connect requests to your own goals)… this is for you. Product Manager, Coach, Manager, Mentor — I’ll share a solid three question framework to tease out the real needs of your stakeholders and a way to contextualize their goals with everything else you’re trying to accomplish. Your teams will succeed more quickly, better help customers & stakeholders, and do so with less friction and frustration. You’ll also know why you should almost never ask the question “why” again when working with requests or the ever-present misnomer, “requirements.”
But first…
Say Goodbye to the 5 Whys
If you’ve been in this business for any length of time — you’ve probably come across the concept of the 5 whys. I myself used it after reading Eric Ries’ book on The Lean Startup more than a decade ago. A long time later, and after too many touchy product conversations with defensive coworkers, customers, and management, it was pretty clear… People REALLY don’t like being asked “why” and doing so was making it harder for me to do my job, and harder to understand the needs of those around me.
I’m sure you’ve been there with a colleague, customer, or user and you simply ask them “why?” Perhaps you’ve asked a friend, or a personal partner. And, I’m also sure you’ve had some pretty sour, defensive responses to that question. Perhaps you walked away thinking “Gee, so and so really needs to chill out!” You chose a path of exploration that was confrontational, and wondered why you ended up in a confrontation. Instead of getting what you wanted out of the conversation, you created an opportunity for discontent. If you (unlike me) have never been this person… congratulations.
I found that using the 5 whys required a heck of a lot of trust in a relationship between people who clearly understood the technique and were self aware enough to avoid the natural defensive response to this question. I’m sorry to say that this just isn’t that common to find. Ideals aside, it is pretty rare that this technique ends in anything but a micro disaster for a Product Manager.
Why should we say goodbye?
Aside from the general unease we experience with the 5 whys, what about the technique is really causing it to fail?
“Why” is incredibly ambiguous.
Rather than giving your conversation partner solid ground to think and address a specific question, you asked a question that is very open to interpretation.
“Why” leads to internal storytelling about your intent.
Instead of considering a response, your partner’s mind may ask itself “Why are they asking me why?” or “They don’t believe in me!” or “They know something and aren’t telling me!”
“Why” doesn’t work well with power imbalance.
Let’s be frank — the power is almost always imbalanced. Product Managers are typically no-one’s boss, and they are often put in a position where their personal success and product success are conflated or at direct odds with each other. Stakeholders often perceive or have a real power advantage over the product manager individually. This means that ego and authority often get in the way of asking a more senior person “why?”
“Why” doesn’t work well with customers.
Customers think they know what they want. So they ask for it. When you ask them “why” suddenly the other reasons we’ve discussed pop into their heads (power, story, ambiguity, ego) and you’re more likely to simply piss them off.
Whether the reason is Self Doubt, Power Imbalance, a lack of shared context, the question “Why” leads to confrontation over collaboration. You simply don’t get what you need most of the time.
So, it’s time to say goodbye to the 5 whys and replace it with a much more powerful and concise set of questions.
The Three Questions to get to the heart of a stakeholder request.
Question # 1: What Goal does this help us(you) achieve?
This question establishes the core intent and purpose of the request. Here we are looking to sort out the ultimate thing a user, stakeholder, customer wants to achieve. We can also use this to determine if the request is aligned with our own goals, and exactly how.
Question # 2: How does this help us achieve that (our) goal?
Now we’re guiding the stakeholder in connecting the dots for us. We are establishing the connection between the request and the intended result (goal). This might be framed as an objective, KPI, or something more abstract that illuminates the uncertainty by the stakeholder without undue confrontation.
Question # 3: How much do you think this will help?
So we know the goal, we know how this helps… but how much of an impact can we expect? At this point we’re hoping for something concrete but we’re more likely to get something abstract such as “oh, it will help a lot.” In these circumstances, it is helpful to follow up with questions that compare the perceived impact with previous suggestions or requests from the same topic (better even if they are from the same stakeholder). Comparisons with existing ideas that have been actioned gives you a more accurate prediction methodology than precise numbers.
Managing Stakeholders
There are a ton of stakeholder archetypes that this can help manage. Fundamentally, these questions help us remove emotion, ego, and authority biases from our discussions with stakeholders. Whether you’re dealing with stakeholders who drop in randomly with highly disruptive ideas, an executive who is the highest paid person in the room, or middle manager yes-people types these questions help get to the heart of the requests in a clear and concise goal oriented way. It allows people to think more thoroughly about their ideas without being put on the spot. And it invites people to provide more thoughtful inputs and requests in a collaborative fashion.
Caveats & Variants
Not every situation is the same. You may have more information already, or the stakeholder may provide several of the inputs to these questions already. Here are some additional ways you may need to flex within these questions.
You may not need to ask all three questions if the stakeholder answers them without prompting.
When the request itself includes some of this information, reference that and dig in for more detail.
Sometimes the responses won’t make any sense or are inconsistent with each other. Thank the stakeholder for their insights, and ask follow ups with focused on question #2.
Sometimes the stakeholder won’t have the answers to these questions. This is an opportunity to collaborate. Ask if the stakeholder would like help thinking about these, or if they’d like to come back to you later once they’ve come up with their answers.
Sometimes the stakeholder doesn’t want to answer, or doesn’t care. This is probably a pre-existing toxic situation. Regardless, acknowledge and note the request then thank the stakeholder.
While these questions are much more likely to lead to positive outcomes and improve your communication over using the 5 whys, it isn’t a magic bullet. There will still be times where a stakeholder simply isn’t in the mood to care, participate, or put in the time. Occasionally, you may simply need to wait and note that if the situation isn’t important enough to discuss and connect to goals — it’s probably not all that important (regardless of how the stakeholder labels it). If this person is your direct boss, you may not have much of a choice in the matter.
In all situations…
Practice Empathy. Get the answers. If they make sense, accept them and move on. Avoid expressing judgements at this stage. The idea isn’t good, it isn’t bad… it isn’t better, it isn’t worse. It simply is.
Can I still use “why?”
Sparingly, yes. The more specific you are about the phrasing and topic, the better. However, most of the time you might find that it’s easy and productive to replace why with how.
E.G. Instead of “Why did you choose this solution instead of that one?” you might ask “How does this solution compare to the one you didn’t choose? How is this one better for our situation?” This avoids the implication that you think you know something the listener does not.
If you have a very strong knit team who is familiar with this concept and has practiced it, then you can continue to apply the 5 whys. I find it unlikely that you will find more success with this strategy than applying this framework at increasing detail. “Why” risk it?
Applying the three questions
At this point, you should clearly understand the three questions. They ask the goal, how the request helps achieve the goal, and by how much. This is everything you need to begin putting the request in context with all the other requests landing on your desk — and give you a head start on prioritization.
The best way to learn this technique is to simply start practicing it. When you find yourself asking “why” — check if there’s an alternative phrasing that utilizes “what,” “how,” and “how much.” You’ll learn the same things, with less friction, and build a better relationship with your stakeholder at the same time.
