Stakeholder Management for Product Managers

Why stakeholder management goes wrong at the feature request

Years ago, when I was first a VP of Product, I reported to a CEO who was a charismatic ideas guy. He came into my office almost every morning with a new one, before I had finished my coffee. About a year in, he stopped mid-idea and said, "Brennan. Are you listening to me?" I was half listening. The other half of me was asking what would come off the roadmap, and whether to push back or just take it.

I saw two options, and I tried both. When I pushed back I sounded defensive, and I lost trust, because getting things done fast was what he relied on me for. When I gave in, my product teams asked me to stop the roadmap whiplash, since we were only getting to version 0.5 of a feature before the next idea arrived. A stakeholder who always gets a yes ends up resenting it too, because they start asking why they have to keep coming up with the next thing to build. Pushing back costs you trust and giving in costs you credibility, and neither one gets you the context you need to make a good decision.

Stakeholder Judo starts before the conversation

Judo is a martial art where you use the other person's energy instead of blocking it. A stakeholder who brings you an idea is bringing energy. Sometimes the reason is their own greed (a salesperson who wants to close a deal). That's okay. Your job is to keep that energy going and still get the context.

The first step happens before anyone walks in. You need a Product Metrics Ladder for what is already on your roadmap, so that every feature connects to a metric it should move, the customer outcome behind that metric, and the business result we get from it. Without the ladder you have nothing to stand on. A roadmap that is only feature, feature, feature gives you no way to show why their idea matters less than the one already there.

Then, when the request arrives, choose sincere curiosity. I can't teach curiosity, but you can decide that you are a curious person. You still need the standard product management answers, but DO NOT ask the standard questions. Every stakeholder has heard "What problem are you really trying to solve?" and it feels like an intake form they have to pass before you let them into the backlog. Ask the way you would ask a friend about an idea:

• That's awesome, tell me more. Where did this come from?
• Can you give me a real name of somebody, so I can picture them?
• What's broken for them right now, and what are they missing out on?
• Does that happen daily, weekly, monthly?
• What do they have to do instead today, and how long does that take them?
• Where else have you seen this?
• If we helped all of them, what do you think happens for us next?

Those questions get you the persona, the current baseline, the frequency, the size of the pain, how many other people have it, and what our business gets if we fix it. And do not tell them it is a good idea. You don't know that yet.

The Reframe Madlib

When you have the answers, ask, "Can I summarize what I'm hearing to make sure that I've got it?" They will always say yes. Then say it back in this format:

Only one blank in the Reframe Madlib is about their solution, and I have generalized that one. If they came in asking for a chatbot for support, the blank becomes "if we could get support answers to customers much faster." Everything else in the summary is a problem statement, which detaches them from the pride of authorship in their own idea. They will also correct what you got wrong, which is more context for you.

Then I do the thing that sounds crazy when the roadmap is already full. I ask for more ideas. "I bet there is even more we could do to help that persona with this kind of problem. What else can we think of?" Adding ideas dilutes their attachment to the one charged idea they walked in with, and it puts the two of you on the same side of the table. Thank them for the problem. Stay away from the words "your idea" after that, because they send the person right back to defending it.

The comparison that says "not yet" for you

The worst thing you can do is let the stakeholder leave your office thinking you are just going to build it. So finish the conversation. Pull up the ladder and ask, "Where do you think this fits with the goals we have right now?"

Sometimes it fits. On a regulatory research product I worked on at PwC, one success metric was getting new regulations into the product within 24 hours. The roadmap plan was to hire 10 content experts to do that by hand. A stakeholder's idea to scrape the regulator websites automatically pointed at the same metric. So we could compare the two on ROI, and ask what would happen if we hired two experts and spent the savings on the scraper.

Sometimes it does not fit, and they will see that themselves. Then the goals have said "not yet" for you, and the stakeholder walks out knowing why it is later. Before you file it there, ask whether you missed something. I used to assume nobody had better ideas than mine, because I had done the most research. But my CEO was talking to presidents of health plans while I was talking to users.

What the person is protecting

Some stakeholders hear every question as a challenge, so it helps to know what is driving the person before you ask anything. I use a test for that, which is to ask what would get them fired. A tech leader worries about the system going down, and a sales leader worries about missing quota. You can usually hear it in what they repeat in meetings. Then you speak to the positive side of that fear, in the metric that person already cares about. (The boss's boss version of the question is in my letter on hidden incentives, and there is another on how to talk to executives.)

For the proactive half of the job, have the meeting before the meeting, a one-on-one ahead of the group, so people are already on board when you walk in. Keep a 60-second Cafe Update ready for when someone at the coffee machine asks what you are working on. Both belong to influence without authority.

What I hold myself to when I use this

I call the summary a trick when I teach it, because it steers the conversation toward the problem without announcing that. You might read this whole page as manipulation, so here is what I hold myself to. The stakeholder gives me more context because they think I want to hear more, which I do. I do not praise an idea I have not evaluated. When I flatter someone, it is for representing a customer and bringing me a problem worth solving, never for how creative the idea is. I treat the first idea someone brings me as a clue to a mystery that is probably bigger than what I was told.

This week, when the next feature request lands on you, do not answer it. Ask where it came from, get one real name, and say the summary back out loud once. You will probably stumble the first time, because you are tracking which blanks you still need while trying to stay in the conversation. Do it again next time.