No. 114Product strategy

The Knowledge Problem

Nobody on your team knows everything your product has decided. Routing it all through one meeting won’t change that.

Here is a memo from the VP of Product at an invented company, sent the week after its engineers' coding agents passed 150 pull requests a week:

To: Product and engineering

Subject: Product Decisions Council, starting Monday

Agents are shipping faster than any of us can follow, and changes to pricing, permissions and data retention are landing without anyone seeing the whole picture. Starting Monday, any change in those three areas needs sign-off from the new Product Decisions Council, which meets twice a week. The council will have the full roadmap, the pricing model and the metrics dashboard, so it can make consistent calls in one place instead of fifteen. Bring your proposals with a one-page summary.

It is a reasonable memo. The problem it names is real. Now consider what the council will not know when it meets on Monday.

The support lead knows that admins keep turning off the export setting by mistake, because the label reads like a privacy control. The sales lead knows that three prospects in the last month asked to pay for extra seats rather than have invites fail. An engineer on the data team knows that the 90-day retention constant in the export service isn't a bug: it covers a legal hold in two enterprise contracts. None of that is on the roadmap, in the pricing model, or on the dashboard. All of it bears on decisions the council will make.

An economist described this problem in 1945, and his answer was neither a council nor everyone deciding alone.

Knowledge that is never given to anyone in its totality

Friedrich Hayek published "The Use of Knowledge in Society" in the American Economic Review in September 1945. He opens by setting aside the textbook version of economics, where someone has all the relevant information and the rest is "purely one of logic." That, he says, "is emphatically not the economic problem which society faces."

The real problem comes from how knowledge is spread out. "The peculiar character of the problem of a rational economic order is determined precisely by the fact that the knowledge of the circumstances of which we must make use never exists in concentrated or integrated form but solely as the dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess." Put briefly, he writes, "it is a problem of the utilization of knowledge which is not given to anyone in its totality." That sentence is Hayek's own statement of what this post calls the knowledge problem.

Hayek frames the argument of his day as a question about who plans. Everyone plans, he says; the question is "whether planning is to be done centrally, by one authority for the whole economic system, or is to be divided among many individuals." And which works better depends on one thing: "under which of them we can expect that fuller use will be made of the existing knowledge."

The particular circumstances of time and place

The knowledge Hayek cares most about isn't the kind experts hold. Beside scientific knowledge, he writes, "there is beyond question a body of very important but unorganized knowledge which cannot possibly be called scientific in the sense of knowledge of general rules: the knowledge of the particular circumstances of time and place." Almost everyone has some of it that nobody else has, and it can be used "only if the decisions depending on it are left to him or are made with his active coöperation."

This kind of knowledge is hard to send upward. It "by its nature cannot enter into statistics and therefore cannot be conveyed to any central authority in statistical form." A central authority would have to work from summaries that lump together "items which differ as regards location, quality, and other particulars, in a way which may be very significant for the specific decision."

It also matters most when things change, which Hayek thought was all the time. "It is, perhaps, worth stressing that economic problems arise always and only in consequence of change." Day-to-day work is kept going "by constant deliberate adjustments, by new dispositions made every day in the light of circumstances not known the day before."

The Product Decisions Council is the central authority, and its roadmap, pricing model and dashboard are the statistics. The support lead's label problem, the sales lead's three prospects and the engineer's legal hold are knowledge of particular circumstances. They are exactly what a one-page summary leaves out.

Decentralization is only half of the answer

Hayek's conclusion is that "the ultimate decisions must be left to the people who are familiar with these circumstances." He calls that person the "man on the spot." But he immediately says it isn't enough. "We must solve it by some form of decentralization. But this answers only part of our problem." The man on the spot "cannot decide solely on the basis of his limited but intimate knowledge of the facts of his immediate surroundings." He still needs "such further information as he needs to fit his decisions into the whole pattern of changes of the larger economic system."

In an economy, Hayek argues, prices do that. A price tells a user of tin that tin has become scarcer without telling them why, and they adjust. "The most significant fact about this system is the economy of knowledge with which it operates, or how little the individual participants need to know in order to be able to take the right action. In abbreviated form, by a kind of symbol, only the most essential information is passed on and passed on only to those concerned."

Product teams fail both ways

Product teams with coding agents tend to land on one of Hayek's two failures.

The first is the memo: route every material decision through one council, one reviewer or one meeting, and hope the summary carries what matters. It doesn't, for the reason Hayek gave. The knowledge that decides the case is the kind that doesn't survive being summarized.

The second is the reverse: everyone decides alone. The engineer and their agent make the call on the export setting, the retention constant and the seat limit, using whatever they can see from where they sit. That is decentralization without the other half. Coding agents make it worse in a way Hayek couldn't have anticipated. An agent is now often the one on the spot, the one actually changing the export service, and it has none of the intimate knowledge Hayek's man on the spot was supposed to have. That framing is ours, not his, but the gap is real. The legal hold lives in an engineer's head and two contracts, and the agent has neither.

