Core Differentiation
"Core" does not mean important; payment is essential and nobody chooses a store for it. Core means the reason a customer picks you — and that is the one thing you cannot buy, because a provider that solves it solves it for your competitors too.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Everyone agrees the "core" of the system should be built in-house. How do you find out what the core actually is, and why is the answer so often not what the engineers think?
The team is arguing about search. One engineer wants to build it — "search is core to a store". The founder is in the meeting, slightly puzzled, because as far as they are concerned the store is about a curated catalog and fast delivery, and search is a box at the top of the page.
Call the parts that are technically central "core". The cart, checkout, search, the product model — they are in the middle of the architecture, everything touches them, and building them yourself feels like owning the business. It is a natural reading of the word, and it comes from the engineer's view of the system rather than the customer's.
Architecturally central and commercially differentiating are different properties, and the reflex conflates them. Checkout is central to every store and differentiates none of them; a team that builds "the core" by the architectural definition builds what every competitor already has.
- Architecturally central and commercially differentiating are different properties, and the reflex conflates them. Checkout is central to every store and differentiates none of them; a team that builds "the core" by the architectural definition builds what every competitor already has.
- The differentiation — the curated catalog, the delivery promise, the part-finder — is often not a component at all, so it never appears in the build-vs-buy conversation. It is in the data, the ranking, the editorial process, or the operations, and the engineers are busy owning the cart.
- Effort flows to the wrong place. A month on a hand-built search that is slightly worse than a rented one, while the ranking logic that would make search *the* reason to use this store is a to-do.
- The word "core" ends arguments instead of starting them. Once something is called core, buying it sounds like betrayal, and the five questions are never asked of it.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Define core as *differentiation*: the capability a customer would name if asked why they use this store rather than another. Then ask the founder that question, cold, and listen for nouns. The nouns are the core; anything not named is a candidate for buying or for a plain implementation.
- Separate three things the reflex merges: *essential* (the store cannot function without it — payment, cart), *central* (the architecture routes through it — the product model), and *differentiating* (a customer chooses you for it). Only the third is core. Essential-but-not-differentiating capabilities are the strongest buy candidates precisely because they must work and someone has already made them work.
- Then look at where the differentiation actually lives. It is often a *layer* — the ranking on top of a search index, the curation on top of a catalog, the evaluation on top of a model — rather than a component. That layer is built; the thing under it can be bought (Abstraction Levels).
- Write the answer down where the build-vs-buy decisions will be made, so that "is it core?" is answered by the list and not by whoever is most attached to the component (What Must Be True?).
Essential, central, differentiating
The reflex has one word; the move has three. The decomposition below is the store's capabilities sorted into them, and each leaf says how you would know it was placed correctly — because "is this core?" is a claim about customers, and a claim about customers can be checked.
- ├Differentiating— a customer would name it
- └Part-finder: fitment data and the ranking over ittestable Customers asked why they use the store name it; a competitor without it loses the comparison.
- └Next-day delivery promisetestable Lives in operations and the stock model, not in a component; removing it changes the pitch.
- ├Essential, not differentiating— the store cannot function without it, and no customer chooses it for this
- └Paymenttestable Asked cold, the founder does not name it; a competitor with an identical card form is not thereby worse.
- └Cart and checkouttestable Same test; the founder's answer does not mention them.
- └Email, accountstestable Same test; providers exist that solve the whole requirement.
- ├Central, not differentiating— the architecture routes through it
- └Product modeltestable Everything depends on it and no customer sees it; built plainly, because there is nothing to buy.
- └Search retrievaltestable The index under the part-finder; a rented one with the same ranking on top produces the same results.
Two leaves under differentiating, seven elsewhere. That ratio is typical, and it is the reverse of where the engineering effort was going.
Where the differentiation lives
The reflex sees "search" as one box. The diagram splits it into the layer that differentiates and the layer that does not, and the build-vs-buy line runs between them. The part-finder is built; the index beneath it is rented; the product model beneath that is built plainly because there is nothing to buy.
The same question, three ways
The ladder is the differentiation question asked badly, better and well. Only the best form produces a list an engineer can locate in the system.
why The vague form is answered by engineers with the architecture. The better form is answered with adjectives. The best form is answered with a noun the customer would say and a layer the engineer can point at — which is a build decision.
Cart, checkout, product model, search — build them all, because everything depends on them.
The part-finder ranking and the fitment data — build them well; rent the index; build the cart plainly or from a library; buy payment.
Effort spent on central-not-differentiating components produces what every competitor has. Effort on the differentiating layer produces the reason the store exists — and it is usually the harder engineering anyway.
How to do it
Most important first.
- Ask the founder, or read the pitch: "why would someone use this and not the alternative?" Write the answer as capabilities, not adjectives — "finds the right part for your car" rather than "great user experience".
- For each capability in the decomposition, mark it essential, central, differentiating, or none. Expect most to be essential or central and very few differentiating; if everything is differentiating, the pitch has not been understood (Decomposition by Capability).
- For each differentiating capability, ask where it lives: which layer, which data, which decision. That is what to build well; the layers beneath it are candidates for buying (Highest Useful Level First).
- Re-ask when the pitch changes. Differentiation moves; a store that started as "curated" and became "fastest delivery" has a different core, and a different build list.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store: the founder, asked cold, says "we know which part fits which car, and we deliver next day". Differentiating: the fitment data and the part-finder over it; the delivery promise, which lives in operations and a stock model. Essential but not differentiating: payment, cart, checkout, email, accounts. Central but not differentiating: the product model. The engineer's "search is core" was half right — retrieval is bought, the fitment ranking on top of it is the most important thing the team builds.
- The chat app, same move: the pitch is "conversations that stay organised". Differentiating: threading and read state that behave well across devices. Essential: message delivery, realtime transport, authentication — all shapes with mature providers or libraries. The team that spends its first month on a custom websocket layer has built what every chat app has and nothing of what this one is for.
- The AI assistant over company documentation: the model is essential and nobody's differentiation. The retrieval is central. The differentiation is whether answers are correct *for this company's documents* — which is evaluation and retrieval quality, built, with a bought model underneath.
- A counter-case: a payments company. Payment is essential, central and differentiating at once, and the five questions invert — the card flow is built, and the store-like parts around it (the merchant dashboard) are the buy candidates. Same questions, opposite answer, because the pitch is different.
How you know it worked
What now exists that did not before, and what question you can now ask.
- There is a short list of differentiating capabilities, in the founder's words, and it is much shorter than the list of essential ones.
- For each differentiating capability there is a named layer where it lives, and the layers beneath it have a buy-or-plain decision recorded.
- The word "core" has stopped ending arguments; when someone says it, the response is "differentiating, or central?"
- Engineering effort has moved toward the differentiating layer and away from rebuilding what every competitor has.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Why would a customer use this and not the alternative — in the words of whoever owns the product?
- ?Is this capability essential, central, or differentiating — and which of those am I confusing?
- ?Where does the differentiation actually live: which layer, which data, which decision?
- ?What sits underneath that layer, and could it be bought without touching what makes us different?
- ?Has the pitch changed since this list was written?
What can go wrong
- Differentiation is defined so narrowly that nothing engineers do is core, and the team becomes an integration shop with no leverage. The differentiating layer is usually the hardest engineering in the system; the move directs effort to it, not away from engineering.
- It is defined so broadly that everything is core again — "our whole experience is the differentiation" — and the reflex returns with a new vocabulary.
- The founder's answer is taken as permanent. Differentiation moves as the market does; the list needs re-asking, and a build decision made for a pitch that no longer holds is a cost with no owner.
- The move is applied by engineers alone. Differentiation is a product fact, and a room without the product owner in it will find the architecturally central components again and call them core.
- Telling an engineer that their favourite component is essential-not-core is a real conversation with a real cost, and it is the conversation the reflex exists to avoid.
- Buying the essentials concentrates the team's expertise in one layer. If the differentiation moves to a layer nobody has built, the team has to learn it late.
- A short differentiation list can be read as "the rest does not matter". The rest must *work*; it just does not have to be built here.
- "So build only the differentiation and buy everything else." Buy everything else *where a provider solves the whole requirement and the failure mode is acceptable*. Some essentials have no adequate provider, and those are built even though they are not core.
- "Core is what the founder says it is." The founder says what the *pitch* is; the engineer works out where in the system that pitch lives. Both halves are needed. "The customer decides what is core" is falsifiable: made precise, it says differentiation is what customers would name, and it takes engineering to locate that in a layer.
- "This is about pride." It is about leverage. A month on a hand-built cart and a month on the fitment ranking cost the same and buy very different things.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALEssential, central and differentiating are distinct for any product-shaped system, and the differentiation is usually a layer rather than a component; for an internal tool the "customer" is the team that would otherwise use a spreadsheet, and the question still has an answer.
- DOMAIN-SPECIFICFor a store, payment and cart are essential and never differentiating; for a payments company the card flow is the differentiation and the merchant dashboard is the buy candidate. The categories are fixed; which capability lands in which is decided by the pitch.
- ILLUSTRATIVEThe car-parts store, the founder's answer, the month on search and the chat app's pitch are invented to show the three categories separating; no real company is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "What Are You Delegating?" cards at /manifesto/delegating are the same question one level down: what a bought thing does for you, and what stays yours.