An Idea Brief gives an AI agent direction. A PRD gives it boundaries.
That distinction matters because an agent does not leave an unanswered product question blank. It fills the gap with an assumption and carries on. Sometimes that assumption is sensible. Sometimes it quietly changes the product.
Episode 2 is about preventing that drift. The goal is not to turn a short brief into a longer document. It is to turn product intent into a set of explicit, traceable decisions before architecture and implementation begin.
A PRD is a decision lock, not a longer Idea Brief
The Idea Brief from Episode 1 captures the product’s purpose, audience, and V1 boundaries. It is enough to begin a product conversation, but not necessarily enough to tell an agent exactly what every meaningful outcome should be.
The PRD is the handoff point where that conversation becomes settled product truth.
[Embed Visual 1 here — replacing or following the ASCII diagram.]
Caption: From product intent to technical design: the PRD decision lock is the handoff point.
Alt text: Flow from Idea Brief through requirement audit and decision lock to a PRD, then architecture.
Production prompt — not part of the published article:
Create a clean editorial diagram in a modern dark-navy technical style. Show five connected horizontal stages: “Idea Brief — Product direction,” “Requirement audit — Find gaps,” “Decision lock — Resolve or classify,” “PRD — Product truth,” and “Architecture — Technical decisions.” Use rounded rectangular cards, thin cyan connector arrows, off-white typography, and restrained green highlights on “Decision lock.” The visual should feel calm, precise, and suitable for a developer education article. No people, no logos, no code, no decorative clutter. Wide 16:9 composition with generous whitespace.
Architecture answers technical questions: how data is stored, how screens are organized, which libraries are used, and how components work together. The PRD answers product questions first: what the user can do, what should happen, what must never happen, and how the product behaves when things go wrong.
That separation keeps “how should we build it?” from quietly deciding “what are we building?”
Not every unanswered question belongs in the same bucket
A useful PRD process does not treat every question as an urgent question. Some answers already exist in the Idea Brief. Some need a creator decision now. Some are valid later decisions. Others simply do not belong in V1.
A product question appears
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Already decided? Needs product Not part of
intent now? this product?
│ │ │
▼ ▼ ▼
Inherited and Needs Out of scope
resolved clarification
│
▼
Can safely wait?
│
▼
Deliberately deferred
with a reopening event
[Embed Visual 2 here — replacing or following the ASCII diagram.]
Caption: Every question must become a carried-forward decision, clarification, explicit deferral, or exclusion.
Alt text: Decision tree classifying product questions as inherited and resolved, needing clarification, deliberately deferred, or out of scope.
Production prompt — not part of the published article:
Create a clear vertical decision-tree diagram for a developer education article, using a dark-navy background, off-white text, cyan connector lines, and subtle green status highlights. Start with “A product question appears.” Branch into four outcomes: “Inherited and resolved,” “Needs clarification,” “Deliberately deferred with a reopening event,” and “Out of scope.” Make “Needs clarification” the central active path. Use rounded cards, simple directional arrows, and ample whitespace. No people, logos, gradients, code snippets, or unnecessary decoration. Portrait-friendly layout that also crops well for a blog column.
For the Habit Tracker, the local-only boundary is already settled. There is no backend, cloud sync, account system, REST API, or network synchronization to rediscover during PRD creation. Those are not open questions; they are out of scope for this series.
A deferred technical decision is different. For example, choosing a persistence library may matter later, but it does not need to be guessed inside a product requirement. It should be deferred deliberately, with a clear owner and a condition that tells the team when to reopen it.
A question left unclassified is the dangerous one. It looks small until the agent supplies its own answer.
Let the agent recommend. Keep the creator as the decision-maker.
A good agent should not merely interrogate the creator with a long checklist. It should help move the conversation forward.
When a product requirement is unclear, the agent can make a recommendation and explain:
- The decision that needs to be made
- Its recommended resolution
- Why it recommends that option
- The trade-offs involved
- What changes downstream if that decision is accepted
The creator can approve the recommendation, reject it, or provide counter-intent: the underlying reason the recommendation does not fit the product.
Unclear requirement
│
▼
Agent recommendation
with reasoning
│
▼
Creator response
approve / reject / counter-intent
│
▼
Approved decision
with rationale and consequence
This is the productive division of responsibility. The agent contributes structured thinking. The creator remains responsible for product intent.
Counter-intent is particularly valuable. It does more than choose a different answer; it tells the agent what principle should guide future decisions. That makes the resulting PRD more coherent than a collection of disconnected approvals.
“No open questions” does not mean “no uncertainty”
A PRD does not need to predict every future choice. It needs to ensure that every current product-definition question has a known status.
By the time the PRD is locked, each item should be one of these:
- Inherited and resolved from the Idea Brief
- Resolved during the PRD conversation
- Deliberately deferred, with an owner and reopening event
- Explicitly out of scope
That is a much stronger condition than simply writing “Open questions: none.” The phrase is only meaningful when the decision record shows where every question went.
The result is not false certainty. It is controlled uncertainty.
Turn a proven conversation into a reusable harness
Once the PRD decisions are locked, the conversation itself becomes a reusable workflow.
PRD-Creation Skill
owns the method
│
▼
PRD-Creator Agent
runs the method
│
▼
PRD Template
provides durable structure
│
▼
Project PRD
captures this product's truth
The order matters. The team should not begin by writing a generic template and then force the product into it. First, observe the conversation that resolves product intent. Then capture the repeatable method as a skill, keep the agent thin and focused on applying that skill, and create a template that supports the proven workflow.
The project PRD then contains only decisions inherited from the Idea Brief or explicitly approved during the conversation. It should not contain the agent’s unapproved preferences disguised as requirements.
The handoff to architecture
A locked PRD does not finish product work forever. It creates a trustworthy starting point for the next kind of work.
For this series, the Habit Tracker remains local-only. The PRD establishes the product behaviour that must be preserved. A later architecture episode can decide how to support that behaviour in Android without reopening settled product intent by accident.
That is the real value of the decision lock: it gives the next agent less room to guess.
Before moving from a brief to a specification, ask one simple question: can every meaningful product question be traced to a decision, a deliberate deferral, or an explicit exclusion?
If not, the agent still has product decisions left to make on your behalf.