Stop Talking Like a Product Manager
PMs say "discovery." CFOs hear "wasting time." The gap isn't vocabulary, it's credibility. Here's how to translate the same work into language executives actually trust.
Last week I came across a very interesting LinkedIn post from Ed Biden, the founder of Hustle Badger and a seasoned product manager. What truly caught my attention was his post’s emphasis on a simple yet transformative concept for product managers: adopting a business mindset. This topic is crucial for all PMs, which is why I decided to go deeper into it.
The Translation Problem Nobody's Teaching
Most product managers learn frameworks. RICE for prioritization. Jobs-to-be-Done for research. North Star metrics for strategy. These frameworks are good. They create structure. They help teams make better decisions, but they also create a vocabulary gap. Basically, what happens is…
😃 You prioritize using RICE.
😒 Finance hears “more process, no commitments.”
😃 You validate hypotheses.
😒 Sales hears “we’re not building yet.”
😃 You improve user engagement.
😒 Your CFO thinks “great, when does that turn into revenue?”
Here’s what I got wrong for years: I thought if I just explained the frameworks better, executives would understand why they matter. I’d walk through the RICE scoring. I’d show the research plan. I’d defend the iteration cycles.
Nobody cared.
They didn’t need to understand my process. They needed to know whether I was reducing risk, driving revenue, or improving efficiency, the same lens they use for every other strategic decision.
Your job isn’t to educate them on product terminology. Your job is to translate your work into the language they already use for capital allocation, ROI, risk management, competitive positioning.
In the same way I’ve watched product leaders present solid work: rigorous research, thoughtful prioritization, deliberate iteration; and lose the room in five minutes. Not because the work was weak. Because they described it in language that sounded like avoidance to executives focused on revenue, pipeline, and quarterly commitments.
Talking to commercial teams can be less credible because they are pragmatic and solution-oriented. When you speak as a PM, commercial teams don’t just perceive you as using different terminology; they interpret it as you being preoccupied with irrelevant matters. It’s crucial for PMs to maintain the trust of commercial teams, as losing their trust can have detrimental consequences.
The fix isn’t to dumb things down. It’s to describe the same work in terms the business already uses.
What Fluent Translation Looks Like
Here’s the disconnected situations I see most often:
Product manager in a planning meeting: “We need to do discovery before we commit to building this feature. We want to validate that users actually need it and understand how they’d use it.”
What the sales VP hears: “We’re going to talk to customers for six weeks instead of building the thing they’re asking for. Meanwhile, I’m losing deals.”
What the CFO hears: “We don’t know if this will work, but we want budget anyway.”
Now watch what happens when you translate:
Same product manager, different framing: “Before we invest $200K in development, we’re doing due diligence with our top 10 enterprise accounts. We’re testing whether this feature actually closes deals or if it’s a nice-to-have that won’t move our win rate. We’ll know in three weeks whether the ROI justifies the investment.”
Same work. Different language. Completely different reception.
You just reframed discovery as:
Risk reduction (testing before investing)
Capital allocation discipline (due diligence on ROI)
Revenue-focused decision-making (will this close deals?)
That’s not spin. That’s accurate. Discovery is due diligence. Prioritization is capital allocation. Iteration is learning before you commit more resources.
You’re just describing the work in terms executives use for every other strategic decision they make.
The Product-Business Translation Framework
Here’s the systematic approach senior product managers use to translate product work into business language:
Step 1: Identify the Product Activity
What are you actually doing?
Discovery
Prioritization
Research
Iteration
Tech debt reduction
Experimentation
Roadmap planning
Be honest about the work. The goal isn’t to hide what you’re doing. It’s to frame it accurately in business terms.
Step 2: Translate to Economic Meaning
What is the economic function of this activity?
Every product activity serves a business purpose:
Discovery = Due diligence on investment decisions
You’re reducing the risk of building the wrong thing
You’re validating ROI before committing resources
Prioritization = Capital allocation optimization
You’re directing resources to the highest-return opportunities
You’re making explicit trade-offs about what not to fund
Research = Risk reduction through information
You’re improving the quality of strategic decisions
You’re identifying cheaper ways to validate assumptions
Iteration = Staged investment based on learning
You shipped v1, gathered data, now you have an informed business case for v2
You’re treating uncertainty with appropriate capital discipline
Tech debt = Infrastructure investment for velocity
You’re removing friction that slows future development
You’re trading short-term capacity for long-term speed
This isn’t spin. This is what these activities actually do economically.
I learned this the hard way. Early in my career, I presented a tech debt initiative as “improving code quality.” Engineering nodded. Finance looked confused. Sales checked their phones.
I tried again: “We’re investing 20% of this quarter’s capacity to remove the bottleneck that’s making features take 3 months instead of 6 weeks. By Q3, we’ll ship 2x faster.”
That version got funded. Same work. Just framed as a velocity investment with a clear ROI timeline instead of a quality improvement that sounded nice but vague.
Step 3: Connect to Business Metrics Leadership Cares About
Now link the activity to metrics executives track:
Revenue metrics:
Pipeline growth
Win rate
Average deal size
Time to close
Expansion revenue
Cost metrics:
Cost per acquisition
Support costs
Development velocity
Time to market
Resource efficiency
Risk metrics:
Churn rate
Technical debt as % of capacity
Compliance risk
Competitive vulnerability
Your research isn’t improving “user experience.” It’s removing the #1 objection in your sales process (which you know because you analyzed lost deals).
Your iteration isn’t about “continuous improvement.” It’s about shipping fast to learn before competitors catch up, then investing in the winners.
Step 4: Present as a Business Decision Story
Frame your work as a narrative executives recognize:
What we did: We invested [X resources] to test [specific assumption]
What we learned: Here’s what the data shows [specific findings tied to business metrics]
What decision comes next: Based on this, here’s the investment case for [next step], or here’s why we’re stopping
This is how every other part of the business communicates strategic work. Sales doesn’t report “we had conversations.” They report pipeline generated and deals closed. Finance doesn’t report “we analyzed data.” They report cost savings identified and risk reduced.
Product should do the same.
The Translation Guide
Here’s the practical vocabulary shift:
You’re doing the exact same work. You’re just describing it in language that makes the business logic obvious.
How Amazon Does This
Amazon product teams are famous for their “working backwards” process. Instead of starting with technical ideas, teams begin with a press release and FAQ document describing the customer value and business impact before development begins.
This isn’t ceremony. It’s forced translation.
By starting with the press release, teams answer the questions executives care about:
What customer problem does this solve?
Why does it matter commercially?
How does this improve the business?
The FAQ addresses the objections:
What’s the investment?
What’s the return?
What’s the risk if we don’t do this?
By the time engineering begins, the product idea is already framed as a business outcome, not a technical experiment. This discipline allows Amazon to run thousands of product initiatives while maintaining alignment with leadership priorities.
The lesson: The most effective product organizations don’t just build products well. They frame product decisions in the language of business outcomes from day one.
When Translation Fails (And Why)
I’ve seen three common failures and made most of them myself:
1. Translation Without Substance
You reframe your work in business language, but you can’t actually connect it to business metrics. You say “this improves our win rate,” but when pressed, you can’t explain the mechanism. You’re just guessing it helps sales somehow.
Translation without substance is worse than PM-speak. It’s credibility suicide.
I did this once in a board meeting. Said our new onboarding flow would “drive expansion revenue.” Board member asked how. I froze. I had no mechanism. I was just hoping better onboarding would somehow lead to upsells.
It didn’t. The board remembered.
Fix: Only translate claims you can defend. If you can’t connect the work to revenue, cost, or risk with a clear logical chain, do more work until you can.
2. Over-Translation into Sales Language
Some PMs swing too far. They frame everything as immediate revenue impact, even when that’s not the primary value. You’re reducing tech debt. That’s not going to show up in next quarter’s bookings. It will show up in development velocity over the next year.
Don’t fake a direct revenue connection when the actual value is cost reduction or risk mitigation.
Fix: Be honest about the type of business value. Revenue isn’t the only thing that matters. Cost reduction, velocity improvement, and risk mitigation are legitimate business outcomes. Frame them accurately.
3. Translation Only at Presentation Time
You do all your product work in PM language, then try to translate at the executive presentation. It’s surface-level. Executives smell it. The best product leaders don’t just translate their work, they think in both languages simultaneously.
When they do discovery, they’re already thinking: “This is due diligence on a $500K investment decision.” When they prioritize, they’re thinking: “This is capital allocation, we’re funding the highest-return opportunities and explicitly choosing not to fund these others.”
Fix: Practice thinking in business terms while doing product work, not just when presenting it. The translation becomes natural.
Making Business Mindset Your Default
Here’s how to build this skill:
1. Attach Every Product Activity to a Business Decision
When you plan discovery, write down:
What investment decision does this inform?
What’s the cost of being wrong?
What business metrics will change if we’re right?
When you prioritize, write down:
What resources am I allocating?
What’s the expected return on each option?
What am I explicitly choosing not to fund?
2. Use Business Metrics in Your Product OKRs
Don’t write: “Increase engagement by 20%”
Write: “Reduce churn from 5% to 3%, retaining $2M in ARR”
Don’t write: “Improve user satisfaction score”
Write: “Increase Net Promoter Score from 40 to 50, reducing CAC by $200 per customer”
3. Rehearse Your Translation
Before any executive presentation, practice describing your work without PM jargon. Record yourself. Listen back. Every time you hear a PM-specific term, reframe it in business language.
I still do this. Every time. (You’d think after 13 years I wouldn’t need to. You’d be wrong.)
4. Study How Other Functions Communicate
Read how sales presents pipeline reviews. Read how finance presents budget requests. Read how operations presents efficiency improvements.
Notice how they frame decisions, how they quantify impact, how they handle uncertainty.
Product should sound like those functions—disciplined, metric-driven, outcome-focused, not like a different species.
What Changes When You Get This Right
When you master translation, three things happen:
1. You earn trust faster
Executives don’t see you as “the product person doing product stuff.” They see you as a strategic function managing capital allocation and risk—just like every other senior leader.
2. You get more autonomy
When leadership trusts you’re making business-aligned decisions, they stop micromanaging your roadmap. They trust you to prioritize like a business leader, not like a technician following a framework.
3. You influence more
When you speak the business language fluently, you’re not just reporting what product is doing. You’re participating in strategic decisions about where the company invests, how it competes, where it takes risk.
That’s the difference between order-taker and strategic partner.
The Real Skill
The best product managers I’ve worked with are bilingual. They do rigorous product work: proper discovery, thoughtful prioritization, continuous learning. And they describe it in terms the business uses to make every other strategic decision: revenue, cost, deals, risk, ROI.
They’re not “dumbing it down.” They’re being more precise. Business language is more concrete than product language. It forces you to connect your work to outcomes that actually matter.
When you say “we need to iterate,” that’s vague. When you say “we shipped v1 for $50K, learned that 60% of users need X capability, and here’s the $150K business case for v2,” that’s specific.
Translation isn’t about hiding what you do. It’s about making the value obvious to people who don’t live in product frameworks all day. If you want executive buy-in, translation is your job. Not theirs.
✌️
Need help translating your product strategy into business outcomes? I work with product leaders who want to earn executive trust and drive real business impact. If your product work isn’t getting the buy-in it deserves, let’s talk.