George from 🕹prodmgmt.world Profile picture
Sep 22 17 tweets 4 min read Read on X
Your stakeholders aren't crazy.

After 6 years of product management, I've realized: every "difficult" stakeholder behavior has a hidden logic.

A thread on the psychology of product stakeholders 🧠 Image
1/ Sales: The Future-Focused Hunters

What they see:
• Revenue targets looming
• Competitors taking deals
• Prospects making demands
• Commission at risk

What they feel:
• Urgency to close deals
• Fear of losing opportunities
• Frustration with product gaps
• Personal financial pressure

This is why they:
• Push for custom features
• Make promises to customers
• Escalate to leadership
• Sound desperate sometimes
2/ Support: The Problem Absorbers

What they see:
• Customer pain daily
• Repeated issues
• Workarounds failing
• Mounting tickets

What they feel:
• Emotional drain from complaints
• Responsibility for customer success
• Powerlessness to fix root causes
• Pride in finding solutions

This is why they:
• Escalate aggressively
• Get emotional about issues
• Create elaborate workarounds
• Take product issues personally
3/ Engineering: The Complexity Guardians

What they see:
• Technical debt growing
• Architecture breaking
• Timeline pressure
• Quality vs speed tradeoffs

What they feel:
• Pride in craft
• Fear of future maintenance
• Pressure to deliver faster
• Frustration with unclear requirements

This is why they:
• Push back on timelines
• Focus on technical elegance
• Seem resistant to change
• Want perfect requirements
4/ Marketing: The Market Watchers

What they see:
• Competitor movements
• Market trends
• Brand perception
• Campaign deadlines

What they feel:
• Pressure to differentiate
• Fear of market irrelevance
• Need for clear narratives
• Anxiety about positioning

This is why they:
• Push for feature parity
• Request "marketable" features
• Focus on competitor moves
• Need long-term roadmaps
5/ Analytics: The Truth Seekers

What they see:
• Usage patterns
• Conversion drops
• Engagement metrics
• Growth opportunities

What they feel:
• Confidence in data
• Frustration with gut decisions
• Need for measurement
• Pride in accuracy

This is why they:
• Question assumptions
• Push for more tracking
• Focus on metrics
• Resist intuitive decisions
6/ Product Executives: The Vision Keepers

What they see:
• Board expectations
• Market opportunities
• Resource constraints
• Competitive threats
• Organizational politics

What they feel:
• Pressure to deliver growth
• Fear of strategic missteps
• Responsibility for team success
• Frustration with execution speed
• Anxiety about market position

This is why they:
• Change priorities frequently
• Push for faster delivery
• Focus on high-level metrics
• Sometimes contradict themselves
• Micromanage key initiatives
7/ Fellow Product Managers: The Territory Guards

What they see:
• Overlapping responsibilities
• Shared resources
• Dependencies
• Career competition
• Political dynamics

What they feel:
• Ownership anxiety
• Resource scarcity
• Career pressure
• Fear of being overshadowed
• Need for recognition

This is why they:
• Resist cross-product initiatives
• Guard their roadmap territory
• Compete for engineering resources
• Sometimes withhold information
• Push back on dependencies
8/ UX/Design: The User Advocates

What they see:
• Inconsistent experiences
• Design debt
• User frustration
• Quick fixes accumulating
• Research insights ignored

What they feel:
• Pride in craft
• Frustration with compromises
• Responsibility to users
• Creative ownership
• Professional standards pressure

This is why they:
• Push for perfection
• Resist quick solutions
• Need research time
• Get emotional about details
• Fight for user testing
9/ Business/Strategy Teams: The Number Crunchers

What they see:
• Unit economics
• Market sizing
• Investment returns
• Competitive analysis
• Strategic fit

What they feel:
• Pressure for business case clarity
• Fear of poor investments
• Need for quantifiable results
• Frustration with vague value props
• Career risk from failed bets

This is why they:
• Demand detailed forecasts
• Focus on financial metrics
• Push for market validation
• Question every assumption
• Need extensive documentation
10/ The Master Key: Understanding Incentives

Every stakeholder's behavior makes sense when you understand:

• What they're measured on
• What keeps them up at night
• Who they report to
• How they get promoted
• What risks they carry

Unfortunately often the incentives are misaligned and it doesn’t help to wish they weren’t.

I spent years fighting stakeholders before learning this.
11/ The PM's Role: The Synthesizer

Your job isn't to make everyone happy.

It's to:
• Understand these perspectives
• Find common ground
• Make informed tradeoffs
• Keep everyone informed

I learned this after years of trying to please everyone and burning out.
Stakeholder management can feel overwhelming.

That's why I curated clear, contextual frameworks at - so you can find exactly what you need when dealing with specific stakeholder challenges.prodmgmt.world/products/produ…
13/ Remember:

Your job isn't just building products.
It's building trust networks.

