Rasp logo

Rasp

Translating Between Stakeholders: What Sales Really Means When They Say 'We Need This Yesterday'

•By Rasp Team

"We need this yesterday."

"This is blocking a huge deal."

"Everyone is asking for this feature."

If you're a product manager, you've heard these phrases a hundred times.

Here's the secret: stakeholders rarely say what they actually mean.

Sales says "we need this yesterday" — but what they mean is "I promised a customer something I shouldn't have."

Marketing says "we need more features to announce" — but what they mean is "I'm struggling to differentiate us."

Support says "this is our #1 complaint" — but what they mean is "I answer this question five times a day and I'm tired of it."

The best PMs are translators. They decode what stakeholders say, understand what they actually need, and figure out the right solution — which is rarely "just build what they asked for."

Here's your translation guide for every stakeholder you work with.

Sales Translation Guide

What Sales Says: "We need this yesterday"

What they actually mean:

  • Option A: "I told a prospect we had this and now I look like a liar"
  • Option B: "I'm trying to create urgency to close a deal"
  • Option C: "I don't understand product development timelines"

How to respond:

  1. Ask: "What's the specific situation? What did the prospect ask for and why?"
  2. Validate: "How many other prospects are asking for this? Is this a pattern or one deal?"
  3. Explore workarounds: "Can we solve their need without building a new feature?"
  4. Set expectations: "This would take 6 weeks. Let's discuss workarounds for the current deal and whether we should roadmap this."

The key: Don't react to urgency. React to data.

What Sales Says: "Everyone wants this feature"

What they actually mean:

  • Option A: "Three prospects mentioned it"
  • Option B: "One big prospect wants it and I'm extrapolating"
  • Option C: "I want this feature to make my pitch easier"

How to respond:

  1. Ask: "Can you share which prospects mentioned this? What's the total ARR?"
  2. Segment: "Was this enterprise, SMB, or both?"
  3. Validate: "Did they say they'd buy if we had this, or just that it would be nice?"
  4. Cross-check: "Let me check if support or existing customers are asking for this too."

The key: "Everyone" usually means "the last three people I talked to."

What Sales Says: "We can't compete without this feature"

What they actually mean:

  • Option A: "Our competitor's demo looked better than ours"
  • Option B: "I lost a deal and need to blame something"
  • Option C: "I legitimately see a competitive gap"

How to respond:

  1. Ask: "Which deals did we lose specifically because of this gap?"
  2. Get context: "What does the competitor's feature do that ours doesn't?"
  3. Explore positioning: "Could we position our existing features differently?"
  4. Validate importance: "Is this feature why they buy the competitor, or is it just a checkbox?"

The key: Competitive features aren't always competitive advantages.

What Sales Says: "This is blocking a $500k deal"

What they actually mean:

  • Option A: "This is actually blocking a deal" (sometimes true!)
  • Option B: "The prospect mentioned this among 10 other objections"
  • Option C: "I'm using a big number to get your attention"

How to respond:

  1. Ask: "Is this the only blocker? What else is the prospect concerned about?"
  2. Validate timing: "When do they need to make a decision?"
  3. Explore urgency: "If we commit to building this in Q2, will they wait?"
  4. Check history: "How often do deals actually close after we build the requested feature?"

The key: Big ARR numbers don't automatically make features strategic priorities.

What Sales Actually Needs (vs. What They Ask For)

What They Ask For What They Actually Need
"Build this feature" Better competitive positioning
"More features to sell" Clearer value prop on existing features
"Faster feature delivery" Better communication on roadmap
"Custom solutions for enterprise" Enterprise tier or professional services
"Match competitor feature-for-feature" Differentiated positioning

Support Translation Guide

What Support Says: "This is our #1 complaint"

What they actually mean:

  • Option A: "I personally get asked about this a lot"
  • Option B: "It's genuinely the most common ticket"
  • Option C: "It's the most annoying thing I have to explain"

How to respond:

  1. Ask: "How many tickets per week? Is it increasing or stable?"
  2. Check data: "Can we pull reports to see actual frequency?"
  3. Assess impact: "Are customers churning over this or just annoyed?"
  4. Explore documentation: "Could better docs/FAQs reduce tickets?"

The key: Support sees every complaint, so their perception might not match actual priority.

What Support Says: "Users can't figure out how to do X"

What they actually mean:

  • Option A: "The feature is confusing"
  • Option B: "Documentation is missing"
  • Option C: "Users aren't finding the feature"

How to respond:

  1. Ask: "Show me a few recent tickets. What specifically confuses them?"
  2. Test yourself: "Let me try to do X as a new user. What do I miss?"
  3. Check discovery: "Are users finding this feature at all?"
  4. Quick fixes: "Could we improve this with better labels, tooltips, or docs?"

