The short version
The PM-as-translator role is dead. For 15 years, PMs were professional middleware: reformatting customer input into decks for engineers, waiting for analysts to pull reports, filing tickets to change a button label. AI and MCP just stripped away three layers of translation. PMs now write markdown in git repos next to the code, query session replays in plain English via LogRocket's MCP server, and fix their own copy by pushing PRs. What survives: judgment about what to build, customer intuition (data isn't understanding), cross-functional alignment, systems thinking. What dies: the planning deck, the weekly metrics meeting, the voice-of-customer monopoly, the feature factory PM. If your 12 PMs are still translators, ask the uncomfortable question: what are they actually doing that needs 12 people?
A CPO at a $16B+ company casually told his product team three things in a tweet: push markdown to git repos instead of building planning decks. Watch customer session replays directly via MCP instead of waiting for summaries. Fix your own copy instead of filing tickets for engineers.
That's it. Three bullets. No memo. No all-hands meeting. No transformation initiative. Just describing what seemed obvious to do next.
The casual tone is what matters here. Inside companies moving fast, this stuff already feels normal. It doesn't feel like change. It feels like Tuesday.
What's happening is simple: each of those three things strips away one layer of translation between the PM and the actual product. Strip away enough layers and the translator role just vanishes.
The fifteen-year middleware problem
Over the last fifteen years, the PM role became this weird middleman job. You had planning decks, PRDs in Google Docs, Jira tickets, design review meetings, stakeholder alignment sessions, quarterly business reviews. Layers and layers of artifacts.
Why? Because PMs couldn't touch the actual product. You couldn't write code, so you documented what you wanted someone else to write. You couldn't look at session data, so you waited for an analyst to pull a report. You wanted to change a button label? File a ticket, wait three days, nag the engineer.
What evolved was professional middleware. Grab customer feedback. Turn it into slides. Show slides to engineers. Turn engineer output into release notes. Repeat every quarter.
Each time you translate something, you lose information. The customer says "this is confusing." The PM translates it to "users report discoverability challenges with the onboarding flow." The engineer reads that and thinks: what am I actually supposed to fix?
We called it "being the voice of the customer." It was really just telephone with PowerPoint.
Three layers collapsing at once
Here's what's actually happening right now at companies shipping real products:
Layer 1: The planning artifact. PMs are now writing where engineers write - markdown in git repos instead of Google Docs exported to Confluence linked to Jira tickets referenced in PRs. One file, version-controlled, sitting next to the code it describes. This requires PMs to learn repo structure, branching, pull requests - skills that used to be engineers-only territory.
Layer 2: The information bottleneck. Tools like LogRocket now let you query session replays in plain English via MCP. One prompt and a PM can scan every session, spot rage clicks, find broken flows, and connect them to specific releases in real time. No analyst. No dashboard. No "let me set up a meeting." The old "voice of the customer" was sitting in meetings reading support tickets and making slides. The new version is: I asked the AI to analyze 10,000 sessions and here's what broke.
Layer 3: The execution handoff. "Fix your own copy" sounds small. It's not. It means the PM knows where copy lives in the codebase, can find the component, change the string, push the PR. No ticket. No "can someone change 'Submit' to 'Save changes'?" Multiply that across a hundred PMs and you've just freed up thousands of engineering hours previously spent on find-and-replace tickets.
Strip away these three layers and there's no reason for a PM to be a translator anymore. The translator disappears.
Why this is happening now
Two things lined up.
AI made building cheap. A prototype now takes an afternoon, not a sprint. You don't need a 12-page spec to justify trying something. You just build it. The cost of failure dropped so far that all those safety mechanisms - PRDs, planning decks, approval gates - became more expensive than the actual risk. Insurance against being wrong costs more than being wrong.
MCP connected everything. Model Context Protocol lets AI agents read and write across your entire stack - analytics, project tracker, support desk, codebase - in one prompt. Before MCP, a PM comparing session replays against support tickets against deployment history needed three dashboards and an analyst sitting next to them. Now you just ask.
Combined: PMs can see the problem (through MCP), build the fix (through AI), and ship it (through git) without ever leaving their desk. Problem at 9am, shipped by 3pm.
Teams running this play lean on being deliberately understaffed. When you have fewer people, everyone has to do more. "More" now means "directly touch the system" instead of "write a document asking someone else to touch the system." Lean teams can't afford translators. They can't afford a PM spending three days on a deck. They need a PM who spots the problem Monday and ships the fix Wednesday.
The convergence nobody's talking about
Garry Tan said what makes a good engineer changed in four months. True. But it went both directions.
Engineers are picking up PM skills. They use AI to do customer research, write positioning, pitch features directly to users. PMs are picking up engineering skills. They push to git, spin up MCP servers, prototype working software.
Both roles are converging on the same spot: the person who can spot a customer problem at 9am, prototype a fix by noon, and ship by 3pm. That person doesn't need a job title. They need a laptop, an AI, and MCP.
Andrew Filev at Zencoder published something on this last week. One of their PMs built and shipped a feature - actual code, actual testing, actual production push - in a single day. No specs. No tickets. No handoff. Their designer found visual bugs in an IDE plugin and used an AI agent to fix the layout himself, tweaking and testing in real time.
When building gets cheap, coordination becomes the slowest thing. All the machinery we set up to protect engineers - specs, tickets, handoffs, backlog grooming - is now the bottleneck. The system built to make teams efficient became what's slowing them down.
What survives
Not all of the PM job is translation. The stuff that isn't becomes more valuable.
Judgment. Deciding what to build - which problems actually matter, what solution fits, what trade-offs are worth it - gets harder when you can build anything. When engineering time was the limit, the PM job was ruthless prioritization. When there's no limit, the job becomes having better taste and stronger conviction about what moves the dial.
Customer intuition. MCP gives you data. It doesn't give you understanding. You can see that users are confused. Understanding why - and what they actually need - that's still human. A PM who can read session data and understand customer emotion is way more powerful than someone with just the data.
Cross-functional alignment. AI builds prototypes. It doesn't do politics. Can't convince a skeptical VP in the hallway. Can't build trust. Can't make the case for why this bet matters. This stuff is human work and it's undervalued in job descriptions.
Systems thinking. When you're touching code directly, you need to understand the system - not just what it does, but how it's built. Component architecture, data flows, API contracts. Not engineer-level deep, but enough to know where to change things and what breaks.
What dies
The planning deck. It was a band-aid for a problem that doesn't exist anymore. PMs used to build elaborate documents describing what they wanted someone else to do because they couldn't touch the product. Now they can. Any artifact that only exists to translate between human and system is now just overhead.
The weekly metrics review meeting. When every PM can query analytics live, the meeting where one person presents yesterday's numbers to a room becomes pointless. Data review is now constant and personal, not some ceremony on Friday.
The "voice of the customer" monopoly. AI can synthesize every support ticket, session replay, and NPS comment in minutes. So the PM's special claim to understanding customers gets weaker. "Voice of customer" now means: I told an AI to analyze 10,000 sessions. Anyone can do that. The value is what you do with the insight, not that you gathered it.
The feature factory PM. The PM whose entire day is: take a roadmap item, write a ticket, hand off to engineering. That's the most exposed role in the industry. Pure middleware. When the whole path from idea to shipped code can run without a human translating, the translator becomes useless.
The uncomfortable question
Most PM teams haven't restructured yet. They're still hiring for the translator model: write specs, manage backlogs, run standups, present. Job descriptions still say "excellent communication skills" at the top - which really means "good at repackaging information for different people."
Here's the uncomfortable part: if your PMs can push to repos, pull production data, and prototype code, what are your 12 PMs actually doing that needs 12 people?
I don't have a clean answer. I think most orgs will realize they need fewer PMs doing radically different work. The PM who survives is part strategist, part builder, part analyst, part organizational leader. The PM who doesn't is the one spending their day repackaging information.
The planning deck is dead. The information bottleneck is dead. The execution handoff is dead.
What's left is the hard stuff. Judgment. Taste. Conviction. The ability to ship something good. That was supposed to be the job all along. We just got distracted by the process.