A business capability map shows what an organization must be able to do to deliver its strategy. It describes stable abilities such as subscription billing or customer support, rather than listing today's projects or drawing the reporting structure. A useful map connects each capability to an outcome, an owner, evidence, and a clearly stated improvement gap.
For the broader strategic context, use strategic analysis on a shared whiteboard and keep the capability map as the concrete view of what the organization can reliably deliver.
Capability, process, project, and department are different
| Term | What it describes | Example |
|---|---|---|
| Capability | A relatively stable ability the organization can perform. | Recover a failed subscription payment. |
| Process | A sequence used to perform work. | Detect a failed payment, notify the account, and retry. |
| Project | A time-bounded change effort. | Replace the payment-retry service this quarter. |
| Department | A group with a reporting or operating relationship. | Revenue operations. |
| Outcome | The result the strategy is trying to achieve. | More customers retain a working subscription. |
These terms can be connected, but they should not be collapsed into one card. A department can own several capabilities, and a project can improve one part of a capability without becoming the capability itself.
A worked SaaS capability map
Consider a SaaS organization that wants to reduce avoidable subscription interruptions. Its map starts with the outcome “customers keep an active subscription when a payment fails,” then groups the supporting capabilities below it.
Build the hierarchy before adding owners or ratings. In this example, Subscription management is the level-1 capability. Its level-2 capabilities are plan and entitlement management, invoice management, payment recovery, and billing reporting. Within payment recovery, level 3 can distinguish failed-payment detection, retry scheduling, and customer notification. Put the subscription-continuity outcome outside this hierarchy and link it to the relevant capabilities.
SAP’s capability-modeling guidance distinguishes a capability hierarchy from an organization chart or a sequence of process steps. Owners and current gaps are annotations on the map, not substitutes for that hierarchy.
| Capability | Owner | Evidence to review | Current boundary | Improvement question |
|---|---|---|---|---|
| Plan and entitlement setup | Product operations | Plan rules and support cases | New plans require a manual review | Which rule needs a clearer approval path? |
| Invoice generation | Billing engineering | Invoice samples and failure logs | Regional tax cases are handled separately | Where does an invoice need an explicit exception state? |
| Payment recovery | Revenue operations | Recovery journey and contact reasons | Retry timing is not consistent across plans | Which retry policy should be tested first? |
| Billing reporting | Finance systems | Reconciliation report and open issues | One report combines settled and pending payments | What distinction does the decision maker need? |
Assess a capability against a defined criterion. For payment recovery, compare how consistently retry rules are applied across plans. Mark a capability as “not assessed” when evidence is missing; that is different from finding that its performance is weak.
Connect gaps to strategic choices
Start with one outcome, then ask which capabilities enable it and what evidence shows their current condition. Highlight a gap only when it changes a decision. For example, inconsistent retry timing may justify a discovery task; it does not automatically justify a rewrite. Add an owner and a review date so the gap can become a bounded improvement question.
Keep the improvement backlog beside the map but visually separate. A map describes the current ability; a backlog describes proposed changes. When a project finishes, update the capability evidence and boundary. Do not leave completed project cards in the map as if they were permanent capabilities.
Copyable capability map structure
| Outcome | Capability | Owner | Evidence | Boundary / unknown | Next question |
|---|---|---|---|---|---|
| Outcome A | — | — | — | — | — |
| Outcome A | — | — | — | — | — |
| Outcome B | — | — | — | — | — |
Build the map in Boardmix
On a Boardmix board, place strategic outcomes across the top, capability cards in rows below them, and evidence notes beside the cards. Use connectors to show a meaningful relationship, not a reporting hierarchy. Keep the improvement backlog in a separate frame so the current map remains readable while the team discusses possible changes.
Open a Boardmix board and start with Subscription management and its four supporting capabilities. Add the payment-recovery detail, then connect the current gap to the improvement backlog.
