Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

Audio Version ($)

Everyone I talk to is rushing to add AI features to their roadmap. And every stakeholder has an opinion about what they should be building.

The challenge is we are forgetting our discovery fundamentals. We are reverting back to a feature factory. Delivery is getting faster and easier, so it feels like we can just ship.

But all we are doing is shipping the wrong stuff faster.

To help course correct, product teams need to recommit to the discovery habits. We need to find the right customer problems to solve. We need to use assumption tests to evaluate if AI can actually solve those problems.

But let's be clear. This is only possible if we can convince our stakeholders that their favorite idea may not be right.

Getting to a good AI prototype is deceptively simple. But getting to a high-quality production release is much harder. This means every idea seems like a good idea to start. Even if it's not.

Stakeholder management—the work of building alignment with the people who influence your product decisions—has always been one of the hardest parts of being on a product team. But the current moment has raised the stakes.

When stakeholders arrive with solutions instead of problems, and an entire industry is validating their urgency, the usual advice falls short. Communicate regularly, build relationships, manage up. That all works, but it's rarely enough.

Product teams need to double down on showing their work. We need to bring our stakeholders along every step of the discovery journey. We need to expose the gaps between the impressive prototype and the production version that isn't quite ready.

That's why today, we are going to do a deep dive on stakeholder management. You'll learn how to show your work, bring your stakeholders along, and get buy-in every step of the way.

Start By Identifying the Stakeholders Who Have the Most Influence

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

Let's start with the basics. In a product context, your stakeholders are anyone who has influence over—or is affected by—your product decisions. That typically includes executives, sales, marketing, customer success, engineering leadership, and sometimes legal or finance.

Not all stakeholders are equal. Some have veto power—they can actually block your work. Others have input—they can influence the conversation but can't stop you. It's worth knowing the difference, because it affects how much energy you invest in each relationship.

One of the benefits of working in a product trio—typically a product manager, a designer, and an engineer—is we can move fast to discover what our customers need. But it's important to realize that even though your stakeholders aren't part of the trio, they absolutely need to be brought along. Otherwise, even your best discovery work can get derailed the moment you present your conclusions.

You'll find no shortage of frameworks for mapping and categorizing your stakeholders—power-interest grids, RACI matrices, and so on. Those can be useful. But in my experience, the real challenge isn't figuring out who your stakeholders are. It's figuring out how to bring them along. That's what the rest of this article is about.

Avoid the Most Common Stakeholder Management Trap

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

When product teams prepare for a stakeholder meeting, they tend to focus on their conclusions—the roadmap, the release plan, the prioritized backlog. And more often than not, this is exactly what stakeholders are asking for.

The problem is that your stakeholders have their own conclusions. It's easy to have an opinion about what to build. We all have preferences about how a product should work. When you anchor the conversation in the solution space—"here's what we think we should build"—you're inviting stakeholders to compare their preferences to yours. And their preferences aren't always grounded in good discovery.

This is how the HiPPO dynamic gets created. HiPPO stands for the "Highest Paid Person's Opinion," and the saying goes, "The HiPPO always wins." Product teams complain about this constantly. But what they often miss is the role they play in creating the situation.

When you present your conclusions, you're not sharing the journey you took to reach those conclusions. You're inviting an opinion battle—a battle you have no chance of winning.

The AI moment makes this even harder. In a normal opinion battle, a stakeholder has a hunch. In the AI moment, they have an entire industry backing up that hunch. "Everyone is doing AI" is a powerful argument—and no amount of product team opinion can counter it. If your response to "we need an AI feature" is "we don't think we should build an AI feature," you've already lost.

So what do you do instead? You bring new information.

This is the only real lever a product team has when managing stakeholders who are more senior. You can't win opinion battles. But you can bring information your stakeholders don't have—insights from customer interviews, data from assumption tests, patterns in the opportunity space that they haven't seen. Good discovery work generates exactly this kind of information.

And in the current moment, that information is more valuable than ever, because the gap between what the industry is hyping and what customers actually need is often enormous.

The question is: How do you share that information effectively? That's where most teams stumble.

(For a deeper dive on why opinion battles fail and the "bring new information" reframe, see The Art of Managing Stakeholders Through Product Discovery.)

A Better Stakeholder Management Strategy: Show Your Work

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

Here's the approach I teach. Instead of presenting your conclusions, slow down and show your work.

