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
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
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
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:
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.
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:
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