For two decades, the Product Requirements Document was the artifact that turned product strategy into engineering work. A 10-to-30-page document with sections for problem statement, goals, user stories, requirements, edge cases, and success metrics. It was the contract between PM and engineering. It worked because software was deterministic, requirements were knowable in advance, and the cost of changing direction mid-build was high.
AI-native products break almost every assumption underneath the PRD. The behavior of an LLM-driven feature is not fully specifiable. Edge cases emerge from probabilistic outputs. The experience itself is the product, not the underlying system. As Rags Vadali argued in a recent Mind the Product episode, the PRD has to be replaced by a different artifact: the Product Experience Document (PXD).
Why the classic PRD breaks for AI products
Three structural mismatches:
1. Specifications cannot fully describe non-deterministic behavior
A PRD says "when the user clicks X, the system does Y." An AI agent does Y, or something Y-like, or something completely different depending on context. Specifying every Y is impossible. Engineering cannot build against a spec that cannot exist.
2. The experience layer is the product
For AI-native products, the underlying model is often commodity. The differentiation is the experience layer: how prompts are constructed, how outputs are presented, how the user collaborates with the agent. PRDs documented the system. PXDs document the experience.
3. Iteration speed exceeds documentation speed
AI products iterate at a pace where comprehensive docs are obsolete before they ship. A document that takes two weeks to write covers a product version that was deprecated a week ago. The artifact has to be faster than the changes it describes.
The product is now the experience layer. When constructing an agent, the actual product is what users experience on top of the foundation model.
What the Product Experience Document (PXD) looks like
The PXD is shorter, faster, and structured for ambiguity. Common sections:
1. The experience hypothesis
Not requirements. A hypothesis about the experience users should have. "Users should be able to draft a customer email by describing the situation in a sentence and getting a complete first draft they can edit." Specific enough to test, abstract enough to allow iteration on how.
2. The interaction model
The shape of the user-AI collaboration. Where the user gives input, where the AI responds, where the user corrects, where the AI learns. Diagram or short prose, not detailed spec.
3. Acceptable ranges, not exact specs
Instead of "the system shall return X", the PXD says "acceptable outputs include A, B, C. Unacceptable outputs include D, E, F. Failure modes to handle gracefully include G, H." The shift from exact to acceptable is the largest mental jump.
4. The prompts and the prompt strategy
For agent-based products, the actual prompts are part of the product. The PXD includes prompt examples, the strategy for selecting prompts, and the criteria for when to update them.
5. The evaluation framework
How will you know if the experience is good? Not just "feature works". "In a sample of 50 user sessions, 80% completed the task without rephrasing more than twice." Evaluation methodology lives in the document.
6. The disposable section
For AI products, 50-60% of what gets built will be discarded. The PXD names what is hypothesis-stage and what is committed, so engineering can prioritize accordingly.
The PXD is written for agents, not just for people
The most interesting structural change: PXDs are increasingly used directly as input to AI coding tools. Engineering takes sections of the PXD and pastes them into Claude, Cursor, or similar tools to generate or refactor code. This reshapes how the document is written:
- Sections need to stand alone, not depend on context elsewhere in the doc
- Examples are concrete and copy-pastable
- Acceptance criteria are testable by code, not just by humans
- The language is precise where humans would tolerate ambiguity
The document is now part of the build process, not just the planning process.
Floto's pattern: parallel products and disposable builds
Several AI-native companies are converging on a pattern: run two or three products in parallel, throw away 50-60% of what gets built. The PXD supports this by being light enough that writing one for a parallel experiment is not a meaningful cost. The classic PRD was a multi-week investment that anchored teams to whatever they specified. The PXD is a one-day artifact that can be discarded as easily as written.
What survives from the classic PRD
Not everything in the old format is wrong. The pieces worth keeping:
- The user / problem framing. Even AI products serve specific users with specific problems.
- The success metrics. Still needed, just measured differently (outcome-based, with evaluation methodology).
- The launch plan. Still needed, including communication, rollback strategy, and monitoring.
- The decisions log. What you considered and chose not to do. More important in AI products than ever, because the space of possibilities is larger.
The hybrid period (where most teams are now)
Most product organizations are not fully AI-native yet. They have some deterministic features that need PRD-style specs and some AI-driven features that need PXD-style hypotheses. The realistic answer is a hybrid format that picks the right structure per feature.
| Feature type | Document type |
|---|---|
| Deterministic CRUD | Lightweight PRD with user stories and acceptance criteria |
| Workflow with branching logic | PRD with decision diagrams |
| AI-driven experience | PXD with acceptable ranges and evaluation |
| Agent that uses tools | PXD plus tool specifications |
| UI-only changes | Visual brief plus 1-page rationale |
The takeaway
The classic PRD was an artifact for an era when software was deterministic and specifications could be exhaustive. AI-native products require something else: the Product Experience Document, which trades exact specifications for acceptable ranges, embeds prompts and evaluation methodology, and is written to be consumed by both humans and AI coding tools. Most teams are in a hybrid period. The right answer is to match the document to the feature type, not to force every feature into a single template that no longer fits. The PRD is dying because software is becoming something different. The PXD is what replaces it.
