Context

Tara Seshan leads product for both Codex and ChatGPT Work at OpenAI, arguably the fastest-growing AI product for knowledge workers right now. Before OpenAI she spent six years at Stripe as one of its first five PMs, led product at Watershed, was a founder, a Thiel Fellow, and an entrepreneur-in-residence at Sutter Hill Ventures (the firm behind Snowflake). In this conversation with Lenny Rachitsky she describes how product management actually changes inside a frontier AI lab: what falls away, what becomes more important, and what stays human. The through-line is practical for any PM, not just those at AI labs: how to build when the ground under your product moves every few weeks.

The Big Idea

AI products are moving through three eras: chat, then agents that do tasks for you, and now persistent AI "coworkers" you steer alongside human teammates. Your job shifts from doing the work (rowing) to steering agents at ever-higher levels of abstraction, which makes human judgment, taste, and ambition the real differentiators, not the tools themselves.

Seshan's frame: era one was chat, era two is agents (so far mostly coding), and the emerging era three is a persistent teammate that works with you and other people collaboratively. As agents absorb more of the execution, what separates people is the quality of their steering.

Key Insights

Build for two to three months out

Seshan's sharpest rule for building on fast-moving models: you fail if you build for where the models are today, and you fail if you build for where you think they will be in a year. Both are equally wrong.

• Why: build for today and you bake in the current model's limits, which vanish almost immediately. Build for a year out and you are too early, shipping something the model cannot yet support.
• How they do it: they aim for roughly two to three months ahead, and stay in very tight contact with the research team about what capabilities are being pushed (better coding, better writing, and so on), so product bets track the actual model roadmap rather than guesses.
• The mindset: "get out of the way of the model." Treat model capability as the center of the product, and avoid product constructs that will look like scaffolding once the model improves.

The PM core survives, trappings fall away

So much changes in this environment, but Seshan argues the essential PM job is unchanged and now more important than ever: define the single most essential question about your product, test it, read the results, and feed them back into a sharper hypothesis.

• What falls away: running execution on a schedule, writing long spec docs and presentations, the "trappings" of the role.
• What remains central: pulling together an understanding of users, the market, and the technology into the sharpest possible hypothesis, then testing it fast. She invokes Shishir Mehrotra's "Eigen question": the one specific most important thing to test. Everything else, including elaborate "grand strategy" documents, is not relevant.
• Why now: engineers, EMs, data scientists, and designers have all converged on this same problem-definition-and-testing loop, which is exactly the loop PMs have always owned.

Be prolific and empirical, not academic

Coming from Stripe (a rigorous, writing-heavy, "reason from first principles" culture), Seshan found the biggest adjustment was moving from theoretical to empirical.

• Static markets reward rigor: in an established market like payments, you can reason carefully through every next move, and winners out-think everyone. Sloppy thinking shows up as carelessness because the outcomes were predictable.
• Dynamic markets reward trying: in AI the future is too emergent to reason out in a long "PhD thesis" doc. What matters is getting to something you can test with users as fast as possible. The rigor moves into being as pointed as possible about your core hypothesis, not into a longer plan.

Steering will keep climbing abstraction

Seshan describes the future of work as "more steering than rowing." Agents do the rowing; you point the ship. Crucially, the level of steering keeps rising: from "I wrote this line of code, press tab," up to directing at the goal level, and higher still.

• Why it matters for PMs: as agents take on larger loops of work, your value concentrates in the opinionated call, deciding which direction to push, not because the alternative is unviable, but because you want the product to be a certain way. That intuition and "positive determinism" about the future is what stays with a person, at least for now.
• Multiplayer steering: she expects work to become a "multiplayer game" where several people steer a shared group of agents together, which is the third-era coworker model in practice.

Ambition becomes the differentiator

When the easy things are trivially easy for everyone, the thing that separates people is how ambitious they are willing to be.

