TL;DR
The short version
When the tools move this fast, a product leader's edge collapses to two durable things — a sharp hypothesis and the ambition to aim the tools higher. Everything else is being automated.
On Lenny's Podcast, OpenAI's Tara Seshan — product lead for Codex and ChatGPT's "work" mode — laid out three eras of AI products (chat, agents, persistent coworkers) and, more usefully, which parts of the job survive the ride.
Built on Tara Seshan's conversation with Lenny Rachitsky on Lenny's Podcast.
Three eras: chat, agents, then coworkers you steer
Seshan frames AI products in three eras. The first was chat. The second is agents that do work — mostly coding, so far. The third, arriving now, is a persistent co-worker you collaborate with like a teammate.
Her metaphor for the shift is steering versus rowing. Agents do the rowing — the tactical execution. The human moves up the abstraction ladder to steering: pointing the ship, then correcting course with each new piece of data. The steering keeps rising — from a line of code, to a goal, to something higher still — but someone still has to decide which direction the ship points.
If you think about the first era of AI products as chat, the second era of these products working with agents, that third era that might come soon is how do you work with a persistent co-worker who is able to get things done with you.
Tara Seshan, OpenAI
The strategy doc is dead weight. The hypothesis isn't.
Seshan spent six years at Stripe, a famously academic, writing-heavy culture. At OpenAI she had to unlearn it. In a market this emergent, the long reasoning doc — "almost like a PhD thesis of what I think should be the plan" — is a liability. Being prolific and empirical beats being academic and theoretical.
What survives is narrower and older than any of the trappings: isolating the one hypothesis that decides whether the product works, then testing it fast. The specs, the timelines, the presentations — most of that has "fallen away." The hypothesis-and-test loop is now the whole job, and not just for PMs. Engineers, designers, and data scientists have all converged on it.
Build for the model two to three months out
The hardest calibration in the role is timing. Seshan's rule: build for where the models will be in two to three months. Too early and you've bet on capability that isn't there. Too anchored to the last model and you've built a museum piece.
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. The only way to build is two to three months.
Tara Seshan, OpenAI
The only way to stay in that window is to stay tied to research — knowing what the model is about to get good at, and getting your product constructs out of its way.
When everything is easy, ambition is the constraint
When the easy work becomes trivially easy, the thing that separates people is how ambitious they let themselves be. Seshan's most effective colleagues don't use AI to automate rote tasks — they use it to widen the set of things they can attempt at all. The old "unicorn" who could design, engineer, and PM at once is now a capability anyone can spin up.
So a new part of the PM job is elevating other people's ambition. When someone says "we can ship this by that date," the move is to ask whether the ceiling is actually much higher. Two internal OpenAI refrains capture it: "Is this maximally accelerated?" and "Are you mainlining it yet?" — meaning, are you using the product all day, every day, to do your own work.
Automate the reporting, never the thinking
Seshan draws a hard line through her own writing. Writing as reporting — status updates, launch summaries — she automates freely. Writing as thinking she never will: "I start myself and I end myself. I might use AI in the middle" to pull data or push back on ideas.
The tell has flipped, too. A long document used to prove you'd thought something through. Now it proves nothing — a model can produce a polished doc that hides the absence of thought. So she's moved to "mocks not docs": a prototype, or an A/B result, communicates conviction better than prose.
This is also where the human stays load-bearing. Coding is output-verifiable — you run the tests. Knowledge work isn't; you have to inspect the process, the inputs, the citations to trust the result.
