The purpose of a product requirements document is communication. It should explain what we are building, why we are building it, what we have learned and which decisions still need to be made.
Historically, product would scope the requirements, design would turn them into wireframes, mocks and prototypes, and engineering would use those artifacts to build the actual product.
That workflow made sense when working software was expensive to produce. AI changes the economics of that.
Show, don't describe
A picture says a thousand words, but working software says more.
Codegen has made prototyping cheap enough that product managers and designers can increasingly start in the product itself. Instead of spending days describing an interaction in a document and then reproducing it in Figma, they can start a branch and build the idea.
At Durable, our monorepo gives product, design and engineering access to the same applications, design systems, shared packages, database schemas and internal tooling. When someone creates a branch, they also get a fork of the production database and a live preview URL.
A PM or designer can go from an idea to something the team can actually use, click through and react to in hours.
The branch is the workspace
The branch replaces much of the traditional handoff between product, design and engineering.
Product can start with customer research, data, market context and a hypothesis, then turn that into a working flow. Design can work directly on the same branch, refining interactions, states, copy and visual details inside the real product and design system.
Engineering can review the implementation, suggest changes, help with architecture or step in when deeper technical work is required. But engineering does not always need to take over.
If the implementation is production ready, the PM or designer who built it can address code review feedback and ship it themselves.
Sometimes engineering rewrites most of the implementation. Sometimes they make a few changes. Sometimes they only review the pull request. All three outcomes are fine.
The goal is to get from idea to production with as little translation and duplicated work as possible.
The PRD becomes an index
Documents do not disappear. They get smaller.
There will always be context that does not belong in code: customer research, product data, strategic reasoning, constraints, tradeoffs, distribution plans and open questions.
The PRD becomes an index into that context instead of an attempt to describe the entire product before anyone builds it.
A useful PRD might contain:
- Objective and background
- DRI
- Customer research and supporting data
- Link to the working branch and preview
- Link to the Linear project
- Relevant Slack discussions
- GTM and distribution notes
- Tracking and evaluation plan
- Open questions and important decisions
That might fit on one page. Sometimes much less.
Keep the why, prototype the what
Product still needs to understand the problem deeply. Design still needs to care deeply about the experience. Engineering still needs to care deeply about reliability, architecture and quality.
AI does not remove those responsibilities. It reduces how tightly those responsibilities need to map to who writes the code.
Research, strategy and constraints often need words. Interaction is usually better expressed through interaction. The closer our shared artifact is to what customers will actually use, the less information gets lost between disciplines.
Sometimes the prototype gets thrown away. Sometimes it becomes the starting point for engineering. Increasingly, it simply becomes the product.
So long live the PRD. It just looks a lot more like a git branch now.