What belongs in a product brain?
A product brain is a maintained collection of product context, approved decisions, feature requirements, and working rules. It gives a team and its agents a reliable starting point for a task. Meeting transcripts provide evidence and history; they do not automatically become current requirements.
TDP’s context-engineering walkthrough describes creating an activity-notification component from an existing feature spec. The demonstration connects the requirement to the project’s component foundations and naming conventions, with review still required afterward. The useful pattern is that chain of references, not a promise that one prompt can replace product judgment.
Use this guide when people repeatedly explain the same product background or disagree about which decision is current. Start with one feature already underway. A small, maintained set of documents is more useful than an archive that an agent must interpret from scratch.
Step 1. Write the entry point
Explain the product, its users, the active work, and where the important rules live. Keep this file short enough to inspect before a task. A founder should be able to identify the current product priorities; a designer should be able to find the component rules without reading every meeting transcript.
Step 2. Separate decisions from raw history
Keep notes and transcripts as supporting evidence. Put approved behavior in a decision record or feature specification. When a decision changes, mark the previous record as superseded and link to the replacement. Otherwise an agent may retrieve a confident answer from an obsolete discussion.
Step 3. Give each document a job
This is a starter structure. Adjust filenames to the tools your team uses and explicitly connect the entry point to the agent’s supported context mechanism.
PRODUCT.md audience, problem, current boundaries
DESIGN.md visual principles and component references
docs/current.md active priorities and open questions
docs/decisions/ approved choices and reasons
docs/features/ behavior and acceptance criteria
docs/research/ supporting notes and source material
| Record | Include |
|---|---|
| Decision | Choice, reason, owner, status, supporting reference |
| Feature | Actor, goal, states, constraints, acceptance criteria |
| Current context | Active work, changes, unresolved questions |
| Design rule | Implementation reference and approved use |
Step 4. Connect one feature to its components
Choose a small feature and link its requirements to the relevant tokens, components, and workflow. Ask the agent to explain the intended behavior and cite the files it consulted before it edits anything. Missing references are easier to fix here than after a polished prototype has embedded the wrong assumption.
Step 5. Establish a maintenance habit
Assign an owner for active context. Update current decisions when work is approved or shipped, and move completed discussion out of the entry point. Keep a small record of retrieval failures: which rule was missing, where it should live, and what changed. This provides a practical basis for improving the structure.
Worked example: promote a conversation into an approved decision
Imagine a customer call contains three statements: a request for bulk invitations, a concern about permissions, and a suggestion to defer role selection. These are different kinds of information. If all three are copied into a feature brief as instructions, an agent may implement a contradiction.
Keep the transcript as source material. Extract the request and concern into a review note. Ask the accountable product owner to decide the intended behavior, then record the approved conclusion with its rationale and a link to the source. The decision might be “invite one teammate at a time for this release; bulk invitations remain an exploration.” That is specific enough to guide implementation without pretending the original discussion was unanimous.
| Record | What belongs there | What should not be inferred |
|---|---|---|
| Meeting note | What was discussed and by whom | That every suggestion was approved |
| Exploration | Options, tradeoffs, and open questions | That a polished mockup is ready to build |
| Decision | Current approved direction and rationale | That it remains current after a later reversal |
| Feature brief | Behavior, states, criteria, references | That omitted edge cases do not matter |
| Current context | Active priorities and unresolved work | That it should duplicate every historical detail |
A small structure you can maintain
context/
start-here.md
product.md
current-work.md
decisions/
features/
meetings/
explorations/
ways-of-working.md
These names are illustrative. Use the structure your team can actually maintain. The entry point should explain where to find current decisions and how to tell them apart from proposals. For each active feature, include an owner, status, acceptance criteria, and the design or code references that matter.
In TDP’s workflow, communication guidance also lives with project context. A useful update follows the team’s agreed tone and reports what changed, what was checked, and what needs a decision. An agent drafting the update should not claim that an unperformed check passed.
Test retrieval before trusting generated work
Ask the agent to answer a few questions without making changes: Who is the user? What problem is the feature addressing? Which behavior is approved? Which component should be reused? What remains undecided? Require source references for the answers.
If it answers from an old exploration instead of the decision record, repair the context structure. Add a clear superseded notice or a pointer to the current decision. If it cannot find the feature spec, make the route from the entry document more explicit.
Then run one bounded design task. Review both the output and the sources used. A convincing result does not prove retrieval worked; an agent can produce a plausible screen while missing a critical permission rule.
Maintain context when work changes
Update the durable record when the team approves a new decision. Preserve history, but make its status clear. A simple decision entry can include the question, decision, reason, owner, date, source, and what it supersedes. Avoid silently overwriting the explanation that a future teammate will need.
Close a feature by recording what actually shipped and any deferred scope. The next task should start from that current behavior. Schedule context review around normal product events—planning, approval, and release—so maintenance is part of delivery rather than an occasional cleanup project.
For the full feature process, continue with planning an AI product workflow. For visual rules, keep a separate design.md connected to real components.
Completion checklist
- Current decisions are distinguishable from proposals.
- Each important document has a clear owner or review responsibility.
- The entry point links to the working rules.
- One feature can be explained from the recorded context.
- The agent identifies unknowns rather than inventing behavior.
Common questions
Must every transcript go into the agent’s prompt?
No. Keep source material available and select what matters for the task. A short, reliable decision record is often more useful than an unfiltered meeting archive.
Can this live outside the product repository?
Yes, if the people and tools doing the work can access it reliably. Document the connection and avoid keeping two conflicting versions of the same rule.
Sources and TDP resources
- TDP’s context engineering walkthrough describes the underlying product-brain approach.
- Product context builder provides a reusable skill for organizing context.