Companies Don't Die from Doing Too Much. They Die from Doing the Same Thing Twice.
Microsoft can't keep its AI products straight. AWS runs more than two hundred services and stays usable. The difference isn't focus — it's overlap. And the AI assistants buyers now ask for advice are about to make the bill come due.
Try this experiment with a friend who works at Microsoft. Pick one who ships AI products — there are plenty. Ask them to explain, on the back of a coffee-shop napkin, the difference between Microsoft 365 Copilot, Agent Builder, Copilot Studio, and Azure AI Foundry. Which one is for which buyer. When you'd reach for one and not the others. And while they're at it, where Agent 365 fits, since that's a fifth thing now.
Watch what happens.
The good ones start strong. They own a piece of this and they know their piece cold. Within a minute they hit the seams between their piece and the next one. By minute three they're hedging. By minute five there is usually a laugh, or a half-apology, and some version of it depends on the customer — honestly, most companies end up using all of them.
That last sentence is the whole article. Hold onto it.
This is not a failure of intelligence or effort. It is a structural fact about a product line that no single person can hold in their head — the same fact a customer hits when trying to architect a solution, the same fact a salesperson hits when trying to qualify a deal, the same fact a partner hits when trying to recommend one.
It is tempting to call this a focus problem and move on. Microsoft does too much, the theory goes. Big companies always do. The cure is to narrow down — be more like a startup. The theory is satisfying, and it is wrong. The reason it's wrong is sitting in plain sight inside the same industry.
The obvious answer doesn't survive a single counterexample.
Amazon Web Services offers more than two hundred distinct cloud services. By any "doing too much" theory of corporate failure, AWS should be an incomprehensible mess, drowning in its own complexity, losing to whichever focused upstart everyone is currently celebrating.
It is, instead, the default substrate of the modern internet and one of the most profitable franchises ever built.
So the framing breaks on contact. If a company with two hundred products can stay usable, and a company with a handful of overlapping AI products can confuse its own engineers, then the number of things a company does is not the variable that matters. Something else is doing the work.
AWS isn't clean either — and the way it isn't clean is the whole point.
Before going further, let me concede the obvious objection, because anyone who actually uses AWS is already forming it. AWS has overlap. Plenty of it. You can run containers on ECS, on EKS, or skip servers entirely with Lambda. You can store relational data in RDS or in Aurora. You can query data with Athena or warehouse it in Redshift. You can call foundation models through Bedrock or build your own on SageMaker. These are not crisply separated products. Anyone claiming AWS is a perfectly orthogonal catalog has not filed an AWS bill.
But look at how AWS overlaps, because it is a different kind of overlap than Microsoft's, and the difference is the entire argument.
AWS's overlaps sit on a single, statable axis. ECS, EKS, and Lambda are points on a spectrum from "I want maximum control and Kubernetes portability" to "I never want to think about a server." Aurora versus RDS is a question of how much performance and managed scaling you're willing to pay for. Athena versus Redshift is ad-hoc querying versus a provisioned warehouse. In every case, you can write the rule for choosing in one sentence, and that sentence references your situation, not Amazon's org chart. The choices are additive — more options along a clear dimension — not substitutive.
Microsoft's AI overlaps don't resolve to a clean axis, and the boundaries won't hold still. Agent Builder is sold as the simple option — until you outgrow it, at which point you "upgrade" into Copilot Studio. Copilot Studio is the enterprise option — except you can also use it as a front end while Foundry does the actual reasoning underneath. Foundry is the custom option — except picking it too early is, by consultants' own accounts, the single most expensive mistake teams make. And sitting above all of them is Agent 365, a separate product whose job is to govern the agents the other three produce. To choose, you don't answer one question. You hold four or five intersecting questions at once — licensing, distribution channel, governance plane, who maintains it — and the products keep absorbing each other's features, so the lines you drew last quarter have moved.
That's the distinction the rest of this rests on. Not breadth versus focus. Additive overlap that sits on a clear axis, versus substitutive overlap where products compete to answer the same question and the boundaries blur. AWS leans hard toward the first. Microsoft's AI portfolio is deep in the second.
The framework, made portable.
If you take one tool from this piece, take this. There are two independent variables, and only one of them is dangerous.
| Low overlap | High overlap | |
|---|---|---|
| Low breadth | Focused product | Confusing product |
| High breadth | Platform | Product swamp |
Breadth is the number of things you sell. Overlap is how much those things compete to solve the same problem. The bottom-left box — high breadth, low overlap — is Platform, and it's where AWS lives and thrives. Breadth is not the failure mode. Breadth plus overlap is. The bottom-right box — high breadth, high overlap — is the Product swamp, and it's where Microsoft's AI portfolio currently sits. Notice that the top-right box is dangerous too: you can be a small company with only two products and still confuse everyone, if those two products fight over the same job.
The startup advice everyone repeats — "do one thing well" — is really advice to live in the top-left box. That works. But it quietly implies the only safe move is to stay small, and the Platform box proves that's false. You can be enormous and clear. You just can't be enormous and redundant.
The product map is the org chart in a costume.
There's a structural reason redundancy happens, and it has a name. Melvin Conway noticed it in 1967: organizations ship their own communication structure. The shape of the software ends up mirroring the shape of the org chart. If you have four powerful groups all chasing the same opportunity, you will ship four powerful products that all chase the same opportunity. The redundancy on the outside is the redundancy on the inside, made visible.
Microsoft's confused AI portfolio is not, primarily, a strategy failure. It is an org-chart failure rendered in product form. The Microsoft 365 group, the Power Platform group, and the Azure group each had a credible claim on AI, each had executive air cover, and each shipped. The customer was handed the job of assembling the result.
This is why "just hire a chief product officer" rarely fixes it. The overlap is downstream of organizational reality, and the organizational reality is that several powerful units cannot be told to stand down without political costs executives are unwilling to pay. The overlap survives because the org chart survives.
"But some overlap is on purpose." Sometimes. Rarely the way you think.
Here is the strongest objection to everything above, and it deserves a real answer rather than a dismissal: not all overlap is a mistake. Large companies sometimes ship overlapping products deliberately, because different buyers, different sales motions, and different price points genuinely call for different products. Toyota and Lexus overlap enormously and it is not an accident. AWS offers both a managed Kubernetes service and a serverless one because the buyers really are different people with different problems. A little internal competition can even drive better products.
This is true, and Microsoft makes exactly this argument. The official framing is that these aren't competing products at all — they are different layers. You consume M365 Copilot, you compose in Copilot Studio, you customize in Foundry. By this account the overlap is apparent, not real; it only looks redundant because everything wears the "Copilot" label. Several thoughtful consultants agree, and they have a point about the underlying architecture: the products do connect to one shared ecosystem.
So how do you tell healthy, intentional overlap from the swamp? There's a clean test: intentional overlap is healthy only when buyers can self-select without expert help. A Toyota buyer and a Lexus buyer sort themselves in the parking lot. Nobody publishes a 3,000-word guide titled Toyota vs. Lexus: How We Decide for Every Client.
Microsoft's AI portfolio fails that test, and the evidence is the existence of the explanation industry around it. When the layers are genuinely distinct, you don't need a dozen consultancies writing side-by-side comparisons, you don't find the official documentation scattered across three separate sites, and the honest answer to "which one should I use" isn't "all of them." Distinct layers don't generate a translation economy. Overlapping ones do. "A different team built it" and "it's technically a different layer" are not the same thing as "a different buyer, with a different job, who can tell which door is theirs." The first two are facts about Microsoft. Only the third would make the overlap intentional in the way that works.
Startups have an unfair advantage they don't even know they're using.
This is also where the usual focus cliché needs correcting. Chatbase, Neon, Clerk — the standard examples of focused startups beating bigger companies — aren't winning because they chose focus. They're winning because their size forced it. A six-person team can only build one coherent thing; it does not have the headcount to spin up three overlapping versions of it. Focus, in other words, is downstream of constraint. It's a phase scarcity hands you for free.
Which is why the same founders sprawl exactly like the giants the moment they have abundance. OpenAI ships a consumer app, a developer API, an enterprise tier, an agent platform, and hardware ambitions. Nvidia long ago stopped being a chip company and became chips, networking, full systems, software stacks, and a cloud. Neither has obviously drowned — yet — and the reason is instructive: so far, both have sprawled more like a Platform than like a Product swamp, adding capabilities that compose rather than capabilities that compete. The lesson isn't that focus is sacred. It's that once scarcity lifts and you can finally afford to build the third overlapping thing, the discipline has to come from somewhere other than your bank balance. Almost nobody supplies it on time.
The tax was invisible for decades. AI search is about to print the receipt.
For a long time the overlap tax was paid quietly. It happened inside confused buyers' heads, inside stalled procurement cycles, inside the consulting fees companies paid firms whose entire business was translating a vendor's product line back into plain English. Real money — but invisible, because it never showed up on an income statement as a line item called confusion.
Something is changing the visibility, and it's worth looking at directly rather than predicting it. So I ran the test this article's argument implies, in mid-2026, the way a buyer now would: I asked the question across the web and the AI assistants people actually consult before they ever talk to a vendor. Which Microsoft product should I use to build an internal AI assistant?
The answers do not converge. They can't, because the source material doesn't. The consistent shape of the response — from Microsoft's own documentation, from independent consultancies, from the assistants summarizing both — is it depends, and most mature organizations end up using all of them. One widely shared consultant guide lays out Agent Builder for quick wins, Copilot Studio as the cross-functional standard, and Foundry for the custom layer, then concludes the real question is never which tool is best. Another, walking through Copilot Studio versus Agent 365, opens by saying that being asked to choose between the two is itself the tell — that the question reflects confusion about what each one does. Microsoft's own Learn pages split the guidance across separate sites for each product, which is why a cottage industry of "how we decide for every client" explainers exists at all.
And the cost is no longer hypothetical. The single most expensive mistake these consultants report is buyers picking the wrong overlapping product: a team hears "AI agent," assumes it needs developers, commits to Foundry, spends three months building, and ends up with something the low-code option would have delivered in two weeks. That is the overlap tax with a number attached — months of wasted engineering, caused entirely by a product line a buyer couldn't read.
Here's the part the giants haven't absorbed. AI assistants have no more ability to disambiguate an overlapping product line than a human buyer does — and arguably less, because they can't pick up the phone and ask a partner. They pattern-match across everything written about a vendor, and when the vendor's own materials are internally contradictory, the recommendation comes back hedged, conditional, or wrong. Clean primitives get clean recommendations. Overlapping suites get a paragraph that begins it depends. The buyer increasingly trusts that paragraph and never visits the vendor's site to have the confusion cleared up in person.
So the companies that built tidy, composable product lines are about to discover an enormous accidental advantage in AI-mediated discovery. The companies that built swamps are about to watch the invisible tax become a visible one — recorded, every day, in the answers an assistant gives to a buyer they're not in the room for.
(A fair caveat: assistant outputs shift week to week, so the specific responses above are a dated snapshot, not a fixed law. But the underlying mechanism — that an AI can only recommend as clearly as a vendor's own materials allow — doesn't move.)
"Just break it up" sounds right. It usually isn't.
The intuitive endpoint of all this is to split the giant into ten focused independents, each with its own inch of wall to own. Decomposition is a real instrument, and occasionally the right one: eBay spinning off PayPal unlocked huge value precisely because the two shared almost no real economies and were clearer apart than together.
But decomposition is the crude instrument, and reaching for it first usually misreads the problem — because Amazon disproves the premise. Internally, Amazon runs as something close to a thousand startups: the two-pizza teams, the mandate that every team expose its work through clean service interfaces and communicate only that way. Each team behaves like a focused company. Yet Amazon never split into a thousand legal entities, because the unified balance sheet is the moat — AWS profits subsidized retail price wars no pure-play retailer could survive, and data flows across units no outsider would have built together.
So the honest rule is narrow: splitting solves overlap only when the units lack meaningful synergies. Microsoft's pieces are not held together by mere inertia; they share genuine, valuable synergies — distribution, enterprise relationships, the cloud underneath. Splitting would trade a fixable problem (overlap) for a permanent loss (synergy). The fix that fits isn't clarity by amputation. It's clarity by architecture: a ruling on what each product is for, enforced hard enough that a customer can choose without a consultant, and a willingness to merge or kill the redundant ones. It's unpopular because it means telling a powerful executive their product is the redundant one. It's also the only move that actually works.
The three questions worth asking of your own product line.
This works whether you run a division of a giant, a Series B startup, or a single product. Don't ask are we doing too much? AWS does an enormous amount and is fine; that question sends you the wrong way. Ask instead whether you're in the swamp — and there are three quick diagnostics:
- Can a new customer tell where one product ends and the next begins — without a sales call? If buyers can't self-select, your "different layers" are overlap wearing a costume.
- Can your own salesperson explain why Product A still exists if Product B already does most of what it does? If the honest answer is "a different team owns it," you've found redundancy, not strategy.
- Can an AI assistant recommend one of your products without a paragraph of caveats? This used to be a soft concern. It is now a distribution channel.
If the answer to any of these is no, you don't have a breadth problem. You have an overlap problem. You are paying for it today in stalled deals and confused buyers, and you are about to pay for it again — in front of a far larger audience — in the recommendations machines give to people who will never visit your website to sort out the confusion themselves.
You do not earn the right to be broad by being big. You earn it by being clear — and clarity, unlike size, is a choice you have to keep making.
Sources for the AI-discovery section (snapshot, mid-2026), for linking on publication:
- Microsoft Learn — "Choose between Agent Builder and Copilot Studio": learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/copilot-studio-experience
- "Agent Builder, Copilot Studio, or Azure AI Foundry: How We Decide for Every Client" (pnp.github.io)
- "Agent 365 vs. Copilot Studio: Which One Does What" (valoremreply.com)
- "Agent Builder vs Copilot Studio vs Foundry — 2026 Guide" (aguidetocloud.com)
- "Microsoft 365 Copilot, Copilot Studio, and Azure AI Foundry: Understanding the Differences" (blog.chiffers.com)
- "Copilot Studio vs Azure AI Foundry: Which Platform in 2026" (wrvishnu.com)