Back in 2014, we were writing about the death of the Product Requirements Document (PRD). The thinking behind this post has never been important, as the purpose was to shift away from hardening our thinking about the product design process too early and encourage iteration through prototyping (!).
Documents become less relevant as the team moves forward with the product. A successful team will prototype early and replace their abstract documents with clear and tangible customer feedback.
Now that vibe-coding is de rigueur, we are seeing prototypes generated faster than ever. But are we also seeing an imbalance in the kind of thinking that keeps projects on track?
In our conversations with Product Managers, we are seeing PRDs being engaged with in new ways:
Directors and Managers are generating PRDs with the help of A.I.
Stakeholders who would not normally read a PRD engaging with LLM synopsis of PRDs to stay informed on the details
Designers feeding PRDs into LLMs to generate prototypes
Our question is:
Are you seeing new value in PRDs with the affordances A.I. provides?
How has the usage of PRDs changed within your teams in the past 5-10 years?
Yes. As an engineer, PRDs is the planning work which allows A.I. to execute at a higher level. Every feature and request, the better the plan, the better the execution, and the more clear on how I’m involved with the goal.
The pitfall of a PRD is relying too heavily on it, as mentioned in your post. We should use PRDs as throwaways, just as how plans should be used (discarded after use). The source should be the product and outcomes themselves.
This is an interesting take! I’d argue from an Ops perspective that PRD’s are seen as helpful because they provide soooo much alignment beforehand. I was reading up on the practical application of these and ran into this lens:
“If this PRD disappeared tomorrow, would execution slow down?”
If yes, it’s valuable
If no, it’s performative
Which I thought, really showcased the value of how they’re applied and leveraged in orgs!
First I’m hearing much about PRDs in a couple years, so I don’t think the concept is necessarily revived, but maybe it will get new life with AI.
If these documents change from just spec sheets to well-structured hunches about what the product can be, you can combine the value of quickly testing hypotheses with the rigor of PRDs to create a process that allows for both specificity and experimentation.
That’s exactly why they should be discarded. They’re mainly for pre-alignment purposes.
Where PRDs get fuzzy when we have 100s of them sitting around “documenting” what things should be, not what they end up becoming. After a year of work, is anything the same as it was when that PRD was created? If not, now it’s actually throwing a wrench in someone else’s understanding, especially if they use that as reference for understanding the “core” truth.
They’re a flawed system because it’s just too easy to detach them from reality by a simple change, and they’re a lot of overhead if we’re trying to keep them up-to-date.
I’d say that they’re performative after about a month. More than likely, especially with larger teams, they are simply just left behind.
I’ve never been PRD heavy, as it’s similar to a problem with programming and comments. Comments are cool, but it’s just too easy for them to not be read, and then also be detached from how things are actually working.
It feels like we’re still calling it a PRD because the term is familiar, but what we’re actually doing is different. The old PRD tried to lock the future in place. What’s happening now is more like structured thinking. A working draft that feeds AI, prototypes, summaries, and conversations.
The risk is confusing output with alignment (saw this first hand this week). Faster prototypes do not replace clarity on why this matters, what problem we’re solving, and how we’ll know it worked. If someone gets a new version 15 minutes later… do they really want to sort through it again?
If AI turns the PRD into something dynamic, shared, and constantly tested against real feedback, that’s where I think this wins.
If it just makes it easier to generate long, confident documents that no one truly owns, we’re back where we started.
Decided to go deeper into this topic of the role of a PRD. It’s more like a working draft that includes AI, prototypes, summaries, and conversations.
This is a great summary. Maybe it makes sense to create a /docs/features structure that highlights how each feature works within platforms, working as the “source” truth.
This is a case-study in utilizing PRDs to structure a build process.
In particular, you’ll see that this takes a meta approach to building a presentation of prototype variations and, rather than simply focusing on PRDs for each variation, starts with a framework for modular viewing across the different prototypes.
Yes AI makes great requirements not just helpful but the only way to make probabilistic AIs output anything we can trust.
We are betting hard on this and trying to open source the underlying patterns that run 80% of software at https://gracecommons.dev/
Please take a look if you have time and throw rocks at the idea.
