Hers's a tactic I use when Stakeholders come with solutions, NOT problems.
Don't work backwards, work forward.
What do I mean by that?
Commonly when a stakeholder comes w/ a solution we try to get them to work backwards to the problem.
But for some this is a stretch.
We hit a wall, there's resistance. The Stakeholder can't understand why they need to give a problem, when they have this amazing solution idea (after all it's an awesome idea, right?)
So instead of trying to work against their thinking, go with it.
Look forward not backwards.
Ask: "If we did deliver this solution, what does it mean?"
...what does it mean for us, the org, our users?
Rather than trying to get them to articulate the problem, get them to think about what would be true if we did deliver their solution.
This is one of my favourite models to encourage collaboration and bring clarity to the messy nature of product work.
Rather then having your typical RACI or accountability framework, map out:
🚗 Who is ‘driving’? and
🗺️ Who is ‘navigating’?
For example, let's take a look at the product process through the lens of the product trio.
At the start we're prioritising, setting the strategy and deciding on what to focus on. During this phase, it's typically led by the PM - they would therefore be the ‘driver’.
But any good PM knows they shouldn’t do this alone.
This is where the ‘navigator’ comes in.
They drive the activity forward and are responsible for making sure it happens but they do it collaboratively with design and engineering (and others). These people are ‘navigators’.
Hers's a tactic I use when Stakeholders come with solutions, NOT problems.
Don't work backwards, work forward.
What do I mean by that?
Commonly when a stakeholder comes w/ a solution we try to get them to work backwards to the problem.
But for some this is a stretch.
We hit a wall, there's resistance. The Stakeholder can't understand why they need to give a problem, when they have this amazing solution idea (after all it's an awesome idea, right?)
So instead of trying to work against their thinking, go with it.
Look forward not backwards.
Ask: "If we did deliver this solution, what does it mean?"
...what does it mean for us, the org, our users?
Rather than trying to get them to articulate the problem, get them to think about what would be true if we did deliver their solution.
“What’s the difference between a Product Designer and Product Manager?”
“There seems to be a lot of overlap between Design and Product Management? Who does what?”
All valid questions but they all have one problem.
They are coming from an individual perspective, not a team one.
When we seek clear role separation and individual accountabilities we discourage collaboration and form gaps.
Gaps where context, knowledge and information is lost.
To plug these gaps we often create admin and coordination roles “to manage the work”