If you've been doing continuous discovery, you've been using an opportunity solution tree to chart the best path to your desired outcome. That same visual is your most powerful stakeholder management tool. It helped you and your team build confidence in your decisions. It will do the same for your stakeholders.

Here's how to walk through it:

Start with the outcome.

Remind your stakeholder what the shared goal is. Ask if anything has changed since you last agreed on this outcome. This sets the scope for the conversation and prevents it from drifting into unrelated territory.

This matters more than you might think. When a stakeholder walks in with "we need an AI feature," starting with the outcome reframes the conversation. It's not about whether to build AI. It's about what will drive the outcome you've agreed to pursue. Starting with the outcome creates stakeholder alignment before you even get to solutions.

Show how you mapped out customer needs, pain points, and desires. Highlight the top-level opportunities. Don't drill into detail unless they ask for it.

Here's the critical move: Ask your stakeholders if you missed anything. They often have knowledge of opportunities you don't. Maybe they've heard something from a customer, or they have context on a market shift you haven't seen. Capture their suggestions. You can always vet them in your future customer interviews. This one question transforms the dynamic. You're no longer presenting to your stakeholders—you're inviting them to contribute.

Walk through your prioritization.

Use the tree structure to show each decision you made and why. Ask your stakeholders if they would have made a different decision at each decision point. Consider their feedback. This is where you leverage their expertise instead of fighting it.

Help your stakeholders fully understand the customer need or pain point you're addressing. Use interview snapshots—one-page visual summaries of what you learned from individual customer interviews—to help them empathize with your customers.

This step is critical. Your stakeholder needs to fully understand the problem before they evaluate your solution. When the problem is vivid and real, the conversation shifts from preferences and opinions to what will actually address the customer's need.

Show the solutions you generated. Ask stakeholders if they have ideas of their own. If their ideas add diversity to your solution set, swap them in. Remember: Solution ideas are cheap. The opportunity is what matters.

Stay open-minded here. Your stakeholders can often help you generate more diverse ideas than your team can on its own. Don't be afraid to include their suggestions in your consideration set.

If you've started testing assumptions, share your story maps, your assumption lists, and your results. Ask stakeholders to add to your assumption lists. This is where their unique knowledge and expertise can be invaluable—they'll often catch blind spots your team missed.

If you have data, share the data. If you don't yet, share your testing plan. Either way, ask for feedback. Consider and integrate what you hear.

Then repeat.

This isn't a one-time event. A good product trio continuously manages stakeholders. Share your work along the way, not all at the end. Some stakeholders will want all the details week over week. Others will want the highlights monthly. Adapt to what each stakeholder needs.

This kind of stakeholder engagement—where you invite contribution, not just attention—is fundamentally different from what most teams practice. You're not selling your conclusions. You're inviting your stakeholders to co-create with you. Instead of sharing your preferences and inviting them to share theirs, you're sharing your thinking and inviting them to improve it. You're leveraging their expertise. And that leads to much more stakeholder buy-in and long-term success.

(For specific tactics on using OSTs with stakeholders, see Engaging Stakeholders with Opportunity Solution Trees: 3 Tactics to Try. And if you want to see a companion talk on this topic, check out Show Your Work: How to Justify Your Decisions & Get Stakeholder Buy-In.)

Tailor Your Stakeholder Communication to Each Audience

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

Showing your work doesn't mean overwhelming people with every last detail. If you're interviewing customers and running several assumption tests every week, everything you're learning will quickly overwhelm a busy stakeholder.

You need to act as a smart filter. Tailor the detail and context to the specific stakeholder you're talking to.

Your direct manager might enjoy the full discovery journey and want week-over-week updates. Your marketing counterpart probably doesn't need that much—monthly highlights might be enough. Your CEO almost certainly needs less.

But less detail doesn't mean you stop showing your work. Even in a 30-second elevator conversation with your CEO, you can walk the lines of the tree. It sounds something like this:

"Our goal is to reduce time-to-first-value for new users. We've been interviewing customers and learned that onboarding is where most people get stuck—specifically, they don't know which features to try first. We explored a few approaches and tested them. The most promising one is a guided setup flow that adapts based on the user's role. In early tests, new users completed onboarding 40% faster."

That's outcome, opportunity, solution, evidence—in four sentences. Your CEO doesn't need to know about the dozen other opportunities you explored or the three solutions you ruled out. They need to know that you're finding solutions customers love that drive the outcome they care about.

