What Everyone Gets Wrong About Stakeholders

When I first started in Product Management, I was told that my job was to keep my stakeholders happy. My stakeholders were members of the sales team. I understand that many Product Managers are taught better today that stakeholders include customers and users, but I was taught the term was reserved for internal folks who had a say in our product. Customers and users were considered separately, and handled differently. So for the purposes of this article, I'm just talking about the internal stakeholders of your company.

Part of my job was "managing" these stakeholders. I kept them informed of our progress. I took their requests and figure out when we could get them done. I got their approval before we launched anything. While we listened to our customers as well, they were not dropping by my desk every day asking for things. Stakeholders were seen as a conduit for the customer, expressing what was best for them. And my job was to keep these people happy.

For years this continued, and for years, this is how the stakeholders were told Product Management worked. We were the people that built things for them. Needed a feature to do you job? Go talk to the Product Manager. Request from a customer? Go talk to a Product Manager. A Product Manager could be seen in either two lights: the person who could save the day, or the evil person who said no.

And Product Managers saw Stakeholders in one light: pains in the asses who destroyed their products.

"My stakeholder is killing me..." - every Product Manager

Stakeholder management is one of the hottest topics from Product Managers going through training. I get asked questions about this on a daily basis:

• "How do I manage a difficult stakeholder?"
• "I have 14 stakeholders, how do I prioritize their needs?"
• "I can't build what's best because my stakeholders keep requesting solutions instead of telling me their problems."

I wrote a post earlier about Product Managers not empathizing with their stakeholders, but I realize that concept doesn't really capture the whole picture. 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.

Product Managers view stakeholders as gatekeepers for launching products. They design for consensus to satisfy this large group of internal people, and get approval to create and ship the product. This stems from the way budgeting was done in the past. Many budgets were tied to marketing or sales budgets in these company, and Product Managers had to ask these people for investment. Most companies, not all, have solved this budgeting problem, but we have not solved the relationship problem between these two groups.

Designing for consensus of internal people who do not use or buy the products just creates terrible products. If Product Managers are responsible and accountable for the outcomes of their products, they and their development team (including designers) need to have the authority to say what should be built. Stakeholders are responsible for informing the decisions the Product Managers make, but they should not be the ones making those decisions.

So what really is a stakeholder today? A stakeholder is someone who will be involved or impacted in the creation of your product. Inside the company, this could be another team that has a dependency on your product and code. It could be a marketing person who needs to create materials to announce your product for customers.

Stakeholders have specific influence and knowledge that can help your product. Remember where that help starts and ends. Marketing cannot accurately determine the features of the product, but they can tell you how to best present it to customers. Sales can inform you about how easy or hard it is to sell products to certain customers, and what people are asking for in meetings. They cannot tell you if a particular design or workflow can delight a user. Only testing and validation can tell you that.

To work with stakeholders effectively, you must remember this relationship. Don't fault them for speaking in solutions - this is human nature. It's your job to get into the root cause. Dig into the problems they are trying to solve, understand how they made the decision that this particular feature was important, and pull out the information you need. At the end of the day, you can make the decision and validate whether that feature idea is the right idea.

Your business will only succeed if your customers and users are satisfied. We need to build and design products for them, not to make internal teammates happy. This is a scary concept because coworkers have the ability to make your life a little more miserable, but it is the right thing to do to create a successful product.