Why every AI-written PRD reads like slop

A new PM with three years in a startup posted a version of this recently: every PRD they came across now reads like AI slop. The structure is fine. The headings are all there. It still manages to say nothing.

Most people diagnose this wrong. They assume the problem is the model, or the prompt, or that they picked the wrong tool — so they go shopping for a better one. But you can run the same vague idea through every frontier model on the market and get back five well-formatted documents that are all confidently wrong in the same way.

The structure was never the hard part. AI nails structure. Problem statement, goals, non-goals, user stories, acceptance criteria — a model lays that out cleanly every time. What it can't do is know things it was never told.

The slop is in the gaps you didn't fill

You give the model a one-line idea — "we need better onboarding" — and ask for a PRD. It returns a complete-looking document. Every section is populated. And because every section is populated, it reads as finished.

But look at what it filled the gaps with. The success metric is "increase activation rate." The user is "a new user who wants to get started quickly." The acceptance criteria cover the happy path and nothing else. None of that came from anywhere. The model needed a value in each slot, so it generated the most statistically average value that fits a PRD. That's not a requirement — it's a placeholder wearing a requirement's clothes.

The danger isn't that it's wrong. It's that it's plausible. A blank section you'd notice. A confidently-filled wrong section sails through review, gets handed to engineering, and surfaces as a "miss" three weeks later when someone realizes the spec described a user who doesn't exist.

The fix isn't a better template. It's a real source.

The one input that changes the output is evidence — actual material the model can ground itself in:

• The transcript of the call where someone described the problem in their own words.
• The support tickets that show what's actually breaking, with frequency.
• The existing codebase or product, so the spec starts from what's really there.
• The vision or strategy note that says what success actually means in your business, not in the abstract.

Give a model that, and the difference is stark. Now the user story has a real user in it, quoting a real frustration. Now the acceptance criteria include the edge case the tickets keep surfacing. Now the success metric is the one leadership already cares about.

Why "the prompt makes the difference" is only half true

A good prompt gets you better structure and tone. It does not get you context the model never had. You can prompt your way to a polished void. You cannot prompt your way to facts that aren't in the room.

A grounded draft doesn't let the model invent. If there's no evidence for a section, it says "open question, no data yet" instead of fabricating a confident answer. That sounds like a downgrade. It's the opposite: an honest gap is something you can go close. A fabricated answer is a landmine you won't find until it goes off.

The workflow shift

Stop asking AI to write your PRD and start asking it to assemble one from material you provide:

1. Gather the real inputs first — the call, the tickets, the existing behavior, the strategic why.
2. Have the model draft from those, citing where each claim comes from.
3. Read for the gaps it flagged, not the prose it wrote. The gaps are the work.
4. Keep a human approval gate on every section before it moves downstream.

The PMs complaining about slop aren't wrong that the output is bad. They're one step upstream of the cause. The model isn't generating slop — it's faithfully reflecting that you gave it nothing to work with.