Desire Paths

Here are two routes for the same decision. The middle column is how a typical product process says a pricing decision gets made. The right column is the route the pricing decision in the example on our homepage actually took.

Nobody did anything wrong in the right-hand column. The question came up where the people were, got argued where the work was, and reached the code because the price API was already changing. The paved path is still there, neatly laid out, with very few footprints on it.

Landscape designers have a name for the right-hand column. A desire path is the trail people wear into the grass where the paved path doesn't go, a record of the route people actually want to take, written by their feet instead of by a planner.

Fence it or pave it

Every desire path presents the same choice. You can fence the grass and post a sign, and make people walk the long way around. Or you can accept that the trail is telling you something true about where people need to go, and pave it.

Software has an explicit version of the second choice. When the W3C's HTML working group set out the principles behind HTML5, its 2007 draft of "HTML Design Principles," edited by Anne van Kesteren and Maciej Stachowiak, listed one called "Pave the Cowpaths": "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new." The example was small and telling. Web authors were already writing <br/>, the XML style, in plain HTML, and the draft's verdict was that "there is no harm done by allowing that to be used." The language bent to fit how people wrote it.

The principle sat next to another one, "Evolution Not Revolution," which made the same point at a larger scale: "it is better to evolve an existing design rather than throwing it away." Between them, they describe a design stance. Watch where people already go, and build the road there.

Every decision process is a paved path

Product teams pave paths for decisions all the time. A proposal template. A decision register in the wiki. An architecture decision record folder in the repo. A weekly meeting where calls get made. Each one is a reasonable design, drawn by someone who thought carefully about how decisions should flow.

And decisions keep walking across the grass. The reason is the same reason people cut across lawns: the desire path is shorter, and it goes where the people are. The pricing question came up in a Slack channel because the people who cared about it were talking there. It stalled in a Jira ticket because that's where the blocked work was. Writing it up in the register is a second trip, across the lawn and back, away from where the conversation is actually happening.

So the register stays empty, or it fills up with a fraction of the decisions, written up weeks late by whoever felt guilty. A common response is the groundskeeper's: a fence, in the form of a rule that every decision must go through the template. If your team has tried that, you know how long the fence lasts.

Agents walk faster than anyone

Coding agents make the gap wider. Our essay on the modern product development lifecycle makes the point that coding agents sped up one stage of seven, Build, while the other six still run on meetings. A faster Build means more decisions per week get made at the point of work: in a merge request, in a code review, in the answer to an agent's clarifying question. Those are desire paths too, and they are worn in hours instead of months.

The paved path doesn't speed up to match. The weekly decision meeting is still weekly. The register still needs someone to go and write in it. The result is a growing distance between the map the organization keeps and the ground the work actually covers, and the agents, which can only read the map, end up walking a path nobody can see.

Where Brief fits: paving the cowpaths

Brief is the product strategy agent, and its design stance is the W3C's: pave the paths people already take. As the homepage puts it, Brief "captures decisions where they happen, connects them into one graph, and acts on them." Here is what that does for the route in the right-hand column.

It reads the paths that already exist. Brief reads decisions from Slack, Jira, Confluence and GitLab, self-hosted included, "so every person and agent works from the same record." Nobody has to walk the decision back to a register. In the Decisions view, Sync has Brief search connected sources for past decisions, which is the equivalent of surveying the trails already worn into the lawn before deciding what to pave.

It paves at the spot where people are standing. In a Slack channel, /decide followed by the choice and the reason shows a Decision Preview, and confirming it saves the decision with the Slack author, channel and time. /propose turns an open question into a proposal. Mention @Brief in a thread, and Brief may propose a structured decision from the conversation for you to confirm or edit. In Microsoft Teams, a conversation that produces a decision can show a Decision proposed card with Confirm, Edit and Dismiss. The capture happens in the thread where the decision was made, which is the whole point of paving a desire path: the route doesn't change, the surface does.

Every paved decision keeps its trail. A decision in Brief carries its sources. On the homepage, D-241, the seat-based pricing decision from the table above, is "Linked to 4 sources": the Slack thread, the Confluence spec, the Jira ticket and the GitLab merge request. Brief keeps proposals separate from recorded decisions, so D-241 shows as pending, with an owner, while CPO sign-off is outstanding. Anyone who wants to know how the decision got where it is can walk the trail back.

Agents walk the paved version. Coding agents connected over MCP ask Brief before they write code with brief_ask. In the homepage example, an agent asked to add per-seat pricing learns that D-241 is still pending, holds the change, and flags a related security review it found. Agents can also call brief_list_pending_decisions to see what's still awaiting confirmation. The decisions that were made on the desire path are now on the map the agents read.

Paving a path doesn't make it the right path. Some desire paths cut through a flower bed, and some decisions take a shortcut around something that matters, like the legal review nobody scheduled. Brief records where the decision went; it doesn't decide whether the route was wise. What it can do is flag when a new route crosses an old one: brief ask --mode check checks a proposed change against existing decisions and flags conflicts. And a person still confirms each decision before it's recorded, the same way a planner still decides which trails to pave.

Where are the desire paths in your organization, the threads and tickets where decisions actually get made, and how many of them are on the map your agents read?

Objections