Somewhere out there, a product team just shipped a roadmap that engineering will build to spec and no further. The PM had the authority to mandate it, so they did. The features will exist. Nobody will volunteer creative problem-solving on top of them.

Coming into product leadership from a technical background, the structural misalignment takes a while to register. You’re accountable for outcomes that depend on engineering, design, legal, and marketing — almost none of which report to you. You can request and occasionally mandate. What you can’t do is mandate your way to good outcomes in work that depends on judgment and discretionary effort from people who had no input in shaping what they’re building.

The leaders who figure this out aren’t doing anything mysterious. They’re building something that formal authority can’t create, and it takes longer than a title change.

Where Position Power Ends

Formal authority is a blunt instrument in cross-functional work. McKinsey’s research on span of control finds that organizations with more management layers between leadership and the front line consistently show slower decision cycles and reduced signal quality, as context strips out at each handoff. Knowledge work has trended toward flatter structures and wider spans for exactly this reason. Reducing organizational distance isn’t just an efficiency improvement, it’s an information quality improvement.

Product leaders often inherit a version of this problem even when they have formal authority. A roadmap you’ve mandated gets built with compliance. Engineers build the spec. They don’t bring you the thing they noticed while building it that would change the spec, because no conditions exist for sharing it.

The ceiling of authority isn’t usually visible in what gets built. It’s visible in what doesn’t get said.

A Track Record Worth Accumulating

Influence in product organizations runs on a track record of being right about things that matter more often than average, and being visible about it when you miss.

This has a practical implication most people underweight. Credibility requires taking positions. The PM who qualifies every prioritization call with “this is just one data point” and hedges every forecast with “it depends on how we define success” protects their record from being wrong. They also accumulate no credibility capital to spend. You can’t call in influence you haven’t built.

The harder half is the public miss. Teams watch what happens when someone calls a shot and misses. If the response is to quietly reframe, cite external factors, or let the miss fade into background noise, the record stays clean but the credibility doesn’t compound. A direct acknowledgment does something a clean record can’t: “I called this wrong, and here’s what I missed.” People remember that, and they extend more latitude to the next call.

Credibility also travels across functions when you engage seriously with domains adjacent to your own. A product leader who understands why the compliance team is pushing back on a particular UX pattern, and can engage with the substance of that concern rather than just the friction, earns a different kind of trust than one who routes every cross-functional conflict through the org chart.

Creating the Conditions

The phrase gets used a lot. What it looks like in practice is less often described, which is probably why it’s hard to replicate.

Google’s Project Aristotle, which studied 180 teams across the company, found that psychological safety (the belief that team members can raise concerns without professional repercussions) was the single strongest predictor of team effectiveness, more predictive than team composition or technical skill level. Teams with high psychological safety showed 19% higher productivity and were 31% more likely to generate innovative solutions. The mechanics of why this holds specifically in technical teams, and what it looks like when it’s working, are covered in depth in Building Psychological Safety in High Performing Teams.

The mechanism matters: psychological safety isn’t about comfort. It’s about whether people believe their input will be engaged with, not just noted. When that belief exists, people bring you the things that don’t fit the current narrative. Those things are usually where the most important information lives.

The WIFM for the team is real but rarely articulated. An engineer who co-owns a problem builds more interesting things. The work becomes about solving something rather than executing a spec. Contributions become visible in ways that spec-following never makes visible, and that visibility has career implications. The people who most want to do interesting work tend to gravitate toward environments where their input shapes outcomes, and stay there.

Three versions of this dynamic show up in cross-functional product work:

What moves a team from compliance to invested isn’t a conversation style change or a new meeting format. It’s a feedback loop built over time by how the leader responds when a concern is raised. The engineering lead doesn’t call proactively because they’re naturally collaborative. They call because they’ve been in rooms where their input changed an outcome and they were credited for it. The loop is learned.

Coaching Yourself Into It

The shift from compliance to invested doesn’t happen through a single meeting or a change in tone. It builds through accumulated small decisions about how you respond when someone raises a concern.

The diagnostic is simple: in the past month, when someone on a cross-functional team raised a concern you hadn’t anticipated, what changed? If nothing changed, or if the concern was acknowledged and the plan continued unmodified, that’s the current baseline.

Four moves that shift it in practice:

• Share the problem before sharing the solution. This single change shifts the team’s first response from “how do we execute this” to “is this the right thing to execute.” It’s harder than it sounds, because it requires having the conversation before you feel ready to direct it.

• When input changes an outcome, say so in the room. Not in a follow-up message, not in the next one-on-one. In the same room where the concern was raised, so everyone present updates their model of whether input matters here.

• When you hold course after pushback, explain why. The difference between “I hear that” and “I hear that, and here’s why we’re proceeding this way” is the difference between people feeling noted and people feeling included. They may not agree with the call, but they understand it. They come back next time.

• Once a quarter, ask someone on the periphery what they’re seeing. A TPM or junior engineer a half-step removed from the core team conversations. The answer is usually useful. The act of asking is half the point.

None of these are complicated. What makes them hard is consistency. They need to happen in ordinary moments, not just the deliberate ones. The baseline is set by what you do when the calendar is full and the decision feels obvious.

The Work Before the Room

Most organizational influence happens in conversations that aren’t on the calendar. The lunch where product and design leads work through a problem before either has a formal position. The one-on-one where a PM finds out what a stakeholder is actually worried about, beneath the objection they’re stating.

Leaders who seem to move organizations effortlessly in formal settings usually aren’t doing it in formal settings. By the time a decision goes to a review meeting, the aligned parties already know what they’re going to say.

This is sometimes called political maneuvering and sometimes called good stakeholder management. The distinction is mostly in intent. Working through the concerns of affected parties before a decision gets framed, so that everyone has been heard, is different from identifying who might object and neutralizing them before they can coalesce. The former creates durable alignment. The latter creates resentment that surfaces in the next decision, often in ways that are hard to trace back to where they started.

The Altitude Question

One pattern that limits influence for senior product leaders is altitude. Either pulled too far into execution details that should sit with the team, or operating at a level of abstraction that doesn’t connect to decisions that need to be made this week.

Influence requires being present where decisions actually get made. In most organizations, that’s the intersection of strategy and near-term trade-offs: connecting a near-term call to its strategic implications, or being specific about what an alternative actually looks like in practice. Leaders who default to one altitude and stay there become less useful for the other kind of conversation, and their influence in those conversations quietly atrophies.

I’ve gotten this wrong in both directions. The gaps tend to become visible only in retrospect, usually as decisions that drifted while I was operating at the wrong level for what that period required.

The Compounding Effect

Credibility and track record are assets that compound in ways formal authority doesn’t. An organization that has watched you be right about hard calls, and seen you acknowledge the misses directly rather than let them fade, extends more latitude and trust to future decisions. That accumulated history survives reorganizations and reporting changes because it’s attached to you, not to your title.

Building it requires consistent behavior over time that isn’t optimized for any single decision. There’s no shortcut that produces the same result faster. That’s probably why it’s uncommon enough to notice when someone genuinely has it.

What does the dynamic look like on your team right now? Are people bringing you problems before they escalate, or after? The answer says more about your actual influence than anything on the org chart.