Build It as an Extension

A new capability is adopted fastest when it reads as an extension of something the user already knows — place it where their mental model already puts the data, and reuse the nearest proven mechanism, so it isn't "a new thing to learn."

Explanation

The source (Working Heuristics — Data, Matching, Product, Org, Tooling) gives two joined moves:

• Place capability where the user's mental model already puts the data. Put the feature where the user would already go looking, not where the architecture finds it convenient to expose. Adoption follows the existing mental map.
• Reuse the nearest proven mechanism. Lean on an interaction or pattern the user has already internalized rather than inventing a novel one. Familiar mechanics carry the new capability in on their back.

Together these make a feature read as an extension of the existing product rather than a separate thing demanding fresh learning — which is the difference between "oh, it just does that now" and "I have to go learn another tool."

Why it matters / where it shows up

• Learning cost is an adoption tax. Every new mental model or mechanism you ask for is friction; building as an extension drives that tax toward zero.
• It's the product-scale twin of Build With, Not Against. "Extension, not a new thing" recurs at two scales in this source: at the product level (extend the user's mental model) and at the org level (make the durable layer the other team's extension of their own work). Same move — fit into what exists rather than erect something rival.
• It rhymes with data gravity. Data Gravity puts compute where the data already is; this puts capability where the user's understanding already is. Both go to where the mass already sits instead of relocating it.

Open questions

• When does "reuse the nearest proven mechanism" calcify into stretching a familiar pattern past its fit, where a genuinely new mechanism would serve the user better? Answered 2026-11-09 from the wiki. The line is crossed when the extension starts changing the land to fit the lens: the data, the user's task or the source's own structure has to be reshaped so the familiar mechanism still applies (Legibility in the Lens, Not the Land). Two tests. Alexander's: is the whole's wholeness increasing in the presence of this step, or only the builder's convenience (Living Structure)? Rao's: some cowpaths should deliberately not be paved (Legibility). Worked example (2026-11-08): the front door adopted a graph data model that matched one already in use (the agent's graph.json) but deferred the graph database the source recommended, because the database would have added a mechanism whose absence nobody felt (Navigation vs Search). Extension up to the model, new mechanism refused past it.

Connections

• Build With, Not Against — the org-scale version of the same "extension, not land-grab" move.
• Data Gravity — both place the new thing where the existing mass (data / mental model) already is.
• Choose the Platform by the Hardest Recurring Part — both resist optimizing for the quickest/newest build over what fits the durable reality.

Sources

• Working Heuristics — Data, Matching, Product, Org, Tooling — "place capability where the user's mental model already puts the data, and reuse the nearest proven mechanism."