When the Capability Commoditizes
There is a moment in the life of a product category when the thing it does stops being rare. The first tool that extracts structured data from a messy document is remarkable. The fifth one is expected. By the time a dozen tools do the same extraction with comparable accuracy, the capability itself has stopped being a reason to choose one over another. This is commoditization, and the instinct is to treat it as the end of the opportunity. It is usually the relocation of the opportunity.
The mistake is to conflate the capability with the product. The capability is “turn this document into structured data.” The product is the entire experience of getting that done — where it happens, what it connects to, how much context-switching it costs, whether it fits the tool the user already lives in. When the capability commoditizes, the differentiation doesn’t vanish. It moves down the stack, from “can this be done” to “where does this happen, and how little friction does it cost me to do it here.”
This distinction matters because the two layers commoditize at different rates. The underlying capability — the model that reads the document, the extraction logic — is increasingly something many teams can build, because the hard part is now a shared foundation that everyone draws from. But the delivery surface is not shared. Whether the capability shows up as a web app you log into, a spreadsheet add-in, or a tool that runs inside the assistant you already have open is a product decision, and the surfaces are not interchangeable from the user’s point of view. One requires the user to leave their workflow; another meets them inside it.
The practical signal to watch for is when the marketing copy across competitors starts to converge. When every tool in a category describes itself with the same verbs — extract, analyze, populate, cite — the verbs have stopped being differentiators. That convergence is the tell that the capability has commoditized. The question to ask at that point is not “how do we do this better” but “where is this happening, and is there a surface where it isn’t happening yet that the user would prefer.” The unoccupied surface is the new opportunity, even when the capability behind it is fully commoditized.
The reason the surface is defensible, at least for a while, is that incumbents are anchored to the surface they launched on. A tool built as a web application has a web application’s architecture, billing, onboarding, and habits. Moving it to a new delivery surface is not a feature addition — it is a second product, with its own integration model and its own user expectations. The incumbent can do it, but not cheaply and not reflexively, which buys the entrant time. The moat is not the capability and not even the surface itself; it is the lead time before the incumbents decide the new surface is worth a second build.
This is also why the window is real but narrow. The same logic that makes the new surface attractive to an entrant makes it attractive to everyone else watching the category. The capability being commoditized means the entrant can’t win on the capability either — they’re drawing from the same foundation. The whole bet reduces to being early and native to a surface the user is migrating toward, before the surface stops being novel. That is a timing bet, not a technology bet, and timing bets reward moving while the observation is still fresh rather than after it has been confirmed by everyone else arriving.