Skip to content

PM on the AI Exponential

Exponential AI model improvement breaks traditional product management assumptions. Features designed around current limitations become over-engineered when the next model ships.

Why the exponential matters

Traditional PM assumes constraints stay stable through a project lifecycle. AI capabilities do not. METR benchmarks show Claude 3.5 Sonnet (October 2024) completed software tasks needing about 21 minutes of human work. Claude Opus 4.6 (February 2026) handles tasks of about 12 hours -- roughly 35x in 16 months (METR time horizons, Time Horizon 1.1).

Features designed around today's token limits, reasoning gaps, or tool limits may be obsolete by ship date. The response is four workflow shifts (Wu, product management on the AI exponential).

graph TD
    A[Long roadmaps] -->|replace with| B[Short sprints + side quests]
    C[Documentation-first] -->|replace with| D[Prototype-first demos]
    E[Ship and forget] -->|replace with| F[Revisit each model release]
    G[Clever workarounds] -->|replace with| H[Simplest thing that works]

Short sprints and side quests

Replace long roadmaps with short planning cycles. Model improvement makes multi-quarter plans unreliable -- constraints you designed around can vanish mid-project.

Side quests are afternoon experiments outside official deliverables. At Anthropic, they produced Claude Code Desktop, the AskUserQuestion tool, and todo lists (Wu, product management on the AI exponential). Failed experiments are cheap. Multi-month plans built on stale assumptions are expensive.

This maps to AI-assisted development. Prompt strategies, agent configurations, and context engineering tuned for one model generation may need rethinking when the next ships.

Prototype-first over documentation

Demo-driven development replaces documentation-heavy planning. Build a prototype in hours, put it in front of users, and let engagement decide what gets polished.

Bihan Jiang (Director of Product, Decagon): "Claude has raised the ceiling on what good product teams can build, and dramatically shortened the distance between idea and prototype" (Wu, product management on the AI exponential).

Failed prototypes cost an afternoon. Failed multi-week spec cycles cost alignment and momentum. When AI generates a working proof-of-concept from a plain-language description, the fastest path to validation is building.

Product blurring follows. Designers ship code, engineers make product decisions, and PMs build prototypes and evals (Wu, product management on the AI exponential).

Revisit features each model release

New capabilities may improve features built under previous constraints. Every model release is a prompt to re-evaluate existing implementations.

Claude Code with Chrome emerged this way. Teams were manually switching between browser and terminal. When models caught up, the manual pattern became a built-in feature (Wu, product management on the AI exponential).

The practice is simple. Use your AI tools daily and deliberately ask them to do things you think are too hard. When they succeed, that is a signal the product needs to catch up.

Kai Xin Tai (Senior PM, Datadog) recommends studying "strengths and failure modes through offline evaluation" and designing "tight feedback loops" to surface when weaknesses disappear (Wu, product management on the AI exponential).

Simplicity-first implementation

Avoid building clever workarounds for current model limits. Those workarounds become needless complexity -- and possibly shadow tech debt -- when the next model removes the limit.

Anthropic's early todo list needed system-prompt reminders to check task completion. Newer models removed this hack entirely (Wu, product management on the AI exponential).

When you build agent workflows, prompt chains, or context strategies, prefer the simplest approach that works. Simpler implementations adapt more easily when capabilities leap. Optimize for capability first, using more tokens than you think you need, then optimize for cost once validated.

This intersects with comprehension debt. Simpler implementations are easier to debug and replace. Complex workarounds compound both technical and comprehension debt.

When this backfires

These shifts assume the organization tolerates rapid reprioritization. Some conditions undercut them:

  • Coordination overhead: short sprints work for small teams. Multi-team orgs with shared roadmaps cannot drop quarterly commitments because a model shipped, and the realignment cost may exceed the benefit.
  • Prototypes promoted to production: prototype-first breaks when time pressure turns a proof-of-concept into production without architectural review.
  • Revisit fatigue: re-evaluating features each release creates prioritization instability. Teams with large legacy surfaces cannot afford to audit them each cycle.
  • Simplicity misapplied: "simplest thing that works" defers necessary complexity rather than removing it. Some edge cases need complex handling whatever the model can do.

These shifts are most reliable for small, fast-moving teams building AI-native products.

Key Takeaways

  • Exponential model improvement (35x in 16 months per METR) makes multi-quarter feature plans unreliable
  • Side quests -- afternoon experiments -- validate assumptions cheaply and have produced real shipping features
  • Prototype-first workflows make failed bets economical; failed specifications waste alignment and momentum
  • Every model release is a signal to revisit existing features and remove workarounds that are no longer necessary
  • The simplest implementation that works adapts most easily to the next capability jump
Established — multiple independent sources Last reviewed: 2026-06-13
Feedback