Product teams building on rapidly improving AI models face a structural dilemma: ship only what works today and risk irrelevance, or build for tomorrow's capabilities and ship nothing usable. Tulsee Doshi, Google's head of product for Gemini, offers a concrete split. Speaking on Lenny's Podcast, she recommends dividing every build into roughly 60% that works today, 20% that nearly works, and 20% that is a bet on future model gains. The framework, reported by BigGo Finance from her podcast appearance, gives product leaders a simple diagnostic for judging whether their roadmap is balanced or stranded.
Understanding Google's 60/20/20 AI Product Development Framework
Doshi's rule addresses a question every AI product team now confronts: how far ahead of model capability should you build? Her answer is a proportional allocation of development effort across three buckets, each defined by its relationship to current model capability. The first bucket contains features fully functional with today's models. The second contains features that are almost working—viable with modest near-term model improvement. The third contains speculative bets on capabilities that do not exist yet but may arrive as models advance.
The framework emerged from Doshi's discussion of the practical craft of building AI products, where she also argued that model behavior should be treated as UX and that "good" should be defined through rubrics and evals. The 60/20/20 split is her answer to the pacing problem specifically: it is a rule of thumb for how much of what you build should depend on capabilities you already have versus capabilities you expect. It is not a budgeting mandate but a strategic posture for teams whose underlying technology improves on its own schedule.
The 60% Allocation: Shipping Value Today
The largest share of effort goes to what current models can already deliver. In Doshi's words, "You want to actually build features that aren't necessarily always working today. Build such that 60% of what you've built works now and your prototype is at least functional." The majority of a product, in other words, must be immediately viable: users get real value now, and the product has a stable, functional core rather than a collection of demos.
This floor matters because it disciplines the rest of the portfolio. If less than roughly 60% of what a team builds works today, the product risks becoming an aspiration wrapped around a prototype—impressive in demos but unable to serve users reliably. The 60% bucket is where immediate user value and product stability live, and it anchors the other two allocations. Everything speculative is funded from the margin above this functional core, not instead of it.
The First 20%: Building for Near-Future AI Capabilities
The first 20% covers features that nearly work. These are initiatives where the model gets close—close enough that the team can see the path to viability, but not close enough to ship. Doshi's framing suggests these features are waiting on incremental model improvement rather than a breakthrough: the capability is on a visible trajectory, and building now positions the product to activate the feature as the model catches up.
This bucket is the framework's hedge against being caught flat-footed. Teams that build only for today's models must start from zero each time a model improves; teams that reserve effort for near-future features have already done the product work when the capability arrives. The allocation is deliberately modest—20%, not 40%—because near-working features still cannot ship, and over-committing to them would starve the functional core. The goal is preparation without over-commitment.
The Second 20%: Strategic Bets on Future AI Breakthroughs
The final 20% is reserved for bets on future model capabilities—features that do not work at all today and depend on gains no one can guarantee. This is the exploratory edge of the portfolio: work on what models might eventually do, built ahead of any demonstrated capability. Doshi's own framing, that you want to build features that "aren't necessarily always working today," applies most fully here.
The value of this bucket is optionality. If a future model gain makes a bet viable, the team that built for it ships first; the team that waited starts late. The 20% cap keeps the exposure bounded—these are bets, and Doshi's language treats them as such. Combined with the near-future bucket, this means 40% of build effort looks forward in some form, but only 20% of it is truly speculative. That proportion lets teams explore breakthrough potential without betting the product on capabilities that may never materialize.
Strategic Rationale: Why a Balanced Approach is Crucial
The rationale behind the split is risk mitigation in a fast-moving landscape. As BigGo Finance reported from the conversation, a product wrapped rigidly around one model version risks being stranded as models improve. The 60/20/20 rule is the countermeasure: by spreading effort across current, near-term, and speculative capabilities, a team ensures that no single model transition—or failure to transition—leaves the product obsolete. The same reporting notes Doshi's broader strategic context: Google's real answer to the frontier race is breadth across the cost-quality curve rather than a single smartest chatbot, a posture consistent with the portfolio thinking the rule embodies.
The framework also reflects where Doshi believes product value now sits. The reporting highlights her view that taste and model intuition have become the scarce product-manager inputs—judgment about which capabilities to build around matters more when the underlying model improves on its own. Her concrete example of disciplined evaluation reinforces this: Google replaced a six-tone Fitzpatrick skin-tone scale, originally built for healthcare and skewed toward lighter tones, with the ten-tone Monk scale developed through anthropological and sociological research, improving representation in products including the Pixel camera and image generation. The lesson for the 60/20/20 rule is that building ahead of models requires rigorous ways of defining and measuring "good," not just optimism about capability curves.
Google's 60/20/20 AI Product Allocation Model
Use the table below as a diagnostic: classify each initiative on your roadmap by its dependency on current versus future model capability, then compare the resulting distribution against Doshi's recommended split.
| Allocation | Focus | Strategic Goal |
|---|---|---|
| 60% — Works now | Features fully functional with today's AI models; the prototype is at least functional | Deliver immediate user value and keep a stable, shippable product core |
| 20% — Nearly works | Features that are almost working, awaiting modest near-term model improvement | Prepare for imminent advancements without over-committing effort that cannot yet ship |
| 20% — Future bets | Speculative bets on future model capabilities that do not work yet | Explore breakthrough potential and avoid being stranded by rapid AI evolution |
To apply it, ask of each roadmap item: does this work reliably with the models available today? If yes, it belongs in the 60%. If it works inconsistently or partially—close enough to see the path—it belongs in the first 20%. If it depends on capabilities no current model demonstrates, it is a future bet. Sum the effort in each bucket and compare: a team with 90% in "works now" is optimizing for the present and may be stranded by the next model release; a team with half its effort in speculative bets has abandoned its functional core. The framework's diagnostic boundary is the ratio itself, not any single feature's merit.
Applying the 60/20/20 Rule: A Path to Sustainable AI Product Growth
Product leaders should regularly review their resource allocation, ensuring a strategic balance of 60% on current model features, 20% on near-future capabilities, and 20% on long-term AI bets. The review's output is concrete: a product roadmap that clearly delineates features into the three 60/20/20 categories, with corresponding resource commitments. Teams that maintain that delineation keep shipping value to users today while holding positioned work for the capabilities that arrive next—and when the next model improvement lands, the measurable test is whether the near-working 20% can move into the shippable core without starting from zero.
Sources
- Why PMs are suddenly valuable again — Apple Podcasts
- Google's Gemini product chief Tulsee Doshi says model behavior is UX, and… — BigGo Finance
