The docs that made product managers look senior? AI just made them free.
That's the joke. Here's what isn't: great PMs are being mistaken for average ones, and AI is why.
Your PRD was never the job. It was the receipt. Nobody could watch you think, so they read your document instead. The document stood in for the judgement, because the judgement happened in your head and in rooms nobody else was in.
That worked for years, for one simple reason. Writing the document required the thinking. You could not produce a clear problem statement, a scoped solution and a list of risks without first working out what you believed and why. A good PRD, roadmap or strategy deck was a fair signal that someone had done the thinking.
AI has broken that link. It can now produce the document without the thinking behind it. Now a polished document just proves you had a good prompt.
AI shortened the wrong path
A product career used to climb through its documents: meeting notes, tickets and user stories, then the PRD, research synthesis and the prioritisation deck, then the roadmap, the strategy deck and the executive narrative. Each step up meant a bigger audience had to believe your work, from your team to your stakeholders to the board.
Every one of those documents can now be generated. AI has shortened the path to senior-looking product work. It has not shortened the path to senior product judgement.
A document was always a container. What made it senior was the thinking inside it: the decision it was built to support, the evidence behind it, the trade-off it accepted. A prompt can fill the container in seconds. It can't decide whether the document should exist, or be accountable for what your team does once they've read it.
Why the polished PRD stopped telling you anything
Every PM I coach has a polished PRD. Very few can explain the calls they made in it.
A Nature study on 880,000 texts found the same pattern from a different angle. After AI rewrote people's work, you could no longer tell who wrote it. The person stays different. The finished work carries less evidence of them.
That is the tricky part for product managers. AI can raise your output and erase what made it yours. Two PRDs can now look equally finished, equally confident and equally well structured, while one was argued through line by line and the other was accepted from a first draft. A reader has no way to tell them apart from the polish.
So the fix is not to write less with AI, or to make the prose sound more like you. You are not adding personality to the document. You are adding the trail of reasoning that produced it. That starts before you write, and it ends after the result comes in.
Before you write: three questions a prompt can ask but not answer
Define the decision first. What must this document help us decide? If you can't say, the document has no job.
Ground it in reality. Which evidence, metric or constraint supports it, and which contradicts it? A document that only lists the supporting side is a pitch.
Challenge the synthesis. What did AI leave out, assume or get wrong? Fluent output is easy to trust and hard to check, so check it on purpose.
Line one: the evidence you trusted
The first line records the gap between what you saw and what the data said. Write it as: "Users said X. But [data] said Y. We trusted Y because..."
Product work is full of contradictions. Interviews point one way and usage points another. A loud customer wants something the numbers say few people need. A generated PRD tends to smooth these over into one tidy story.
Do not just record the contradiction. Record which evidence you trusted and how it changed the work. That sentence shows a reader where your judgement sat, and it gives the next person a way to challenge the call if the evidence shifts.
Line two: the alternative you rejected
The second line records the strongest alternative you turned down. Write it as: "We chose X over Y because... We accepted Z as the cost."
Name the best option you did not take, not an obviously weak one. Listing a straw man next to your choice proves nothing. Naming the option a smart colleague would have argued for, and the price you agreed to pay by not taking it, shows a real trade-off. A plan that costs nothing hasn't decided anything.
Your judgement lives in the trade-off. A document that only describes the chosen path hides the decision behind it.
Line three: what would prove you wrong
The third line records the condition that would change the call. Write it as: "We will change this if X falls below Y by [date]."
Write it before launch. Give it a signal, a threshold, a date and a response. Without those four parts it is not a test. It is an escape route, a vague promise to "keep an eye on it" that lets any result be read as success.
This line is easy to skip, because it feels like admitting doubt. It is the opposite. Naming your exit in advance turns a stubborn plan into a testable one, and shows you thought about failure before anyone had a reason to argue.
Line four: the prediction against the result
The fourth line records what you expected against what happened. Write it as: "We expected X by [date]. We saw Y. So we kept, changed or stopped Z."
Return to the document after the result and close the loop. A prediction written after the outcome proves nothing, because anyone can explain a result once they have seen it. A prediction written first, then checked against what happened, is the clearest record of judgement a PM can leave. It is also how the next call starts smarter instead of from zero.
Over time, these entries build into something no model can generate for you: a track record of calls, with the reasoning attached.
The polish is free now. The reason behind it never was.
The product managers who keep climbing kept the judgement and handed off the typing. When AI can make the document, the difference between two product managers isn't who produces more of them. It is who can show the reasoning inside the ones they produce.
Open your last PRD. Find one line that could only have been written by you. If you cannot find one, that is not a failure. It just means the four lines above are where you start.
To check your reasoning before the document reaches your team, Product Manager Judgement and AI at /vault/product-manager-judgement-ai covers the questions to ask yourself first. And if you want to see where you land between prompting and AI-native product work, the free scorecard at martongaspar.com/scorecard shows you.