--- title: How to Make a Business Capability Map Slide in PowerPoint description: Build a business capability map slide in PowerPoint that holds its grid together when L2 capability counts run from 4 to 14 across business units. image: https://www.advis-io.com/hubfs/blog-key-visuals/138-business-capability-map-powerpoint.en.kv.png --- [![logo\_transparent-Apr-12-2025-09-23-39-9623-AM-1](https://www.advis-io.com/hubfs/logo_transparent-Apr-12-2025-09-23-39-9623-AM-1.svg)](https://www.advis-io.com/en/?hsLang=en) - [BLOG](https://www.advis-io.com/blog?hsLang=en) - [ABOUT](https://www.advis-io.com/about?hsLang=en) [CREATE SLIDES](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview) Consulting Slides # How to Make a Business Capability Map Slide in PowerPoint Build a business capability map slide in PowerPoint that holds its grid together when L2 capability counts run from 4 to 14 across business units. [Advisio Editorial](https://www.advis-io.com/en/blog/author/advisio-editorial) Oct 14, 2026 --- A reasonable Level-1 business capability map has seven to ten top-level domains. Below that, the count stops being tidy: a global manufacturing company's capability map, documented as a working example by enterprise architecture practitioners, runs eight L1 domains and 45 L2 capabilities — an average of roughly 5.6 per domain, but that average hides a lot. Finance might carry four L2 capabilities. Operations might carry fourteen. A capability map built on a template with one fixed box size per L2 capability survives exactly until it meets that spread, at which point the fourteen-capability domain turns into a wall of overlapping text and the four-capability domain turns into a mostly empty rectangle sitting the same size next to it. ## Why a Fixed-Grid Capability Map Was Never Going to Hold A capability map's entire job is to show what an organization can do, independent of its org chart, independent of its current processes, independent of who happens to run each function this year. That's also exactly why its shape can't be decided in advance. A template assumes some default — four capabilities per domain, say, arranged in a uniform grid of uniform boxes — because that's the only assumption available before anyone has actually listed the organization's capabilities. The moment a real list gets built, that assumption breaks, because capability count per domain tracks organizational complexity, and complexity is never evenly distributed across a business. A commercial-heavy retailer's capability map typically shows a thick Marketing & Sales domain — channel management, pricing, promotions, loyalty, merchandising — sitting next to a comparatively thin Legal & Compliance domain. A regulated insurer flips that: Risk & Compliance carries the weight, and Marketing stays lean. Neither pattern is a sign of something wrong with the business. It's a sign the map is doing its job — showing where the organization's actual complexity sits. A fixed grid can't show that signal, because a fixed grid forces every domain to look equally complex whether it is or not. ## The Counterintuitive Part: More Capabilities Isn't More Important The instinct when a domain's box starts overflowing is to treat it as the "big" one — the one that matters most, visually reinforced by taking up the most space. That instinct is backwards often enough to be worth naming directly. Capability count measures how granular the organization's work in that domain happens to be, not how strategically important the domain is. A fourteen-capability Operations domain on a manufacturing company's map usually means operations work has been well-decomposed into distinct, nameable activities — inbound logistics, production scheduling, quality control, each one its own line. A four-capability Corporate Strategy domain on the same map doesn't mean strategy is unimportant; it means strategy work hasn't been (and often shouldn't be) broken into that many discrete, named capabilities, because strategic work is inherently less modular than operational work. Sizing a domain's box by capability count, then, isn't a claim about importance — it's a claim about granularity. Conflating the two is how a capability map ends up accidentally arguing that Operations matters more than Strategy, which is not what the exercise was built to say and not something a TOM or DX steering committee wants a slide implying by accident. The fix isn't to suppress the size difference — a map with every domain artificially forced to the same visual weight loses the one piece of information worth showing. The fix is to size by capability count deliberately, and say so in the slide's framing, so a reader reads box size as "how granular," not "how important." ## Building the Grid So Granularity Differences Don't Break It The construction that survives a 4-to-14 spread treats each L1 domain as an independent container sized to its own L2 count, not a cell in a shared grid. **Step 1 — Fix column count, not box size.** Decide how many L1 domains run across the top (seven to ten is the practical range most enterprise architecture guidance converges on for a map that stays legible at a glance; going much past ten usually means two domains should merge). Give each domain column an equal width — that part should stay uniform, since column width communicates nothing about capability count and uneven widths would just look like a layout accident. What varies is height. **Step 2 — Size each column's capability stack to its own L2 count.** Within a domain column, stack each L2 capability as its own small box, roughly 0.35 inches tall at 10-point type with a thin 0.5pt border, with 0.05-inch gaps between stacked boxes. A four-capability domain needs about 1.5 inches of stack height; a fourteen-capability domain needs about 5.5 inches. Let the column literally be that much taller — don't compress the fourteen-capability column's boxes to 0.15 inches to force it to match the others, which is the direct equivalent of shrinking font size to cram six competitor bullets into a box built for three on a [3C analysis slide](https://www.advis-io.com/en/blog/3c-analysis-slide-powerpoint?hsLang=en): a reader clocks compressed, barely-legible boxes as "this got crammed in" even without being able to name why. **Step 3 — Anchor every domain header to the same top edge, let bottoms fall where they fall.** All eight (or nine, or ten) domain header labels sit in a single row at a fixed y-position, same font size, same height. Below that shared line, each column's capability stack grows downward to whatever length its own count requires. The map ends up with a flat top edge and a jagged bottom edge — Operations extending much further down than Corporate Strategy next to it — which is the visual signature of a map that's actually showing its own data rather than hiding it inside a uniform box. **Step 4 — Group each domain column as one object.** Select a domain's header, its full capability stack, and its background fill, and group them with Ctrl+G, named for the domain ("Domain\_Operations," not "Group 7"). When a scope review adds two capabilities to a domain — common after the first workshop with a function's actual leadership, once "what we thought we did" gets corrected to "what we actually do" — that's a matter of inserting two more boxes into one group and letting the column's height grow, not re-measuring eight other domains that didn't change. ## Keeping Three Levels Honest Without a Fourth Enterprise architecture guidance is fairly consistent on one point: a capability map should stop at three levels — L1 domain, L2 capability, and an optional L3 for cases where an L2 genuinely needs further breakdown. Push past three and the map stops describing stable capabilities and starts describing process steps, which drift and reorganize far more often than capabilities do, defeating the reason to build a capability map instead of a process map in the first place. That distinction matters on the slide, not just in the methodology memo: a capability map answers what an organization can do, independent of org structure, while a process map answers how the work actually happens, step by step, inside a specific team. The two get confused constantly because both can look like a box diagram — the tell is whether the boxes are named as outcomes ("Manage Supplier Relationships") or as activities ("Send Purchase Order, Receive Invoice, Approve Payment"). On a slide, that means resisting the request — and it comes up in nearly every TOM workshop — to add a fourth level "just for this one complicated domain." If an L2 capability like Order Management genuinely needs more resolution than a single box can carry, the right move is an L3 sub-box nested under it (Order Capture, Order Fulfillment, Returns Processing), not a structural fourth tier applied map-wide. Keep L3 visually subordinate — smaller type, lighter border weight, indented under its parent L2 box — so it reads as detail on one capability rather than a new layer the whole map now has to support. ![Comparison diagram: a business capability map with uniform domain box sizes causing a fourteen-capability Operations domain to overflow into compressed, barely legible text while a four-capability Strategy domain sits mostly empty, versus the same map with each domain column sized to its own L2 capability count and a flat top edge.](https://www.advis-io.com/hubfs/blog-figures/138-business-capability-map-powerpoint-fig1.en.png) Figure: uniform domain boxes compressing a fourteen-capability domain into illegible type (left) versus columns sized to each domain's own capability count (right). ## What This Looks Like Across Two Very Different Businesses A mid-size SaaS company building its first capability map for a TOM redesign typically produces a Technology & Data domain that dwarfs the rest — platform architecture, data infrastructure, security, integration, each its own named capability, often twelve or more in total — next to a comparatively thin Finance domain with five or six. A regional bank doing the same exercise for a digital transformation program usually inverts that: Risk & Compliance and Customer Operations carry the bulk of the capability count, while Technology, perhaps counterintuitively, stays leaner, because the bank's core processing runs on a small number of broad, well-established capabilities rather than many narrowly decomposed ones. Nothing about the four-step construction changes between these two cases. What changes is which column ends up tall, which is itself the reason the column height can't be decided before the actual capability list exists — a SaaS company's map and a bank's map should not share a template, because sharing a template is exactly what produces a slide that misrepresents where each organization's real complexity sits. ## FAQ ### How many Level-1 capabilities should a business capability map have? Most enterprise architecture practice converges on seven to ten L1 domains for a map that stays readable at a glance and avoids collapsing meaningfully different functions into one bucket. Some organizations run as few as eight or as many as fourteen broad domains; past that range, two domains usually overlap enough to merge. ### What's the difference between a capability map and a process map? A capability map shows what an organization can do — stable, outcome-oriented, independent of org structure or current tooling. A process map shows how a specific capability actually gets executed — the sequence of steps, decisions, and handoffs, which changes far more often than the capability itself. A capability box is named as an outcome ("Manage Supplier Relationships"); a process box is named as an activity ("Issue Purchase Order"). ### Should every domain on the map have the same number of capabilities? No — forcing an even distribution misrepresents the business. Capability count reflects how granular that domain's work happens to be, not how important the domain is. A map that shows genuinely uneven counts, sized honestly, communicates more than one that's been artificially balanced to look tidy. ### How many levels should a capability map go down? Two levels (L1 domain, L2 capability) covers most maps; a selective L3 is reasonable when a specific L2 needs more resolution. Going further usually means the map has drifted into documenting processes, which belong in a separate process map rather than a fourth capability tier. [Advisio](https://www.advis-io.com/?hsLang=en), listed on [Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview), builds the domain grid directly from an actual L1/L2 capability list as native, editable PowerPoint shapes — sizing each domain column to its own capability count and keeping every header anchored to the same top edge, so a capability map that goes from forty to fifty-five capabilities after the second workshop is a column that grows, not a map that gets rebuilt. It's the same engine behind the [target operating model slide](https://www.advis-io.com/en/blog/target-operating-model-powerpoint?hsLang=en) most capability-mapping workshops eventually feed into. [Consulting Slides](https://www.advis-io.com/en/blog/tag/consulting-slides) [Slide Design](https://www.advis-io.com/en/blog/tag/slide-design) ## Similar posts ![logo\_white-1](https://www.advis-io.com/hubfs/logo_white-1.svg) Transform your business data into actionable insights with AI-powered analytics. Get consultancy-grade presentations in minutes, not weeks. N&E Building, 6th Floor 1-12-4 Ginza, Chuo-ku Tokyo 104-0061 Japan [contact@advis-io.com](mailto:contact@advisio.com)   - [Blog](https://www.advis-io.com/en/blog) - [About Us](https://www.advis-io.com/en/about?hsLang=en) - [問い合わせ](https://www.advis-io.com/contact?hsLang=en) - [特定商取引法に基づく表記](https://www.advis-io.com/jacommercialtransaction?hsLang=en) - [利用規約](https://www.advis-io.com/terms?hsLang=en) - [プライバシーポリシー](https://www.advis-io.com/privacy-policy?hsLang=en) © 2026 Advisio Inc. All rights reserved. [Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Advisio Editorial", "url" : "https://www.advis-io.com/en/blog/author/advisio-editorial" }, "dateModified" : "2026-10-14T23:27:55.999Z", "datePublished" : "2026-10-14T23:27:55.000Z", "headline" : "How to Make a Business Capability Map Slide in PowerPoint", "image" : [ "https://www.advis-io.com/hubfs/blog-key-visuals/138-business-capability-map-powerpoint.en.kv.png" ], "mainEntityOfPage" : { "@id" : "https://www.advis-io.com/en/blog/business-capability-map-powerpoint", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://www.advis-io.com/hubfs/logo.svg" }, "name" : "Advisio株式会社" } } ```