George from 🕹prodmgmt.world Profile picture
May 14 20 tweets 3 min read Read on X
Support teams think product ignores customers.
Product teams think support escalates everything.

Both are wrong.

After years of mediating this conflict, I’ve learned the real problem isn’t tools or processes.

Here’s how to fix it forever: 🔄🧵
I spent years as the buffer between our support and product teams.

Every prioritization meeting felt like UN peacekeeping.

Support: "Customers are SCREAMING about this bug!"
Product: "We can't build features if we chase every support ticket."

Both were right. Both were wrong.
The fundamental issue:

Support focuses on anecdotes; Product focuses on patterns.

Support addresses individual pain; Product seeks systemic solutions.

50 tickets overwhelm Product; Ignoring tickets makes Support feel dismissed.

This translation gap is the real problem.
Here's what transformed our relationship:

1. The Feedback River
2. The Translation Protocol
3. The Joint Prioritization Matrix

These three elements create a shared language that both teams can actually understand.
First, the Feedback River:

Create a dedicated Slack channel where ALL customer feedback flows.

- Every frustrated call
- Every feature request
- Every customer success story

Support teams post these in a structured format.
Product observes the patterns in real-time.
The River format matters:

[ISSUE TYPE] - [CUSTOMER SEGMENT] - [IMPACT]

Example:
[BUG] - [ENTERPRISE] - [BLOCKING DEPLOYMENT]
"Customer unable to bulk import users, delaying their rollout to 500 employees"

This structure transforms anecdotes into analyzable data.
Second, the Translation Protocol:

Once a week, hold a 30-minute "Translation Meeting."

The ONLY agenda: Support presents the top 5 patterns they see in the River.

Not individual tickets.
Not urgent escalations.
PATTERNS.

This forces support to do the first level of synthesis.
The pattern format:

1. "We've seen 12 customers struggle with X"
2. "This impacts mostly segment Y"
3. "The common workaround is Z"
4. "The requested solution is typically A"

Conversation goes from "Customer X is angry" to "Here's a systemic issue affecting multiple customers."
3 - The Joint Prioritization Matrix:

Create a shared framework with these axes:

X: Volume (how many customers affected)
Y: Business impact (revenue/retention risk)

Plot issues together for a shared visual language both teams understand. Support gains system thinking; Product connects to individual pain.
The support team needs to feel HEARD before they can think strategically.

Before implementing this system, we started with a "Purge Session" - 90 minutes where support could share their most painful tickets with zero judgment.

Just listening completely reset the relationship.
Common objection I hear from junior PMs:

"But my support team just escalates EVERYTHING!"

That's because they don't trust you to listen otherwise.

When there's no system, support learns that only squeaky wheels get grease. So everything becomes "urgent."
The empathy map of a frustrated support agent:

THINKING: "Product doesn't care about customer pain."
FEELING: Helpless to help customers they talk to daily.
SAYING: "This is urgent!" (about everything)
DOING: Creating workarounds rather than waiting for solutions.

They need structural validation, not dismissal.
The empathy map of a defensive product manager:

THINKING: "Support doesn't understand our constraints."
FEELING: Pulled in too many directions.
SAYING: "We need data, not anecdotes."
DOING: Filtering out support requests as "noise."

They need pattern recognition, not constant interruption.
Practical first step:

1. Make a spreadsheet with columns for:
- Issue description
- Number of customers affected
- Customer segments involved
- Business impact (H/M/L)
- Requested solution
- Current workaround

2. Do a joint session to fill it together
Second step:

Schedule a recurring 30-minute weekly meeting with one rule:

Support cannot bring individual tickets.
They must present grouped patterns of issues.

This forces the first level of aggregation to happen before product gets involved.
The transformation takes about 4-6 weeks.

What to expect:
Week 1-2: Purging of accumulated frustration
Week 3-4: First attempts at pattern recognition
Week 5-6: Genuine collaborative prioritization

Patience is required. Years of mistrust aren't fixed overnight.
Most important lesson: This isn't about tools.

I've seen teams try to solve this with expensive systems while ignoring the human translation problem.

