I have been thinking about what separates the product managers who create outsized impact from the ones who are competent but unremarkable. It is not strategy. It is not technical depth. It is not user empathy, though all of those matter.
It is translation.
The best PMs I have worked with are translators. They move fluently between worlds that do not naturally communicate with each other. They take what an engineer says and translate it into what a business stakeholder needs to hear. They take what a user says and translate it into what an engineer needs to build. They take what the data says and translate it into what a decision-maker needs to decide.
This sounds simple. It is not.
Why Translation Is Hard
Translation is hard because every domain has its own language, its own assumptions, and its own definition of what counts as a good answer.
When an engineer says "that is technically complex," they mean something specific: there are dependencies, edge cases, or architectural constraints that make the feature harder to build than it appears. When a business stakeholder hears "technically complex," they often hear "the engineers are being difficult." The translation failure creates friction, erodes trust, and slows everything down.
When a user says "I want it to be easier," they mean something specific: there is a step in the workflow that requires more cognitive effort than it should. When an engineer hears "make it easier," they often hear "make it simpler": which might mean removing features that the user actually needs. The translation failure produces a product that is simpler but not easier.
The PM's job is to prevent those translation failures. To understand what each domain means when it uses its language, and to render that meaning accurately in the language of the other domain.
The Three Translations That Matter Most
In my experience, there are three translations that PMs get wrong most often.
Engineering to Business: When engineering says "this will take three months," the business hears "the engineers are slow." The PM's job is to translate: "This will take three months because it requires changes to the data model that affect five other features. Here is what we can ship in six weeks that delivers 80% of the value while we build the foundation."
User to Engineering: When a user says "I want to see everything in one place," the PM's job is not to pass that requirement to engineering. It is to translate: "The user is spending fifteen minutes per day switching between three different views to complete a single workflow. Here are the specific data elements they need to see together, and here is the workflow they are trying to complete."
Data to Decision: When the data shows a 15% drop in a key metric, the business wants to know what to do. The PM's job is to translate: "The drop is concentrated in this user segment, in this part of the workflow, and it started on this date. Here are three hypotheses about the cause, and here is what we would need to test each one."
In each case, the translation adds context that the raw signal does not contain. And that context is what makes the information actionable.
How to Get Better at Translation
Translation is a skill, and like most skills, it improves with deliberate practice.
The most effective practice I have found is to spend time in each domain before you try to translate between them. Before you translate engineering constraints to business stakeholders, spend time with engineers: not just in meetings, but in their actual work. Before you translate user needs to engineering requirements, spend time with users: not just in user research sessions, but in their actual workflows.
That domain fluency is what makes translation possible. Without it, you are not translating. You are just passing messages: and hoping that the recipient understands what the sender meant.