Our essay on the modern product development lifecycle describes a stage between the two: "Material decisions go to a named owner, routine ones stay with the team." That is close to Hayek's answer. Decisions stay near the knowledge. What's missing in most teams is the other half: a way for each decision, once made, to reach the people and agents whose work it affects. We've written about why so much of this knowledge is tacit and hard to hand over at all. Hayek's point is that it doesn't have to be handed over: what has to travel is the result, small enough to pass on.

Where Brief fits: passing decisions on

Brief is the product strategy agent. The homepage says it "captures decisions where they happen, connects them into one graph, and acts on them." In Hayek's terms, it is meant to be the other half: decisions stay with the people who know the circumstances, and what they decide reaches everyone else in a form small enough to use.

Decisions stay with the people who know. In the Brief app, Propose turns an open question into a pending decision and can name Who should decide?, so the export setting can go to the support lead's team and the retention question to the engineer who knows about the legal hold. With the user's approval, an agent can record a pending decision too. Recording a decision requires both What was decided? and Why? before Record Decision will save it, and a decision can also carry Tags and a Re-evaluate when condition.

Decisions are read from where they are made. The memo asked people to bring one-page summaries to a meeting. The homepage says Brief "reads decisions from Slack, Jira, Confluence, and GitLab, self-hosted included." The sales lead's seat decision, settled in a thread, and the retention rule, settled in a ticket, can be recorded without anyone writing a summary for a council.

What gets passed on is the decision. Hayek's prices work because "only the most essential information is passed on and passed on only to those concerned." A recorded decision is our analogy for that: a short statement and its reason, in place of the thread, the contracts and the meeting. Coding agents set up with Brief search the recorded decisions before they start work, and ask Brief to check significant changes with brief_ask in check mode, which compares a planned change against existing decisions and flags conflicts. An agent about to shorten the retention period in the export service can meet the legal hold decision without ever reading the contracts. People can run the same check with brief ask --mode check.

Open questions hold instead of guessing. When a decision is still pending, an agent can hold. The homepage shows an agent asked to add per-seat pricing to the checkout API learning that D-241, the seat-based pricing decision, is pending, and replying: "Holding the pricing change until D-241 is decided." Agents can call brief_list_pending_decisions to see what is waiting.

Change is the normal case. Hayek's problems "arise always and only in consequence of change." A decision's Re-evaluate when condition records in advance what change would justify a new look, and its History shows status changes when it moves. With Proactive Brief turned on, Brief can also prompt people to revisit decisions that may need reconfirming.

None of this solves Hayek's problem outright. Much of the knowledge he meant can't be written down, and Brief only passes on the decisions someone records. A decision isn't a price, either. A price moves on its own when circumstances change, and a recorded decision moves only when someone records the change. When nothing has been recorded, check mode has nothing to conflict with, and the agent goes ahead on what it can see. What Brief changes is the path. Decisions are made close to the knowledge, and the result reaches the next person or agent without passing through a council that can't know what they know.

Hayek's question was which arrangement makes "fuller use" of the knowledge that already exists. On your team, how much of what your support, sales and engineering leads know ever reaches the agent making the change?

Objections

Objection 1

What is the knowledge problem?

The knowledge problem is a name for the problem Friedrich Hayek set out in "The Use of Knowledge in Society" (1945): the knowledge needed for good economic decisions never exists in one place. In his words it exists "solely as the dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess," so no central authority can gather it all, and decisions have to make use of knowledge "which is not given to anyone in its totality."

Objection 2

What did Hayek mean by the man on the spot?

Hayek used "man on the spot" for the person who knows the particular circumstances of time and place relevant to a decision. He argued that "the ultimate decisions must be left to the people who are familiar with these circumstances," but that the man on the spot also needs information from beyond his own surroundings, which in an economy prices supply.

Objection 3

Why did Hayek think central planning could not use this knowledge?

Hayek argued that knowledge of particular circumstances "by its nature cannot enter into statistics and therefore cannot be conveyed to any central authority in statistical form." Summaries lump together things that differ in ways that matter for the specific decision, and circumstances change constantly, so a central authority would always be working from incomplete and outdated information.

Objection 4

How does the knowledge problem apply to product teams?

The reasons behind product decisions are spread across sales, support, engineering and leadership, and much of that knowledge is about particular customers, contracts and code. Routing every decision through one council loses that knowledge in summaries, and letting everyone decide alone leaves each person and coding agent without decisions made elsewhere.

Objection 5

How does Brief help with the knowledge problem?

Brief lets decisions be made by the people who know the circumstances, with pending decisions that name who should decide, and records each decision with its reason, including decisions it reads from Slack, Jira, Confluence and GitLab. Coding agents set up with Brief search recorded decisions before they start work and use check mode to flag conflicts in significant changes. Brief only passes on decisions a team has recorded, and much dispersed knowledge is never written down.


Previously
No. 113

Information Cascades

Five copies of a guess look like a convention. One recorded decision can undo all five.