Notice how this line of questioning never makes a promise to build the thing. It just takes their desire for the thing as the starting point for a larger conversation.
In this episode, Richard and Peter discuss how to work with stakeholders who always bring solution requests, like detailed requirements or technical specifications. How can you have an effective conversation to identify the underlying problem so you can collaborate with your team to solve the problem well?
Learn More
Certified Scrum Product Owner Workshop (virtual, instructor-led)
Advanced Certified Scrum Product Owner Program (virtual, instructor-led)
2-Week Backlog Makeover (online, self-guided)
80/20 Product Ownership (online, self-guided)
Contact Us
We’d love to hear from you! Tell us what you’ve found useful on the show. Tell us what you’d like to hear us talk about more. Maybe share a challenge you’re facing in your work that would benefit from a Humanizing Work Show perspective. Shoot us a quick email at mailbag@humanizingwork.com.
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work community.
Peter Green
Today we’re answering a question about how to work with stakeholders who always bring solution requests, like detailed requirements or technical specifications.
Richard
Why is this an issue? Well, too many Product Owners just become order takers for their stakeholders.
Great Product Owners think strategically about the problems that their stakeholders, customers, and users are trying to solve. So, getting alignment around the problem creates opportunities for Product Owners and their teams to come up with better, faster, more valuable solutions than what their stakeholders might have initially had in mind.
Peter
Before we jump into that episode, we want to help you with whatever challenges are most frustrating you right now. If you’re feeling stuck on something, whether that’s trying to take a more human-centric approach to your work, trying to make your product or business outcomes better, or if you’ve just got a more tactical process-related question, let us know about it.
Send us an email at mailbag@humanizingwork.com with a few details about the situation, and we’ll share how we might think through your challenge right here on the Humanizing Work Show.
Richard
And just a quick reminder to please rate and review the Humanizing Work Show in your podcast app. Or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable. Your help spreading the word about the show is super meaningful to us.
Peter
Want to get more access to free content we produce—not just the show? Sign up for our newsletter where we share one key idea every week. You can sign up at humanizingwork.com/HWnews, or in the footer of any page of Humanizing Work.
Richard
Alright, onto the question: When a stakeholder comes to you with a solution-focused request, “I need you to build me such and such a feature,” here’s how to get at the underlying problem:
Peter
First off, the one question you want to ask, but definitely shouldn’t, is “Why?” Why provokes defensiveness or just leaves you with an unhelpful answer like, “I want it because I want it.”
Richard
Instead, ask questions about the situation in which the solution would be used, or the outcomes they’re hoping it’ll create.
Here’s what those sound like: So, they come to you with “Build me X.”
You reply, “Oh, that sounds interesting. I want to learn more. What were you doing the last time you wished that feature existed?” And then you’re off and running with a customer problem interview. You know the follow-ups, like “What was hard about that? What did you try instead? What’s another example of where that happened?”
Similarly, on the outcome side: again, they come to you with, “Hey, build me one of these.”
You reply, “Huh. Sounds interesting. I want to learn more. If we had that feature, what would happen next for you? What difference would that make for you?” And you follow that into a conversation about the larger goal that this feature would help them achieve.
Peter
That first approach is usually best if you get the sense that the proposed solution is a response to some pain or frustration. The second approach is better if you get the sense that it’s about creating some new positive outcome. You can always pivot from one to the other if your initial move doesn’t work.
Richard
At some point in the conversation, you might find it useful to float an alternative solution that gets at the same problem—or even just the prospect of an alternative. You know, “If we could find another way to solve that problem, would you be satisfied with that?” Their response may reveal some other details about what made that particular proposed solution seem attractive to them.
Peter
Notice how this line of questioning never makes a promise to build the thing. It just takes their desire for the thing as the starting point for a larger conversation. Then, based on that conversation, you can decide what you want to commit to.
Maybe a new item goes on the backlog, maybe not.
Richard
Sometimes when we’re talking about this with product people, they object that their stakeholders just shouldn’t be bringing them solutions. “That’s my job,” they say. “My stakeholders should stay out of the solution space and let me do my job.”
And while that may be true, and it may be useful over time to nudge at that—especially if they won’t budge from their initial preferred solution—we find it more productive to just accept that some people’s intuition leads them to solutions. They may not even be able to articulate the problem clearly and accurately. So you’re better off starting with whatever they offer you, and then having a conversation to get to the information you really need.
Peter
Please like and share the episode if you found it useful, and keep the questions coming. We love digging into the topics that are most relevant to our audience right now, so send them our way—and thanks for tuning in.
Last updated