Influencing without authority: a playbook for product leaders
Product initiatives rarely fail on ideas. They stall when a team gets left out. How product leaders can influence without authority, from day one.
Most product leaders don't have much formal authority. You don't manage engineering. You certainly don't manage compliance, sales or the CTO. Yet you're accountable for getting the product out of the door, and for it being any good.
That's why influencing without authority is one of the most important skills a product leader can have. It means getting people you don't manage to back a decision through trust, evidence and shared goals, rather than through hierarchy.
The idea isn't new. Allan Cohen and David Bradford first published Influence Without Authority in 1991, and it's now in its third edition. Their model is built on reciprocity: work out what the other person cares about, then find a way for your goal to serve theirs. It still holds. But most influencing advice skips the most basic step. Before you can influence anyone, they need to be in the room.
The biggest mistake: leaving teams out
Here's a pattern we see again and again. A product leader expects a team to be difficult, or suspects they aren't on board, so they quietly work around them. Fewer opinions, fewer meetings, faster progress.
It feels efficient. It isn't.
Leaving a team out doesn't remove their objections. It delays them until the moment they're most expensive to deal with. It's one of the clearest early signs of product team misalignment, and it's easy to miss because everything looks fine until it suddenly isn't. Get people on board at the start, or you're just making life harder for yourself later.
Two projects that stopped in their tracks
We've seen this play out more than once.
On one project, the CTO wasn't involved because they were seen as "old school". The team assumed they'd resist new thinking, so they designed around them. The project reached development, the CTO finally saw it, and it stopped. Not paused. Stopped.
On another, compliance wasn't involved. The initiative got all the way to the edge of go-live before compliance reviewed it, said it didn't comply and halted it. Weeks of design and build had to be reworked.
In both cases, the people who stopped the work weren't being obstructive. They were doing their jobs. They just weren't given the chance to do them early enough to help. Another framework wouldn't have saved either project. Earlier conversations would have, which is why we think you can fix cross-functional misalignment without another framework.
Bring compliance in early (it won't kill your big ideas)
The usual worry about involving compliance early is that it'll stunt your thinking. Invite them to the first workshop and you'll end up playing it safe.
We understand the fear, but the logic doesn't hold. In regulated industries, the constraints exist whether you know about them or not. Rules like the FCA's Consumer Duty, in force since July 2023, don't disappear because nobody mentioned them in product discovery. Your only choice is whether you find out about them now or at go-live.
Bringing compliance in early means you can understand what they need, design within those constraints, and then push the boundaries of what's possible inside them. Constraints aren't the enemy of ambition. Surprises are.
Let users do the talking
When it comes to changing minds, nothing beats letting stakeholders hear from users directly.
You can present research findings all day. But play a sceptical sales director a clip of a customer struggling with the exact workflow they've been defending, and the conversation changes instantly. Hearing it from the horse's mouth is powerful because it stops being your opinion against theirs.
Nielsen Norman Group has made the same point for years. Their main reason for inviting colleagues to observe usability sessions is that it makes them far more likely to accept the findings.
A few ways to put this into practice:
- Invite someone from every team to observe at least one user interview.
- Share short clips, not long reports. Two minutes of a real user beats twenty slides.
- Let the quote make the argument. Resist the urge to explain it.
- Keep clips somewhere everyone can find them, so your user research stays evergreen rather than dying in a slide deck.
If your user feedback feels too messy to use, we've written about turning messy user feedback into actionable product bets. And when the data is thin, there are still ways to align stakeholders when the numbers don't tell the full story.
Prototype to align, not to promise
It's quicker than ever to mock something up. With AI-assisted design tools, a team can put a convincing prototype in front of stakeholders in an afternoon. That's a huge advantage when you're trying to get people excited about an idea.
But be careful. A polished prototype looks finished, which makes it dangerously easy to overpromise. Show a slick concept to a leadership team before engineering and compliance have seen it, and you may be selling something nobody can build or is allowed to ship. It's the same reason AI speeds up product development but also speeds up risk when design thinking gets skipped.
Use prototypes to start conversations, not to close them. Be clear about what's a concept and what's committed. Show them to the people who'll build and approve the work before you show them to the people who'll celebrate it. If you're working through this with engineering, here's how to align design and engineering for better product execution.
Listen more than you pitch
Product and design can't work in a silo. Influencing isn't something you do to other teams. It's something you do with them.
That means genuinely listening. Not waiting for your turn to talk, and not running a consultation where you've already decided the outcome. Ask each team what worries them, what success looks like for them and what would make them block the work. Then show them where their input shaped the plan.
Don't be afraid of some disagreement along the way. A little friction is good for your product team, as long as it happens early and in the open. And listening doesn't mean agreeing to everything. You'll still need to say no to senior stakeholders without damaging relationships. It's just far easier when they know they've been heard.
People back decisions they've helped make. It's also why this approach is far less draining than managing internal stakeholders in firefighting mode later.
What to ask each team at kick-off
Here's what this looks like in practice. Before ideas are fixed, spend 30 minutes with each team that could stop the work, and ask a version of these questions.
Engineering and the CTO: What would make this hard or risky to build? What existing systems or plans does it need to fit around?
Compliance and legal: Which rules apply here? What would you need to see to sign this off with confidence?
Sales and account management: What are customers asking for, and what do they complain about? What would make this easier or harder to sell?
Customer support: Where do users get stuck today? What would cut the number of tickets you handle?
Finance and leadership: What does success look like in numbers? What would make you pull funding?
Write the answers down and share them back. When a team sees its own words in the plan, it stops being your project and starts being theirs too.
When an outside voice helps
Sometimes the hardest part of influencing without authority is that everyone knows which side you're on. A product leader proposing a direction is, fairly or not, seen as having an agenda.
That's where a third party can help, as long as they're genuinely good at stakeholder management. An objective outside voice can spend time with each team, take their views seriously and propose the best way forward, without anyone feeling they've lost to an internal rival. It can also break the kind of decision paralysis that stalls product leadership. It's one of the reasons businesses bring in outside product design support at critical moments.
A simple playbook for influencing without authority
- List every team that could stop the work, including the ones you'd rather avoid.
- Involve them before ideas are fixed, not after.
- Ask what they need and what worries them, and write it down.
- Treat constraints as design inputs, not blockers.
- Let users make the case through interviews and clips.
- Use prototypes to explore, and be honest about what's committed.
- Show people where their input changed the plan.
Final thought
Influence isn't a charm offensive you launch when a project hits trouble. It's groundwork you lay on day one: inviting every team in, listening properly and letting users make the argument for you. The teams you're tempted to leave out are usually the ones who can stop you. Bring them in early, and they're far more likely to help you go further.
Struggling to get every team behind your product without losing momentum?
We act as the objective voice in the room, bringing product, tech, compliance and commercial teams together around real user evidence and a way forward everyone can back. See how we work with product teams.
👉 Book a call with our team to talk about how we can help.
Are you wondering...
It means getting people you don't manage, such as engineering, compliance or sales, to support a decision. You do it through trust, evidence and shared goals rather than hierarchy. For product leaders, it's a core skill, because most of the people needed to ship a product sit outside their reporting line.
Product leaders are accountable for outcomes but rarely control the teams that deliver them. Without influence, initiatives stall when engineering, compliance or commercial teams object late in the process. Strong influence skills let product leaders build buy-in early and keep work moving.
Involve them early, before ideas are fixed. Ask what they need and what worries them, and show them real user evidence through interviews or short clips. Then show where their input shaped the plan. People support decisions they've helped make.
Leaving teams out because they expect them to be difficult. It feels faster at first, but it only delays objections until they're most expensive to fix. Projects can stop at development or just before go-live when an excluded team finally gets a say.
Ask each team what would make the work risky, what they'd need to see to support it, and what would make them block it. Engineering will tell you about build risk, compliance about rules, sales and support about customers, and finance about what success looks like. Write the answers down and share them back.
At the start, in discovery. In regulated industries, compliance constraints exist whether you know about them or not. Involving compliance early lets you design within those constraints from the outset, rather than reworking a product just before launch.
No. It's a common worry, but compliance constraints apply either way. Knowing them early means you can push the boundaries of what's possible within them, instead of having a finished idea blocked at go-live.
Letting stakeholders hear directly from users is one of the most persuasive tools a product leader has. Watching a real customer struggle turns a debate about opinions into a shared problem. Short clips from user interviews often change minds faster than any report or slide deck.
Yes, but use them carefully. Prototypes make ideas tangible and quick to share, especially with AI design tools. Because they look finished, they can also create promises engineering or compliance can't keep. Use them to start conversations, and be clear about what's a concept and what's committed.
Yes, if it's skilled at stakeholder management. An outside partner can act as an objective, unbiased voice. It spends time listening to every team, takes their views seriously and proposes the best way forward. That can break deadlocks that are hard to resolve internally.
More insights
Should you add AI to your product? A business-value checklist for B2B product teams
.png)
PM, designer or product builder? How AI is reshaping product team roles
Need help delivering at pace whilst maintaining product integrity?
We help B2B product teams rebalance pace and purpose — designing workflows where speed serves strategy instead of undermining it. Book a call to talk about how we can help you deliver your product's vision.
