Blog

Posted on

The Stakeholder Management Mistake Most Product Leaders Make in Year One

Six months into a new VP of Product role, I had a healthy roadmap, a strong team, and a growing list of stakeholders who were convinced I didn’t understand the business. The product was moving. The stakeholders weren’t moving with it.

I had made the mistake that most first-year product leaders make: I treated stakeholder management as communication. Send the update. Host the roadmap review. Present the metrics. Repeat. What I was actually doing was broadcasting — not managing. And there’s a meaningful difference.

The Communication Trap

Stakeholder management isn’t a communication problem. It’s an alignment problem. The goal isn’t to keep people informed — it’s to keep people aligned on what winning looks like, why the current plan is the right bet, and what you’d need to see to change it. When you confuse these two goals, you end up with stakeholders who are technically up-to-date and fundamentally unconvinced.

The sign that you’re in the communication trap: you’re spending more time explaining decisions than making them. Roadmap reviews turn into Q&A sessions. Strategy presentations generate more questions than clarity. Stakeholders seem to relitigate settled decisions at each new meeting. You feel like you’re doing the same work twice — once to build the plan, once to defend it.

This pattern usually signals that stakeholders don’t share your model of the problem. They’re not resisting your roadmap — they’re resisting your framing of the situation. And no amount of additional communication fixes a framing gap. You have to go upstream.

What Stakeholder Management Actually Requires

Effective stakeholder management in product leadership has three components that most people underinvest in: problem framing, assumption surfacing, and decision rights clarity.

Problem framing means getting explicit — before the roadmap — about what problem the product is trying to solve and what success looks like in measurable terms. This sounds obvious, but it rarely happens. Most organizations inherit their problem definitions. They’re embedded in legacy priorities, historical roadmaps, and department OKRs that no one has questioned in years. When a new product leader arrives and starts making decisions from a different problem frame — even a better one — the decisions feel wrong to people who are operating from the old frame.

The fix isn’t to present your frame louder. It’s to surface the existing frame, make it explicit, and negotiate — collaboratively — toward a shared one. That conversation is uncomfortable. It takes longer than a roadmap presentation. And it’s the only thing that actually works.

Assumption surfacing means making the reasoning behind decisions transparent. Not just the decisions — the reasoning. When stakeholders understand the assumptions behind a bet, they can engage with the substance rather than the surface. They can tell you when your assumptions are wrong. They can contribute information you don’t have. And when a decision doesn’t work out, there’s a shared understanding of why the bet didn’t land — rather than a search for someone to blame.

Decision rights clarity is the most neglected piece. In most product organizations, it’s unclear who can change what. Can the Head of Sales override a prioritization decision by escalating to the CEO? Can a board member request a feature and expect to see it in the next sprint? Until these questions are answered explicitly — in writing, with leadership alignment — stakeholders will default to maximum pressure as their escalation strategy. And you’ll spend your year managing escalations instead of building product.

The Year-One Priority: Map Before You Manage

The most useful thing a first-year product leader can do with stakeholders isn’t a roadmap presentation. It’s a stakeholder map — a candid, private document that captures each stakeholder’s goals, concerns, influence level, and current mental model of the product. Not to manipulate them, but to understand what alignment actually requires for each person.

Different stakeholders need different things. The CFO needs confidence that the product investments are tied to revenue outcomes. The Head of Customer Success needs to know that the product team understands what’s driving churn. The CEO needs to know that you’re thinking about the business, not just the features. The engineering lead needs to know that the roadmap is actually buildable in the timeframes proposed. None of these are the same conversation — and the same deck won’t serve them all.

When you know what each stakeholder needs to feel aligned — not just informed — you can design your communication strategy around those needs. You can have the CFO conversation before the roadmap review, not after. You can proactively address the customer success concern in the planning process, not in the next escalation. You can show your work to the CEO in the format that resonates with how they think, not how you think.

A Note on Trust

Everything in stakeholder management runs on trust — and trust in year one is earned slowly and lost quickly. The fastest way to build it: do what you say you’ll do, say what you believe even when it’s inconvenient, and be transparent about uncertainty. The fastest way to lose it: overpromise, change direction without explanation, or let stakeholders feel surprised by something you knew was coming.

The leaders I’ve seen build durable stakeholder trust in year one share a common habit: they bring problems to stakeholders before they have solutions. Not to alarm them — to involve them. Stakeholders who feel like partners in identifying the problem are far more likely to support the solution, even when it’s not exactly what they would have chosen.

Your Turn: Apply This Today

