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

Deep thoughts on AI and aspirations —— ByteDance Deep Thinking Circle

The old product playbook focuses on nailing one killer feature, polishing it to perfection, then using it to win users. This approach worked reliably in the mobile internet era. But for 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 that scenario gets casually covered by a general-purpose model, the product loses its footing.

In a 2023 conversation, Yang Zhilin from Moonshot AI laid this out clearly. He made a call that nobody took seriously at the time but has grown sharper since: what AI products should compete on isn’t how strong a single feature is, but 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” is dangerous, you first 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 one feature is one feature. AI-native products are different. In Yang’s words, the frontend is converging toward conversational interfaces, the backend is converging toward a unified large model, and the real differentiation happens 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 usable those capabilities actually are in practice.

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

Because expansion is cheap, perfecting just one scenario becomes the least efficient choice—you’re putting all your chips on one point, and that point is precisely the easiest for others to replicate at lower cost.

A New Metric: Scenario Moore’s Law

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

Traditional Moore’s Law measures hardware metrics like transistor count and compute power. He transplants this 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 new scenario, you need to add specific data and tune the model separately”—that’s still the old AI approach, never scaling fast. Only when the foundation is a sufficiently general capability engine can scenario unlocking happen in batches and accelerate mutually.

He has a vivid analogy: don’t plant trees, claim territory. Traditional product managers are like sharpshooters, carefully picking a plot, planting one tree, betting it grows into a forest. The AI-era approach is to stake out an entire territory, let general capabilities sweep through it all at once, and validate in one go which of dozens or hundreds of scenarios will thrive and which will die. The process of finding product-market fit 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 scenario count reaches a certain threshold, the product naturally becomes an entry point—this evolution doesn’t need human planning; the engine is inherently general, so the product expands along its boundaries naturally.

Why Single-Scenario Is Especially Dangerous

Flip the logic above, and you see the fatal flaw of single-scenario products.

First, coverage risk. A product solving only one scenario stakes nearly all its value on that scenario’s uniqueness. But general-purpose model capabilities continuously spill over—today’s incremental edge from fine-tuning could easily be flattened tomorrow by a base model upgrade. Building walls on someone else’s foundation means when the foundation shifts, the walls collapse.

Second, 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 can’t access this compounding effect. Their data is thin and stagnant, unable to sustain continuous evolution.

Third, unfavorable valuation logic. When investors look at single-scenario products, they see “how big is this scenario’s market”—a ceiling you can see immediately. When they look at multi-scenario engines, they see “how many more scenarios can be unlocked”—an open-ended story. Same effort, completely different imaginable upside.

To be clear, generality and doing multiple scenarios don’t conflict with “serving a super-app everyone uses.” The G in AGI stands for general—it solves an ever-expanding range of problems by nature. Product boundaries naturally expand. Riding this expansion aligns with technology’s inherent nature; clinging to one point goes against it.

The Counterargument: This Rule Doesn’t Apply to All AI Products

We need to pour cold water here—Scenario Moore’s Law has boundaries and can’t be blindly applied.

First, it holds most strongly for “general engine” products, not necessarily for deeply vertical ones. If you’re doing deep work in an extremely narrow industry—say, local merchant operations management as discussed earlier—the moat comes precisely from extreme understanding of that single scenario and its data loop. Spreading across scenarios dilutes depth. Depth and breadth are two different paths; you can’t mix them.

Second, “unlocking scenarios” must be premised on “actually usable.” Inflating scenario counts with half-baked features nobody actually uses is 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 shaky, claiming more territory just grows weeds. First build a general engine, then talk about batch unlocking—the order matters.

So the more precise statement is: when your product is essentially a general capability engine, measure yourself by scenario unlocking velocity; when you’re essentially vertical deep work, measure yourself by penetration depth in a single scenario. The worst position is ambiguity—neither general enough nor deep enough, stuck in the middle.

Translating to Action

If you’re building an AI product, test yourself with three questions.

First, is your product actually an engine or deep work? This determines which ruler to measure yourself with—don’t use the wrong metric.

Second, if it’s an engine, replace the core dashboard metric with “how many genuinely used scenarios did we add this quarter,” not DAU. DAU tells you how many people you have now; scenario unlocking velocity tells you how many you could have in the future.

Third, invest resources where they feed data feedback loops. Every real scenario should route its interaction data back into the model, making the next scenario cheaper to unlock. Mutual acceleration between scenarios is where this law’s true compounding happens.

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