Every stakeholder relationship is a long-term investment.

Build these bridges before you need them.

You're not just managing a product.
You're orchestrating a complex human system.
14/ Practical Application:

For each stakeholder:
1. Map their incentives
2. Listen for underlying fears
3. Acknowledge their constraints
4. Show you understand before pushing back
15/ Remember:

Everyone is trying to do their job well.

Their "unreasonable" behavior usually comes from:
• Misaligned incentives
• Different time horizons
• Incomplete information
• Personal career risks

Understanding this changes everything.
Get instant access to stakeholder-specific conversation templates and frameworks by grabbing my AI prompts collection: )prodmgmt.world/products/ai-pr…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with George from 🕹prodmgmt.world

George from 🕹prodmgmt.world Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @nurijanian

Sep 20
Technical folks transitioning to product often struggle with strategic thinking.

Not because they can't think strategically.

But because they're stuck solving the wrong problems.

After mentoring a few bring PMs, here's what actually works for developing strategic thinking🧵
1/ First, let's destroy a myth:

"Strategic thinking means having a grand vision"

No. Strategic thinking starts with being comfortable in the problem space before jumping to solutions.

I made this mistake for 2 years as a PM, trying to come up with solutions before understanding problems.
2/ The hard truth about strategic thinking:

Your technical background isn't holding you back.

Your solution-first mindset is.

Engineers are trained to:
- Find optimal solutions
- Reduce ambiguity
- Fix what's broken

Product strategy requires:
- Finding valuable problems
- Finding leverage and real hurdles
- Getting comfortable with ambiguity
- Deciding what NOT to fix
Read 17 tweets
Sep 18
My first year as a PM, I burned bridges by saying 'no' wrong:

- Lost eng team trust
- Damaged stakeholder relationships
- Got labeled as 'not a team player'

Until I discovered this counterintuitive approach to saying no (that actually builds stronger relationships)

🧵
1/ The conventional wisdom is broken:
- "Just say no firmly"
- "Stand your ground"
- "Protect the roadmap"

These create adversaries, not allies.

The hard truth: Your 'no' is probably making you look weak, not strong.
2/ The real problem isn't saying no.

It's that most PMs try to win the current battle (saying no to a request) while losing the war (long-term influence).

I made this mistake for 18 months until I learned this framework:
Read 11 tweets
Sep 9
You left engineering because you were tired of:

- PMs who don't understand system dependencies
- "Product people" who can't think in flows
- Leaders who demand random features
- Roadmaps built on hope

But what if product management was actually about systems?

"Thinking in Systems" blew my mind:Image
1/ Most technical people are trained to see the world as a series of cause-and-effect relationships:

- Input → Process → Output
- Problem → Solution
- Bug → Fix

But products are systems, with:

- Multiple feedback loops
- Delays
- Unintended consequences
2/ Meadows taught me why obsessing with the "parameters" (features, specs, technical details) ranks as the LOWEST leverage point in any system.

The highest? Mental models and system goals.

PMs, take note 😅
Read 12 tweets
Sep 3
Stop asking engineers for estimates.

Basecamp eliminated them entirely with Shape Up because estimation is the wrong question.

When you ask "How long?" you should ask "How much time is this worth?" 🧵
You ask: "How long will this take?"

Engineer says: "2 weeks"

3 weeks later: "Just need a few more days"

4 weeks later: "Almost done, ran into some edge cases"

Every PM has lived this nightmare.
Most PMs blame:
• Poor estimation skills
• Lack of experience
• Not breaking work down enough
• Unclear requirements

So they add more process. More planning. More granular tasks.

The estimates get worse.
Read 11 tweets
Sep 2
Your product leader doesn't care about technical debt.

The business case that changes their mind: 🧵
Most engineers-turned-PMs present technical debt like this:

"We need 3 sprints to refactor the user service. The code is unmaintainable."

CEOs hear: "Engineers want to play with code instead of shipping features."
Instead, translate technical problems into business language:

**Risk × Time × Cost = Business Impact**

Every piece of technical debt creates measurable business consequences. Show those consequences, not the code.
Read 8 tweets
Sep 1
Ah, a PM joining an established team

Eager to make an impact. Ready to use your PM skills

But then reality slaps you:
🚨 Engineers already own the roadmap
🚨 They have years of context you don’t
🚨 And they don’t seem to need you

How do you earn trust & find your voice? ↓
I made this mistake repeatedly in my first years as a PM.

Joining teams with established dynamics, I'd immediately try to "add value" by:

- Questioning their roadmap
- Pushing for more discovery
- Inserting PM frameworks

The result? Quiet resistance and damaged relationships.
You want to make an impact quickly.
The team wants confirmation they hired someone who understands their world.

But here's what I've learned after 7+ years and multiple team transitions:

First impressions aren't about your PM skills - they're about trust.
Read 18 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(