I kept a folder of product context so the AI would stop inventing things. Strategy, decisions, metrics, feedback, all in markdown, fed into every prompt. For about two weeks it was great. Then the team shipped, the folder didn’t move, and the AI started answering with total confidence about a product that no longer existed.
That folder taught me something I did not want to learn. Building the brain is the easy half. The question that decides whether any of it survives contact with a real team is the one I had no answer for: who keeps it up to date?
The folder lies the moment you ship
A folder of notes has a quiet failure mode. It does not break. It drifts.
You write the PRD on Monday. By Friday the team shipped three changes, two of which quietly contradicted it. Nobody updated the doc, because updating the doc is nobody’s job and everybody’s chore. So now the AI reads a context that is half true, and it answers with confidence about a product that no longer exists.
There are two pains here and you have felt both. The AI gives you stale answers, because the context it reads went old. And you spend your evenings updating docs, PRDs and product state, because the moment you stop, your own documentation starts lying to you.
The usual reaction is to build a better brain. Better templates, stricter conventions, a nicer wiki. That is optimizing the file. It does not help, because the problem was never the file. The problem is that the file has no way to know the product changed.
The brain has to be a graph, not a folder
A folder is a pile. A pile has no idea what relates to what. When a decision changes, a folder cannot tell you which user stories it just invalidated, because a folder does not know they were connected.
So the first move is to stop storing product context as documents and start storing it as a graph. Every artifact is a node: the PRD, each epic, each user story, each acceptance criterion, each decision record, each risk. And the nodes are connected by typed relations that mean something: this epic is part of that PRD, this acceptance criterion validates that story, this decision supersedes that one, this task implements that criterion.
That sounds like bookkeeping. It is the opposite. Once the relations are real, the graph answers questions a folder can’t:
- Change one decision, and you can see every downstream story and criterion it touches.
- Reopen a risk, and you can walk to the work that was supposed to mitigate it.
- Ask “why does this exist”, and the graph walks you back up from a line of behavior to the objective that asked for it.
The product hierarchy stops being a story you tell in standup and becomes a structure the machine can traverse. That is the difference between documentation you maintain and a brain that holds its own shape.
The loop that a human cannot run
Now the part that matters, and the part the folder crowd keeps underselling.
Five things should feed a product brain: feedback comes in and clusters into opportunities; you make a decision and it gets recorded; a metric moves and the brain absorbs it; you do discovery and it goes in; and the big one, your team ships something, and that updates the state of the product, the guides, and reconciles the PRD.
Four of those you can do by hand if you are disciplined. The fifth you cannot. Not because you are lazy. Because the trigger is wrong.
When the loop fires on “the team shipped”, what it really fires on is someone marking a task as done. And a task marked done is an opinion. The agent said it was finished, the build went green, the card moved. None of that means the code does what the story asked. A green build is not a correct feature. If your product brain updates every time someone clicks done, it fills up with confident lies, and it does it faster than you can catch them.
So the trigger has to change. The brain should update when the work is verified against the criterion that defined it, not when a human declares victory.
Tie the code to the decision that asked for it
Here is the version I have been building instead of a folder.
When a piece of work completes, it does not just flip a status. The system goes and finds the real evidence for it in the repo, the actual code, tests, configs and runs, and links that evidence back to the artifact that required it. Not “this PR is probably related”, but a durable, typed link: this code satisfies this acceptance criterion, this run validates this story. Each artifact declares up front what kind of evidence would prove it, and completion is the act of producing that evidence, not asserting it.
The effect is that every line of code is attached to the product decision that asked for it. The graph is no longer a description of the product sitting next to the code. It is wired into the code. When the work changes, the brain changes, because the link between them is the same fact, not two facts you have to keep in sync.
This is the loop a human cannot run by hand, running on its own. The brain stays true not because you updated it, but because “true” is what passing verification means.
The side effect: you can finally see where your time goes
Once code is tied to product artifacts, something falls out for free that I did not expect to value as much as I do.
You can see where your time and your spend actually go, by product, not by commits.
Every unit of AI work gets attributed: which role spent it, on which project, against which artifact. Not “we burned a lot of tokens this week”, but “this epic cost this much, the product-owner work cost that much, this feature was three times more expensive to get right than we estimated”. Cost and effort roll up the same graph as the work itself, because they are hanging off the same nodes.
For a PM that changes the conversation. You stop arguing about activity and start looking at where effort concentrates against outcomes. The graph that keeps your context true is the same graph that tells you what your roadmap actually cost.
Stop optimizing the file
The mindset shift is small and it changes everything. Stop trying to build a better archive. The archive was never the point.
Build the structure that connects product to code, and let the trigger be verification, not a click. Do that and the brain maintains itself, because keeping it true stops being a chore you do and becomes a property of how the work gets done.
The folder was the easy part, and it was never the part that mattered. What I actually needed to build was the loop that keeps it from lying to me.
This is one of the reasons I build PaellaDoc the way I do, and it sits right next to the rest of the argument: making product is not productizing, and a green build is not a correct feature.
How are you keeping your own product brain from going stale? Tell me on the forum, I want to hear what’s working.