Main idea

A role is often defended by the domain expertise it supposedly holds: the Product Owner is said to know the field, and to act as the interface on that basis. Observation contradicts the attribution. That expertise is found in Customer Success Managers who came from the field, in support people who hear the same situations every day, in a long-standing developer on the team.

It is also acquired, and the work is identifiable: in industrial maintenance, devouring books and videos on the domain is the condition for having anything to arbitrate. A Product Manager who doesn't do that work has no view worth carrying.

A role therefore isn't justified by holding knowledge that others can acquire, and that part of the team already has.

Why it matters

This removes a frequent argument from authority in organizational discussions, and replaces it with a verifiable question: who, on the team, actually knows the domain, and how did they learn it?

And it turns domain expertise into a training objective for several people, rather than a justification for a single point of passage.

Nuances and limits

Some expertise isn't acquired by reading: practising a regulated trade, the experience of a workshop, years spent operating a piece of equipment give an understanding that study doesn't replace.

And expertise shared by everyone can be held by nobody: spreading it doesn't remove the need to name who must keep it up to date.

Layer added by "AI Wiki: why I built a knowledge base maintained by an AI" (2026-05-25). Having a machine structure the domain doesn't shorten the acquisition, and even closes a door you thought was open. A base of 950 notes drawn from standards and industrial maintenance books gives nobody the competence to judge what it contains: whoever isn't at the level to validate what the machine extracted is building on sand, and a well-formed output won't flag it. The tool structures and capitalizes knowledge acquired elsewhere; it doesn't replace the work of devouring the books, it makes it the prerequisite.

Open questions

• How does a product team check its real level of domain knowledge, other than by noticing a mistaken arbitration after the fact?