The key: Often the fix is UX polish or better docs, not rebuilding the feature.

What Support Says: "We need to automate this workflow"

What they actually mean:

  • Option A: "I'm tired of answering the same question manually"
  • Option B: "This repetitive task wastes our time"
  • Option C: "I think I know better than PM how to fix this" (rare but happens)

How to respond:

  1. Ask: "How much time per week does this consume?"
  2. Explore interim fixes: "Can we create macros/templates while we decide if automation is worth it?"
  3. Assess ROI: "If we automate this, what's the time savings vs. engineering cost?"
  4. Validate user need: "Do users actually want this automated, or just support?"

The key: Support efficiency is valuable, but balance against product priorities.

Marketing Translation Guide

What Marketing Says: "We need more features to announce"

What they actually mean:

  • Option A: "I'm struggling to create compelling content"
  • Option B: "Competitors are launching more than us"
  • Option C: "I don't know how to market what we have"

How to respond:

  1. Ask: "What message are you trying to send to the market?"
  2. Reframe: "What if we positioned existing features differently?"
  3. Dig deeper: "Which features we already have aren't getting enough attention?"
  4. Collaborate: "Let's find the compelling narrative in our roadmap."

The key: More features ≠ better marketing. Better storytelling = better marketing.

What Marketing Says: "We need this for the launch"

What they actually mean:

  • Option A: "This would make my campaign more compelling"
  • Option B: "I promised the CEO we'd have this"
  • Option C: "I'm worried the launch will flop without it"

How to respond:

  1. Ask: "What happens to the launch if we don't have this?"
  2. Explore alternatives: "Can we position what we have differently?"
  3. Assess timing: "Can this feature come shortly after launch?"
  4. Reality check: "What's the actual impact of delaying launch vs. shipping without this?"

The key: Perfect launches don't exist. Shipped beats perfect.

Executive Translation Guide

What Execs Say: "I think we should build X"

What they actually mean:

  • Option A: "I saw something interesting at a conference"
  • Option B: "A board member mentioned this"
  • Option C: "I have a genuinely good strategic insight"

How to respond:

  1. Validate interest: "That's interesting. What made you think of this?"
  2. Connect to strategy: "How does this fit with our Q2 goals?"
  3. Gather data: "Let me research this and come back with analysis."
  4. Don't immediately commit: "I want to make sure this is the right priority. Give me a week to validate."

The key: Execs appreciate thoughtful pushback more than immediate agreement.

What Execs Say: "Why is this taking so long?"

What they actually mean:

  • Option A: "I don't understand the complexity"
  • Option B: "Board is asking me and I feel pressure"
  • Option C: "I'm frustrated by lack of visible progress"

How to respond:

  1. Provide context: "This touches 3 core systems. Here's why that's complex."
  2. Show progress: "We're 60% done. Here's what we've shipped and what's left."
  3. Explain trade-offs: "We could ship faster if we cut X and Y. Worth it?"
  4. Set expectations: "This type of feature typically takes Z weeks. We're on track."

The key: Execs want reassurance you're in control, not excuses.

What Execs Say: "Can't we just hire more engineers?"

What they actually mean:

  • Option A: "I don't understand diminishing returns of adding people"
  • Option B: "I'm frustrated by capacity constraints"
  • Option C: "Money feels easier than time"

How to respond:

  1. Explain ramp time: "New engineers take 3 months to become productive."
  2. Cite Brooks's Law: "Adding people to late projects makes them later."
  3. Offer alternatives: "We can ship faster by cutting scope or delaying other work."
  4. Be strategic: "If we hire now for Q3 capacity, that could work. But it won't help Q1."

The key: Educate on reality of software development.

Engineering Translation Guide

What Engineering Says: "This is technically complex"

What they actually mean:

  • Option A: "This will take longer than you think"
  • Option B: "We need to refactor other things first"
  • Option C: "I don't want to build this and I'm using complexity as cover" (rare)

How to respond:

  1. Ask: "Help me understand what makes this complex."
  2. Explore options: "If we scoped it down, what's the simplest version?"
  3. Validate priority: "Given the complexity, is this still the right priority?"
  4. Trust them: "What timeline makes sense given complexity?"

The key: Listen to engineering about complexity. They know better than you.

What Engineering Says: "We should rebuild this"

What they actually mean:

  • Option A: "Current system is genuinely broken and blocking us"
  • Option B: "I want to work on interesting technical challenges"
  • Option C: "I'm embarrassed by the old code"

How to respond:

  1. Ask impact: "What can't we build because of current system?"
  2. Quantify pain: "How much time per week does this cost us?"
  3. Explore incremental: "Could we improve it incrementally?"
  4. Business case: "If we rebuild, what business outcomes improve?"

