Capability-Based Planning
Capability-Based Planning is a strategy approach that defines the company in terms of its capabilities (WHAT the business can do — pricing optimization, customer onboarding, demand forecasting) rather than its functions (WHO does it — Marketing, Sales, Operations) or its products (WHAT it sells). The strategic question becomes: 'Which capabilities must we be world-class at to win, which must we be competent at to operate, and which can we outsource or automate?' Capabilities are the persistent assets that survive product pivots, market changes, and reorganizations. A SaaS company might have 50-80 capabilities mapped; only 3-7 of them are 'differentiating' (where the company must be top-decile). Strategy becomes an explicit allocation of investment across the capability map.
The Trap
The trap is producing a beautiful capability map that nobody uses for actual decisions. Most enterprise architecture teams produce capability heatmaps that gather dust because they're not tied to investment, hiring, or technology decisions. The other trap: claiming too many capabilities are 'differentiating.' If 25 of your 60 capabilities are 'must be world-class,' you have no strategy — you're trying to be excellent at everything, which means you'll be excellent at nothing. Real capability-based planning produces uncomfortable choices.
What to Do
Map your business capabilities (use ~60-80 capabilities at level 2 detail). For each, classify: (1) Differentiating (must be top-decile to win), (2) Strategic Necessity (must be competent), (3) Commodity (table stakes), (4) Outsource-able. Force yourself to mark only 3-7 as Differentiating. Compare current investment, hiring, and technology spend against the classification — most companies discover they're under-investing in differentiating capabilities and over-investing in commodities. Re-allocate over 12-18 months. Re-map every 18 months as the strategy evolves.
Formula
In Practice
Amazon under Bezos has been ruthlessly capability-focused since the early 2000s. The 'API mandate' of 2002 was effectively a capability declaration: every team had to expose their work as a capability via API, with no exceptions. This forced clarity about what capabilities Amazon actually had. The discipline produced AWS — Amazon recognized that 'elastic compute' was a capability they had built for themselves, that this capability had external value, and that the capability was differentiating relative to potential competitors. Without capability-based thinking, AWS would have been buried inside an internal IT cost center.
Pro Tips
- 01
The capability map should be 'capability-centric' not 'org-centric.' If your capability map maps 1:1 to your org chart, you've just renamed your org chart. A real capability map cuts across the org and reveals the 5-7 horizontal capabilities (data, ML, customer onboarding) that multiple teams touch.
- 02
Capability maturity matters more than capability ownership. A 'pricing optimization' capability owned by 4 different teams at low maturity is worse than the same capability owned by one team at high maturity. The map should explicitly score maturity (1-5) per capability and force investment toward maturity gaps.
- 03
Use the capability map to guide build/buy decisions. Differentiating capabilities should be built and owned. Commodity capabilities should be bought (use vendors). Strategic Necessity should be evaluated case-by-case. Most companies invert this — they build commodities (auth, infra) and buy differentiators (their core product logic), which is exactly backward.
Myth vs Reality
Myth
“Capability-based planning is an enterprise architecture exercise relevant only to large companies.”
Reality
Startups gain disproportionately from capability thinking because they have limited resources. A 50-person startup that invests 80% of engineering in differentiating capabilities and outsources/buys the rest will out-execute a 50-person startup that builds everything itself. The framework scales down better than most strategy frameworks scale up.
Myth
“If a capability is core to the customer's experience, it must be differentiating.”
Reality
Customer-facing doesn't mean differentiating. Authentication is customer-facing — every user touches it — but it's a commodity. Differentiation is about whether your version of the capability creates measurable competitive advantage. Most customer-facing capabilities are table stakes; only a few are sources of advantage.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
A B2B SaaS company has these capabilities. Which one is most likely a TRUE differentiating capability where the company should invest heavily and own it in-house?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
Engineering Investment Allocation by Capability Type
Mid-to-late-stage tech companies (Series B+, 100-2000 engineers)Differentiating Capabilities
50-60% of spend
Strategic Necessity
25-35% of spend
Commodity Capabilities
10-20% of spend
Outsource-able / Vendor-served
5-10% of spend
Source: TOGAF Capability Planning; Gartner Business Capability Modeling research
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Amazon
2002-Present
Jeff Bezos's 2002 'API Mandate' was capability-based planning made operational. Every team at Amazon had to expose their work as a callable service via well-defined APIs. No exceptions. The mandate forced every team to articulate WHAT capability they provided, separate from WHO consumed it. This produced clarity about Amazon's true capabilities — and revealed that 'elastic compute and storage' was a capability of significant external value. Andy Jassy spotted the opportunity and AWS launched in 2006. AWS is the most successful business unit in technology history, generating over $100B annual revenue by 2024 — and it exists because Amazon thought in capabilities, not just products.
Year of API Mandate
2002
AWS launched
2006
AWS revenue (2024)
$100B+
AWS operating margin
~30%
Capability thinking unlocks businesses that product thinking misses. Amazon never set out to build AWS as a strategic bet — they built it as a logical extension of their internal capability map. Companies that don't think in capabilities miss these adjacent value creation opportunities.
Lego
2003-2014 (turnaround)
Lego nearly went bankrupt in 2003-2004 with €238M in losses. The new CEO Jørgen Vig Knudstorp ran a capability assessment and discovered the company was over-invested in non-differentiating capabilities (theme park operations, video games, clothing) and under-invested in its true differentiators (the brick design system, design-for-manufacturing, and the play-pattern expertise). He divested the theme parks (sold to Merlin Entertainments), exited categories where Lego had no capability advantage, and concentrated investment on the core brick capability and master licensing. By 2014, Lego had become the world's most profitable toy company.
Losses (2003)
€238M
Theme parks divested
70% sold to Merlin
Outcome (2014)
World's most profitable toy company
Strategic focus
Brick capability
Lego's turnaround was a textbook capability-based pivot: identify true differentiators, exit non-differentiating businesses, concentrate capital. The hardest part was psychological — the theme parks were emotionally important to leadership but were not part of Lego's true capability advantage.
Hypothetical: 800-person enterprise SaaS company
2022-2024
An 800-person enterprise SaaS company conducted a capability audit and discovered they had 18 capabilities marked 'must be world-class' (impossible). Forced to re-prioritize, they reduced this to 5: vertical workflow expertise, ML-powered insights engine, customer onboarding velocity, data ingestion pipelines for legacy systems, and renewal motion. The other 13 capabilities were demoted to 'strategic necessity' or 'commodity.' Engineering investment was reallocated: differentiating capabilities went from 22% of spend to 54%, commodities went from 38% to 14% (replaced by vendors). Within 18 months, ARR growth re-accelerated from 18% to 33% with the same engineering headcount.
Differentiating capabilities (before)
18 (claimed)
Differentiating capabilities (after)
5 (real)
% Spend on Differentiators (before/after)
22% → 54%
ARR growth change
18% → 33%
Most mid-stage SaaS companies claim 15+ differentiators because nobody wants to admit their work is 'commodity.' The forcing function of picking only 5 produces uncomfortable but clarifying conversations. The growth acceleration came from concentration, not from new capabilities.
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Capability-Based Planning into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Capability-Based Planning into a live operating decision.
Use Capability-Based Planning as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.