Whether you’re new to a role or recalibrating a stakeholder dynamic that isn’t working, here are six concrete moves to shift from stakeholder communication to stakeholder alignment:

  • Build a private stakeholder map this week. For each key stakeholder, write down: their primary goal, their biggest concern about the product, their current mental model of what the product should be doing, and how much influence they have over your team’s ability to execute. You can’t align people you don’t understand.
  • Schedule one-on-ones before your next roadmap presentation. Don’t use these to preview the roadmap. Use them to understand what each stakeholder needs to feel confident in the direction. Ask: “What would you need to see in the next 90 days to believe we’re on the right track?” Their answers should shape your presentation — not the other way around.
  • Write down your problem frame explicitly. In one paragraph, describe the core problem the product is solving, for whom, and what success looks like in 12 months. Share it with your key stakeholders and ask if they agree. Disagreements you find here are far cheaper to resolve than disagreements that surface in a roadmap review.
  • Make your assumptions visible in decision documents. For any significant prioritization decision, document the assumptions that justify it alongside the decision itself. This doesn’t slow you down — it accelerates alignment because stakeholders can engage with your reasoning, not just your conclusions.
  • Clarify decision rights in writing. Work with your manager or leadership team to document who can change what and under what circumstances. Even a simple RACI that covers roadmap changes, sprint reprioritization, and feature escalations will reduce the ambient anxiety that drives stakeholder pressure.
  • Bring one problem to a stakeholder before you have the answer. Pick a real challenge you’re working through and involve a key stakeholder in the thinking — not the solution. Ask for their perspective. Listen. You’ll get useful information and build a partnership dynamic that pays dividends for the rest of your tenure.

Stakeholder dynamics rarely exist in isolation — they’re almost always entangled with strategy and execution. The Product Roadmap Isn’t the Strategy explains why roadmaps often create stakeholder misalignment rather than resolving it. And The Business Case for Change Management covers how to bring organizations along when the direction needs to shift significantly.

Navigating a difficult stakeholder environment in a new product leadership role? I consult with product leaders on alignment strategy, decision-making frameworks, and the organizational dynamics that determine whether great product work actually ships. Let’s talk.

Posted on

Why Your AI Feature Doesn’t Need More Data — It Needs Better Problem Definition

The request comes in through Slack, dressed up as a technical conversation: “We need more training data before we can improve the model.” Sometimes it’s true. More often, it’s a symptom of something upstream that no amount of data will fix.

I’ve sat in product reviews where teams requested months of data collection before they could ship a meaningful AI feature — only to discover, after collecting the data, that they’d been optimizing for the wrong output the whole time. The model got better at predicting something. It just wasn’t predicting the right thing.

The AI Feature Problem That Isn’t a Data Problem

Most AI feature failures I’ve seen in product organizations aren’t engineering failures. They’re problem definition failures. The team knew what they wanted to build. They knew which model architecture they’d use. They had a rough sense of the training data they’d need. What they hadn’t done was write a crisp one-paragraph answer to a deceptively simple question: What specific decision are we trying to improve, for whom, and how will we know the improvement is real?

That question sounds basic. In practice, it’s brutally hard to answer precisely — and most AI feature discussions move past it without ever settling it. Instead, teams anchor on the technical implementation (which model, which API, which pipeline) and skip the product fundamentals that determine whether any of it will matter.

The result is a common and expensive failure mode: you ship an AI feature, it’s technically impressive, and adoption is flat. Users aren’t hostile to it — they just don’t reach for it. Because the feature is solving a problem that wasn’t sharp enough to justify its existence in the first place.

Problem Definition Before Model Selection

There’s a sequence that high-performing AI product teams follow — often implicitly — that lower-performing teams skip. It goes: problem definition → success metric → data requirements → model selection. Most teams invert this. They start with a model or an API capability, then work backward to find a use case. The resulting features are technically coherent but strategically thin.

Problem definition, done right, answers four things before any engineering begins:

Who has the problem? Not “our users” — a specific persona, role, or workflow. The tighter your answer, the more precise your feature can be. Vague personas produce vague AI features that try to be useful to everyone and end up indispensable to no one.

What decision are they currently making badly? AI is most useful when it augments or automates a decision that a human is already making but making slowly, inconsistently, or with incomplete information. If you can’t identify the decision, you can’t define what “better” looks like.

What does “better” actually mean? Faster? More accurate? More consistent? Less effortful? These aren’t the same, and they don’t optimize for the same outputs. A feature that reduces decision time by 40% but introduces 15% more errors may be worse than no feature at all — depending on the stakes of the decision.

How will you measure the improvement? Before you define your data requirements, you need your success metric. If you can’t articulate a measurable outcome that would tell you the feature worked, you’re not ready to scope the data pipeline.

Why Teams Skip This Step

