Why Product Teams Struggle to Influence Upwards - and What to Do About It

It's a situation most product people will recognise.

A team has done solid work: talked to customers, mapped the landscape, built a clear picture of what matters and why. They prepare a presentation, get time with the leadership team, and make their case. There's some nodding. A few questions. And then, not much changes.

It's rarely that the ideas are bad, or that leadership is disengaged. Something just doesn't quite connect. The thinking stays with the team rather than landing in the room. A few weeks later, the same conversation happens again with a slightly different framing.

This is one of the more common frustrations in product organisations, and one of the less examined ones. It tends to get written off as a communications issue, or a cultural one, or just the nature of working in a large company. Teams adapt around it rather than addressing it directly.

That's worth changing - not just for the sake of the individuals involved, but because when product thinking doesn't reach the people making strategic decisions, the decisions tend to be worse.

The gap is usually about translation, not quality

Product teams that struggle to influence upwards are rarely doing poor product work. They understand their users. They can articulate tradeoffs clearly. They've often spent more time thinking about the right direction than anyone else in the organisation.

The gap is usually not in the thinking. It's in how that thinking is framed for a different audience.

Senior leaders - particularly those outside product and engineering - tend to work in a different frame of reference. Their questions are about risk, capital, competitive position, and what they can credibly take to a board or to investors. They're usually carrying several bets at once, and managing upwards themselves.

When product teams arrive with language that makes sense inside the product world - roadmaps, velocity, discovery sprints, epics - it isn't that leadership dismisses it. It's that they can't easily connect it to the decisions they're actually trying to make. The conversation tends to stall at that translation point.

A useful way to think about it: product teams often present answers to questions that leadership isn't quite asking yet. The product team has already worked through the problem. Leadership is still deciding whether and how much it matters.

Why influence tends to get stuck

There are a few patterns that come up repeatedly.

The problem of assumed context. Product teams can have weeks or months of immersion in a problem. Leadership has the next half hour. When teams skip straight to recommendations without first building a shared picture of the situation, the conclusion can feel like it arrived without sufficient justification - even when the underlying reasoning is sound. The logic makes sense to the people who did the work. For everyone else, it can feel somewhat out of nowhere.

Metrics that don't travel upward. Engagement rates, cycle times, sprint velocity - these are useful internal signals, but they're not natural decision-making tools for senior leaders. When the case for a direction is built on metrics that don't translate into the language of risk and return, even a well-constructed argument can fail to create movement. The data isn't wrong. It just answers a different question than the one leadership is sitting with.

The credibility loop. Influence upwards is partly earned through a track record - a history of recommendations that turned out to be sound. Teams that haven't had the opportunity to demonstrate that track record, often because they haven't been given enough room to make real calls, can find themselves in a difficult position. They need trust to get the autonomy, and they need the autonomy to build the trust.

Arriving with problems rather than a perspective. There's a real difference between presenting a problem and presenting a shaped view of what should happen. Leadership teams tend to move quickly toward resolution, and if a team walks in with an open question and no clear steer, the room tends to fill that space - sometimes in ways that the product team then has to work around. Coming with a point of view isn't the same as being rigid. It just gives the conversation somewhere useful to start.

A mismatch in time horizon. Product thinking tends to live in the near-to-medium term: what to build, for whom, and when. Leadership thinking often operates at a longer range - what kind of company are we becoming, and is this work taking us in that direction? When product teams present near-term priorities without a visible connection to that bigger picture, the work can feel tactical even when the intent is strategic.

What tends to help

This isn't really about becoming a more polished presenter. The adjustment that makes a genuine difference is more substantive: it's about positioning product thinking in relation to the decisions that leadership is actually trying to make.

Start with the business question. Before drafting any recommendation, it's worth stepping back and asking what leadership is actually trying to decide at the moment. What are their pressures? What would make them feel more confident, or better placed to manage risk? A product strategy framed in direct response to those questions tends to land quite differently from one framed in response to internal product logic.

