Capability

Skelton and Pais connect this stability to org design. Their primary unit is the value stream🌊Value StreamStrategyAn end-to-end flow delivering value to the customerView reference →, and business capability is one of the candidate criteria they use — via the Independent Service Heuristics — to find where a stream-aligned team's boundary should fall, precisely because a capability is a coherent thing the business can do independently of any one system. The book's four team types divide the labour around those streams: stream-aligned teams own end-to-end delivery, platform teams offer self-service infrastructure as an internal product, complicated-subsystem teams absorb deep specialism, and enabling teams help stream-aligned teams build capabilities they lack. Read against this entity's own distinction — the stream is the verb, the capability the noun it consumes — a capability map is not itself a Team Topologies artefact, but a stable capability lattice is the kind of input their boundary-finding heuristics are designed to act on.

Origin & evolution

Capability-based thinking grew out of the enterprise and business architecture communities through the 2000s, where teams needed a way to plan investment that did not break every time the org chart or tech stack changed. The clearest early articulation came from Ulrich Homann at Microsoft in his February 2006 paper A Business-Oriented Foundation for Service Orientation. He defined a business capability as "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose," and stressed that it describes what a business does without explaining how, why, or where.

The idea was formalised by the Business Architecture Guild in its BIZBOK Guide, where the business capability map became the discipline's central artefact: a stable, layered picture of everything an organisation can do, used as a shared reference for strategy, technology, and operating-model decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. Practitioners began calling it the "Rosetta Stone" of business and IT alignment, because a capability name means the same thing to a strategist and an engineer.

A second lineage runs through Simon Wardley's mapping work, which placed capabilities on an evolution axis from genesis to custom-built to product to commodity, and on a visibility axis from invisible infrastructure to user-facing anchor. Wardley's contribution was to argue that the same capability should be managed differently depending on how evolved it is. A genesis capability deserves exploration; a commodity capability deserves outsourcing. The contemporary view holds both: a capability is a stable noun for what you can do, and its maturity and evolution are properties you track over time.

How it works in practice

A logistics startup maps its capabilities before its next funding round. One leaf reads "real-time shipment tracking," rated at maturity developing with a target of managed, and placed at visibility 0.8 because customers see it directly. Beneath it sits "geospatial event ingestion" at visibility 0.2, the infrastructure no customer names but everything depends on.

The map changes the investment conversation. A competitor🥊CompetitorMarket IntelligenceA competing product or companyView reference → analysis shows three rivals already offer tracking as a commodity, so the team stops trying to differentiate there and instead invests in a genesis-stage capability, predictive delay alerts, where no competitor has anything. The capability frame let them separate "what we do" from "how well the market already does it," and route money to the genesis edge instead of polishing a commodity.

Capability vs. its neighbours

• Feature: a feature is a specific, shippable piece of product that users interact with. A capability is the underlying ability a feature expresses. One capability can be implemented by several features, and a capability can exist with no feature yet built for it.
• Value stream: a value stream is the end-to-end flow that delivers value to a customer. A capability is a building block that the flow draws on. The stream is the verb; the capability is the noun it consumes.
• Strategic theme🧵Strategic ThemeStrategyA high-level strategic focus area for a planning period. Its own time_horizon is now deprecated: promote the period to a planning_cycle and link the two with strategic_theme_scoped_to_planning_cycle, so themes share one dated, nestable interval instead of a drifting per-theme label.View reference →: a theme is a direction the business chooses to invest behind. A capability is something the business can do. A theme requires capabilities; it does not contain them.

In the graph

In the Unified Product Graph, capability💪CapabilityStrategyAn ability that enables value delivery is a leaf in the Strategy & Outcomes🏆OutcomeStrategyA desired business or user outcomeView reference → region, carrying Wardley properties (evolution_stage, visibility) alongside a maturity model (maturity_level, target_maturity, gap). It is enabled from above by strategic_pillar_enables_capabilityStrategic PillarenablesCapabilityhierarchy and required by strategic_theme_requires_capabilityStrategic ThemerequiresCapabilitycausal, and it reaches down through capability_implemented_by_featureCapabilityimplemented byFeaturehierarchy into the delivery region and capability_enables_value_streamCapabilityenablesValue Streamcross-domain into flow. capability_depends_on_capabilityCapabilitydepends onCapabilityhierarchy makes the dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → lattice explicit, which is what turns a flat list into a map: you can query which commodity capabilities a genesis bet quietly rests on, the question Wardley's axis was built to answer.