skip to content

Search

Why the Best PMs Are Translators, Not Gatekeepers

Less than one minute read Updated:

The PM role is mistakenly treated as a bottleneck that controls information flow, when the real value is translating context across functions so teams can decide without waiting on a single throat to choke.

# product-management
# strategy
# leadership
# communication
Not in series

If the org falls over the week you take a vacation, you were never the PM. You were the queue.

I own the system of record under InMobi’s demand-side platform and ad exchange, the layer that reconciles ad events from 200M+ devices a day. Before that I led the platform team behind an AI creative product at Pixis through a run that went from $0 to $10M ARR in five months. Neither job survives on one person holding the whole picture in their head. Both only work because the picture gets written down and handed to people who were never in the room.

That is the argument of this post. Most organizations still hire a PM to be the person who decides what gets built, and treat every other role as a request that routes through them. Watch what that does to a team of any real size, and the gatekeeper model falls apart on its own evidence.

So that’s today’s post.

Today’s Post

Why the gatekeeper model breaks past one team, and what a translator does instead, in six sections.

  • The gatekeeper model, in the numbers
  • What actually gets translated, with the number attached
  • The habit that gives the game away: what happens without you
  • Bottlenecks don’t create discipline, they create queues
  • When the PM leaves, you find out which model you had
  • What leadership has to change for the model to survive

1. The gatekeeper model, in the numbers

A gatekeeper is not a slur, it is a design. One person holds the requirements, the customer evidence, and the executive intent, and every other role asks that person before it moves.

The design works for exactly one team, for exactly as long as that team is small. At Pixis I watched it fail past that point directly: a 12-person data platform pod, a 20-person AdRoom creative team, and a 15-person Prism co-pilot team cannot all wait on one inbox to explain what changed this week. Somebody always waits.

Two models, the same four moments One PM inbox versus one shared document. Row by row, the cost shows up in different places. Grey monospace text names the post's example of each row. INFO FLOW PM IS OUT DECISION COST HANDOFF VERDICT GATEKEEPER TRANSLATOR Every fact routes to one inbox sales, eng, legal each wait their turn calendar becomes the product Decisions stall the team waits or improvises blind nobody is allowed to think in full color Cost scales with headcount one router, three product teams at Pixis 12 plus 20 plus 15 people, one inbox Private lore, not a document replacement PM reconstructs it from scratch A single point of failure the org stutters when the PM is gone Facts live in a shared document problem brief, constraint map, decision log any team reads it without asking The team keeps working constraints were never locked in one head reason from shared facts, not lore Cost is writing the brief once 15+ interviews, one document, three teams five features kept, forty declined, on paper The map, not the map-maker research, constraints, and decisions in writing unwritten means undecided The org is the map a strong integrator leaves; the map stays what the gatekeeper model costs a cost that scales with headcount what the translator model builds a step that never happened
Same four moments, two ways of running them. The gatekeeper column gets more expensive as the team grows; the translator column does not. PNG ↓

The gatekeeper fantasy flatters everyone involved. It flatters the PM, who feels load-bearing. It flatters leadership, who gets one name to call when a number slips instead of a system to understand. Neither of those feelings is evidence the model works.

2. What actually gets translated, with the number attached

Translation is not empathy or stakeholder management. Those matter, but they are not the job. The job is moving a real signal from a form one side can read into a form the other side can act on, and the test of whether you did it is a number on the far end.

Three of these crossed my desk in the last two years. Pixis’s data platform hit 99.6% end-to-end sync reliability, with sync delay cut from 4 hours to under 15 minutes, across 400+ enterprise customers. That is an engineering SLA. Nobody in sales or finance reads an SLA. What they read is that 400+ enterprises trusted Advance’s bid and budget recommendations enough to act on them without re-checking, because the number underneath had already been translated into “you can trust this.”

