For many product managers, managing stakeholders is probably the least favorite part of their job. I don't want to suggest that this will always be easy, but it can usually be substantially improved.
First, let's consider just who is a stakeholder, then what the product manager's responsibilities are with these stakeholders. After that, we'll talk about techniques for success.
In many product companies, just about anyone and everyone feels like they have a say in the products. They certainly care about the product, and they often have many ideas—either derived from their own use, or from what they hear from customers. But, regardless of what they think, we would not consider most of them to be stakeholders. They are just part of the community at large—another source of input on the product, along with many others.
One practical test of whether a person is considered a stakeholder is whether or not they have veto power, or can otherwise prevent your work from launching.
This group of people typically includes:
There can be others, but you get the idea.
In a startup, there are few stakeholders because the company is very small, and frankly, there's not a lot to lose. But in large companies, quite a few people are there to protect the substantial assets of the company.
In terms of the stakeholders, the product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team. It doesn't do anyone any good to build things that may work for the customer, but then at some review meeting find out that you're not allowed to deploy what was created. This happens much more than you might realize, and every time it does happen, the company loses a little more confidence in the product team.
The product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.
However, beyond understanding the constraints and concerns of each stakeholder, if you want the latitude to come up with the most‐effective solutions, then it's critically important that the product manager convince each of these stakeholders that she not only understands the issues, but that she is committed to coming up with solutions that not only work for the customer, but also work for the stakeholder as well. And this must be sincere. I emphasize this because, if the stakeholder does not have this trust that you are going to solve for their concerns as well, then they will either escalate, or they will try to control.
Success in terms of stakeholder management means that your stakeholders respect you and your contribution. They trust that you understand their concerns and will ensure solutions work well for them too. They trust that you will keep them informed of important decisions or changes. And, most of all, they give you the room to come up with the best solutions possible, even when those solutions end up being quite different from what they might have originally envisioned.
It's not that difficult to have this kind of relationship with stakeholders, but it does require first and foremost that you are a competent product manager. This especially means having a deep understanding of your customers, the analytics, the technology, your industry, and in particular, your business.
Without this, they won't trust you (and in fairness they shouldn't). The main way we demonstrate this knowledge to the organization is by sharing very openly what we learn.
With this as a foundation, the key technique is to spend one‐on‐one time with the key stakeholders. Sit down with them and listen. Explain that the better you understand their constraints, the better your solutions will be. Ask lots of questions. Be open and transparent.
One of the most common mistakes product managers make with stakeholders is that they show them their solution after they have already built it. And, sometimes, there are issues because the product manager did not have a clear enough understanding of the constraints. Not only will the stakeholder be frustrated, but your engineering team will be frustrated as well with all the rework. So, commit to previewing your solutions during discovery with the key stakeholders before you put this work on the product backlog.
This is one of the keys of product discovery. In discovery, you are not only making sure that your solutions are valuable and usable (with customers), and feasible (with engineers), but you are also making sure your stakeholders will support the proposed solution.
The other big mistake I often see being made is when situations boil down to the product manager's opinion versus the stakeholder's opinion. In this case, the stakeholder usually wins because he or she is usually more senior. However, as we've already discussed many times before, the key is to change the game by quickly running a test and collecting some evidence. Move the discussion from opinions to data. Share what you're learning very openly. It may be that neither of your opinions were right. Again, the discovery work is designed specifically as a place for these tests.
Mostly this is about creating a collaborative, mutually respectful personal relationship. For most companies, it takes about two to three hours a week—meeting for half an hour or so with each key stakeholder—to keep them apprised, and to get their feedback on new ideas. My favorite way to do this is a weekly lunch or coffee with your most‐involved stakeholders.
Many product managers tell me that the way they deal with testing business viability with all their different stakeholders is by scheduling a large, group meeting and inviting all the stakeholders. The product manager then presents to them what they want to build, usually with a PowerPoint presentation.
There are two very serious (potentially career limiting) problems with this.
First, presentations are notoriously terrible for testing business viability. The reason is that they are far too ambiguous. A lawyer needs to see the actual proposed screens, pages, and wording. A marketing leader wants to see the actual product design. A security leader needs to see exactly what the product is trying to do. Presentations are terrible for this.
In contrast, high‐fidelity user prototypes are ideal for this. I plead with product managers in larger companies to not trust a sign‐off on anything other than a high‐fidelity prototype. I have seen far too many times where the execs agree to something based on a presentation, but when they see the actual product, they are completely shocked, frustrated, and often visibly angry.
The second problem is that a group setting is not the forum for designing strong products. It results in design by committee, which yields mediocre results at best. Instead, meet privately with each stakeholder, show them the high‐fidelity prototype, and give them the chance to raise any concerns.
This may sound like more work to you, but please believe me that, in the long run, it will turn out to be far less work, time, and grief.
One final note: in many companies, some of the stakeholders may not even understand what product does, and some may even feel threatened by the role. Be sensitive to this. You may need to spend some time explaining the role and how technology‐enabled product companies operate and why.
Lots of people have written about the challenges of managing growth, and especially about the importance of working hard to maintain staff quality as you scale the organization.
There is little question that most organizations become worse in their ability to rapidly deliver consistent innovation as they grow, yet most people attribute this to staff quality, process, and communication issues of scale. Some believe that this is unavoidable.
There's an anti‐pattern I see in many companies that are doing very well, growing aggressively, yet they will sometimes—over time and unintentionally—replace their good behaviors with bad ones.
I have never seen this anti‐pattern written about before, and I suspect it's going to make more than a few people uncomfortable. But it's a serious issue that I think needs to be out in the open, as it's not hard to prevent if you're aware.
The scenario is that you are probably a later‐stage startup or growth‐stage company. You've probably achieved product/market fit, at least for an initial product, and to have accomplished that, you've probably done some important things right. But then you get some substantial funding, or a board member strongly suggests that you need to bring on some “adult supervision” or some experienced people from brand‐name companies.
Here's the thing. The new people you hire are often from those large, brand‐name companies that have stopped growing, have long since lost their ability to innovate, and have been living off their brand for many years. Because of this, they're not on the trajectory they once were, and people leave.
Would you rather hire all your staff and leaders from Google, Facebook, Amazon, and Netflix? Sure you would, but these people are in very short supply and there is lots of strong talent at other companies.
There is little question that most organizations become worse in their ability to rapidly deliver consistent innovation as they grow, yet most people attribute this to staff quality, process, and communication issues of scale.
But, let's say you are at a young, growth‐stage company, and you decide to hire a senior leader—maybe the head of product, or the head of engineering, or the head of marketing—from a brand name like Oracle. Your board will probably like that. The issue is that, unless you make this clear at the outset, that new leader may assume you're hiring them for their knowledge of process and how to define and deliver products. And, so they bring with them their views on how things should work. Even worse, they often then proceed to hire people that want to work in those ways.
Note that I'm picking on Oracle here as an example, but they are certainly not the only one. There are a great many very strong people to hire from Oracle as they love to acquire companies, often very good companies, but those strong product, design, and technology people they also acquired rarely like Oracle's culture or ways of creating product.
I have seen this anti‐pattern play out at every level of a company—from individual engineers all the way to CEO. It doesn't happen overnight; it happens over years. But I've seen it enough to be convinced it's an anti‐pattern. Many people intuitively sense this problem but they usually just attribute it to a “big company person,” but this is less about being from a big company and more about being from a company that's not strong at product.
I know of two ways to prevent this problem from infecting your company:
The first is to have a very strong and very intentional product culture, and to have that culture very well established so that new hires know they're joining a different type of company that takes pride in how they work and in using best practices. When you join Netflix, or Airbnb, or Facebook, it's something you figure out in your first days, and that's their intention.
The second way of preventing this is to make this explicit in the interview and onboarding process. As part of my advisory work, I'm often on the interview team for senior positions, and when the person is coming from one of these types of companies, I'm up front with the prospective hire. We'll talk about the reasons why their former company has not produced successful new products in many years, and I'll emphasize to them that the new company is interested in them because of their mind and their talents, and of course they wouldn't want to bring with them the bad practices of their former company.
In my experience, people are really good about this when you talk openly and honestly about it. In fact, people often tell me it's a major reason why they want to leave their former company. It's more about getting this to be something you and they are very aware of.