The Death of the PRD
The Product Requirements Document existed because humans couldn't speak each other's language. LLMs can.
The Death of the PRD
The Product Requirements Document has been the centrepiece of software development for decades. A product manager talks to customers, distils their needs into a structured document, and hands it to engineering. Engineering builds what the document says. The PM translates between two groups that speak different languages.
LLMs speak both languages natively.
Familiar Ground
The traditional workflow has three steps. Customer expresses a need in their language (“I want it to be faster”). PM translates into engineering language (“Reduce page load time to under 200ms by implementing lazy loading and CDN caching”). Engineer builds to spec.
The PM’s value was the translation. Understanding what customers mean, not just what they say. Converting fuzzy requirements into precise specifications. Managing the gap between intent and implementation.
This gap was real. Customers think in outcomes. Engineers think in systems. Someone needed to bridge the two. That someone was the PM, and their artifact was the PRD.
Counter-Signal
The gap has closed. An LLM can hear “I want it to be faster” and produce the engineering specification, the implementation plan, and the code. It does not need a translator. It is the translator.
This is not a hypothetical future. It is current practice. Product teams using AI coding agents skip the PRD entirely. They define the intent (“reduce load time”), the agent produces the implementation, a human reviews the output. The 40-page specification document that took two sprints to write is replaced by a paragraph of context.
The PM’s translation work was BODY-layer work dressed up as MIND-layer work. It looked cognitive (distilling requirements) but was actually mechanical (converting one format to another). LLMs excel at format conversion. The translation layer was always going to be automated the moment a system could process natural language as well as structured specifications.
⚛️ The Fusion
Three patterns crash here, and the collision reveals the shape of the surviving role.
The translation layer death is the structural event. The PM existed because customers and engineers spoke different languages. LLMs are native speakers of both. They process customer language (natural text) and produce engineering language (code, specifications, system design). The bilingual intermediary is no longer necessary.
This is not about PMs learning to code. Learning syntax is a lateral move into a function that is also being automated. The correct move is vertical: from translation (converting formats) to curation (judging quality, setting direction, enforcing standards).
The middle management squeeze is the same pattern at a different altitude. Just as integration frameworks are being squeezed out of software architecture (the Intelligence Layer swallowed them), human middle managers (translators, coordinators, information routers) are being squeezed out of organisations. The squeeze is universal: it hits software AND people.
| What got squeezed | In software | In organisations |
|---|---|---|
| The translator | MCP, integration APIs | Product Managers writing PRDs |
| The coordinator | Orchestration frameworks | Project managers routing tasks |
| The information router | Middleware | Middle managers forwarding context |
The curator as the surviving role completes the collision. The PM who writes PRDs is dead. The PM who curates agent output, judges competing implementations, defines quality constraints, and sets the strategic direction is the surviving form.
This is functionally identical to a specific role pattern: the Arbiter. Someone who does not produce the work. Someone who governs the process, judges the output, and synthesises competing perspectives into a decision. The PM is not dying. The PM is evolving from translator to judge.

The New Pattern
The question for every PM: are you a translator or a curator?
Translators convert input from one format to another. Customers say it in English, the PM writes it in Jira. This is the PRD function. It is dead.
Curators judge, select, and refine. The agent produces three implementations. The curator evaluates which one serves the customer intent, which one aligns with the product strategy, and which one meets the quality standard. This is a judgment function. It requires understanding both the customer and the system, but instead of translating between them, you are governing the agent that serves both.
The practical transition:
Stop writing specifications. Start writing constraints. Not “build a login page with these fields.” Instead: “the login experience must complete in under 3 seconds, support SSO, and meet WCAG AA accessibility standards.”
Stop routing information. Start defining quality gates. Not “engineering, here are the requirements from the customer.” Instead: “before any feature ships, it must pass these five criteria.”
Stop translating. Start curating. The agent speaks both languages. Your value is in knowing which output is right, not in converting the input.
The Open Question
For thirty years, the PRD translated between people who could not understand each other.
The LLM understands both sides natively. The translation layer is dead.
Are you translating, or are you curating, and do you know the difference?
This fusion emerged from a STEAL on the Modern AI PM thesis, tracking the convergence between the product and engineering roles as the linguistic gap collapses.