What gets translated, with the number attached Three real handoffs. Each one moves a signal one side can read into a form the other side can act on. Grey monospace text is the number the translation produced. RAW SIGNAL READ BY THE OTHER SIDE 99.6% end-to-end sync reliability an engineering SLA on the data platform 400+ enterprises trust the recommendation Advance's bid calls get acted on, not re-checked Pixis data platform, delay cut from 4h to 15min 15+ voice-of-customer interviews a stack of transcripts, not a document yet 5 roadmap features, 40 declined in writing engineering builds from evidence, not a hunch Prism GTM, every launch, per interview Reconciliation pipeline, live an engineering artifact, invisible to finance Close: 5 days to 12 hours, signed by finance a number finance re-checks 12 times a year InMobi, system of record under 200M+ devices/day a translation, not a hand-off of the raw number
Each row is the same fact told twice: once in the language of the team that produced it, once in the language of the team that has to act on it. PNG ↓

The second pair ran through Prism, the co-pilot I led the GTM for at Pixis. Fifteen-plus voice-of-customer interviews became exactly five roadmap features, with the other forty declined in writing, so engineering could see the evidence behind the five instead of a PM’s hunch. The third pair is the InMobi close: a reconciliation pipeline is an engineering artifact until it becomes a number finance signs off on, and today that number is 12 hours, down from 5 days.

None of those three sentences is a soft skill. Each one is a translation with a number attached, and the number is how you know the translation actually happened instead of just getting talked about.

3. The habit that gives the game away: what happens without you

Watch a team on a Monday when the PM is not in the room, and you learn which model you are running.

A gatekept team waits. Requirements sit in a queue, engineers pause for clarification, and the pace of the week depends on whether the one person who “knows the full picture” answers Slack. A translated team keeps working, because the constraints were never locked inside a single head.

One brief, read by three teams before the roadmap locks The habit that tells you which model you are running: what happens after the interview. Scroll slowly, this plays once and settles. 15+ interviews run every launch, not just this one Prism GTM, Pixis Problem brief written user, evidence, constraint, one doc forty ideas declined on paper Shared with eng and sales before commitments harden same document, no retelling Team decides, PM absent 5 features kept, traceable to evidence no escalation needed raw signal from the customer a step of the relay, written down
Four steps, and the fourth one is the point: the team decides without you, because the brief did the work the meeting used to do. (animates as you scroll to it) PNG ↓

The relay that produces that outcome at Pixis started with the same fifteen-plus interviews mentioned above, but the sequence matters as much as the count. The problem brief gets written before the roadmap locks, not after. It goes to engineering and sales in the same form, not retold twice by the same person. By the time a decision needs making, the team has read the same document you have, so the decision does not need you in the room to be correct.

Compare that with a worked engineering handoff on this site: the fix for an adversarial PM-engineering dynamic is the same shared-context move, just one level down, before commitments harden rather than after.

4. Bottlenecks don’t create discipline, they create queues

Every gatekeeper defends the role the same way: someone has to protect the roadmap, someone has to say no. That much is true. The error is assuming the PM has to be the one holding the “no” personally, every time, for it to count.

No without context is friction. A team told “not now” with no reason attached does not get more disciplined, it gets more resentful, and it stops trying to reason about priority because reasoning was never rewarded. Yes without context is worse: it is chaos wearing a green light. The productive middle is context strong enough that a team can say no to itself, early, for a reason it can state out loud.

That is what the two-week onboarding sprint at Pixis actually taught the team, past the growth number it produced. We instrumented one behavior, a published on-brand ad, and ignored logins, and we told engineers exactly why before they built anything. The team that later said no to forty of forty-five feature requests was not being gatekept into silence. It had the same evidence the PM had, and it used it.

An engineer-trained PM has one advantage here worth naming: reading the code and writing the SQL yourself means the “no” you hand engineering is one they can argue with on its merits, not one they have to take on authority. Related read: how to actually measure whether a feature worked, which is the other half of saying no early instead of late.

5. When the PM leaves, you find out which model you had

Every gatekeeper organization eventually runs the experiment it did not sign up for: the PM leaves, on purpose or not, and the org finds out in real time what was actually written down.

