PRD, RIP?
The PRD still seems to be everywhere. But is it still useful?
Picture the scene. You’re a stakeholder in an upcoming product initiative, and you’ve just been handed a 40-page Product Requirements Document to review. Your name is in the document header, there’s a meeting in three days, and your job is to turn up with feedback.
You open it. There’s a cover page, a change history, an executive summary, an objectives section, seven user personas, a detailed feature list, functional and non-functional requirements, technical constraints, dependencies, assumptions, risks, a go-to-market overview, and an appendix.
You close it. It’s not that you don’t care. It’s that your brain simply can’t engage meaningfully with forty pages of somebody else’s thinking in one sitting.
Even worse, imagine if you’re part of the team tasked with delivering the initiative, and the first thing you see is a fully worked-out solution.
Perhaps there are occasions when this might be the right path. Such as a contracted, fixed-scope deliverable for a specific client, with engineers waiting on sign-off before they can start work.
But most modern product teams are not in that situation. This is just one initiative amongst many that they’re weighing up, prototyping, rolling out, or tracking the impact of. They care about speed, clarity of thought and strong collaboration. Traditional PRD templates aren’t optimised for any of those.
But the term is still everywhere. Product courses teach it. Job descriptions demand it. AI tools are now specifically built to generate them. So it’s worth asking: what is a PRD actually trying to achieve, why can it fall short, and what might you do instead?
What a PRD is actually for, and why it can set you on the wrong path
To be fair to the PRD, it is trying to solve a set of real problems. As a document, it is trying to answer the questions that a product team needs to align on: who are we building for, what problems are we aiming to solve for them, why does that matter, what’s our solution, how will it reach those users, and how will we know if it succeeds? Those are genuinely important questions. The problem isn’t the questions. It’s the answer format.
Bundling all of that thinking into a single template can create some serious issues.
Firstly, a PRD template implies that its content can all be known upfront. In reality, it needs to evolve as discovery and design diverge and then converge again. The real work of product management is grappling with ambiguity: which of many possible paths is the most promising? What assumptions are we making, and how do we test them? How will we know if we’re making a difference? Those questions can only be answered through deep thinking, collaboration, and contact with the real world. A long-form template can quietly nudge the writer away from that hard work, toward simply writing down their own convictions. It leans the writer towards waterfall, rather than agile working practices.
Secondly, there’s the gravity problem. Once a PRD exists, people tend to treat its contents as settled. Challenging a “requirement” feels like undermining the process, so the really important debates — about which problem is worth solving, or whether this solution is the right one — often don’t happen. The author becomes a gatekeeper, patrolling what gets accepted into the PRD and what doesn’t. Marty Cagan put it bluntly: “When you just provide those engineers requirements instead of collaborating with them in determining what the right solution is, then you are effectively neutering those engineers.”
Thirdly, there’s the duplication problem. A PRD typically restates descriptions of the product strategy, target segments, and customer research — all of which should already live in a fuller form somewhere else. When those descriptions drift out of syncwith the originals, teams quietly form views based on outdated information.
Consider these alternatives
The goal isn’t less documentation, it’s more focused documentation. Artefacts that are written for a specific purpose, at the right moment, for the right audience.
In practice, that tends to mean a stack of shorter, dedicated documents, alongside collaboration boards and prototypes. A product strategy that sets stable context across multiple initiatives. A clear narrative of the business outcome you’re aiming for. An opportunity-solution tree to map customer needs and potential solutions. A prototype that lets you feel the experience directly, rather than simply read about it. A go-to-market plan, defined only when you have a clear view of what the market needs. Each item short enough to actually be read (or experienced) and debated.
For broader stakeholder alignment, I’ve found a short narrative document can be more effective. Amazon’s PR/FAQ format can work well, using the style of a fictional future press release to get the key information across.
Sometimes you need a quick answer to “what is this initiative?”. For that, a one-page doc that succinctly explains the opportunity that you’re pursuing and your selected solution that you’re working towards can suffice.
Another practice that can be useful is to maintain a short “initiative overview”, which expands the one-page “what is this initiative?” doc to add key details and reference points, with signposts for further detail. Make sure that everything in the overview has earned its right to be there, after it’s been debated, tested and agreed. And keep it regularly updated throughout the lifecycle of your initiative.
This initiative overview may well be what some people think of as a PRD, but personally I find that title unhelpful. It’s not a statement of “requirements” — those things that must be delivered for the work to be “accepted”. Rather, it’s a summary of your learnings, your decisions, and your plan for building, landing and tracking the outcome — for the purpose of aiding further collaboration.
The impact of AI
A wave of LLM-based tools now claim to write a PRD for you. It’s worth being a little sceptical. They can only ever be as good as the information you provide — which, as we’ve seen, is wholly dependent on the quality of the discovery and collaboration that happened beforehand. Without that, you can end up with overly long PRDs that say nothing real, resulting in your PRD being read even less than before. AI can accelerate the format; it can’t fix the underlying problem.
There is, though, a more interesting use of AI here. Rather than asking it to generate a PRD from scratch, consider sharing your individual discovery and collaboration documents with it — the strategy, the opportunity-solution tree, the assumption map, the go-to-market thinking — and using it to generate point-in-time narratives, tailored for specific audiences. You could ask for a version for your marketing team, a version for a legal stakeholder, or a version for a senior leader who wants the two-minute story. You can also ask it to surface key decisions to add to your initiative overview.
That’s AI as a synthesis tool, not a shortcut around the thinking.
The bigger picture
There’s a reason that the concept of the PRD has stuck around so long. Writing something forces a level of clarity that informal conversations don’t. Structure helps PMs early in their careers know what they need to think about.
The problems arise when a PRD template is used to paper over a lack of real discovery work or genuine collaboration — when the document becomes a substitute for the thinking, rather than a record of it.
As a Product Manager, your focus should be on finding the best path to achieving your target outcome. That requires strong collaboration to achieve a deep understanding of the problems to solve, a sharp view of how to effectively solve them, and the discipline to let go of your assumptions when the evidence tells you to.
Keep those main things the main things. But don’t forget that, as Product Manager, you’re also the chief evangelist for your initiative. You need to bring your team with you, whilst keeping stakeholders aligned and championing your product amongst the noise of your organisation. For that you do need a strong narrative, and you do need to find the right tools to collaborate. Think deeply about how to best fulfil those needs for each audience, and try to avoid reaching for a template unless it genuinely supports those needs.
The label you put on your documents matters far less than whether they reflect real thinking, invite genuine debate, and help the people who read them to make better decisions.
The PRD served its era well. Most of us are working in a different one now.