Skipping problem definition isn’t laziness. It’s usually organizational pressure. There’s a demo to prep for. There’s a competitor who just shipped something. There’s an executive who read about the technology and wants to see it in the product. In those conditions, “we need to define the problem more precisely” sounds like a stall tactic. It isn’t — but it can feel like one.

The reframe I use with teams: problem definition doesn’t slow down AI feature development. It accelerates it. When the problem is crisp, data requirements become obvious. Model selection becomes obvious. Evaluation criteria become obvious. The team spends less time rebuilding the pipeline because they didn’t spec it wrong the first time.

I’ve watched teams spend 12 weeks collecting data for a feature that took 4 weeks to build — only to realize at launch that they’d defined the output variable incorrectly. A week of problem definition work at the front would have surfaced that misalignment long before the data collection started.

The Practical Test: Can You Write the Prompt?

Here’s a heuristic I’ve started using with teams evaluating AI features: can you write the prompt that would produce the output you want, and does that output solve the problem as you’ve defined it? If you’re using a generative model, this is literal — write the prompt. If you’re using a predictive model, translate: can you describe in plain English what you’re asking the model to predict, and does that prediction map to a real decision that real users need help making?

If you can’t write the prompt — or if the prompt output doesn’t map clearly to a user decision — you don’t have a data problem. You have a problem definition problem. And that’s a conversation to have in a product review, not a sprint planning session.

Your Turn: Apply This Today

Before your team writes another line of code or collects another batch of training data, run your AI feature through this problem definition checklist:

  • Write the one-paragraph problem statement. Include: who has the problem, what decision they’re currently making badly, what “better” means in measurable terms, and how you’ll know the feature worked. If your team can’t agree on this paragraph in one working session, that’s your first sprint — not the model.
  • Identify the specific decision your AI feature augments or automates. If you can’t name a decision, you don’t have an AI problem — you may have a search problem, a dashboard problem, or an information architecture problem. AI is not the right hammer for every nail.
  • Define your success metric before scoping data requirements. What measurable outcome will tell you the feature improved the user’s decision? Write it down. Lock it. Then — and only then — work backward to determine what data you need to produce that outcome reliably.
  • Run the “prompt test.” Can you write the prompt (or describe the prediction) in plain language? Does that output directly address the decision you identified? If there’s a gap between the model output and the user’s decision, that gap is your product design problem.
  • Interview three users about the decision before building. Ask them to walk you through the last time they made this decision. What information did they use? Where did they get stuck? What would have made it faster or easier? Their workflow, not your intuition, should drive your data spec.
  • Set a problem definition review gate. Before any AI feature moves from ideation to data collection, require a written problem definition document. One page. Four questions answered. This gate will save you more engineering cycles than any model optimization will.

Related reading: The Product Leader’s AI Infrastructure Blind Spot covers the organizational patterns that cause AI investments to underperform, and Opportunity Solution Trees Meet AI Reality at Scale addresses how to adapt discovery frameworks when AI is the solution space you’re exploring.

Working through AI product strategy and finding that your team keeps building features that don’t land? I consult with product leaders on AI feature scoping, problem definition frameworks, and the organizational dynamics that cause AI investments to underdeliver. Let’s talk.

Posted on

How to Run a Product Strategy Review When You’ve Inherited Someone Else’s Roadmap

The first roadmap review I inherited as a new product leader had 47 line items, three different color-coding systems, and a column labeled “Strategic Priority” where everything was marked high. The outgoing PM had built something comprehensive. What they hadn’t built was a strategy.

I spent my first two weeks trying to understand what was there before I changed anything. That instinct was right. The execution was wrong. I was trying to reverse-engineer a strategy from a list of features rather than asking the more fundamental question: What problem is this roadmap trying to solve, and for whom?

The Inherited Roadmap Trap

When you inherit a roadmap, you inherit a set of commitments, a set of assumptions, and a set of organizational relationships — all wrapped in a document that looks like a plan. The danger is treating it like one.

Roadmaps reflect the strategic thinking of the person who built them, at the moment they built them. When you take over, you’re not inheriting a strategy — you’re inheriting a snapshot. The market has moved. The team has changed. The business context may have shifted entirely. None of that shows up in the roadmap columns.

New product leaders routinely make one of two mistakes: they either preserve the inherited roadmap out of respect (or political caution), executing someone else’s bets without interrogating them; or they blow it up immediately, which destroys trust and loses whatever genuine strategic insight was embedded in the existing plan. Both moves cost you credibility and time.

The Product Strategy Review: A 30-Day Framework