A gatekept team discovers the backlog was a pile of words without intent, because intent lived in one head that is now gone. Stakeholders start lobbying again instead of reading a shared brief, because there was never a shared brief, only a person who remembered the reasoning. The replacement PM spends a quarter reconstructing lore that should have been infrastructure the whole time.

A translated team loses a strong integrator and feels the loss, but it does not lose the map. The InMobi close is the version of this I can point to directly: the target and the twelve-times-a-year cadence are written down, so the close keeps running at 12 hours whether or not the person who first cut it from 5 days is the one running the review this month.

That is not an accident of a well-run team. It is what happens when clarity was built as a team output from the start, instead of a personal talent one person happened to have.

6. What leadership has to change for the model to survive

One PM choosing to write things down buys one good quarter. The model survives past that only when leadership rewards it on purpose, in a few specific ways.

  • Treat clarity as a deliverable. A problem brief, a constraint map, and a decision log are work product, not overhead around the “real” work of shipping.
  • Protect writing time against meeting time. The translator’s Monday is spent on a document that changes how three teams interpret the same problem, and that time gets taken first if nobody defends it.
  • Let expertise meet expertise directly. An engineer arguing feasibility with a customer’s actual words in front of them does not need the PM as a relay for that conversation.
  • Reward the decision, not the routing. If the PM who “owns everything” gets praised and the PM who “lets too many people talk to customers” gets quietly corrected, the organization is training gatekeeping on purpose while saying it wants the opposite.

The habit that ties all four together is treating a killed idea as evidence instead of a miss. Forty declined features out of forty-five interviews is not a PM being stingy. It is the discipline that makes the five that shipped worth believing in, and it only works if leadership calls that a win out loud, in the room, where the team that did the declining can hear it.

Takeaways

The best PMs are translators, not routers Six sections on distributing context instead of hoarding it, with the numbers behind each one Hoshank Ailani · hoshank.vercel.app 1. Gatekeeper vs translator GATEKEEPER TRANSLATOR info flow: one inbox a document three teams read PM is out: decisions stall team decides from the brief cost scales with headcount cost is writing the brief once handoff: private lore handoff: decision log a single point of failure the org is the map 12 + 20 + 15 people at Pixis, one inbox versus one brief 2. What gets translated 99.6% sync reliability → 400+ enterprises trust it 15+ VoC interviews → 5 features, 40 declined reconciliation pipeline → close: 5 days to 12 hours each row moves a signal into a form to act on 3 handoffs eng to biz, customer to roadmap, data to finance 3. The context relay 1 15+ interviews run, every launch 2 Problem brief written, one document 3 Shared with engineering and sales 4 Team decides, PM absent no escalation needed 5 of 45 kept from 15+ interviews, the rest declined 4. Bottlenecks vs judgment No without context is friction Yes without context is chaos Shared context lets a team say no early A queue feels like rigor and is just delay an engineer-trained PM reads the code and writes the SQL, not just the ticket 5. When the PM leaves gatekeeper org: backlog stalls, replacement rebuilds lore from scratch translator org: the close still runs, the target and cadence are written down 12 hrs InMobi's close, re-checked by finance 12 times a year 6. What leadership changes Treat clarity as a deliverable Protect time for writing, not meetings Let expertise meet expertise directly Reward the decision, not the routing a killed idea is evidence, and evidence is a win, not a miss If the org falls over when you take a vacation, you built a queue, not a team. The test: pick one decision your team made this month, and check who else could have made it. Full post: hoshank.vercel.app/posts/why-the-best-pms-are-translators Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Six panels, one per section. The callout is the test to run on your own team this week.

Final Words

Most PMs already believe they are indispensable, and most organizations reward exactly that belief. Pick one decision your team made this month, and check who else in the room could have made it without you. If the answer is nobody, you have a queue. If the answer is anybody who read the brief, you have a team.

Reply and tell me what you found today.

Cheers, Hoshank