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.
Want to know more?
If you learn better with video rather than reading, you may want to check out Analysis Techniques for Product Owners Live Lessons, a set of video training sessions that show you how to apply analysis techniques to product ownership. Lesson 2 focuses on understanding stakeholders.
Analysis Techniques for Product Owners is available on Safari – O’Reilly’s online learning platform. Sign up for a 10-day free trial to view the video lessons.
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.
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.