What Does a Product Manager Actually Do When AI Can Write the PRD?
If an LLM can generate a flawless PRD in three seconds, what is your job? It turns out, writing the document was never the hard part.
It is a terrifying moment for a lot of Product Managers.
You take five bullet points from a stakeholder meeting, paste them into Claude or ChatGPT, and hit enter. Three seconds later, it spits out a gorgeous, formatting-perfect, six-page Product Requirements Document. It has edge cases you didn't think of. It has a telemetry plan. It has a launch checklist.
You look at the screen and wonder: "If a machine can do this in three seconds, why is my company paying me a six-figure salary?"
To survive this era, you have to realize a brutal truth: The document was never the work. The document was just a receipt for the work.
The Illusion of Documentation
For years, we mistook the artifact (the PRD) for the outcome (the alignment).
Writing a PRD was traditionally a solitary, grueling process. Because it took so long to write, PMs felt immensely productive when they hit "Save." But a PRD sitting in Notion is useless energy. It only becomes kinetic energy when it hits the brain of an engineer and alters the trajectory of code.
When you remove the friction of writing the document, you suddenly realize that the vast majority of the job is making sure the document reflects reality.
AI will confidently write a PRD that assumes your backend infrastructure is modernized to support real-time webhooks. If you just hand that AI-generated PRD to an engineer, they will look at you like you are insane, because your backend is held together by duct tape and a cron job from 2018.
The AI writes theory. The PM binds the theory to physics.
The Shift: From Authoring to Editing
When AI does the heavy lifting of drafting, the PM's role shifts dramatically to what I call "High Context Editing."
Here is what you actually do when the AI hands you the first draft:
1. You Hunt for Hallucinated Assumptions
AI models are crowd-pleasers. They want the feature to exist perfectly, so they assume away all organizational and technical friction. Your job is to read the draft and inject the friction back in. "Wait, the AI assumes the user will proactively upload their ID document. Our data shows 80% of users abandon the funnel if requested to upload a document upfront. We have to change the onboarding sequence."
2. You Manage the Human Physics of Alignment
The AI wrote the document, but the AI cannot defend it in a room full of angry stakeholders.
When the VP of Sales says the feature misses the mark for enterprise clients, the AI cannot read the room, understand the political dynamic, and negotiate a phased rollout. That requires mammalian empathy and organizational capital. You use the AI artifact to force the argument, and then you mitigate the fallout.
3. You Verify the Definition of Done
AI is notoriously bad at defining "good enough." It will write a testing plan that guarantees a NASA-level lack of bugs. But if you are building an MVP for a B2B beta test, NASA-level quality is too slow. You must adjust the ceiling. You are the one who looks at the AI's ambitious requirements and strikes a line through half of them, saying, "We don't need this to prove the hypothesis."
Output Velocity vs. Absorption Velocity
There is a concept in software development that people forget when they praise AI.
Just because you can output code and PRDs 10x faster does not mean your users can absorb changes 10x faster.
If you use AI to ship four massive feature overhauls a month, your user base will mutiny. Humans hate cognitive overload. They hate when buttons move. They hate having to relearn their daily workflows.
The PM’s job shifts from pushing features out the door, to acting as a governor on the engine. You decide the launch pacing. You protect the user's cognitive load. AI just wants to build. The PM decides if building is actually necessary.
Stop Writing, Start Thinking
The fact that you no longer have to spend 10 hours a week formatting Jira tickets and fixing markdown in Notion is a gift.
It strips away the busywork and exposes whether or not you actually have product strategy. If your strategy was bad, the PRD task used to hide it. Now, bad strategy is exposed instantly.
Lean into it. Generate the PRD in three seconds. Then spend the ten hours you just saved talking to a human user who is struggling to use your software in the real world.
FAQ
Should I tell my team I am using AI to write the PRDs?
Absolutely. Trying to pass off AI-generated work as your own manual labor is insecure and pointless. Tell the engineering team: "I used an agent to draft the boilerplate, but I spent two hours refining the edge cases. Let's review the edge cases together." They will respect the efficiency.
If PRDs are so easy to make, won't stakeholders just make their own?
Yes. Stakeholder-generated PRDs (the "shadow roadmap") are already happening. Your job isn't to stop them; your job is to triage them. When a stakeholder hands you an AI-generated PRD, you run it through the exact same rigorous prioritization framework as any other request. The speed of the request does not change the constrained capacity of engineering.
What is the biggest mistake PMs make when using AI for PRDs?
Failing to provide negative constraints in the prompt. If you just ask AI to build a feature, it will bloat it. You must prompt it with constraints: "Draft a PRD for this feature. CRITICAL CONSTANTS: No new database tables can be created, and it must load within 200ms on a 3G connection." AI needs boundaries to be useful.
PPranay Wankhede
Senior Product Manager
A product generalist and a builder who figures stuff out, and shares what he notices. Currently Senior Product Manager at Wednesday Solutions. Mechanical engineer by training, physics nerd at heart.
Keep Reading on Orlog
External Product Resources
What's your PM Nature?
Take the free, 10-minute assessment to discover your core PM type and how you naturally solve problems.
Take the Orlog Test →