Key Takeaways

  • Tara Seshan recommends that AI product teams plan only two to three months ahead instead of writing multi-year roadmaps.
  • Building solely for current model limits guarantees obsolescence, while predicting capabilities years out is historically inaccurate.
  • Seshan maintains a personal document of her own failed tech predictions to counter long-term forecasting bias.
  • Stable enterprise markets like payments at Stripe allow for long-range planning, but frontier model companies require a dynamic planning cadence.

The Failure of Multi-Year Roadmaps in AI

Most product leaders learned their craft in environments where the underlying technology stayed relatively still. In enterprise software or fintech, databases got cheaper and APIs became cleaner, but the core mechanics rarely mutated overnight. Product managers could plan twelve, eighteen, or twenty-four months into the future with reasonable confidence that their software would still matter when it shipped.

At the Lenny and Friends Summit, OpenAI product leader Tara Seshan explained why that playbook fails completely when building on frontier models. The pace of model capability shifts makes long-range roadmaps counterproductive. Teams that plan out a two-year vision end up building complex scaffolding around problems that the next model update solves natively in three months.

Seshan keeps herself honest about long-range forecasts with a simple personal practice: “I have a personal dock of incorrectly predicted things that I thought were going to happen and didn't happen, just to remind myself of my inability to predict the future years out. At the same time, if you build exactly for today you're going to get left behind.”

The 60-to-90-Day Window

The real challenge in AI product development is avoiding two equal and opposite failure modes. The first trap is anchoring to today's exact model constraints, which leads teams to build narrow workarounds that collapse the moment a new model drops. The second trap is designing for a distant science-fiction future that current software cannot reliably execute.

Seshan points to a narrow middle ground between these two mistakes. “Probably most importantly in this era is this aiming for 2 to 3 months of where the models will be rather than being overly anchored in the present or being overly futuristic and unusable,” Seshan said. “To me it's like the ideal is two to three months. You can't be too big-brained and be like this is the future in years because I think that inevitably our predictions of that are almost always wrong.”

A sixty to ninety-day horizon allows engineering and product teams to anticipate immediate model jumps without hallucinating future capabilities. It gives teams enough runway to test features, build evals, and ship working software without over-engineering for an unpredictable future.

Why Market Dynamics Dictate Planning Cadence

This shortened planning horizon is not universal across all tech sectors. The right roadmap length depends directly on how fast the underlying platform is moving. Seshan contrasted her current work at OpenAI with established enterprise companies.

“Stripe's business is very different than OpenAI's business,” Seshan noted. “The dynamics of the payments market look largely similar to how they looked before.” When building payment infrastructure, stability, uptime, and multi-year compliance matter far more than rapid reaction to weekly model releases.

Founders must match their planning rhythm to the rate of change in their foundational tech stack. “Understanding given the pace and the dynamics of that market at what cadence should I be thinking and planning in the future,” Seshan explained. If you build on top of frontier AI, your planning cycle belongs in weeks and quarters, not years.

What to Do With This

Audit your active product backlog this week and flag any feature scheduled more than ninety days out that exists only to patch a current model limitation. If a planned engineering project takes six months to build a custom prompt routing workflow that next quarter's frontier model might solve out of the box, kill the ticket or reduce the scope to a two-week prototype.