A product strategy review is different from a roadmap audit. An audit asks: “Is this roadmap right?” A strategy review asks: “Is the strategy behind this roadmap still sound, and is the roadmap the right expression of it?” That’s a much harder and much more useful question.

I run these in three phases over 30 days.

Phase 1 — Days 1–10: Understand the bets. Every item on the roadmap represents a bet. Someone believed that building this thing would move a metric, serve a customer, or create a competitive advantage. Your job in phase one is to reconstruct the reasoning — not to evaluate it yet. Interview the people who made each decision. Ask: “What were you trying to achieve? What did you believe to be true when you committed to this?” Write down what you learn. You’re building a map of assumptions, not a list of problems.

Phase 2 — Days 11–20: Stress-test the assumptions. Now you compare the assumptions you collected against current reality. Which beliefs have been validated? Which have been falsified? Which have never been tested? For each unvalidated assumption on a high-priority item, you have a decision to make: validate it before building, build and measure, or deprioritize until the assumption is clearer. The goal isn’t to eliminate uncertainty — roadmaps are always bets. The goal is to know which bets you’re making and why.

Phase 3 — Days 21–30: Rebuild the narrative. With your assumption map in hand, you can now articulate what the roadmap is trying to accomplish — in terms of customer outcomes and business results, not features. Write a one-page strategy brief: who you’re building for, what job you’re doing for them, what winning looks like in 12 months, and how each major initiative contributes to that. Then compare that brief to the existing roadmap. The gaps and misalignments you find are your roadmap.

What to Do With What You Find

Every roadmap review produces three categories of findings: things that are right for the right reasons, things that were right for reasons that no longer apply, and things that were never clearly reasoned through.

Items in the first category — protect them. They represent institutional knowledge and strategic clarity you shouldn’t discard. Items in the second category — evaluate whether the new context changes the bet. Sometimes the feature is still worth building; the rationale just needs updating. Items in the third category are the most important: these are where your predecessor’s gaps become your opportunity to add genuine strategic value.

The output of a strategy review isn’t a new roadmap. It’s a shared understanding — across your team, your stakeholders, and your own thinking — of why the roadmap looks the way it does and what it would take to change it. That shared understanding is worth more than any reprioritization session.

The Political Reality Nobody Warns You About

Inherited roadmaps come with inherited stakeholders. Some of those stakeholders have personal investment in specific items. Some of them advocated hard for features that are now in jeopardy. When you start asking pointed questions about strategic rationale, those conversations can feel like attacks — even when they aren’t.

The reframe that works best: you’re not auditing their work. You’re bringing yourself up to speed so you can be an effective advocate for their priorities. When stakeholders trust that your process is about understanding before changing, they become your allies in the review rather than your obstacles.

One specific tactic I’ve used: before any strategy review conversation, I tell the stakeholder explicitly — “I want to understand what we’re building and why before I have opinions about what we should change.” That simple statement defuses most defensive posturing before it starts.

Your Turn: Apply This Today

Whether you just took on a new product role or inherited a roadmap mid-cycle, here’s how to run your first strategy review without burning political capital or flying blind:

  • List every roadmap item and its stated rationale. If you can’t find a documented rationale, that’s data. Undocumented bets are the ones most likely to be wrong — or the ones where the reasoning exists only in someone’s head and needs to be surfaced.
  • Interview two people per major initiative. Talk to the person who championed it and one person who was skeptical. You need both perspectives to reconstruct an honest picture of the assumption set.
  • Write the assumption behind each initiative as a testable statement. “We believe [user type] will [behavior] because [reason], and we’ll know we’re right when [measurable outcome].” Items where you can’t complete this sentence need additional scrutiny.
  • Identify your three highest-assumption items. These are the bets that rest on the most unvalidated beliefs. Decide explicitly: validate before building, or accept the uncertainty and build anyway. Either decision is fine — what’s not fine is not knowing which bet you’re making.
  • Write a one-page strategy brief before you touch the roadmap. Articulate who you’re building for, what job you’re doing for them, and what winning looks like in 12 months. If you can’t write this page yet, you’re not ready to reprioritize anything.
  • Communicate your process to stakeholders before you share findings. Explain the three phases. Give them a timeline. Tell them when you’ll have recommendations. Stakeholders who feel included in the process are far less likely to resist the output.

For more on strategic thinking in product leadership, The Product Roadmap Isn’t the Strategy unpacks the distinction between execution plans and actual strategy. And if you’re navigating stakeholder dynamics alongside the strategy work, The Business Case for Change Management covers how to bring organizations along when the direction needs to shift.

Just taken on a new product leadership role and trying to figure out what to keep, what to change, and how to build credibility fast? I consult with product leaders on exactly this kind of first-90-days challenge. Let’s talk.

View all posts