Method · Delivery & Validation
Capability Mapping
Laying the capabilities a delivery requires against the capabilities you actually have, layer by layer, so the gaps that will stop you shipping are visible before they stop you.
Every plan assumes the organisation can execute it. This is the method that checks. The gap is the finding, and a gap at the foundation is quietly holding up everything above it.
The signature visual
The layered capability map
Capabilities arranged in layers (foundational at the base, EPIC-level at the top) with dependencies flowing upward: the top visibly rests on the bottom. Each capability scored in one of three states: HAVE IT, PARTIAL, or GAP. The glowing absence at PIPELINE RELIABILITY is carrying everything above it.
What it is
A diagnostic, not a training programme
Capability mapping lays the capabilities a delivery REQUIRES against the capabilities the organisation ACTUALLY HAS, and makes the difference between them visible. Those differences are the delivery gaps: the specific missing skills, processes, assets, and ways of working that will stop you shipping the thing you have decided to do. The map is a diagnostic, and the gap is the finding.
It matters because every other method in this group quietly assumes the organisation can execute. A roadmap sequences work on the assumption the work can be done. A pilot tests whether the solution holds up, taking for granted that there is an operation to hold it up. A feedback loop assumes that when a decision is made, someone can actually ship the change. Capability mapping is the method that asks whether any of that is true, and it is the only one that will tell you, early and in the open, that the plan you have written requires an organisation you do not have.
The structure of the map is what makes it useful. Capabilities are emphatically not a flat list. They are LAYERED: foundational capabilities at the base (the underlying data, infrastructure, skills, processes, and habits everything else depends on) rising to EPIC-level capabilities at the top (the big, visible, ambitious things the strategy actually promises). Dependencies flow upward: the top rests on the bottom. They are also SEGMENTED, cut across those layers by whatever divisions are real in your organisation. And the map holds two states at once: what exists TODAY, and the GAPS to be addressed.
From that structure comes the method’s sharpest teaching: you cannot build an EPIC-level capability on a foundational gap. Organisations do this constantly. They staff the exciting top-layer capability, the one the strategy is named after, and cannot understand why it never quite lands, because the foundational capability it silently depends on was never there, and nobody mapped the dependency. A gap at the top is visible and embarrassing. A gap at the bottom is invisible and fatal, and it is holding up everything above it.
Explore the map
Toggle today against target. Find the hole, and see what stands on it.
Toggle between TARGET (what delivery requires) and TODAY (what you actually have). The gaps are what appear in the difference. Click any capability to see its state and what depends on it. Click a foundational gap and watch the instability propagate upward through everything resting on it, including the EPIC-level capability the strategy is named after.
When to deploy
When you need to check whether the plan is deliverable
The right moment
- You have a plan or a roadmap and need an honest answer to whether this organisation can actually execute it
- An ambitious EPIC-level initiative keeps failing to land, and nobody can say why
- A pilot or rollout has exposed operational strain, and you need to know whether the constraint is local or structural
- You are about to commit to a delivery whose requirements you have never checked against your actual capacity
Not yet ready when
- The strategy itself is not settled: mapping capabilities against a direction nobody has committed to produces a map of nothing in particular
- The organisation is not willing to hear the answer: a map produced for an audience that has decided it is ready will be softened until it agrees
- You would treat it as a scoring exercise: the point is finding the gaps that will stop delivery, especially the foundational ones
The honest limit
A capability map tells you where the gaps ARE; it does not close them. Closing a gap (building, hiring, partnering, or buying the capability) is a programme of work that plays out over months. The map’s most sobering property is that it exposes just how slow capability is to change. You can rewrite a strategy in a meeting and a roadmap in an afternoon; you cannot change what your people can actually do in under a year.
How it works
Six disciplines
Derive the required capabilities from the actual delivery
Start from what you have committed to ship, and work backwards to what the organisation must genuinely be able to DO in order to ship it. Be concrete: a capability is a thing you can do repeatedly and reliably, not an aspiration. "Data-driven" is not a capability. "Serve a real-time personalised recommendation in under 200ms" is.
Structure them in layers, foundational to EPIC
Sort the capabilities into a stack: foundational at the base (data, infrastructure, core skills, processes, ways of working), rising to the EPIC-level capabilities the strategy actually promises. Then make the DEPENDENCIES explicit: what does each upper capability rest on? This is the step that most flat capability lists skip, and it is where the method’s value comes from.
Segment across the layers
Cut the map by the divisions that are real in your organisation (front-end and back-end most commonly, but whatever cuts reflect actual operational reality). This reveals that gaps cluster: an organisation can be strong down one column and hollow down another, and a flat list would never show that.
Assess today honestly: HAVE IT, PARTIAL, or GAP
Score each capability against reality, not intention. Be especially rigorous about PARTIAL: a capability that half-exists is routinely recorded as present, and it is more dangerous than an outright gap precisely because everyone assumes it is there. The check is not “could we do this?” but “what actually happens when we try?”
Toggle to target, and let the gaps appear
Lay the required state against today’s state. The difference IS the delivery gap, and seeing it whole (all at once, in a structure that shows what depends on what) is what the exercise is for. A flat list of gaps is still a list. A layered map of gaps is a diagnostic.
Find the foundational gaps first, and sequence from the bottom
Look underneath. A gap at the base is carrying everything above it, and it must be closed before anything that depends on it can be built, however unglamorous that is. Closing gaps from the top down is how organisations spend a year staffing an EPIC-level capability that never had a floor. Hand each gap to the roadmap as work: BUILD (slowest, deepest), HIRE (faster, needs somewhere to land), PARTNER (fastest, does not accrue), or BUY (expensive, integration risk).
Best practices
What good looks like, and the mistakes
When it goes well
- Required capabilities are derived from the actual delivery, concretely, not listed as aspirations
- The map is layered with explicit upward dependencies, so a foundational gap is visibly carrying what sits on it
- Today's state is assessed honestly, PARTIAL especially, which is the state most often mis-recorded as present
- Foundational gaps are found and sequenced first, however unglamorous the work to close them is
- Gaps are handed to the roadmap as real work (build, hire, partner, buy) with honest timelines, not absorbed as scheduling optimism
- The people doing the actual work assess the state, not the leadership deck
The mistakes
- ⚠Mapping capabilities as a flat list: without layers and dependencies, every gap looks equally important, and the foundational one disappears into the middle of a spreadsheet
- ⚠Building top-down: staffing the exciting EPIC-level capability while the foundation it depends on is missing. It will not land, and the organisation will conclude the people were wrong when the floor was
- ⚠Scoring PARTIAL as present: a half-capability recorded as a tick, and everyone proceeds as though it is there. Partial is more dangerous than absent
- ⚠Assessing intention instead of reality: capability is what you can do repeatedly and reliably, not what you could do if the right person had time
- ⚠Softening the map for its audience: a capability map exists to say uncomfortable things. One negotiated into agreement has been made worse than useless
- ⚠Treating a gap as a scheduling problem: "we will figure it out" is how a gap becomes a mid-rollout crisis
Logistics
What running this requires
Time required
1–2 facilitated sessions to build the initial map; revisited when delivery plans or team capabilities change
Who to involve
Practitioners who actually do the work, not just leadership. Real capability is known to the people doing it, not the people describing it upward
Format
Works remotely and in person; the map should be a shared, visible artefact: a living document, not a slide filed away after the session
State to be rigorous about
PARTIAL. Create the middle category and use it honestly. The instinct to round PARTIAL up to HAVE IT is what puts a hole under an EPIC-level bet
Output
Layered, segmented map with today's states and the target states; gap list with closure route (build / hire / partner / buy) and honest timeline for each
What to attach to
Gaps go straight onto the delivery roadmap as work items, not absorbed as scheduling assumptions, not filed as "things to address later"
AI-reactivated
AI genuinely closes some capability gaps. It also produces a convincing imitation of the ones it has not closed.
The distinguishing test (can we judge this work?) is what separates a capability you have from an output you can merely obtain. A gap that looks closed on the surface but has no human judgment underneath it is the most dangerous cell on the map: solid on the surface, hollow underneath, and most devastating at the foundational layer where it silently carries everything above it.
Worked example
Eighteen months and no answer
A company committed to real-time personalised recommendations, the centrepiece of the strategy. Two teams, eighteen months, and it had not landed. Nobody could say why. The map produced the answer in one session. The two approaches below differ in method, not in scenario.
Shared scenario
A company has committed to an ambitious EPIC-level capability: delivering personalised, real-time recommendations to its customers. It is the centrepiece of the strategy. Two teams have been staffed against it, and eighteen months in, it has not landed. Nobody can say why. Before spending another year, they map the capabilities. Both versions map the same organisation; only the method differs.
Both versions map the same organisation. Only the method differs.
Map as a layered stack, not a list
The team built the map as a layered stack rather than a list, and that structural decision was what produced the answer. At the top sat the EPIC-level capability the strategy was named after: real-time personalisation. It was staffed, funded, and visible. Below it, the map made the dependencies explicit: personalisation rested on a capability to serve and act on customer data in real time, which rested in turn on foundational capabilities in data quality, pipeline reliability, and engineering practices for operating live systems.
The practitioners, not the leadership deck
Assessed honestly (and this required asking the practitioners rather than reading the leadership deck) the foundational layer had a hole in it. Data quality was not a gap exactly; it was PARTIAL, which was worse, because for two years it had been recorded as present. The data was good enough for reporting, which was what everyone had checked, and nowhere near good enough to drive a real-time decision, which nobody had checked. Pipeline reliability underneath it was a genuine gap: held together by one engineer’s undocumented knowledge, unavailable when that person was away.
The moment the dependencies were drawn
The moment the map was drawn with dependencies, the eighteen-month mystery evaporated. The EPIC-level capability had never failed for lack of talent or funding; it had been standing on a foundational gap the whole time, and no amount of staffing the top could compensate for a missing floor. The two teams had been asked to build a house on a hole.
Resequence from the bottom
They resequenced from the bottom: closed the foundational data-quality and pipeline-reliability gaps first (unglamorous, and the only thing that could possibly work) and put those gaps on the delivery roadmap as real work with honest timelines, rather than absorbing them as scheduling optimism. The EPIC-level capability landed the following year, on a floor that existed. The map did not build anything. It simply made it impossible to keep failing for a reason nobody could name.
What this taught
A flat capability list would never have found the foundational gap, because every item would have looked equally important. The layers and the dependencies are what made the foundational hole visible, and visible before another year was spent building on it.
Framework connections
Where this sits in the larger frameworks
Double Diamond
Checking, before committing to the Deliver phase, whether the organisation can actually build and run the solution it has designed. Capability mapping belongs here: before build, not during it.
Agile Innovation
Sequencing work against the capability that genuinely exists, not the capability the plan assumes. Agile planning without a capability map is velocity against an unknown floor.
Front-End of Innovation
Organisational feasibility, distinct from technical feasibility: not just whether the technology can work, but whether this organisation can build, run, and sustain it. These are independent questions with independent answers.
Lean Startup
Whether this organisation can actually build and operate what it intends to test. The Build phase assumes a build capability that may not exist at the required layer or scale.
Related methods
The methods that connect here
Capability mapping sits underneath the other Delivery & Validation methods: it asks the question they all assume is already answered. Its closest partner is the Delivery Roadmap, where every gap it finds becomes a piece of real work.
The closest relationship. The roadmap sequences work on the assumption the work can be done; the capability map checks whether that is true. A capability gap is not a scheduling problem to absorb. It goes on the roadmap as an item in its own right (build, hire, partner, or buy) with an honest timeline.
The pilot exposes capability gaps too, but late and expensively: a pilot routinely reveals that the operation cannot absorb real volume. Capability mapping surfaces the same constraint early, on purpose, before you have put it in front of customers.
A useful pairing: a PoC proves the THING can work; a capability map asks whether the ORGANISATION can build, run, and sustain it. Both can be true, and both can be false, independently.
A loop that dies at SHIP is often a capability problem, not a decision problem: the organisation decided, and simply could not execute. The map tells you which.
A shared blind spot worth naming: like the real flow of a process, an organisation’s real capability is tacit and undocumented. Both methods find the truth by asking and watching the people who do the work, not by reading what is written down.
Sources and further reading
What this draws on
Competing for the Future: Gary Hamel and C.K. Prahalad (1994)
The foundational work on core competencies and building the capabilities a strategy requires. The argument that capability is the real constraint on strategy, and that competing for the future means competing to build the capabilities that the future will require.
The Innovator’s Dilemma: Clayton Christensen (1997)
On why capable organisations fail at new things, and how capability itself becomes the constraint. The resources, processes, and values framework maps closely to the foundational-to-EPIC layering: what an organisation can do is determined by its processes (foundational), not just its resources.
Accelerate: Nicole Forsgren, Jez Humble, and Gene Kim (2018)
On the foundational engineering and organisational capabilities that actually predict delivery performance. One of the few empirical works on what capabilities belong at the foundational layer and which ones actually determine whether the EPIC-level ambitions land.