Dealing with Stakeholders coming with Solutions, not Problems
Hey I’m Ant and welcome to my newsletter where you will find actionable posts on topics related to product, business and leadership.
You might have missed these recent posts::
- 3 Product Vision Formats That Aren’t Boring!
- Building Effecive Product Roadmaps
- Break Outcomes Down, Not Initiatives
My day job is helping companies shift to a Product Operating Model.
My evening job is helping product people master their craft with Product Pathways.
If video is more your thing, check my Youtube channel out!
Here's a hack I use to dealing with stakeholders coming with solutions, rather than problems.
Don't try to work backwards, work forward.
Let me explain.
No doubt you’ve been in this situation before.
A stakeholder has come back from a conference or read one of the latest Forbes article and they’re pumped to jump on the latest trend.
And you’re now being asked the implement it.
But it’s pretty clear that it’s a solution looking for a problem.
The typical advice is to work backwards and unpack the problem they’re trying to solve.
We know that great product teams are problem solvers, not a feature factory. As Marty Cagan puts it;
“rather than providing the product team with a roadmap of features and projects to build, the product team is instead given a set of problems to solve and desired outcomes to achieve.”
And this is good advice. Even if you’re not empowered. You should always try to understand why.
However, working back towards a problem can be a stretch for some stakeholders.
I’d also bet that you’ve run into some resistance trying to do so too.
And it’s understandable.
Asking this question can be seen as challenging their idea.
It can also feel dismissive.
Which is why I've found a more effective approach has been to go forward rather than backwards.
Rather than trying to work backwards to a problem, go with the idea.
Cast forward.
So rather than asking “what problem does this solve?”
Ask: "If we did deliver this solution, what does it mean? What does it mean for us, the org, our customers?”
What we're doing is rather than trying to get them to articulate the problem - which sometimes can be hard - we’re facilitating their thinking around what they expect to be true if their idea was implemented.
We can then reverse engineer that end state back to what they think the original problem might be.
This is a great way to uncover the problem in a non-confronting way.
Here's a real example I did with a client recently:
Idea: "move DB to cloud"
If we did this, what would it mean for us/org/customers? “Speed, reduce costs, reduce complexity, Improved experience”
Why do we need these outcomes? ”Currently costly to run, slow processing, slow development times due to difficult integrations, etc.”
BOOM 💥 Problem spaces!
And just like that you’ve worked from the solution (moving the DB into the cloud) to the benefits they expect to get when that has happened, to inverting into the current problems that we’re trying to solve.
As a side note, the conversation organically moved into identifying an initial set of assumptions that might need to tested.
Which helped to highlight the need for product discovery before jumping into delivering the solution.
Something that wouldn't have happened otherwise.
Need help with scaling your product or business? I can help in 4 ways::
Level up your craft with self-paced deep dive courses, FREE events and videos on YouTube, templates, and guides on Product Pathways.
1:1 Coaching/Mentoring: I help product people and founders overcome challenges through 1-hour virtual sessions.
Consulting and Advisory: I help companies drive better results by building effective product practices.
Private Workshops and Training: I run practical workshops and training courses for product teams globally.
Popular Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…