A product plan a coding agent can read
Most product plans are written for people in a meeting. They live in slides, documents and boards, and an agent working in your repository cannot reach any of them. So when the agent needs to know why a piece of work exists, it has the code and your last message, and it guesses. This page is a plain-words definition of the alternative: a plan that is written for the agent as much as for you.
Four layers, in order
Goals sit at the top. A goal is an outcome, not a feature, and it carries a measure so you can tell whether you are getting closer. "Independent publishers earn a living on the platform" is a goal. "Add a paywall" is not.
Needs sit under goals. A need is a user problem that stands between you and the outcome. One goal usually has several. "A reader who likes one post has no way to find the next" is a need.
Approaches sit under needs. An approach is a bet on how to meet the need, and because it is a bet it has a status: in development, in validation, resolved, or retired. Two approaches under one need are two competing ideas, and the plan is allowed to say that one of them lost.
Jobs sit under approaches. A job is an observable checkpoint, not a task. "A follow from another server shows up within a minute" is a job; "add the webhook handler" is implementation detail, and it goes in the job's notes. Jobs are assigned to phases, which is how the same tree turns into a delivery view.
Why this shape and not a document
The layers give every piece of work a parent, and every parent a reason. That is the property an agent needs. Handed a job, it walks up: this job checks that approach, which is a bet on that need, which serves that goal. Handed a request that does not fit anywhere, it can say so, which is usually the most useful thing an agent can say.
The shape is also small. A real product, even a large one, fits in a hundred or two nodes. An agent reads that in a single call and holds it in context alongside the code. A document of the same content would be longer, would have no addresses, and could not be updated one node at a time.
What "an agent can read" means in practice
Three things, all of which exist today and none of which need the agent to be clever.
It can fetch the plan: the whole tree as JSON, one node with its ancestors and children, or a search for the node that matches a phrase. It can write to it: add a job under the right approach, mark it done when the change is live, record what changed. And it can take it with it: the plan exports to JSON and to an OKF markdown bundle, one file per node with the relationships as links, so it can sit in a repository next to the code or move to another tool without loss.
In ProductBrain the same tree is the canvas you edit and the API the agent calls, over REST or an MCP server. The agent guide is a single public page the agent reads once. The free tier includes the API, with a cap of a hundred nodes.
What it is not
It is not a task tracker, and it does not replace one. Tickets, sprints and assignees stay where they are; the plan sits alongside and answers a different question. It is not a spec: a spec describes one feature in full, a plan says why that feature exists and what else serves the same need. And it is not memory. The agent still starts each session cold. It just has something structured to read first.
Read one
Definitions are cheaper than examples. This plan is for Immich, the self-hosted photo platform, reconstructed by a coding agent from the public repository, including the bet on a plugin platform and the jobs that will tell whether it pays off. Open it, pick a job, and walk up to the goal.