• The pattern: the most effective people do not just automate rote tasks with AI, they use it to expand the set of things they can personally do. The old "unicorn" (great product sense plus engineer plus designer) is now within more people's reach, so you can realize more of what is in your head at higher fidelity, like an auteur.
• The PM angle: a huge part of the modern PM role is elevating others' ambitions, reminding the team the ceiling is far higher. When someone proposes a modest version or timeline, ask whether the possibility ceiling is meaningfully higher, or whether it could be done faster or at 10x scale (a nod to Tyler Cowen's point that people underrate asking this).
• The hard part: the capabilities have expanded faster than our imagination. The real work is expanding your thinking of what is now possible in an unreasonably short timeframe, and simply remembering to try (Patrick Collison's list of fast, ambitious projects is her reference point).

Knowledge work needs visible reasoning

One of the most product-relevant insights: coding and knowledge work are fundamentally different, which changes how you build the product.

• Coding is output-verifiable: you can run tests and see if the code works, so you can trust the end output without watching every step.
• Knowledge work is not: you cannot just look at a finished deck, see "90% success," and believe it. You have to trust the process, the inputs, and the reasoning that produced it.
• The product implication: for knowledge work, the model has to be a visible collaborator. Show in-progress work, citations, inputs, and chain of thought so the user goes on the journey and can trust the result. The threaded, output-first UI that suits coding is not automatically right for knowledge work.

Conviction beats polish now

A direct reversal from Seshan's pre-AI experience. Previously, polish was king: if every UI corner was not perfect, you might as well not ship, because time did not change the outcome much. Now, when you have real conviction that something is transformative, getting it into users' hands early beats perfect. The urgency of introducing the product matters more than finishing every detail, and you iterate quickly on real feedback (ideally pre-launch, but post-launch is fine too). "Done is better than perfect," then keep going.

Mental Models & Frameworks

The three eras of AI products

A map for where AI products are heading, useful for deciding what to build toward:

• Era one, chat: question and answer with a model.
• Era two, agents: the model does tasks for you, so far mostly coding agents, and increasingly at higher levels of abstraction.
• Era three, persistent coworkers: an agent that persists like a teammate, does a batch of work, takes your input, and continues, syncing at different cadences, and eventually collaborating with multiple humans and agents together.

Use it to place your own product and ask what the next era demands of it.

Writing as thinking vs writing as reporting

Seshan splits work writing in two and treats them oppositely:

• Writing as reporting (status updates, launch plans, summaries): automate it heavily with the model.
• Writing as thinking (a brief arguing for a product or strategy, a spicy take): never automate it. The act of outlining, turning it into prose, cutting, and iterating is how she actually forms and sharpens ideas. She starts and ends the writing herself, and only uses the model in the middle for research, pulling data, or pushing back on ideas.

The broad-brush positions ("I never use AI to write" or "I always do") are both wrong; the distinction is what matters.

Product marketing fit before product-market fit

Her biggest takeaway from Sutter Hill and Mike Speiser: the narrative and positioning of a product are testable before you build it, and often should be tested first.

• How: go pitch 100 people, refine the pitch and the marketing narrative of why the thing is transformative, and only then commit to the exact product shape.
• Why it matters: she had previously underrated product marketing as "the glue between functions." Done excellently, the positioning can be the element that makes a company succeed. It also reframes PMF itself: Sutter Hill treats finding product-market fit as a repeatable playbook, not a dark art or luck.

The three product-development memes

OpenAI's internal shorthand for how to build, worth borrowing as a checklist:

• "Is this maximally accelerated?" Are we moving as fast as possible?
• "Are you mainlining it yet?" Are you using the product all day, every day, to get your own work done? (Her framing of dogfooding.)
• "Are we being as ambitious as possible?" Is the scope and scale of what we are attempting high enough?

Decision Principles

Principle: Remove user decisions, not add options

• When: your product has accumulated overlapping modes or toggles (their example: ChatGPT vs Codex, and a Chat vs Work toggle).
• Why: the North Star is that users should not have to choose between products or understand internal concepts like "harnesses." Ideally they state a task and the system picks the right model and harness. Meet people where they are on familiarity, then decomplexify so the default is the right thing, rather than pushing the choice onto the user.

Principle: Prototype or result over document

• When: you need buy-in for a direction.
• Why: a long document no longer signals that you thought something through, because anyone can generate a long document. Something people can try, or better, an A/B result showing what happened, is a stronger communication tool than the doc itself. Seshan still writes many docs, but now for her own thinking, not as the artifact she shares.

Trade-offs & Nuance

Speed and conviction vs polish

Shipping early on conviction beats perfect polish in this era, but it is a real trade-off, not a free lunch. It works when you have genuine conviction the product is transformative and can iterate fast on live feedback. It is still on the team to make the product usable and to listen to the right signals; "done is better than perfect" is a reason to start, not an excuse to stop improving.

Fluid roles vs craft depth

Seshan loves that boundaries between engineer, designer, and PM are dissolving, with someone simply accountable (a DRI) for whether the product is used, wanted, and high quality. The honest tension: when models abstract away parts of your craft (like an engineer hand-writing code), you gain range but may lose the depth and flow of your specialty. She does not claim a clean answer, only that your craft shifts from doing a specific task to applying that judgment elsewhere.

Practical Application

Anchor product bets to the model roadmap

• Do: for any AI feature, explicitly decide what model capability you are betting will exist in two to three months, and check that assumption directly with whoever knows the model roadmap.
• Why it works: it avoids the twin failure modes of building for today's limits (obsolete on arrival) or a year out (too early to work). Design the product to get out of the model's way as it improves.

Protect your thinking, automate your reporting

Separate your own writing into thinking versus reporting. Hand reporting (status, summaries, plans) to the model. Do the thinking writing yourself, start to finish, using AI only mid-way for research or to attack your ideas. Seshan's discipline: if you will make people read a document, invest at least as much time writing it as they will collectively spend reading it, which also guards against your own reasoning atrophying.

Share at 70%, not 100%

Take a brief to about 70% completion, then bring it to the people whose buy-in you need and get it from 70% to 100% together. A perfectly polished idea makes new ideas bounce off it; something with rough edges invites collaborators to shape it with you. Aim for prototypes or real results as the shareable artifact rather than a finished doc.

Test the narrative before building

Before committing to a product's exact shape, pitch the story to many prospective users and refine the positioning until the "why this is transformative" lands. Treat product marketing as a first-class, early test, not an afterthought, because a sharp narrative can be what makes the product succeed.

Questions to Consider

• For our current AI feature, what specific model capability are we betting will exist in two to three months, and have we checked that against the actual model roadmap rather than guessing?
• What is the single most essential question (the one hypothesis) that determines whether our product works, and are we testing that as fast as possible instead of writing longer strategy docs?
• Where are we still adding user-facing options or toggles when the better move is to remove the decision and pick the right default for them automatically?
• In our product, does the user need to trust the process (like knowledge work) rather than just the output (like code), and if so, are we exposing the reasoning, inputs, and citations they need to trust it?
• Which parts of our own writing are "thinking" that we should never hand to a model, versus "reporting" we should automate, and are we accidentally outsourcing the thinking?

Bottom Line

As AI moves from chat to agents to persistent coworkers, the PM's job shifts from doing the work to steering agents, which makes human judgment, taste, and ambition the scarce inputs. Build for where the model will be in two to three months, keep the one essential hypothesis at the center, protect the writing you do to think, and remember that when everyone has the same tools, the human deciding what to build is the differentiator.

Concepts to Explore

Software as filmmaking, not real estate

Seshan (citing the Collison brothers) argues software is not like real estate, where you put money in and get value out. It is more like filmmaking: a big budget does not guarantee a good film. There is authorship, opinionation, and artistry, which is why the human "auteur" behind a product still matters even as tools get more powerful. Worth sitting with when thinking about what makes your product distinctive versus a generic build.

The capability overhang

The gap between what AI can already do and what people actually do with it. Seshan's point is that the binding constraint is now human imagination, not model capability: the hardest part is expanding your thinking of what is possible and simply remembering to try. Naming this gap helps a team deliberately hunt for uses they are not yet attempting.

Notable Quotes

"You fail if you build for where the models are now. You fail if you build for where you think the models will be in a year. Both outcomes are equally wrong. The only way to build is two to three months." (Tara Seshan)

"The future of work will look more like steering than rowing." (Tara Seshan)