The PRD controversy misses the point. They should be viewed as outputs of good product discovery, not substitutes for it.

Why people hate PRDs

PRDs can be long. I’ve written 20+ page ones and read ones nearly double that. Who’s going to read this? is a fair question. People don’t like reading lengthy documents where not all information is relevant to their work.

Some PMs, stakeholders, and leadership teams hate PRDs to the point of dogmatism. We don’t do PRDs here, they say. It’s easy to empathize.

Why PRDs are actually useful

But dismissing PRDs entirely overlooks their value for knowledge transfer and organizational alignment. As a PM joining a new organization, PRDs enable rapid knowledge acquisition. One standardized document tells you why something was built. There’s no convincing me that Slack pestering and searching or deciphering poorly maintained docs beats that.

The “PRDs aren’t agile” argument

Another common argument is that PRDs aren’t agile. The rationale is that a PM disappears to write the PRD in isolation from their triad, then dumps requirements on them last minute with little room for negotiation.

Whether an organization adopts PRDs has little to do with how collaborative Product chooses to be. It’s hard to imagine PRDs encouraging or discouraging collaboration either way.

The actual problem

The PRD process can encourage bad patterns. It can make PMs think writing a PRD is the product discovery process instead of the output of one. This distinction matters.

Do a quick search for PRDs and you’ll find endless posts chasing the “perfect” or “best” PRD. That obsession is the problem. It confuses the artifact with the work.

If leadership asking for success metrics in your PRD causes panic, something’s wrong. When you’ve done proper discovery, defining impact and metrics is straightforward. It’s literally part of understanding the problem.

The real issue

PRDs are a red herring. The real issue is a potentially broken product discovery process and culture. This should be addressed independent of what artifacts are produced.

Fix your discovery process first. The artifact is secondary to actually understanding customer problems.

← Back to Home