Stakeholders are problematic.
Ok, perhaps I should say that differently. The concept of a stakeholder is problematic.
(Although I know some of you immediately thought “you said it!” and had a particular person in mind.)
Technically, a stakeholder is anyone who impacts or is impacted by an organization’s actions, product, or product. By that definition, customers, users, and anyone inside your organization with an interest in your product is classified as a stakeholder.
That definition of stakeholder isn’t very helpful if you’re trying to differentiate between customers, users, and those internal folks who have an interest in your product.
Since those internal folks who have an interest in your product can quickly become cumbersome I apply the term stakeholders to that group specifically.
Stakeholders play a big part in internal products. If you’re not careful, you can easily confuse them for customers. As I mentioned in The difference between customers, users, and stakeholders, you don’t want to do that.
The road to bloated internal products is paved (with gold plating) by features added to appease stakeholders, but do nothing for your organization’s real customers.
It’s easy to do. Stakeholders may control access to the users because the users work for the stakeholders.
Or the stakeholders are the users.
It can be very tempting to ask them what they want and just deliver that. It can be very tempting to look at your stakeholders as “internal customers.”
Except that isn’t necessarily going to result in something that’s good for your real customers – the people who give your organization money in exchange for some product or service.
You can’t ignore your stakeholders and you can’t focus solely on them either. When your product is used by both stakeholders and customers, the customers needs should trump those of your stakeholders.
Make things seamless for your customers, even if in the short term they may be a little clunky for your stakeholders.
But don’t make it painful for your stakeholders. Remember you want to have a product that your users don’t dread using.
Here are some techniques that I’ve found helpful for working with stakeholders, as well as a couple of other perspectives on how to treat stakeholders appropriately, and not as internal customers.
The stakeholder map is a technique commonly used for stakeholder analysis. Using the stakeholder map to guide conversations helps a team understand who the stakeholders for the project are, understand key characteristics about those stakeholders, and identify plans for engaging the stakeholders on an ongoing basis.
Primary outcomes from a stakeholder map include
- A comprehensive list of the stakeholders involved with the project
- An understanding of how to interact with those stakeholders
The commitment scale is a stakeholder analysis technique. This technique gauges the current level of stakeholder commitment to a project, as well as what level of commitment is needed to ensure the project’s success.
What everybody gets wrong about stakeholders
It’s very important to empathize and understand your coworkers, but the problem with the relationship between stakeholders and Product Managers runs a lot deeper. It starts with an murky view of what the job responsibilities are of the two and how they should work together. Melissa Perri talks about the importance of understanding your relationship with your stakeholders in order to effectively deliver your product.
Optimizing Internal Communications
A lot of your time as a product person is spent communicating with other people in your organization. There’s high-level communication and discussion, and there’s low-level interaction with stakeholders about the day-to-day of the product’s development and operation. If you stop to think a little bit about your internal communication strategy you can be both more effective in getting the message through, and reduce the amount of time you spend on this.
Product Discovery in Regulated Environments
Marty Cagan explored the special case of running discovery at companies in highly regulated industries (and more broadly, companies with very strong internal governance policies) like financial services and healthcare. These industries have strong consumer and patient protection laws. The laws impact the products that can be put into the market, but they might also affect the discovery process itself. As a result, companies in these industries often have complex approval processes just to run a single experiment.
It’s in these situations where stakeholders, sometimes ones you don’t expect can have a big impact.
Thanks again for subscribing to Inside Product Management.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.
Talk to you next week,
Kent J. McDonald