No tool replaces the practice of teaching both teams to speak each other's language.
One communication hack that worked amazingly well:

Have product sit with support for 1 day/month.
Have support join product planning for 1 day/month.

This shared context is worth more than any formal process.
Advanced technique: The Ticket Upgrade Path

Create a clear protocol for how tickets move from "individual issue" to "product consideration."

Define exactly what information support needs to provide for product to take action.

This creates a shared expectation of what "good escalation" looks like.
Your first action: Create that spreadsheet today.

Reach out to your support counterpart and say:
"I want to better understand the patterns you're seeing."

That single sentence changes everything. From adversaries to allies.

Let me know how it goes.

• • •

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

May 18
When execs say “just whip up the PRD by tomorrow,” most junior PMs say yes... and immediately set themselves up to fail.

I did this for years until a principal PM taught me how to bridge the gap between speed and quality.

Here’s the 4-part framework I wish I had on day one:
1/ when your exec says "we need that prd by tomorrow, it shouldn't take more than a few hours" but you know it needs days of work, you're experiencing the classic product estimation gap.
2/ veterans know this happens because executives and product managers operate with different mental models of documentation.

executives think about prds as:
1. a simple description of what to build
2. a checkbox for process compliance
3. something that should be quick to produce
Read 18 tweets
May 17
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
May 17
"Documentation is killing me"

That was me 3 years ago, overwhelmed by 5 unfinished PRDs.

My ADHD brain struggled with the usual "sit down and write" method every PM book suggests.

Here's what finally worked after many failures:
1/ The Voice Note Method

Stop trying to write perfect prose immediately. Instead:

• Walk around and talk through your thoughts
• Record voice notes explaining the problem/solution
• Use Otter or Rev or many other similar apps to transcribe
• Clean up the transcription

Your brain works better in motion. Use it.
2/ The Screenshot Journal

Instead of trying to remember everything:
• Take screenshots of important Slack discussions
• Capture whiteboard photos
• Screenshot key metrics

Create a Miro board as your "evidence board"

Later, writing becomes connecting dots instead of recall
Read 11 tweets
May 16
i spent years as a pm building features nobody used until i learned the one skill elite product managers never skip: reframing the problem.

i’ll teach you in 5 minutes what took me years (and countless wasted sprints) to learn: Image
product management reality:

stakeholders hand you their framing. engineers want your framing. users have their own framing.

everyone assumes their frame is right & yours is wrong.
reframing isn't just semantic games.

it's the difference between:
- building a faster horse vs inventing a car
- adding more filters vs redesigning search
- optimizing a confusing flow vs questioning if the flow should exist

the best PMs aren't problem solvers. they're problem shapers.
Read 19 tweets
May 15
Your PRD process shouldn’t take days.

An engineer-turned-PM taught me a 30-minute workshop that changed everything.

Most PMs build PRDs backward. This method flips the script and gets instant stakeholder buy-in.

I'll break it down in 3 minutes. 🧠 Image
1/ First, understand why traditional PRD processes fail:

- Writing alone = missing context
- Reviewing later = endless feedback loops
- Sequential input = conflicting requirements

Product leaders: Your teams need psychological safety to adopt rapid documentation.
2/ The 30-minute workshop framework:

Step 1: Pre-work (5 mins)
- Problem statement draft
- Success metrics outline
- Key stakeholders identified

Don't overthink. Rough notes work.
Read 17 tweets
May 15
If you say "no" to stakeholder requests, they will get angry.

If you say "yes" to everything, your roadmap falls apart.

In my first 2 years as a PM, every "no" felt like making enemies.

Until a mentor showed me something that changed everything: Image
First, let's acknowledge reality:

Junior PMs often resort to these harmful patterns:
- Generic "not now" responses
- Over-apologetic language
- Vague prioritization excuses
- Promises they can't keep

The cost? Lost trust and credibility.
Here's what veteran PMs understand:

A rejection isn't about saying no.

It's about demonstrating:
- Strategic clarity
- Resource stewardship
- Stakeholder partnership
- Professional maturity
Read 14 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!

:(