A capability is an organizational ability to perform a business function or produce an outcome. It provides a useful starting point for deciding where teams should focus, which work needs custom technology, and where boundaries might sit. A capability is not automatically a product: a product is a complete offering that provides customer value, while features and components may contribute to that offering without doing so independently. section 16.1.2 section 6.4.1
Map the ability, then test the boundaries
At a European telco, customer self-fulfillment of an internet broadband package was identified as a capability within product fulfilment. Its operational value stream ran from placing an order through preparing, shipping, and delivering equipment to self-installation and activation. Those steps suggested initial team and software boundaries, but business logic alone was not enough: the proposed structure was also checked against team relationships and problematic dependencies. section 15.2
To use capabilities in modernization:
- Map capabilities alongside events and value streams to start conversations about candidate domains and boundaries; treat the maps as working aids, not final answers. section 15.2
- Distinguish generic and supporting capabilities from core domains. Consider buying, using managed services, or outsourcing the former so teams can concentrate on what is distinctive. section 16.1.2
- Check ownership and dependencies before centralizing a widely used capability. Shared platform ownership warrants an explicit review rather than following automatically from reuse. section 16.3.5
The term also applies to what an internal developer platform provides. In that setting, ask both which capabilities developers need and how they should access them—for example, through a UI, YAML, CLI, or GitOps-based experience. This is a platform-design question, distinct from mapping the business abilities that shape domains and investment. section 13.2
