01 Triggering Event

Google Gemini product lead Tulsee Doshi explained in Lenny's Newsletter that developing a frontier model is not simply a matter of making model engineering more complex. It requires simultaneously addressing research, product, infrastructure, and commercialization. She also introduced a 60-20-20 framework for allocating resources across work that is already effective, nearly effective, and still unproven.

This may appear to be a product management methodology, but its real signal is that Google is placing Gemini, Nano Banana, Genie, Veo, Lyria, and other models within one full-stack frontier AI system rather than operating several isolated models.

02 What It Really Means

The issue is not that Google has articulated another frontier model development process, but the organizational model it has chosen.

Doshi compared model development to Snape's potions class. The point of the analogy is not that the recipe is mysterious, but that every step requires judgment across objectives, constraints, and contingencies: Is the data sufficient? Is the training scale appropriate? Does the eval genuinely measure user value? Can the product form convert model capability into usage?

This exposes an often-overlooked fact about frontier labs: model capability is only one layer of the system. Beyond model quality, the data pipeline, training resources, post-training, serving stack, developer tooling, distribution, and product feedback loop determine whether capability can become revenue.

It also explains why Google's advantages cannot be measured only through benchmarks. It owns TPU, Gemini, Vertex AI, AI Studio, Android, Search, and Workspace. For frontier models, these assets create a complete loop from training to distribution. But the longer the loop, the greater the risk that local decision errors will be amplified.

The value of 60-20-20 lies not in the numbers themselves, but in forcing teams to distinguish explicitly among three types of uncertainty:

  • Work that has already been proven effective;
  • Work that is technically close to maturity and can receive additional investment;
  • Directions that remain unvalidated and should receive only controlled investment.

Many AI startups lack this discipline. Teams commit all their resources to a capability that is “almost working,” yet cannot explain which results come from genuine product signals and which are merely demos. That distinction directly affects the next fundraising round and the next hiring plan.

I have not participated in these resource allocations inside Google, so 60-20-20 should not be interpreted as Gemini's actual budget sheet. It is better understood as a public management framework than a specific operating plan.

03 Historical Analogy / Structural Comparison

The closest historical analogy is the 2007 iPhone, although a common claim needs qualification.

The iPhone's breakthrough was not merely putting a computing device into a phone; Apple regained control over the hardware, operating system, app store, and developer distribution. Model capability is the “kernel,” while the API, developer tools, SDK, and ecosystem are the “App Store.”

The 2008 financial crisis offers a counterexample: high-growth narratives do not automatically create moats. Financial institutions treated credit growth as value until the loss distribution was repriced. AI is no different. Token usage may grow rapidly, but if customers cannot retain, inference costs exceed gross margin, and model differences are copied quickly, growth itself is not a moat.

ChatGPT in 2022 demonstrated the power of distribution. Its model may not have been unambiguously the strongest, but it reached the right user entry points and created a low-friction trial and developer feedback loop. Google has a more complete distribution system than ChatGPT had at the time, but it must prove that it can convert those assets into model usage rather than merely exposure.

The core structure is aggregation: model capability will continue to become commoditized, while the product layer that embeds models into existing workflows, accumulates proprietary feedback, and raises switching costs is more likely to retain value.

This does not automatically mean closed models will win. Open-source models will continue to push down API prices for comparable capabilities, forcing closed models to charge premiums for reliability, tool use, multimodality, safety, latency, and integration. If the full stack does not create such premiums, distribution is merely an expensive customer acquisition channel.

04 What It Means for AI Builders

First, rewrite the product roadmap this week. Identify which capabilities already produce repeatable customer outcomes and which are only “nearly working.” Do not substitute model benchmarks for product evals. Define the cost of task failure, latency budgets, and conditions requiring human intervention.

Second, API products need their own eval layer. Tulsee discussed how to write the first eval; the emphasis should be on real task distributions rather than general leaderboards. A minimum viable eval need not be complex, but it must include failure cases, version records, and regression tests. Without them, every model change becomes a gamble.

Third, model routing should not be based on price alone. Teams should also calculate quality, latency, context length, tool-call reliability, data residency, and provider outage risk. Assigning simple tasks to cheaper models is basic token economics, but if higher error rates trigger retries or manual review, the apparent discount merely shifts costs elsewhere.

Fourth, AI startups should select at least one existing channel with strong distribution. A product moat often comes from workflow integration, permission systems, auditability, and team collaboration data rather than the model itself. Models can be replaced, but friction and data gravity accumulated during migration are much harder to move.

Fifth, for model access platforms such as opcx.ai, the key is not the number of supported models, but turning routing into an observable product capability. Users need to understand why each request was routed to a particular model, how quality and latency performed, how much cache hits saved, and whether switching providers is worthwhile. That control panel could create switching cost.

I may be overestimating how quickly a full stack creates synergies. Owning more assets does not guarantee stronger decision-making. If internal approvals, compute queues, and the burden of legacy products slow iteration, the full stack can become full-stack bureaucracy.

05 Counterargument / Risks

I may also be underestimating the importance of model technology itself.

Doshi's narrative emphasizes product and organization, which can create a misleading impression that model supply is already highly homogeneous and the application layer merely needs effective packaging. In reality, frontier models still differ significantly in reasoning, multimodality, context handling, agentic execution, and safety. Those differences directly determine whether a product can work.

More sharply, Google's full stack may also be a defensive structure. It needs Gemini to remain integrated across models, cloud, devices, and applications so that independent AI products cannot bypass its distribution system. Viewed in reverse, this structure may constrain Anthropic, OpenAI, or AI-native startups from building independent distribution. The higher Google's resource barriers, the more likely its platform is to lock APIs, toolchains, and default routing into its own ecosystem.

A second risk is that 60-20-20 becomes a slogan. If resources are still allocated around highly visible projects, or if internal narratives determine what counts as “already effective,” the framework is merely annual planning repackaged. AI companies' common problem is not a lack of methodology; it is an inability to admit that a direction is wrong.

A third risk is overengineering evals. A sophisticated eval platform may be more polished than the customer's actual work, ultimately optimizing metrics rather than outcomes. Tulsee discussed writing the first eval. Expanding from one useful eval into a credible evaluation system requires real data, continuous maintenance, and sufficient sample size—tasks far harder than producing a leaderboard.

Finally, Google's organizational capabilities should not be extrapolated directly to startups. Google can simultaneously support TPU, data centers, research labs, consumer distribution, and enterprise sales. Small AI builders attempting to replicate this structure usually replicate only its complexity. A better strategy may be to explicitly abandon a layer and assemble a combination of model providers, cloud services, and existing workflow platforms.

I still believe this public signal deserves attention: the unit of competition in frontier AI has shifted from the individual model to the complete “model–product–infrastructure–distribution” system. But what deserves observation is not how many benchmarks Google's next model wins. It is whether the full stack simultaneously improves Gemini's unit economics, developer adoption, and product retention.