Key Takeaways

  • Tulsee Doshi, Head of Product for Google's frontier AI models, argues standard MVP playbooks fail because base model capabilities shift every few months.
  • Complex prompt logic built to patch current model weaknesses quickly turns into technical debt when base weights update.
  • Teams should track their own internal proxies and look for glimmers of light rather than relying on public benchmarks.
  • Doshi compares frontier model work to Severus Snape's potions class, where intuition and experimentation matter as much as rigid recipes.
  • Product teams should balance roadmaps using the 60-20-20 AI Product Development Rule.

The 60-20-20 AI Product Development Rule

Standard startup doctrine says build an MVP that works smoothly end to end. If a feature fails or hallucinates, you cut it. Doshi argues that playbook backfires when building on foundation models. If you only ship what works perfectly today, your product freezes in time while base models advance.

“Traditional startup wisdom. You're just like build an MVP that works,” (play from 0:41) Doshi says. “But I think you want to actually build features that aren't necessarily always working today.” (play from 0:45)

Doshi structures roadmaps into three tiers:

  • 60% Functional Core: Build 60% of the product so that it works reliably right now and ensures your prototype or product is fundamentally functional today.
  • 20% Near-Term Trajectory: Dedicate 20% to features where the model is not perfect today but works well enough, where you can clearly anticipate the model will reach sufficient quality in the near future.
  • 20% Frontier Aspirations: Reserve 20% for ambitious features where the model currently only shows glimmers of light, betting that if you can crack the experience as models advance, it creates a magical product unlock.

The mistake Doshi spots is engineering heavy scaffolding around current model flaws:

“I think one thing we've also seen with customers sometimes is like they've built a very rigid system around for example where the model was and now the model has gotten so much better,” (play from 35:52) Doshi explains. “So how do you go from where the model was to like being adaptable to kind of consist continuing to iterate it.” (play from 36:02)

When new checkpoints arrive, that rigid scaffolding turns into dead weight. “And I think if you build in that way, you are building a product that works today, but you're setting yourself up to build a magical product experience as the models become better and also to grow as the models grow too.” (play from 34:30)

To spot the aspirational 20%, Doshi tests for vibe proxies over public leaderboards: “I think using more of your own proxies of like where is my product? Where do I see glimmers of light? Where do I see it? Kind of bridging that gap I think is a more concrete way to hopefully like ask that same question.” (play from 35:05)

When This Works (and When It Doesn't)

This framework fits product managers building AI-native applications who need to ship real utility without capping their product at current model limitations. It lets founders design interfaces that easily absorb future model upgrades.

It fails in zero-tolerance domains. If you build tax filing, medical dosing, or automated compliance tools, speculative outputs ruin user trust and invite legal liability. It also fails if your startup has under six months of runway. Waiting for frontier labs to solve your reliability problems will kill you before the update lands.

What to Do With This

Split your team sprint backlog into these three tiers on Monday:

1. Put 60% of engineering hours into reliable utility. For a customer support tool, that means deterministic ticket tagging and draft answers for standard documentation questions.

2. Put 20% into near-term bets like multi-step ticket resolution. Keep a human in the loop to review actions today, knowing upcoming model weights will raise accuracy.

3. Put 20% into frontier bets like autonomous bug reproduction from user chat logs. Keep the code lightweight. When new frontier weights drop, retest the raw model before writing any defensive workaround logic.