You've been writing the wrong document.
The PRD was designed for a world where a PM writes a spec, hands it to engineering, and waits. That handoff created a gap, so the PRD got longer. More context. More mockups. More "background" sections nobody reads.
Intent specs work differently. They're short, testable, and linked to real user evidence. With coding agents in the loop, you often don't write the first draft at all: the agent proposes the spec from the request and the codebase, and your job is to judge it. That turns out to make a better alignment artifact than the 5-page doc it replaces.
A PRD tells the team what you want. An intent spec shows them what the user needs and how you'll know it's done.
What Stakeholders Actually Need to See
When your VP asks "what are we building next?" or your designer asks "what problem are we solving?", they don't need your implementation notes. They need three things:
1. The objective. What user problem are we solving, in one sentence?
2. The outcomes. What will be true when this ships? (Not what we'll build: what will change.)
3. The edge cases. What could go wrong, and have we thought about it?
That's it for the room. You don't walk the whole spec. You surface these three parts, any open product choices, and the verification that makes "done" unambiguous. (The full spec carries more: evidence, scope, constraints, health metrics. Those rarely need a live walkthrough.)
Compare:
| PRD | Intent Spec |
|---|---|
| 5–15 pages | Half a page |
| Background, goals, user stories, wireframes, technical notes, open questions | Objective · outcomes · evidence · scope · constraints · edge cases · health metrics · verification |
| Read time: 20+ minutes | Read time: 2 minutes |
| "What does paragraph 3 on page 7 mean?" | Everything fits on one screen |
| Updated quarterly (maybe) | A new revision every time a decision changes |
The 10-Minute Spec Review
Here's the workflow that replaces your 45-minute PRD walkthrough.
Step 1: Share the Proposal Before the Meeting
Send the review link 24 hours before. It takes 2 minutes to read, so everyone arrives having read it. (This never happens with PRDs, because nobody reads 12 pages before a meeting.)
If the coding agent drafted the spec, make sure the original request is attached. The room should see the words the agent was asked to interpret beside what it understood.
Step 2: Start With the Evidence
Don't start with "here's what we're building." Start with "here's what users are experiencing."
Every claim in the spec shows its state: Backed, Unreviewed, Assumption, or No evidence. Expand the backed ones and show the friction, the quotes, the metrics, and who reviewed them. Spend 3 minutes here. This is where alignment actually happens: the room agrees on the problem and can see what the agreement rests on.
Step 3: Walk the Outcomes
Read each outcome aloud. For each one, ask: "If this is true after we ship, are we satisfied?"
This is a different question from "do you like this feature?" Outcomes are testable propositions. The team either agrees that these outcomes solve the problem or it doesn't. There's no room for "I think the button should be blue" because the outcomes don't specify buttons.
Step 4: Settle the Choices and Stress-Test the Edge Cases
Edge cases are where alignment falls apart in traditional processes. The PM assumed one thing, engineering assumed another, and you discover the disagreement three days before launch.
In an intent spec, both are explicit. A decision the request left open shows up as a product choice with a recommendation, a trade-off, and an alternative. Settle it in the room. Then walk each edge case. When someone raises a new one, record it as a correction on the proposal right there. The spec does not change silently: the repository agent applies the correction, and the result is a new revision everyone can see.
Step 5: Decide
At the end of 10 minutes, the proposal is authorized, sent back with corrections, or sent back for more evidence. Authorization is recorded for the whole proposal at that exact revision, by the person who made the call. No action items. No follow-up doc. The spec lives in the repository as intent.md; Pathmode keeps the evidence and the judgment behind it.
Verification Replaces "Definition of Done" Debates
Every team has had this argument: "Is this done?" "Well, it depends on what you mean by done."
Intent specs settle it with verification: concrete checks that say how you will know the change worked, including after it ships:
- "End-to-end: exporting 10,000 rows produces a CSV in under 5 seconds"
- "A failed export shows a retry button and the specific failure reason"
- "After release, new users reach their first successful export within 3 steps"
These aren't acceptance criteria engineers bolt on at the end. They're written when the spec is designed, informed by the evidence, and each one carries a status (unknown, passing, failing) that moves as the work does. When engineering delivers, you look at the statuses, not at a debate. For designing the whole loop, see Verification Is a Feedback Loop.
Handling Pushback
Stakeholder pushback is not a problem. It's the whole point.
When someone says "I don't think this outcome is right," they've just given you an edge case or a constraint. Record it as a correction. The spec gets better.
When someone says "we should also add X," check the evidence. Is there evidence supporting X? If yes, it might belong in this intent or in a new one. If no, it can still go in, but it goes in as what it is: an assumption, visible to everyone as one, and never presented as backed.
This is how you say "no" without saying "no." The evidence speaks for you.
💡 Tip: When a stakeholder pushes a pet feature with no evidence, don't argue. Say "Let's write that as an outcome and see whether anything backs it." Either a reviewed signal shows up against that claim, or the claim keeps reading No evidence and the conversation ends naturally.
Anti-Patterns
❌ The PRD in Disguise: Writing a 3-page intent spec with "Background" and "Technical Considerations" sections. If it doesn't fit on one screen, you're writing a PRD with a new name.
❌ The Rubber Stamp Review: Authorizing a proposal in a meeting where nobody pushes back. If everyone agrees immediately, either the problem is trivial or people didn't read the spec. Probe.
❌ The Spec Hoarder: Writing intent specs but never sharing them, then building in isolation. The spec is an alignment tool. If nobody else has seen it, it's just your notes.
❌ The Scope Creep Meeting: Starting a spec review and ending with 15 new requirements bolted on. Each piece of feedback is either an edge case (record it), a new intent (create a separate one), or an opinion without evidence (park it).
Next Steps
- Pick your next feature discussion. Instead of writing a PRD, have the agent propose the intent and share the review link 24 hours before.
- Run a 10-minute review. Follow the five steps above. Time it.
- Compare. Was alignment faster? Were the decisions clearer? Did "done" become unambiguous?
For the review screens themselves, see Your First Intent in Pathmode.