View profile

Some thoughts on how to keep stakeholders in the problem space instead of the solution space - Adam's Product Management Newsletter - Issue #12

This is a challenge I’ve been facing recently and I wanted to write down my thoughts on how I’ve appr
Some thoughts on how to keep stakeholders in the problem space instead of the solution space - Adam's Product Management Newsletter - Issue #12
By Adam Wintle • Issue #12 • View online
This is a challenge I’ve been facing recently and I wanted to write down my thoughts on how I’ve approached and overcome these types of problems as a product manager. 

This is a challenge I’ve been facing recently and I wanted to write down my thoughts on how I’ve approached and overcome these types of problems as a product manager. 
First of all let’s quickly define what is a stakeholder and what’s not. 
Essentially anyone who is not in the working team, or if you’re using Scrum, people who a NOT part of the Scrum team, are product stakeholders. They have a vested interest in the product, but they don’t directly work on the product day-to-day. 
This could be people from different business units (e.g. the sales team, or the marketing team), this could be investors, or even your boss who doesn’t work directly on this product everyday. 
Also its important to remember your users and customers are stakeholders too. 
When meeting and working with stakeholders its important to keep them in the problem space as much as possible. 
The problem space (or sometimes referred to as the problem domain); is where some kind of pain point is being experienced. This problem could be in the business side or on the user’s experience side of the product. When working in this space your objective is to understand and explore the problem from as many different perspectives as possible. 
Some examples of things that are in the problem space for business stakeholders: A particular metric a stakeholder cares about is on decline. A certain market isn’t being leveraged enough. A feature is too being underutilized.
There is no product which exists in the problem space, which means no specific solutions exist yet either; everything is an open book and all options are on the table. When discussing ideas in this space you want to foster an atmosphere of creativity and understanding. 
Essentially you want to frame this as “you tell me your problems and we’ll figure out how to fix them”. 
If you happen to find a stakeholder jumping into the solution space, it can cause all sorts of problems and headaches. 
The solution space is where the problem is looked at from all points-of-view, and a representation of what the product may look like with the problem solved starts to take shape. When working in the solution space you’re defining how the product will look, what it does and how it will work. 
If a stakeholder ventures into the solution space, gently nudge them back into the problem space. Usually I find stakeholders only think about the problem from their own perspective and don’t take a holistic view of the product into account. This can result in features for one customer, or features for a very limited use case. Or features which haven’t been fully explored and validated. 
The key to keeping stakeholders in the problem space is the word “what” and “why”. What is the problem you’re facing today? Why do you want this feature? What is your goal with this? What do you want to achieve? What are the key tasks that you need to complete? 
I can probably think of more to write about this, but I think that’s enough for now. If you’re interested in this let me know. 
Cheers, 
Adam

P.S. here’s some links related to this:
Did you enjoy this issue?
Adam Wintle

People & Product Newsletter Archive.

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Made in Bangkok 🙏🏻