🗣️The Languages of Product Management
Great PMs speak engineer, designer, marketer, and exec — fluently. Mediocre PMs speak only their native tongue.
Your job is largely translation: turning customer pain into engineering spec, engineering reality into exec narrative, design intent into sales talk track. The PMs who can fluently move between five different professional dialects scale 10x faster than those who can't.
Every function in a company speaks a different professional language. Engineers want technical precision and constraints. Designers want context and creative space. Sales wants concrete promises tied to revenue. Execs want narrative and metrics. Customers want outcomes, not features. The PM is the only role that has to speak all five — natively.
The five languages
Engineering
What they need to hear: Specifics. Constraints. Trade-offs. "When you say 'fast', what's the p95 latency target?" If you can write a PRD that an engineer can build from without coming back with 20 clarifying questions, you're speaking their language. Engineers respect PMs who have considered edge cases and don't change their minds weekly.
Design
What they need to hear: The problem, not the solution. "Users are abandoning the checkout flow at step 3" beats "let's redesign step 3 with a progress bar." Designers want to be given a problem and the creative latitude to solve it. They want context (user research, data, business goals) and they want their craft respected.
Marketing
What they need to hear: The story. The differentiated value prop. Who it's for. Marketers want to know how to position the launch, what to put in the email, how to brief the agency. Give them the narrative, not the changelog.
Sales
What they need to hear: Concrete capabilities tied to deals. "We're shipping SSO in Q2" is what sales needs to hear, with realistic timing. Sales also wants the carve-out: "this isn't ready for enterprise yet — don't promise it on the call." Be honest about what's ready.
Executives
What they need to hear: Strategic narrative + sharp metrics. Execs scan documents for the headline; they want to know what the bet is, what the team is investing in, what'll move, when, and what could go wrong. Don't bury the lede.
Customers
What they need to hear: Outcomes, not features. "Save 4 hours a week on reconciliation" beats "automated CSV import." Speak in their language and their pain, never in your internal terms.
The translation trap
Junior PMs default to their native language. If you came from engineering, you write PRDs that read like architecture docs and confuse marketing. If you came from consulting, you write strategy decks that frustrate engineers because there's no spec. If you came from design, you write briefs that are aesthetic but skip business context.
The fix: for every important communication, ask "what does the listener need to hear, in their language, to act?" Then write that — not what's comfortable for you to write.
Practical tactics
- Keep two versions of your roadmap. One for engineers (specifics, dependencies, scope) and one for execs (themes, outcomes, big bets). Same content, different language.
- Pre-write launch comms during the build, not after. When you write the marketing one-liner before the feature is built, you find the spec problems early.
- Sit with each function for a week, once a year. Spend a week shadowing a salesperson; a week with a support agent. The dialect literacy you gain is permanent.
Real-world examples
Stripe is famous for hiring PMs who can read code and write technical docs that engineers want to use. The company also pioneered writing user-facing API docs as a first-class PM output — translating between the engineering and developer-customer languages.
Apple PMs are closer to product marketing than engineering. The PM role at Apple emphasizes the narrative, the launch story, the press headline. The technical depth often sits in engineering leadership rather than the PM.
Go deeper — recommended reading
Interview questions (1)
Q1Walk me through how you'd communicate a delayed launch to (a) engineering, (b) sales, and (c) the CEO.behavioralmid▼
Three different conversations.
Engineering: technical, blameless, forward-looking. "The integration with vendor X took 3 sprints longer than estimated. Here's what we learned: [specifics]. We're now confident on the new timeline because [evidence]." Engineers want to know you understand the root cause and aren't going to repeat the mistake.
Sales: practical and consequence-focused. "The launch slips from June 1 to July 15. Here's the impact on the deals you've committed: [list]. Here's what we recommend you tell customer X (the one with the contract clause)." Give them the words they need to use.
CEO: narrative and decision-focused. "We're slipping the launch six weeks because of a vendor dependency. Three options: ship without feature Y on the original date, ship with Y on the new date, or descope Y entirely. Recommend option B because [reason tied to strategy]. Asking for your call by Friday." Lead with the headline and the ask.