Make the investment framing visible. Senior leaders tend to think in terms of bets: how much is going in, what's the exposure, what's the expected return. When product teams translate their priorities into those terms - not just "here's what we should build" but "here's how we're thinking about allocating effort across protecting what we have, growing, and exploring new ground" - it creates a conversation that leadership can genuinely engage with rather than simply receive.

Build the picture before making the case. Effective product communication tends to follow a fairly consistent structure: shared understanding of the situation, a clear statement of what's at stake, and then the recommendation. Teams that go straight to the recommendation often lose the room before they've had the chance to make the argument. Investing time in shared context isn't a detour. It's what makes the conclusion feel grounded.

Focus on decisions rather than roadmaps. Rather than presenting a roadmap and looking for endorsement, it's usually more effective to go into a leadership conversation with one or two specific, well-framed decisions that need to be made. That's a more respectful use of limited time, and it creates a clearer record of what was actually agreed. Over time, a pattern of good decisions builds the kind of credibility that makes future conversations easier.

Build the relationship before the high-stakes moment. Influence in important conversations is usually built in less important ones. Product teams that only engage leadership when they need approval tend to start those conversations at a disadvantage. Regular, light-touch contact - brief updates, early thinking shared informally, the occasional question asked before it becomes urgent - means less trust-building has to happen in the room itself.

The structural version of the problem

There's a harder version of this question that's worth acknowledging.

In a lot of organisations, product teams don't have the influence they need because influence wasn't really part of what they were hired to do. The expectation - sometimes explicit, sometimes just ambient - is that product insight flows upward only when it's asked for. Teams are there to deliver against a strategy set elsewhere, not to shape it.

That's a structural problem, and better communication skills won't fix it. What's needed is for leadership to genuinely want to be influenced by the people closest to the work, and to build the conditions that make it possible. That means sharing strategic context downward with enough clarity that product teams can make good decisions independently. It means delegating real calls to the people best placed to make them. It means a genuine rhythm of dialogue between product and senior leadership, rather than a reporting cadence dressed up as one.

Where that appetite exists, the influence gap tends to close fairly quickly. Where it doesn't, the problem is upstream of anything a product team can fix on their own.

Using AI to prepare for these conversations

One underused application of tools like Claude is preparation and rehearsal for exactly this kind of situation. Working through how an argument might land, testing a frame before taking it into a room, identifying the gaps in a recommendation before someone else does - all of this benefits from a thinking partner, and AI is reasonably well suited to that role.

A few prompts worth trying:

To reframe a recommendation in leadership terms: "Here is a product recommendation I'm planning to take to our leadership team: [paste your recommendation]. Our senior leaders tend to think in terms of [risk / return / competitive position / customer retention - choose what fits]. Help me reframe this so it speaks directly to those concerns, without losing the substance of the underlying product thinking."

To stress-test the argument: "I'm planning to recommend the following to our leadership team: [paste recommendation]. Act as a sceptical but fair CFO who hasn't been involved in the product work. What questions would you have? What would you push back on? What would make you more confident?"

To build shared context before making the recommendation: "I need to help a leadership team understand why [product area / customer problem / strategic shift] matters before I recommend a course of action. Help me structure a brief two-minute narrative that builds the case from their perspective - assume they're knowledgeable but time-poor."

To identify the actual decision: "We're heading into a leadership review of our product priorities. I know what I think we should do, but I'm not sure I've identified the right decision to ask them to make. Here's the situation: [describe it]. What are the one or two decisions that actually need to be made here, and how might I frame them?"

To prepare for the conversation going sideways: "I'm presenting a product strategy recommendation and I'm concerned the conversation will get pulled toward [a specific objection or competing priority]. Help me think through how to acknowledge that concern and bring things back to the core decision, without being dismissive of it."

The ability to influence upwards is not just a useful career skill. It's what allows product thinking to actually shape the direction of a company - which is, in the end, the point. Teams that work this out don't just get better at presenting their work. They get better at the work itself, because they're operating with a clearer sense of what decisions actually need to be made, and why.