Most capability maps are built once, admired briefly, and abandoned. The ones that survive share a few plain traits — and almost none of them involve being complete.

The capability map is the most reused artifact in business architecture and the most often abandoned. A team spends a quarter building a beautiful three-level model, presents it to applause, and watches it gather dust. Six months later someone asks for "the capability map" and three versions surface in three decks, none of them current. The failure is rarely the modeling. It is that the map was built to be complete instead of being used.

A map that gets used looks different from a map that gets praised. It is smaller, blunter, and more opinionated. Here is what the durable ones have in common.

Start from what the business does, not who does it

The first decision is the one most teams get wrong: they draw the map from the org chart. Sales, Marketing, Operations, IT — each department becomes a box, each box gets sub-boxes, and the result looks like a capability map while behaving like an org chart. The moment the company reorganizes, the map is wrong. A capability describes what the business does — onboard a customer, price a product, settle a payment — independent of which team owns it today. The test is simple: if you renamed every department tomorrow, not one capability name should have to change. If they would, you have drawn the org chart again.

Two levels first, three at the very most

The instinct to decompose is the second trap. Teams push to level four and five because deeper feels more rigorous. It is mostly more fragile. Start with roughly seven to fifteen level-one capabilities that describe the whole business, then decompose one or two levels where it earns its keep. A map a leadership team can take in on one screen will be opened again. A 400-box model that took two quarters to build will be opened once, by its authors, at the launch meeting. Completeness is the enemy of adoption.

Name them as stable nouns

Naming is where maps quietly rot. A capability is a noun phrase — "Customer Onboarding," "Claims Adjudication," "Demand Planning" — not a verb, not a project, and never a system. The day "Salesforce" or "the CRM migration" appears as a capability, the map has started tracking tools and initiatives, both of which change far faster than what the business fundamentally does. Names should read the same after the next re-platforming as they did before it.

Stable at the top, moving at the edges

The top two levels should be boring on purpose. Anchor them to an industry reference model where one exists, so you are not inventing the obvious from scratch and you can compare yourself to peers. Let the lower levels evolve as the business learns. A good map has a calm, stable trunk and branches that you expect to prune and regrow. When the trunk keeps changing, no one trusts the map enough to plan against it.

Test it against a real decision

The only validation that matters is use. Take a live decision the business is actually wrestling with — a funding choice, a reorg, an audit finding, a build-versus-buy — and try to answer it on the map. Can you shade the map by something a leader cares about: maturity, investment, risk, customer impact? If you can, you have a tool. If all you can do is point at boxes, you have a diagram. The difference shows up the first time someone disagrees with what the colors say — that argument is the map doing its job.

Give it an owner and a heartbeat

Every abandoned map has the same cause of death: no owner and no cadence. A living map has one named owner, lives in one place rather than scattered across slide decks, and is reviewed on the same rhythm as planning and funding. Tie it to a moment that already happens — the quarterly review, the annual budget — and it stays current because the business needs it current. Leave it floating and it is two reorgs out of date before anyone notices.

The two-week version

If a quarter-long modeling effort sounds like exactly the kind of thing you do not have time for, good — that instinct is correct, and it is rather the point. The map worth building is the one you can stand up in a week or two: a workshop to agree the level-one capabilities, a second pass to decompose the handful that a current decision actually touches, and one shared place to keep it. That is enough to find a duplicate, expose an unfunded priority, or settle a build-versus-buy. Everything past that is investment you make only when a real decision asks for it. The teams that succeed treat the map as something they grow on demand, not a monument they unveil once and never reopen.

A worked example: the map that found the duplicate

A mid-size insurer built a level-two capability map after years of running on the org chart. It took three weeks, not three quarters, because they capped it at two levels and refused to go deeper. The payoff arrived in the first review. Two divisions — personal lines and commercial lines — each had a separately funded programme to build "customer document management." On the org chart the two were invisible to each other: different VPs, different budgets, different steering committees, no shared reporting line. On the capability map they landed on exactly the same box. The map did not resolve the politics of merging the two efforts, but it made the duplication impossible to un-see — and being impossible to un-see is the first useful thing any map does.

Notice what made that work, because it is everything above in miniature. The map was small enough to read in one sitting, named by capability rather than by team, and opened during a funding review rather than filed after a launch. Remove any one of those traits and the duplicate stays hidden in plain sight. The value was never in the modeling effort; it was in the modest, used artifact those choices produced.

The completeness trap, stated plainly

It is worth naming the deepest reason maps fail, because it runs against every modeling instinct: a map's usefulness peaks well before its completeness does. The first twenty capabilities you draw carry most of the decision-making value, because they are the ones leaders actually argue about. Capabilities one hundred through four hundred add precision almost no real decision requires, at a maintenance cost that all but guarantees the map drifts out of date. A complete map is not a more useful map; it is a more expensive one that goes wrong sooner. Build to the decisions in front of you and leave the rest deliberately blank — a blank you can always fill the day a decision genuinely needs it.

None of this is difficult. It is just disciplined, and discipline is less fun than detail. But the map that survives contact with the org is the modest one: a stable trunk, a few honest levels, real names, an owner, and a reason to be opened. If you want a head start, the starter template below is the skeleton — the rest is the unglamorous part only you can do.

A capability map is not a deliverable. It’s a conversation starter. Its value is not in the artifact — it’s in what the artifact provokes when you put it in front of the right people.

The failure mode is producing a 200-tile capability map, sending it around for “review,” collecting polite nods, and filing it. Six months later, no one references it. The map exists. Nothing changed.

The success mode is producing a deliberately incomplete map, showing it to a business leader, and asking: “What’s missing? What’s misnamed? Which of these is actually two capabilities pretending to be one?” The conversation reveals more than the map ever could.

The map is the excuse. The conversation is the product.

A business capability is the ability to do something the organization needs to do — "manage customer onboarding," "underwrite a policy," "fulfil an order." It names an ability, not an activity, a team, or a tool. Phrased as a noun, it answers "what must we be able to do?" rather than "how, or who does it?"

That distinction is what makes capabilities useful for planning. A process can be re-engineered and a department can be dissolved, but the capability to onboard a customer persists as long as the company has customers. Because it holds still, it is something you can rate for maturity, fund over time, and trace strategy to — none of which you can reliably do against a moving org chart.

A capability is not a function (a grouping of related work, often org-aligned) and not a process (an ordered set of steps that produces an outcome). Functions and processes describe how work is organized and performed; a capability describes the underlying ability they deliver. Keep the three separate and each becomes useful; blur them and the map becomes an org chart with extra steps.

A model so large and so vast,
Could predict any moment, past or last.
But it cost the whole farm,
Set the budget alarm —
Now it sits in a folder, downcast.