The key: Balance engineering wants with business needs.

Design Translation Guide

What Design Says: "This needs a full redesign"

What they actually mean:

  • Option A: "Current design is genuinely broken"
  • Option B: "I have better ideas now"
  • Option C: "I want portfolio-worthy work"

How to respond:

  1. Ask: "What specific user problems does current design create?"
  2. Data check: "Do we have evidence users are struggling?"
  3. Incremental approach: "Could we fix the worst issues first?"
  4. Effort vs. impact: "How much time for full redesign vs. iterative improvements?"

The key: Perfect design is the enemy of shipped design.

What Design Says: "Users need more customization options"

What they actually mean:

  • Option A: "Users are asking for flexibility"
  • Option B: "I want to show design range"
  • Option C: "I'm solving for edge cases instead of core experience"

How to respond:

  1. Validate: "Which users? How often?"
  2. Complexity check: "How much does this complicate the core experience?"
  3. Progressive disclosure: "Could we hide advanced options?"
  4. Default wisdom: "What if we just picked the right default?"

The key: Flexibility often means complexity. Simple defaults usually win.

The Universal Translation Framework

When any stakeholder makes a request:

Step 1: Decode What They Actually Need

Ask yourself:

  • What's the underlying need?
  • What problem are they trying to solve?
  • Is their proposed solution the best way?

Step 2: Ask Clarifying Questions

Instead of agreeing or disagreeing, ask:

  • "Help me understand the context"
  • "What happens if we don't do this?"
  • "How many people/deals/users does this affect?"
  • "What's the timeline pressure?"

Step 3: Translate to Product Terms

Convert their language to yours:

  • Sales "we need this" → "Is this a pattern or one-off?"
  • Support "users hate this" → "What's the frequency and churn impact?"
  • Exec "this is important" → "How does this fit strategy?"

Step 4: Respond with Options

Don't just say yes or no:

"Here are three ways to solve this:

  1. [Full solution] — [Effort] — [Timeline]
  2. [Workaround] — [Effort] — [Timeline]
  3. [Alternative approach] — [Effort] — [Timeline]

I recommend [X] because [reasoning]."

Common Stakeholder Phrases & Real Meanings

What They Say What They Mean How to Respond
"This is urgent" I feel pressure Validate actual urgency with data
"Everyone wants this" A few people mentioned it Ask for specific names and numbers
"It should be easy" I don't understand complexity Educate on what's involved
"Can you just..." I'm minimizing the work Explain actual effort required
"This is critical" It's important to ME Assess importance to business
"We're losing deals" I need something to blame Check if this is actual blocker
"Users are confused" We need better UX/docs Determine if it's feature or explanation problem
"Competitors have it" I saw it in a demo Validate if it drives their success

The Translation Checklist

Before responding to any stakeholder request:

  • What's the underlying need behind this request?
  • Is their proposed solution the best way to solve it?
  • How many people/deals/users does this affect?
  • What's the real timeline pressure?
  • What happens if we don't do this?
  • Are there workarounds or alternatives?
  • Does this align with strategy?
  • What would we NOT do if we do this?

If you can't answer these, ask more questions before committing.

Real-World Example: Sales Edition

Scenario:

Sales VP: "We need Salesforce integration ASAP. We're losing enterprise deals left and right without it."

Bad PM Response:

"Okay, I'll prioritize it for next sprint."

Good PM Response:

PM: "Help me understand the situation. Which specific deals mentioned Salesforce integration?"

Sales VP: "Well, the Acme Corp deal for sure. And I think TechCo mentioned it."

PM: "Got it. So two deals. What's the total ARR?"

Sales VP: "Acme is $200k. TechCo is... they're still early stage, maybe $50k."

PM: "Is Salesforce integration the only blocker for Acme?"

Sales VP: "They also want SSO and better reporting."

PM: "If we committed to building this in Q2, would they wait? Or do they need it to sign?"

Sales VP: "They'd probably wait if we committed."

PM: "Here's what I'm thinking:

  • SSO affects multiple enterprise deals, not just Acme
  • Salesforce integration is important but affects fewer prospects
  • What if we prioritize SSO for Q1 since it unblocks more deals, and commit Salesforce for Q2?
  • In the meantime, can we manually sync data for Acme as a workaround?"

Sales VP: "That could work. Let me check if manual sync is acceptable."

Outcome: PM translated "we need this ASAP" into actual priorities, proposed better solution, and offered workaround.

Final Thought

Stakeholders don't intentionally mislead you.

They're just speaking their native language — and it's not product management.

Your job isn't to blindly execute their requests.

It's to understand what they need, translate it into product terms, and find the best solution.

Sometimes that's building what they asked for.

Often it's something completely different.

Start translating.

Your roadmap will be better for it.