Stop planning for 2027: how OpenAI builds product 90 days at a time | Tara Sesha and Nan Yu (OpenAI)

The conversation opens with a deliberately imperfect interface choice: a toggle separating two modes of an AI product. Tara Sesha describes changing her instincts from polishing everything in advance to putting a useful capability in users’ hands and learning from actual use.

That is not a quality-free shipping rule. Her checks include whether the product adds something genuinely useful, whether colleagues keep using an internal release and whether it reveals a valuable new use case. She offers no fixed retention threshold. Nan Yu adds that users can accept change more readily when they can follow a coherent story about where the product is going.

Sesha repeatedly returns to a two-to-three-month horizon for building on rapidly changing models. Building only for today can leave a product behind; making detailed assumptions years out can create a different kind of error. She even keeps a record of predictions that did not come true.

The title’s 90-day idea needs that context. The speakers explicitly contrast AI with payments, where some market dynamics may remain more stable and longer planning may be appropriate. They are describing judgment under a particular pace of change, not banning annual planning for every business or announcing a guaranteed future model capability.

Yu sees a major constraint in people’s ability to understand and absorb what a product offers. A model can possess useful capabilities that users never discover or learn to apply. Shipping more functions alone does not close that gap.

Sesha describes the opposite pressure too: enterprise customers can feel overwhelmed by change, yet delaying a meaningful new capability may leave them without value they need. The tension cannot be settled by assuming every requested slowdown is wrong. It requires a product that helps users form a useful mental model while actually delivering the new workflow.

The moderator asks whether users should work with one general agent or many specialized identities. Yu starts from the burden of managing many simultaneous threads: people may naturally bundle activity behind a coordinating interface.

Sesha grounds the design in specific use cases. Does an action use the person’s credentials or a service account? What memory can an agent carry into a private channel? How does the interface make those differences understandable? A single friendly identity does not remove these architectural choices, and multiple named agents do not solve them automatically.

The platform discussion separates native functions, hooks for applications and fallback interactions such as computer use. The goal is to compose layers around the user’s task rather than treat every feature as belonging exclusively inside or outside one product.

Yu emphasizes the frustration of an agent that finishes almost everything but cannot complete the final step. Computer use is attractive in this account because it may bridge missing integrations, even at higher latency or token cost. The interview’s enthusiastic language about it always working is not a measured reliability guarantee; completion still has to be checked.

Sesha says working with research required a different approach from working with engineering. A useful contribution starts with a precise user goal, reading the actual session and identifying where the model failed to achieve the intended outcome.

She describes learning to write evaluations and showing cases where prompts or skills already elicit a desired behavior, so that post-training colleagues can investigate making that capability more native. The interview does not promise that every demonstrated workflow can simply be trained in. It explains why detailed evidence is more actionable than an abstract feature wish.

The speakers retain familiar product skills: user empathy, systems thinking and careful attention to details. They add a faster empirical loop. Yu argues that onboarding matters more when users face an intelligent system and an empty input box without knowing what to do next.

Sesha emphasizes privacy, data use and understandable product norms. Semi-autonomous behavior makes it especially important that a user can anticipate what may happen. Direct contact helps, but useful feedback often arrives only after follow-up questions about the precise output and surrounding context, rather than the first broad complaint.

At the end, Sesha highlights voice as a more natural interaction path, while Yu imagines products gently guiding their own use instead of leaving people with an empty box. The moderator adds a hardware prediction.

These are their recorded expectations about future experiences, not announced delivery dates or evidence that the predictions succeeded. They return to the same product question: how can improving capabilities become something a person understands and can actually use?