The Greatest Fear for AI Products: Being Limited to a Single Use Case

Deep thinking on AI and aspirations —— ByteDance Deep Thought Circle

The old product playbook is to identify one killer feature, polish it to perfection, and use it to win users. This approach worked repeatedly in the mobile internet era. But when applied to AI products, it’s quietly failing. The real danger isn’t that a feature isn’t good enough—it’s that the entire product only works in one scenario. Once a general-purpose model casually covers that scenario, the product loses its foothold.

In a 2023 conversation, Yang Zhilin of Moonshot AI explained this clearly. He made a call that nobody took seriously at the time but has grown sharper ever since: AI products shouldn’t compete on how strong a particular feature is, but on how many “usable” scenarios they can unlock per unit of time.

AI Product Boundaries Are Defined by Data, Not Features

To understand why “single-scenario” products are dangerous, we need to see a fundamental difference between AI products and traditional ones.

Traditional product boundaries are hardcoded: product managers define requirements, engineers implement them deterministically, and a feature is a feature. But AI-native products are different. As Yang puts it, frontends are converging toward conversational interfaces, backends are converging toward unified large models, and the real differentiation falls in the middle layer—data. An AI product is largely defined by two datasets: training data determines what capabilities the model can provide, and test data determines how well those capabilities actually work.

This difference has real consequences: the marginal cost of adding a new scenario has dropped dramatically. In the traditional approach, each new scenario requires full redevelopment with linearly stacking costs. In the AI-native paradigm, as long as underlying capabilities and data feedback loops are connected, expanding to a new scenario is more like “swapping in a new dataset” than “rebuilding a product.”

Because expansion has become cheap, focusing on just one scenario has become the least cost-effective choice—you’re betting all your chips on one point, and that point is precisely what others can most easily replicate at lower cost.

A New Metric: Scenario Moore’s Law

So how should AI products measure themselves? Yang’s answer is what he calls “Scenario Moore’s Law.”

Traditional Moore’s Law measures hardware metrics like transistor count and computing power. He transplants it to AI: the truly critical metric is how many scenarios shift from “unusable” to “usable” over a given period. And this process must be exponential, not linear.

Why emphasize exponential? Because linear means “for each scenario, add dedicated data and tune the model separately”—that’s still the old AI approach, and it will never scale. Only when the foundation is a sufficiently general capability engine can scenario unlocking happen in batches and accelerate each other.

He has a vivid metaphor: don’t plant trees, claim territory. Traditional product managers are like sharpshooters, carefully selecting one plot, planting one tree, betting it will grow into a forest. The AI-era approach is to stake out an entire area, let general capabilities sweep through in one pass, and validate which of dozens or hundreds of scenarios will thrive and which will die. The PMF discovery process itself should be done the AI way—through batch experimentation, not a single bet.

The value of this insight is that it shifts AI product competitiveness from “single-point strength” to “unlocking velocity.” Once the number of scenarios reaches a certain threshold, the product naturally becomes an entry point—this progression doesn’t require human planning; if the engine is inherently general, the product will expand along its boundaries.

Why Single-Scenario Products Are Especially Dangerous

Flip the logic above and you’ll see the fatal weakness of single-scenario products.

First is the risk of being overtaken. A product that only solves a single scenario stakes nearly all its value on that scenario’s uniqueness. But general-purpose models continuously expand their capabilities; the incremental gain you achieve through fine-tuning today may be casually erased tomorrow by a base model upgrade. Building walls on someone else’s foundation means when the foundation shifts, the walls collapse.

Second is the lack of data feedback. More scenarios mean more user interactions across different contexts, richer feedback data, smarter models, which unlock even more scenarios—a positive feedback loop. Single-scenario products don’t capture this compounding effect; their data is thin and stagnant, insufficient to sustain continuous evolution.

Third is disadvantaged valuation logic. Investors looking at single-scenario products ask “how big is this scenario’s market”—the ceiling is immediately visible. Looking at multi-scenario engines, they ask “how many more scenarios can be unlocked”—the story is open-ended. For the same effort, the imagination space is completely different.

To be clear, being general-purpose and doing multiple scenarios doesn’t conflict with “serving a super app that everyone uses.” The G in AGI stands for general; the problems it can solve are inherently expanding, and product boundaries naturally grow. Expanding with the flow follows the technology’s nature; stubbornly defending one point goes against it.

The Counter-Argument: This Rule Doesn’t Apply to All AI Products

At this point, we must pour cold water: Scenario Moore’s Law has boundaries of applicability and can’t be blindly applied.

First, it applies most to “general engine” products, not necessarily to deeply vertical ones. If you’re building something for an extremely narrow industry vertical—like the local business agency work we discussed earlier—the moat comes precisely from extreme understanding of that single scenario and its data loop. Spreading out into multiple scenarios would dilute depth. Depth and breadth are two paths; they can’t be mixed.

Second, “unlocking scenarios” must be premised on “actually usable.” If you inflate the scenario count by including half-baked features nobody actually uses, that’s self-deception. The denominator in Scenario Moore’s Law is “usable,” not “launched.”

Third, this approach has a hard prerequisite: the underlying general capability must truly be sufficient. If the foundation is unstable, no matter how much territory you claim, you’ll only grow weeds. Build the general engine first, then talk about batch unlocking—the order can’t be reversed.

So the more accurate statement is: when your product is essentially a general capability engine, measure yourself by scenario unlocking velocity; when you’re essentially a vertical deep play, measure yourself by single-scenario penetration depth. What’s most dangerous is fuzzy positioning—neither general enough nor deep enough, stuck in the middle.

Translating to Action

If you’re building an AI product, you can self-assess with three questions.

First, is your product fundamentally an engine or a deep play? This determines which yardstick to use—don’t pick the wrong metric.

Second, if it’s an engine, replace the core dashboard metric with “how many truly user-adopted scenarios were added this quarter,” not DAU. DAU tells you how many users you have now; scenario unlocking velocity tells you how many you could have in the future.

Third, invest resources where they can feed data back into the loop. For each real scenario added, ensure its interaction data flows back into the model, making the next scenario cheaper to unlock. Scenarios accelerating each other is the true compounding source of this law.

The safest way for AI products to survive is to make the trees on your plot grow faster than anyone else’s.