TL;DR Two weeks ago, I argued that the buyer your PRD targets is being replaced by an agent. This week, I did the work: I sat down with the Persian Sunrise PRD and rewrote it for an agent-readable world. About a third of the template stayed exactly the same. About a third got reframed. And one section, the one I’d written most carefully two years ago, turned out to be the section I should have been writing all along. I Rewrote My PRD Template for Agents. Here’s What Survived. Here are the actual before/afters, in the order I touched them.
I spent Saturday morning at the kitchen counter with two printouts: the Persian Sunrise PRD as it was, and a blank template I was rebuilding. I’d promised at the end of last week’s piece that I’d actually do the rewrite, not just talk about it. The PRD had been good enough to get us through Q1 through the blender selection, the lid+vessel decision, and the first NFC chip embedded in a lid prototype. Good enough wasn’t going to survive a buyer without eyes.
What I expected: a complete teardown. What actually happened was more interesting. About a third of the document didn’t need to change at all. About a third needed reframing. And one section, Provenance, turned out to be the most important section in the document, the section I’d written most carefully back when nobody but our farmers and our future customers would ever read it. That section was already an agent-readable artifact. I just hadn’t known it.
Here’s what changed, in the order I touched it.
What survived without a single edit
The first thing I want to say, because it’s easy to lose in a “rewrite your PRD!” post: the foundational sections didn’t need to move. Strategic context, user problem statement, success metrics, and dependencies still read true regardless of whether the buyer has eyes. The Persian Sunrise PRD’s opening still reads:
Strategic context: Trevean's first ready-to-sell blend, designed to
validate the lid+vessel+NFC system end-to-end before we expand to
Caribbean Sunset and the broader catalog.
User problem: experienced home cooks want flavor authenticity but
have no reliable way to verify origin claims for the spices they buy.
If anything, the agentic shift sharpened those sentences rather than challenged them. The user problem “no reliable way to verify origin claims” is more acute when the verifier is an agent than when it’s a curious human. The strategic context got reinforced, too. Nothing to do here. Move on.
This is worth naming because Build-to-Learn / Build-to-Earn is sometimes mistaken for “rewrite everything every quarter.” It’s not. The verb is build, not raze. You only rewrite what the world made wrong.
The first real diff: user persona
This is the change that took the most thinking and the least typing.
Before:
Primary persona: Maya, 34, home cook, shops once a month at
specialty grocers and online. Values origin storytelling, willing
to pay a premium for verified single-origin spice.
After:
Primary persona (human): Maya, 34, home cook, shops once a month
at specialty grocers and online. Values origin storytelling.
Primary persona (agent): a shopping agent acting on Maya's behalf
under an intent like "find a smoky paprika under $20, single-origin
preferred, from a producer Maya hasn't bought from before." The
agent will not view the PDP. It will query our capability surface,
read structured product attributes, and verify any sourcing claims
against attestation endpoints before recommending.
One persona became two. Same Maya, two distinct buyers acting on her behalf at different moments in the funnel. The agent-persona has its own acceptance criteria: the post-checkout summary it returns to Maya must be able to truthfully answer “why this one?” using machine-readable evidence.
I almost didn’t add that second persona; it felt redundant. Then I tried writing the rest of the PRD without it and watched every other section fall apart for lack of a target user.
The middle: experience requirements
This was the section that got the heaviest reframe. The old PRD had a long subsection called “PDP experience” that described the hero image, the origin video, the sticky add-to-cart, and the testimonial carousel. None of that goes away; Maya the human still lands on PDPs. But it stopped being the load-bearing section.
I added a sibling subsection above it called “Intent-surface experience”:
Intent-surface experience:
When an agent queries Persian Sunrise via UCP or equivalent
protocol, our capability surface must respond with:
- canonical product attributes (origin region, harvest window,
varietal, Scoville range, smoke intensity, recommended uses)
- price + availability in real time
- provenance attestation URL (resolves to signed evidence
of origin claim see Provenance section below)
- 2-3 substitution suggestions from our catalog with structured
reasons (e.g., "lower smoke intensity but similar origin")
Latency target: <400ms p95 for the attribute query.
Latency target: <800ms p95 for full provenance resolution.
That’s a real PRD section now. It has acceptance criteria. It has latency targets. It has a contract.
Two practical notes for any PM doing this:
First, the latency targets matter more than they look. Human PDPs can take two seconds to load, and most users don’t notice. Agent surfaces compete for selection inside a multi-merchant query. Slow attribute resolution gets you ranked below the next paprika. This is the agentic version of the SEO race I wrote about in [How Generative AI Is Reshaping SEO], with the same dynamics, on a faster clock.
Second, the substitution suggestions section was the part I most wanted to skip. Why would I send an agent toward an alternative? Because if I don’t, the agent will. The agent will find a substitute anyway; the question is whether it finds my substitute or my competitor’s. Surfacing structured alternatives keeps Maya inside the Trevean catalog even when Persian Sunrise isn’t quite the right fit.
The provenance section is already agent-ready, and I didn’t know it
Here’s the part that surprised me.
When we wrote the Persian Sunrise PRD in late 2025, the Provenance section was the one I rewrote the most times. It felt important and slightly self-indulgent to have pages of detail about farmer attestation, harvest timestamps, signing keys, and the chain from field to lid. I assumed most of that would never be read.
The agent reads all of it.
Provenance, as written, looked like this:
Each Persian Sunrise unit carries an NFC chip embedded in the lid
that resolves, on tap, to a unique provenance record at
provenance.trevean.com/{unit_id}. The record contains:
- farmer attestation (signed by the producing cooperative)
- harvest timestamp range
- testing lab attestation for capsaicin/smoke metrics
- chain of custody from origin to filling facility
I didn’t change a word. I added one sentence at the top:
This section also serves as the agent-facing trust receipt
specification. The same attestation chain readable by Maya via
NFC tap is queryable by an agent via the provenance attestation
URL surfaced in Intent-surface experience above.
That’s it. The work I’d done to make the NFC tap meaningful for a human turned out to be the work I needed to make Persian Sunrise legible to an agent. This is the practical version of what I argued in Transparency Isn’t a Feature, It’s the Floor if you build trust as structure rather than vibe, it carries across the boundary between human-readable and machine-readable for free.
It also reframed my read of the NFC + provenance work going forward. I used to think of it as a marketing differentiator. I now think of it as the load-bearing wall of the entire “ready to sell” claim. Pull that wall, and the PRD collapses on both sides, human and agent.
What got cut
One section came out entirely: “Conversion funnel optimization.” Not because conversion doesn’t matter, but because the funnel framing was wrong. I replaced it with a section called “Capability completeness” that asks a different question:
Capability completeness checklist:
- [ ] Every customer-facing capability has a documented, agent-callable endpoint
- [ ] Every product claim resolves to a verifiable attestation
- [ ] Every PDP element has a structured-data equivalent
- [ ] Every substitution path is enumerated in the catalog graph
This wasn’t a hard cut. The funnel section had been the least-read part of the document anyway, full of A/B test plans that always slipped behind other priorities. The capability section is read at the start of every sprint.
What I learned doing it
The most useful thing about the rewrite wasn’t the diff itself. It was what the diff revealed about the work I’d been doing all along.
Roughly a third of the PRD didn’t need to change. Strategic context, user problem, success metrics, and dependencies, those translate. If your foundational thinking is right for humans, it’s mostly right for agents too.
Roughly a third got reframed but not replaced. The PDP experience didn’t disappear; it got a sibling. The funnel section got renamed and tightened. Most of the work was adding load-bearing structure next to existing prose, not tearing prose out.
The remaining third of the provenance and capability surface was where the real shift lived. And both of those were already implicit in the work we were doing for human-facing reasons. The agent rewrite mostly named what we were already building. As I argued in the original UCP post, the trust receipt was the load-bearing concept; the PRD rewrite just made it explicit.
There’s a pattern in here that I want to name for any PM doing this exercise: you are probably further along than you think. Most of the panic around “designing for agents” assumes you have to start over. You don’t. You have to find the sections of your existing PRD that were already structured, surface them as first-class artifacts, and let the loose marketing-prose sections take their proper place as one rendering rather than the rendering.
What I’m doing next
The Persian Sunrise PRD is committed. Caribbean Sunset is next, and I expect it to be a faster rewrite now that the template has been through the wringer once. After that, I’m going to do something I should have done weeks ago: write the cross-product capability schema that both blends share. Right now, Persian Sunrise’s intent-surface section lives inside Persian Sunrise’s PRD. That’s fine for one product. By blend three or four, it’ll be a maintenance nightmare. The schema needs to live one level up.
I’m also adding a new ritual to our weekly cadence: every PRD review now includes a “what would an agent see?” pass. Whoever drafts the PRD walks through it as if they were the agent querying it, looking for missing structure, hitting endpoints that don’t exist. It’s an awkward exercise the first time. It gets faster.
That, more than any single PRD section, might be the real takeaway. The work isn’t to ship a new template. The work is to add a new reader to the room every time you write one.
Related reading from PMJ
If this post resonated, the through-line continues across earlier pieces:
- Your Next Customer Doesn’t Click Three PRD Lines for Agentic Commerce last week’s piece; the why behind this week’s what.
- Transparency Isn’t a Feature, It’s the Floor why structured trust travels across the human/agent boundary for free.
- Build-to-Learn / Build-to-Earn the verb the Product Onion was missing, and the lens I used to decide what to rewrite versus what to leave.
- The Coming Distribution Wars why agent-readable PRDs are a competitive moat, not a chore.
- How Generative AI Is Reshaping SEO the SEO/AEO context that explains why the intent-surface latency targets matter.
- AI Can Now Smell a Fake why the provenance section turned out to be the load-bearing wall.
FAQ
Do I need to rewrite every PRD in my backlog? No. Start with one, ideally a product currently in flight that has a real shot at being agent-discovered in the next 6–12 months. The point of the rewrite is to surface the gaps in your existing template, not to ship a documentation refactor. Once you’ve done one, the next ones get easier, and you’ll find a lot of the same patterns.
What if my company doesn’t have provenance or NFC work to anchor the trust section? Provenance is one form of structured trust; it’s not the only one. Verified supplier lists, third-party audit endpoints, signed test results, dated certifications, and even structured customer-review schemas can play the same role. The bar is “can an agent read this and decide whether to believe it?”, not “does it involve NFC?”
How does this PRD template interact with our existing PRD process? Mine still lives in the same tool with the same review cadence. The change is structural, not procedural. The biggest behavioral change is the “what would an agent see?” review pass I described at the end, which is worth installing even before you do a full rewrite. See also The Coming Distribution Wars for why this matters competitively.
What about products that will never be agent-discovered (B2B, regulated, complex sales)? Some products genuinely sit outside the agentic surface yet. The reframing exercise remains useful because it forces you to write down your product’s definition in a structured format. That artifact is valuable even if no agent ever reads it; your sales team and your AEs will use it. If you’re sure agents will never matter to your product, do the exercise anyway and keep it in the drawer.
What’s the single thing I should do this week? Open the most active PRD in your backlog. Add one line under the primary persona: “Primary persona (agent): […]”. You don’t have to finish it. Just see what happens when you try.
If you’re rewriting your own PRD template for this shift, I’d love to see what stayed and what didn’t. Reply and tell me or send me the diff.
Leave a Reply