Main idea

Support does not need the same memory as product, marketing does not slice things the way engineering does, and leadership does not work at the level of detail of the team that executes. Each of those lenses is a legitimate way of sorting the material, and merging them into a single base amounts to choosing which one wins — hence making the memory unusable for all the others.

But separation is not enough either: a product context must be able to draw on support signals, a marketing context to pull the objections salespeople run into, a training context to lean on the documentation and on the product's actual behavior, a source code context to serve as the reference for regenerating documentation. Without those passages, each team reconstitutes on its own what its neighbour already knew.

The goal is therefore neither merger nor autonomy: it is that each team contributes to a shared memory without losing its business lens. Connectability is what replaces centralization.

Why it matters

It gives a design criterion that settles a recurring discussion, the one about the single tool. The debate usually bears on who has to give up their tool; the useful question is what each memory must expose to the others, and in what form.

It also shifts the interoperability work: what has to circulate is not the raw data but what has been understood — a qualified signal, a decision, a limit.

Layer added by "AI Wiki: why I built a knowledge base maintained by an AI" (2026-05-25). A domain memory built separately becomes a building block that other work draws on without absorbing it. The industrial maintenance wiki — standards, processes, certifications — is queried while studying a product opportunity, alongside the source code, competitive intelligence and product knowledge, each staying where it belongs. What the separation makes possible reads here in the negative: there is nothing to prepare at the moment of studying the opportunity, the domain context is already structured and ready to be injected, because it was built for itself and not for that particular case.

Nuances and limits

Connectability has a price that separation does not: you need a shared vocabulary at least on what crosses over, failing which a support signal arrives in the product context without being understood.

And separating the lenses allows divergence: two contexts can carry two incompatible versions of the same fact, and nothing flags it as long as nobody brings them together.

Layer added by "The second brain is a dead end for product management" (2026-05-03). What "connectable" allows exactly remains to be settled, and the answer is not the live link. A bounded workspace — the directory dedicated to a product opportunity — does not accept a reference back to the original source, because a reference brings the whole context of the emitting domain with it: information from elsewhere is copied there and restated in the local vocabulary. Connectability is therefore settled at the boundary, by a translation made once and owned, not by a maintained link. What that requirement adds is a cost the original formulation did not carry: a copy goes stale, and the receiving context does not know it.

Open questions

• What is lost at the boundary when an element passes from one business lens to another, and what should be transmitted with it?