Managing Up, Down, and Sideways: Influencing Without Authority
Product managers have the worst org chart position in tech.
You're responsible for the product's success, but you can't fire anyone, approve budgets, or force decisions.
Engineering doesn't report to you. Design doesn't report to you. Sales definitely doesn't report to you.
Yet somehow you're supposed to:
- Get engineers to prioritize your features
- Convince designers to iterate on your feedback
- Align sales on positioning
- Persuade executives to fund your roadmap
- Keep support happy despite declining their requests
You have all the responsibility and none of the authority.
Welcome to product management.
The PMs who fail try to control through force. The PMs who succeed learn to influence without authority.
This is how.
Why Authority Doesn't Matter (And Influence Does)
Authority gets compliance. Influence gets commitment.
Authority says: "Do this because I said so."
Result: Minimal effort, no ownership, resentment
Influence says: "Here's why this matters and how it helps you."
Result: Enthusiasm, collaboration, ownership
In product management, you need people to care — not just comply.
That requires influence.
The Three Directions of Influence
You need different strategies for each.
Managing Up: Influencing Executives
What they care about:
- Business outcomes (revenue, growth, retention)
- Risk mitigation
- Strategic alignment
- Looking good to board/investors
What they don't care about:
- Feature details
- Technical complexity
- Your process
- Internal politics
Managing Down: Influencing Your Team
What they care about:
- Interesting technical challenges
- Clear requirements
- Autonomy
- Not wasting time
- Career growth
What they don't care about:
- Corporate politics
- Your relationship with executives
- Why someone else wants this
Managing Sideways: Influencing Peers
What they care about:
- Their team's goals
- Their metrics
- Their roadmap
- Not being surprised
- Looking competent
What they don't care about:
- Your roadmap conflicts
- Your resource constraints
- Your deadline pressure
The key: Frame everything around what THEY care about, not what you need.
Managing Up: Getting Executive Buy-In
Executives are busy and impatient. Make it easy for them to say yes.
Technique 1: Lead with Business Impact
Bad: "We should rebuild the dashboard because users complain about it."
Good: "Dashboard performance is correlated with 15% lower retention in first 30 days. Fixing it could recover $500k ARR annually."
Why it works: Translates product problem into business outcome.
Technique 2: Present Options, Not Problems
Bad: "We don't have enough engineers for Q2."
Good: "Here are three Q2 roadmap scenarios based on team capacity:
- Option A (current team): Ship X and Y, defer Z
- Option B (add 2 engineers): Ship X, Y, and Z
- Option C (cut scope): Ship only X, faster
I recommend A because [reasoning]."
Why it works: Shows you've thought through trade-offs and gives them a decision to make, not a problem to solve.
Technique 3: Use Their Metrics
Bad: "Feature adoption is at 40%."
Good: "This feature is being used by customers representing $2M ARR, which is 40% of our ICP segment and tracking toward our Q2 expansion goal."
Why it works: Connects your work to metrics they track.
Technique 4: Anticipate Objections
Example:
"I'm proposing we delay the marketplace launch by one quarter to fix onboarding. I know this conflicts with our Q2 revenue goal. Here's why I think it's the right call: [data]. And here's how we can partially offset the revenue impact: [alternative plan]."
Why it works: Shows you understand their concerns and have thought through implications.
Technique 5: Make Them Look Good
When your work succeeds, credit them.
Say: "Your push for better activation metrics led us to discover this onboarding issue."
Why it works: Executives who look good because of you will support you more.
Managing Down: Getting Engineering Buy-In
Engineers respect competence, clarity, and autonomy.
Technique 1: Respect Their Expertise
Bad: "Just do it this way."
Good: "Here's the problem we're solving and the outcome we need. What's the best technical approach?"
Why it works: Engineers want to solve problems, not take orders. Give them the problem.
Technique 2: Provide Context, Not Just Requirements
Bad: "Add a filter for date range."
Good: "Users analyze data across different time periods, but currently can only see last 30 days. This blocks quarterly reporting use case, which we've heard from 15 enterprise customers."
Why it works: Engineers make better decisions when they understand why.
Technique 3: Protect Their Time
Bad: Constantly changing priorities mid-sprint.
Good: Batch changes. Commit to scope for sprint. Buffer time for unexpected.
Why it works: Engineers hate context switching. Stability builds trust.
Technique 4: Celebrate Their Work
When feature ships:
- Share it with leadership and credit engineering
- Highlight technical challenges overcome
- Show user impact and positive feedback
Why it works: Recognition motivates. Engineers who feel valued work harder for you.
Technique 5: Take Responsibility for Failures
Bad: "The feature flopped because engineering built it wrong."
Good: "I misjudged the user need. Here's what we learned."
Why it works: Taking blame builds loyalty. Blaming others destroys it.
Managing Sideways: Getting Peer Buy-In
Peers have their own goals that conflict with yours.
Technique 1: Make It a Win-Win
Bad: "I need sales to stop selling this feature we don't have."
Good: "What if we gave sales a clear 'coming soon' timeline and talking points? They could close deals by setting expectations, and we buy time to build it right."
Why it works: Offers solution that helps both sides.
Technique 2: Trade Favors
Example:
"I know marketing wants analytics dashboard prioritized. If we ship that in Q1, can you help me get engineering resources for my Q2 integration work?"
Why it works: Reciprocity. You help them, they help you.
Technique 3: Align on Shared Metrics
Bad: Competing for resources based on different priorities.
Good: "We both need to hit activation targets. What if we jointly prioritize the onboarding flow since it helps both our goals?"
Why it works: Shared goals create natural allies.
Technique 4: Overcommunicate
Don't: Surprise peers with decisions that affect them.
Do: Proactively share roadmap changes, ask for input early, give visibility.
Why it works: People resist surprises. Inclusion builds support.
Technique 5: Acknowledge Their Constraints
Example:
"I know you're slammed with the rebrand. I'm not asking for immediate action — just want to flag this dependency so we can plan together."
Why it works: Shows respect for their bandwidth and priorities.
The Universal Influence Techniques
These work in all directions.
1. Build Relationships Before You Need Them
Don't: Only talk to people when you want something.
Do:
- Regular 1:1s with key stakeholders
- Casual coffee chats
- Help them with their problems
- Learn their goals and pressures
Why it works: Relationship capital makes influence easier.
2. Use Data, Not Opinions
Bad: "I think users want this."
Good: "67% of churned users mentioned this in exit surveys."
Why it works: Data is objective. Opinions are debatable.
3. Tell Stories
Bad: "Conversion rate dropped 15%."
Good: "I watched 5 users try to sign up. Each one got to the payment page, paused, then closed the tab. They told us the pricing was confusing. We lost $50k MRR this month from that friction."
Why it works: Stories stick. Numbers alone don't.
4. Ask Questions Instead of Making Demands
Bad: "We need to prioritize this."
Good: "What would need to be true for this to become a priority?"
Why it works: Questions invite collaboration. Demands create resistance.
5. Give Credit Generously
When things go well:
- Credit engineering for execution
- Credit design for UX
- Credit sales for feedback
- Credit executives for vision
Why it works: People support those who make them look good.
Navigating Disagreements Without Authority
You'll face conflicts. Here's how to handle them.
Strategy 1: Disagree and Commit
When to use: You disagree but the decision isn't catastrophic.
How:
"I see it differently, but I respect your call. I'm fully committed to making this work."
Why it works: Shows maturity and team-first mindset.
Strategy 2: Escalate with Data
When to use: The decision is high stakes and you're confident you're right.
How:
"I want to share some data that might change our thinking. Can we review it together before finalizing?"
Why it works: Not personal disagreement — just new information.
Strategy 3: Propose an Experiment
When to use: Disagreement on approach, not goals.
How:
"What if we test both approaches with 10% of users and let data decide?"
Why it works: Removes ego from decision-making.
Strategy 4: Find the Shared Goal
When to use: Conflict seems fundamental.
How:
"We both want [shared outcome]. Let's work backward from there."
Why it works: Refocuses on common ground.
The Weekly Stakeholder Rhythm
Consistent communication builds influence.
Monday: Alignment
- 30-min sync with engineering lead
- Review week's priorities
- Flag blockers
Tuesday: Executive Update
- Email summary to leadership
- Top 3 priorities
- Key decisions needed
- Wins from last week
Wednesday: Design Review
- Progress check
- Feedback loop
- Upcoming needs
Thursday: Cross-Functional Sync
- 30-min with sales/marketing/support
- Share roadmap updates
- Gather feedback
- Align on positioning
Friday: Reflection
- Document decisions
- Update roadmap
- Note what worked/didn't
- Plan next week
Why it works: Regular touchpoints prevent surprises and build relationships.
Red Flags You're Losing Influence
Watch for these symptoms:
1. Decisions Happen Without You
- Major changes you learn about second-hand
- Meetings about your product area you're not invited to
Fix: Proactively ask to be included. Add value when you're there.
2. People Stop Asking Your Opinion
- Engineering makes product decisions independently
- Design ships without your input
Fix: Provide better, faster feedback. Make yourself valuable to include.
3. Your Requests Get Ignored
- Features you prioritize get deprioritized
- Meetings you schedule get cancelled
- Emails go unanswered
Fix: Rebuild trust. Deliver wins. Prove your judgment.
4. Constant Pushback
- Every proposal met with resistance
- Always fighting for resources
Fix: Check if you're proposing things that align with team goals or just your own.
5. You're Bypassed in Escalations
- Stakeholders go around you to engineering or executives
Fix: Take responsibility for outcomes. Become reliable.
Building Influence Over Time
Influence compounds.
Month 1-3: Build Credibility
- Ship what you commit to
- Make data-driven arguments
- Be reliable
Month 4-6: Build Relationships
- Regular 1:1s with stakeholders
- Help others succeed
- Become connector
Month 7-12: Build Track Record
- Point to successful launches
- Show metric improvements
- Demonstrate good judgment
After Year 1:
- You've earned benefit of the doubt
- People trust your instincts
- Your recommendations carry weight
The key: Consistency. Small deposits into trust account.
When Influence Isn't Enough
Sometimes you need to escalate.
Escalate when:
- Decision has major business impact
- Stakeholder is actively blocking progress
- Safety or security risk
- Ethical concerns
How to escalate properly:
- Try to resolve first: "I'd like to work this out between us."
- Frame as problem-solving: "I need help resolving [issue]."
- Bring solutions: "Here are three options I see."
- Stay objective: Focus on business impact, not personalities.
- Escalate to right level: Don't skip two levels up.
Real-World Example
Scenario:
You need engineering to prioritize performance improvements. They want to build new features.
Bad approach:
"We HAVE to fix performance. It's critical. Stop working on new features."
Good approach:
-
Gather data: "Performance issues cause 20% drop-off in first session. That's 500 lost users/month."
-
Frame around their goals: "I know you're excited about the new dashboard. Performance fixes will make everything you build feel better and increase adoption of all features, including new ones."
-
Propose compromise: "What if we dedicate 20% of sprint capacity to performance for next 6 weeks? You can still ship features, and we'll see meaningful improvement."
-
Offer help: "I'll handle all communication with stakeholders about the slight delay to dashboard."
-
Show commitment: "If we don't see metric improvement after 6 weeks, we'll stop and I'll own that decision."
Result: Engineering agrees because:
- You showed impact with data
- You connected to their goals
- You offered compromise
- You took on burden
- You put skin in the game
Final Thought
Authority is a crutch.
Influence is a skill.
The best PMs don't need org chart power because they've built something more valuable: trust, credibility, and relationships.
You won't get it right immediately.
You'll make mistakes. People will ignore you. Decisions will go the wrong way.
But every interaction is a chance to build influence.
Start small. Be helpful. Deliver results. Build relationships.
Over time, you won't need authority.
You'll have something better.