Stakeholder Management

I’m not sure why I haven’t written specifically on this topic before because it comes up as an issue with so many teams.  For many product managers, managing stakeholders is probably the least favorite part of their job.

I don’t want to suggest that this can always be easy, but it can usually be substantially improved.

First let’s discuss just who is a stakeholder, then what the product manager’s responsibilities are with these stakeholders, and then we’ll talk about techniques for success.

STAKEHOLDER DEFINED

In most companies, just about anyone and everyone feels like they have a say in the products.

Certainly they care about the product, and they often have many ideas, either derived from their own use, or from what they hear from customers.  But the vast majority of them we would not consider stakeholders.  They are just part of the community at large; another source of input on the product, alongside many others.

The main test of whether a person is a stakeholder is whether or not they have veto power, or can otherwise prevent your work from launching.  Specifically, each stakeholder represents some core part of the business.

Typically this includes the executive team (CEO and leaders of marketing, sales, and technology), but often others such as finance (to make sure the product fits within the financial parameters and model of the company), sales and marketing (representing your go-to-market channels), legal (to make sure that what you propose is defensible), compliance (to make sure what you propose complies with any relevant standards or policies), and business development (to make sure what you propose does not violate any existing contracts or relationships).  There can be even more, but you get the idea.

In a startup there are very few stakeholders other than the founders because the company is very small and frankly there’s not a lot of assets at risk.  But in large companies, there are quite a few people there to protect the substantial assets of the company.

PRODUCT MANAGER RESPONSIBILITIES

In terms of 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 confidence in the product team.

However, even 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.

STRATEGIES FOR SUCCESS

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 they are very different from what they may have originally envisioned.

It really is not that difficult to have this 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 your business.

Without this, they won’t trust you (and 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 main technique is to actually 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.

Next, one of the most common mistakes product managers make with stakeholders is that they show them their solution after they have already built it.  Many times 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 Continuous Product Discovery.  In the discovery work, 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 solutions are viable – the stakeholders can support the solution.

The other big mistake I see made is that things essentially boil down to the product manager’s opinion vs. the stakeholder’s opinion.  In this case, it is all too often the stakeholder that wins because they are usually more senior.  However, as we’ve discussed many times, 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 3-4 hours a week to meet for half an hour or so with each 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.

Notice the very intentional lack of big stakeholder group meetings.  We try hard to avoid those.  Much better to meet privately and give the stakeholder the chance to provide feedback, and give you a chance to address any issues.

It may sound like meeting individually would require more meetings, but usually the opposite is true because of all the swirl that results when these groups get together.  All too easy for them to turn the group meeting into either a design by committee session, or a steering committee.

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.