Product managers spend 80% of their time talking to people. That could mean meetings, emails, or working through product plans.
Communication is central to the role. But when you look for advice on how to do it well, most of it falls flat. You’ll hear things like “Be concise” or “Tell stories,” but that doesn’t help much when you’re managing a tough conversation or trying to align a cross-functional team.
What matters more is knowing how to change the way you communicate depending on what’s needed. Great product managers don’t stick to one style. They adjust and choose the right tool for the job.
A hammer works for nails, but it won’t help you cut wood.
Communication works the same way. One approach won’t fit every situation.
I’ve spent the last ten years working with product teams and learning from others in the field. I’ve also spoken with product managers at companies like Monzo, Amazon and Meta during networking events. One thing keeps coming up.
The moments that shape decisions and move work forward usually fall into four types of communication:
- Pitching a vision to bring people on board
- Translating between teams that use different language
- Negotiating when priorities compete
- Storytelling to help everyone see the bigger picture
1. The Pitch: Selling Your Vision
Pitching is one of the most useful skills a product manager can learn, but it rarely gets the attention it deserves. You can come up with a brilliant idea, but if you can’t explain it in a way that makes people care, it won’t go anywhere.
A strong pitch doesn’t rely on being persuasive or clever. It’s about making people feel confident enough to back your idea.
Different people need different kinds of reassurance:
- Executives want to know if the idea is worth the investment .
- Engineers need to believe it’s possible to build.
- Designers care about how users will feel when they use it.
A good pitch answers these questions clearly, without drowning everyone in detail.
Start with the problem, not the feature
One common mistake is jumping straight into what you want to build. A better way to start is by focusing on a problem your audience already recognises. That creates interest and shows that the work matters.
Take this example: saying “We should build dark mode because users want it” sounds vague, and there’s no reason to act now.
Instead, try this:
“23% of our users access the app at night. 15% of them leave within 30 seconds because the screen is too bright. This is costing us around £500,000 a year in lost engagement. A dark mode could help us win back half of that.”
This version is stronger because it connects the problem to a real cost. People tend to act faster when they’re losing something (loss aversion). Using numbers, even rough estimates, makes the argument feel more concrete and concise.
When a PM at Airbnb pitched a fix to the search experience, they didn’t say “Search is a bit slow.” They said that “every 100 milliseconds of delay was costing the company £2 million a year in bookings.” That got people’s attention.
Speak to what people care about
Every audience has different concerns. Some care about money. Others are focused on the user experience or risk. Your message should reflect that.
If you’re speaking to executives, highlight the financial impact (Revenue/Cost).
For example: “This feature could unlock £1.2 million in enterprise sales.”
Designers or marketers might respond better to emotional value (Psychology).
You could say: “This update will give users a smoother, more delightful experience. Here’s a quick demo…”
For legal or compliance teams, it helps to flag what could go wrong (Risk/Cost of Inaction).
Try: “If we don’t fix this issue, we could face a serious GDPR fine.”
Tip:
Use the “Money, Magic, or Risk” Framework from Marty Cagan to tailor your pitch to your audience. You can also mix these themes when it makes sense.
For example:
“This AI help assistance could save customers five hours a week, which makes a huge difference to them. It also reduces our support load by 30%.”
Address concerns before they come up
Questions always come up. That’s part of the process. What matters is how you handle them as a PM.
A common objection is: “This isn’t a priority.”
You might respond with: “That’s fair. But it could be affecting our key metrics. Let’s test it and find out.”
When people raise concerns about time or resources, offer a small, low-risk starting point.
For example: “Let’s build a quick prototype over the next two weeks and see if there’s real interest.”
If the idea feels risky, show how you’ve planned to manage that risk. A product manager at Revolut knew engineers would worry about mistakes in their fraud detection system.
They opened their pitch with this line: “We’ll start with just 1% of users. If we see more than 2% false alarms, we’ll pause and reassess.”
Keep your visuals simple
A strong pitch doesn’t need dozens of slides. One clear visual is enough. Show the problem in a sentence, add a sketch or diagram to show the idea, and include a quick summary of what you need. That might be two engineers for six weeks, or approval to run a test.
When Slack pitched threaded messages, they showed three things. First, a quote from a user: “I lose track of conversations in busy channels.” Then, a simple mock-up of how threads would work.
Finally, a timeline: three months for a working version, six months for full release.
Always end with a clear ask
Your pitch should lead somewhere. Make it obvious what you’re asking for. That might be approval to start a prototype by next Friday. Or it could be two engineers for four weeks to build a first version.
Give people a deadline so things don’t stall. For example: “If no one raises any concerns by Friday, we’ll take that as a yes and begin.” This keeps momentum going and gives your team something concrete to work from.
2. The Translation: Bridging Gaps Between Teams
This is where strong product managers stand out. The role sits between design, engineering, and business teams. These groups often approach the same problem in very different ways.
Engineers focus on scalability, edge cases, and technical debt. Business teams care about growth targets, timelines, and customer demands. Designers think about the user experience, how things look, and whether the product feels right.
Your job isn’t to pass messages back and forth. It’s to reframe problems so that each team sees how the concerns of others connect to their own goals.
Spot where things break down
Misalignment tends to happen in many organisations and you may have come accross these:
- Business leaders say, “We need this live by next week.”
- Engineers push back with, “Not unless we cut corners.”
- One team says, “This feature is too complex,” while another insists, “Users expect it to be seamless.”
At Deliveroo, product managers help teams stay aligned by reframing problems so everyone sees the same goal.
When restaurant partners raised concerns about late orders, the engineering team was focused on route optimisation.
A product manager linked the two by showing how better prep-time accuracy would help drivers arrive at the right moment, which could reduce late deliveries by 30%.
This made the technical work feel directly tied to partner satisfaction and business results.
Learn to speak clearly across functions
When you’re passing business needs to technical teams, don’t be vague. Avoid saying “Sales says clients want bulk exports.” That sounds like a passing comment.
Try:
“Enterprise clients are exporting data manually 20 times a week. This wastes around 10 hours a month. Can we automate that without breaking GDPR compliance?”
Now the team has a clear task and a reason to care.
The same principle applies in reverse. Instead of saying “We need to refactor the checkout API,” link the technical work to business outcomes:
“If we don’t refactor, adding PayPal will take eight weeks instead of three. That could delay Q3 revenue by £250,000.”
You can also lay out trade-offs visually:
- Patch it now: saves £50,000 short-term, increases long-term debt
- Refactor now: costs £20,000 up front, saves £200,000 over time
This ensures the discussion is based on facts, not assumptions.
Help teams see the whole picture
People push back when they don’t understand the reason behind a decision. Your job as a PM is to connect the dots.
Start with user stories that cut across roles. Instead of handing design a visual change and engineering a code update, focus on the shared problem behind both.
“Users are missing this button because it blends in with ads. Can we test a higher-contrast version that won’t slow page load?”
This gives everyone a shared outcome to focus on.
Add written context to your decisions. A product manager at Monzo stopped ongoing debate by sharing a short summary:
“Why we’re prioritising this feature: Business impact is £500,000 a year if 10% of users adopt it. Tech risk is low using existing APIs. User risk is moderate, so we’ll run an A/B test.”
This made the decision clear and reduced unnecessary back-and-forth.
3. The Negotiation: Managing Conflict
Conflict is part of the job. Engineers push back on scope. Sales asks for last-minute features. Designers want more time to get the details right. You can’t avoid these moments, but you can manage them in a way that protects both your product and your working relationships.
Negotiation in product management is all about understanding what people care about, balancing solutions, and keeping trust in place for the next round of decisions.
Step 1. Turn “No” Into “Yes, If”
When a request comes in, look for a way forward that still protects your priorities, instead of saying no.
Let’s say Sales comes to you and says they need a custom feature for an important client. You tell them it’s not on the roadmap and shut down the conversation. Now you’ve got a standoff.
A better response might be: “We can build it if the client commits to a £20,000 annual plan and the feature also works for at least three other customers.” That opens up a real conversation about value, scale, and priorities.
SaaS companies sometimes take on custom feature requests, but only when they support wider business goals. That might mean bringing in new revenue, solving a problem shared by other customers, or turning the work into a paid feature later.
For example, some e-commerce platforms have built one-off solutions for clients, then reused that work as part of their premium plans.
Saying “yes” shows you’ve listened. Adding “if” ties the request to a shared goal, like revenue, reuse, or long-term impact.
Step 2. Show Trade-offs Visually
Teams get stuck when they see decisions as yes or no. Visual trade-offs help them see the space in between.
Use a simple whiteboard or screen share. Lay out the options clearly.
For example:
- Option A launches in two weeks with basic styling
- Option B takes six weeks but includes animations and thorough testing
You could also compare scope and stability. Five features may increase risk. Two features may feel limited but ship with more confidence.
Ask the team to weigh the options. When they make the trade-off, they’re more likely to stand by the result.
At the BBC, product managers have used simple visual trade-offs to help teams work through tough decisions. One example was choosing between launching in time for a major event or spending more time on visual polish. By laying out the impact of each option, the team aligned on what mattered most. They shipped on time and added the extra details later.
Step Focus on the Problem, Not the Person
Argumentts can get heated when people take things personally. You can prevent that by shifting the focus.
Instead of saying someone is ignoring user feedback, ask how you can align the feature with what users have requested for. Reframe it as a shared challenge, not a personal mistake.
When you’re stuck, ask for help. Say, “I’m not sure how to solve this—what would you do?” This brings people into problem-solving mode and often reveals blockers they haven’t said out loud, like legal or compliance teams who won’t approve a certain flow.
Sometimes, the best move is to acknowledge emotion directly. If someone seems frustrated, say so. Ask what’s their biggest concern. This shows you’re listening and not brushing past the tension.
Use Facts Not Opinions
When someone says a feature is critical, check whether your top customers have asked for it. If they haven’t mentioned it and it is not mandated (regulatory), that tells you something.
Time constraints can be addressed in the same way. Point to similar work and show how long it took. Break down the steps so people understand the effort involved.
External research can also help. Quoting a source, like a survey showing that 60 % of users expect the feature, adds weight without sounding personal or biased.
Know When to Escalate
Some disagreements can’t be solved in your group. When that happens, escalate with care.
Start by summarising clearly. Say, “We’ve discussed this for two weeks. Engineering is concerned about performance. Sales is pushing for the extra feature. If we don’t decide soon, we’ll miss the deadline.”
Then outline two or three realistic options. You might suggest pushing the launch or removing a feature. Let senior leaders choose the direction and take responsibility for the impact.
How Netflix Handles Priority Battles
At Netflix, product managers use a method called Priority Poker. Everyone on the team scores projects from one to ten, based on impact. Once the scores are in, the product manager shows where the biggest gaps are.
If engineering gives something a three and marketing gives it a nine, that’s the start of a useful conversation. Teams talk through the differences, and often, hidden priorities surface—like a legal requirement that no one mentioned before.
This process works because it makes each team explain their view. It also gives everyone a say before decisions are made.
4. The Story: Creating Shared Understanding
A good story gives context to the numbers. Instead of saying, “20 % of users drop off after sign-up,” describe what that looks like. “Users land on the dashboard, don’t know what to do next, and close the app within 30 seconds.” That picture stays with people. It also helps teams ask better questions about what to fix.
Stories are useful in meetings, strategy documents, and one-on-one conversations. They cut through noise and help teams remember what matters. When everyone sees the problem the same way, it’s easier to agree on what to build next.
Structure Your Story Like a Hero’s Journey
The best product stories follow a simple pattern. Start with a person facing a real problem. Show what’s making their job harder. Then explain how your product changes that. Finish by showing why the fix matters.
Take Maya, a nurse who uses three different apps to manage her shifts. She loses five hours a week sorting out mistakes. Your tool replaces that with one reliable schedule. Without it, her hospital keeps wasting £200,000 a year on overtime. The story is simple, specific, and tied to outcomes that matter.
Pair Data with Emotion
Numbers alone will not move people. To drive action, combine the data with real user experiences. Instead of saying “30% of users drop out at step two of checkout,” explain what’s happening.
Then bring it to life with a direct quote. A user might have said, “It felt like a scam! You asked for my ID before showing the price.” That’s the detail people remember.
Use quotes from interviews wherever you can. Add photos from testing sessions if appropriate. Help the team see and empathise with the user, not just the metric.
Make Your Stories Visual
A story has more impact when people can see what you mean. Use simple visuals to highlight real problems and show what’s changed.
At a large e-commerce company, a product manager had to show why checkout speed mattered. She began with a graph that showed how even small delays in page load time led to fewer completed purchases. Then she played a short video of a real customer trying to check out, clearly frustrated as the loading wheel dragged on. To wrap up, she shared two mockups side by side. One showed the old, slow-loading page. The other showed a redesigned version with a progress indicator and clearer feedback. The new version felt smoother, even though the actual speed hadn’t changed yet.
Share Stories About When Things Go Wrong
Being open about failure builds trust. It also helps teams avoid making the same mistake twice. Instead of writing vague post-mortems, share a clear story about what went wrong and what you learned from it.
A strong failure story names the key issues without blaming individuals. It ends with the actions you’ll take next time. You might admit that you ignored warning signs. User testing showed people were confused, but you shipped the feature anyway. Engineers flagged concerns about technical debt, but you overruled them. You skipped A/B testing and pushed the final version live.
Now, you run user tests before development starts. You lock scope after the first week to stop last-minute changes from derailing the team.
A Slack product manager shared a story about building threaded direct messages. The team thought it was something power users wanted. After launch, they realised most people just needed faster search. That mistake led them to introduce small paid pilots before investing in new features.
Edit Your Stories Ruthlessly
A good story is short and clear. It makes one point. It explains why something matters. It ends with a specific next step—like asking for time, resources, or a change in direction.
Try trimming your next story to fit in a tweet or post. Boil it down to 280 characters. Then imagine explaining it in a 30-second voicemail to your Senior Executives. These constraints help you focus on what’s essential and cut everything else.
Telling clear, human stories is one of the most valuable skills you can build as a product manager. It helps you explain why something matters, even when your audience doesn’t know the full context.
Start with a real person. Describe their problem. Show how your solution makes a difference. Then explain why that outcome matters to the business, not just your team.
The best stories feel specific and personal. That’s what people remember. Not broad trends. Not spreadsheets. Real situations, explained simply. That’s what leads to action.
How to Train Your Communication Skills
Strong communication is learned, not inherited. Great product managers build it over time through consistent practice. Below are exercises and tools that will help you improve in four core areas.
Practise Your Pitch
Record a 90-second video explaining a feature idea
Choose a fictional feature like AI-powered expense reports. Record a short pitch using Loom. Keep it under 90 seconds and focus on three things:
- Did you lead with the problem before introducing the solution?
- Did you tie the idea to money, innovation, or risk reduction?
- Did you end with a specific ask, such as needing two engineers for four weeks?
Watch the recording and be honest with yourself. Would you approve it if you were the decision maker? If not, record it again until the answer is yes.
You can also use Otter.ai to review how you speak in real meetings. Look at how much you listen compared to how much you talk. Strong communicators are clear, but they also know when to step back and hear others out.
Build Your Negotiation Muscles
Practise saying no to important peopl
Set up a role play in which your CEO asks for a last-minute feature and your team says it can’t be done. Your job is to hold the line while keeping trust intact.
Use the “yes, if” approach. Say yes, but only if they agree to delay the launch by two weeks or drop other features to make room.
After the session, debrief.
- Did you explain the trade-offs clearly?
- Did you defend the team’s limits without harming the relationship?
Create trade-off sliders in a tool like Miro. Show how speed relates to scope or how cost links to quality. When people see the options laid out, they understand the impact of their choices.
Make Your Metrics Tell a Story
Turn boring numbers into something people care about
Start with a single data point, such as a 15% increase in churn. Then turn it into a short, visual story.
Use a three-panel format:
Panel 1: Show a frustrated user saying, “This is too confusing.”
Panel 2: Show a simple graph with churn rising.
Panel 3: Show your solution, with a quote like, “Onboarding is much clearer now.”
This helps you connect real user pain to the numbers and link the data to your response. Tools like Canva’s comic strip templates can make this process faster. The visual constraint forces you to focus on what matters most.
“Oh”, One last thing
You don’t need to improve everything at once. Choose one skill to work on this week and practise it with intention.
- If pitching needs work, record a Loom video.
- If translation is your gap, rewrite a spec in plain English.
- If negotiation feels weak, run a role play.
- If storytelling needs polish, sketch a simple user story with data.
Top class PMs treat communication as a skill to hone, not an innate talent. Your technical ability may land the job. Your ability to explain clearly, negotiate fairly and inspire action will take you further.
Every meeting is a chance to improve. Every conversation is an opportunity to practise. Start small, stay consistent and measure your progress.