This principle applies to every form of stakeholder communication—whether it's a weekly Slack update, a monthly review, or a quarterly planning session. The format changes, but the structure stays the same: outcome, opportunity, solution, evidence. Walk the lines of the tree, and adjust the level of detail for your audience.

(For a deeper dive on tailoring stakeholder communication by role—engineering, sales, marketing, customer success, and leadership—see Product in Practice: Finding the Best Way to Communicate with Different Stakeholders.)

Four Anti-Patterns That Destroy Stakeholder Trust

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

As you put this into practice, watch out for these common mistakes.

Telling instead of showing

We're proud of our work. We're excited about our conclusions. We love our ideas—so of course our stakeholders will love them, too. We rush into telling stakeholders everything we've learned instead of showing them so they can draw their own conclusions.

There's a cognitive bias at play here. It's called the curse of knowledge. Once you know something, it's hard to remember what it was like not to know it. Your conclusions—your roadmap, your backlog, your release plan—start to feel obvious. But they're not obvious to your stakeholders. And your stakeholders very likely have their own conclusions that feel obvious to them.

The fix: Slow down. Start at the beginning. Walk through what you learned and what decisions you made. Give your stakeholders space to follow your logic. Give them time to reach the same conclusion.

Shooting down stakeholder ideas

As you do more assumption testing, you build up a library of building blocks. You start to know which assumptions hold up and which don't. When a stakeholder suggests an idea, you can quickly see the flawed assumptions it's built on.

But shooting down that idea is the fastest way to lose their trust. Nobody likes the know-it-all.

Instead, help the stakeholder see where their idea fits in your discovery framework. If it addresses a different opportunity, say, "That idea has promise—we'll consider it when we address that opportunity."

If it's based on a faulty assumption, don't just call that out. Story map their idea together. Generate assumptions together. When your stakeholder sees what assumptions their idea rests on—and you can share what you've already learned about those assumptions—they'll reach their own conclusions.

This is far more effective than telling someone why they're wrong. (For more on this technique, see What Do You Do With Stakeholder Feature Requests?)

Saving everything for a big reveal

Teams that batch their stakeholder communication into infrequent, comprehensive updates are setting themselves up for opinion battles. By the time you present, your stakeholders have been in the dark for weeks or months. They've developed their own conclusions in the meantime. And now you're walking into exactly the dynamic we talked about earlier—your conclusions versus theirs.

Short, frequent updates beat long, infrequent ones. Show your work continuously. Bring stakeholders along as the work unfolds, not after it's done.

Fighting the ideological war

No matter how strong your discovery process is, there will be times when a stakeholder overrules you. If they're more senior in the hierarchy, that's their prerogative.

What you can control is how you respond. Resist the urge to turn the conversation into a debate about how product decisions should be made. If you ever catch yourself saying, "This is the way it's supposed to be done," take a deep breath and walk away.

This is especially tempting in the AI moment. When a stakeholder says, "Just build the AI feature," it's easy to turn it into a debate about discovery versus feature-factory thinking. Don't. You won't win the ideological battle in one conversation.

Instead, focus on the decision at hand. Do the best work you can given the constraints. Choose your battles. Show the benefit of discovery through results, not arguments. Over time, results are far more persuasive than ideology.

Stakeholder Management Is a Co-Creation Opportunity

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

Most stakeholder management advice frames the problem as a communication challenge: Communicate more clearly. Communicate more often. Build better relationships.

That's not wrong, but it misses the deeper opportunity. When you show your work—using visual artifacts like opportunity solution trees, experience maps, and interview snapshots—you're not just communicating. You're inviting stakeholders to co-create with you. You're presenting potential paths and asking them to help you choose the right one. You're leveraging their expertise, their context, and their connections to make better product decisions.

This transforms the relationship. Stakeholders stop being obstacles you need to manage and start being partners in the process. And when they've been part of the journey, they don't need to be sold on the destination.

Stakeholder engagement doesn't have to mean status updates and slide decks. It can mean genuine collaboration—the kind where everyone's expertise makes the product better.

The next time you have a stakeholder meeting, try this: Don't start with your conclusions. Start at the top of your opportunity solution tree. Walk them through the outcome, the opportunities, your prioritization, and what you're learning. Invite them to contribute. See what happens.

You might be surprised at how much easier managing stakeholders becomes when you stop trying to sell them your ideas and start showing them your work.

Audio Version

The audio version is only available for paid subscribers.

Stakeholder Management for Product Teams: Show Your Work, Don't Sell Your Conclusions

Comments