ExpertsFMAI’s third era: the rise of persistent AI coworkers | Tara Seshan (Product Lead ChatGPT Work)
Lenny's Podcast: Product | Career | Growth · August 30, 2026
5 Selected Lessons:
heuristic · 4 framework · 1
DRI-over-title role fluidity
Source
Lenny's Podcast: Product | Career | Growth — AI’s third era: the rise of persistent AI coworkers | Tara Seshan (Product Lead ChatGPT Work) (August 30, 2026) · at 42:20 ▸
When this applies
when tools erode traditional functional boundaries within a team
The takeaway
Replace role-based task ownership with outcome-based accountability (a single Directly Responsible Individual) once tooling flattens functional skill gaps.
Why it works
When capability barriers between roles disappear, assigning work by job title becomes arbitrary; what matters is that someone is accountable for the outcome (quality, usage, effectiveness), regardless of who executes which task.
One level up
Structure organizations around outcomes and accountability, using role boundaries only as a convenience, not a constraint.
Where it stops holding
This stops working when deep specialized craft is still the actual bottleneck (e.g., highly regulated domains, or when individuals lose motivation/skill development without clear role identity), per Tara's own unresolved question about craft erosion.
Detail
procedure:
- Designate one accountable owner (DRI) for whether the product is used, wanted, high quality, and effective
- Let anyone pick up any task based on affinity/capability rather than title
- Accept that individual craft mastery in a narrow domain may get traded for broader fluid contribution
rationale: 'Everything and nothing is your responsibility... someone is the DRI' captures the core operating principle Tara has always favored at startups, now increasingly enabled by AI leveling capability.
In their words
The thing I really care about is that someone needs to look after the or have core accountability for is this product being used by users? Is it something that people want? Is it high quality? Is it effective? And whether that person is like an engineer or a designer or a PM or whomever, like someone is the DRI.
The two-to-three-month build horizon
Source
Lenny's Podcast: Product | Career | Growth — AI’s third era: the rise of persistent AI coworkers | Tara Seshan (Product Lead ChatGPT Work) (August 30, 2026) · at 0:00 ▸ · at 26:48 ▸
When this applies
when building on top of a fast-moving underlying technology whose capability keeps shifting
The takeaway
Pick a forecast horizon short enough to be reasoned about concretely but long enough to not be obsolete on arrival, and anchor product design to that specific point.
Why it works
Building for current capability wastes the upside of imminent improvements; building for capability a year out produces something unusable today because the gap is unpredictable and too large to design against confidently.
One level up
In exponentially changing environments, calibrate your planning horizon to the rate of change itself rather than using a fixed planning cadence borrowed from stable markets.
Where it stops holding
This stops working when the underlying technology's improvement rate is slow or predictable, where longer-horizon planning (grand strategy) becomes viable and even necessary.
Detail
rule: Design products for where the model will be in two to three months, not where it is now or where it will be in a year.
threshold: 2-3 months
rationale: Both building for current capability and building a year ahead are 'equally wrong'; the only viable horizon in a fast-emergent market is 2-3 months, validated by tight communication with research roadmaps.
In their words
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. Only way to build is two to three months.
Human creativity/opinion as the differentiator when tools are commoditized
Source
Lenny's Podcast: Product | Career | Growth — AI’s third era: the rise of persistent AI coworkers | Tara Seshan (Product Lead ChatGPT Work) (August 30, 2026) · at 13:20 ▸ · at 20:05 ▸
When this applies
when a powerful capability becomes universally accessible and ceases to be a competitive moat
The takeaway
When capability becomes commoditized, competitive advantage shifts to the human judgment layer: taste, authorship, and point of view.
Why it works
When tool access converges across competitors, differentiation must come from something tools can't commoditize — human taste, opinion, and artistic statement in what is chosen to be built.
One level up
Durable advantage lives wherever commoditization cannot reach — usually human authorship and distinctive intent, not raw capability.
Where it stops holding
This stops working when taste itself becomes replicable or quantifiable by the tools, or when the product category truly is just a commodity utility with no room for differentiation through opinion.
Detail
rule: Treat your product like an auteur's film, not a real-estate investment: opinionated artistry, not capability access, determines success when everyone has the same tools.
rationale: Software is 'not like real estate... it is a little bit more like filmmaking' — money/capability in doesn't guarantee good/successful outcome; the human statement does.
In their words
If everybody has access to the same tools, the thing that will separate you is this, is the huge, is human, the person, basically.
Writing-as-thinking vs. writing-as-reporting split
Source
Lenny's Podcast: Product | Career | Growth — AI’s third era: the rise of persistent AI coworkers | Tara Seshan (Product Lead ChatGPT Work) (August 30, 2026) · at 52:41 ▸ · at 58:08 ▸
When this applies
when deciding what parts of a cognitive task to delegate to an AI tool
The takeaway
Delegate tasks whose value is purely transmissive (reporting known facts), but keep ownership of tasks whose value lies in the generative friction of doing them yourself (thinking through a novel idea).
Why it works
The physical act of outlining, drafting, cutting, and editing prose is itself the mechanism by which ideas get clarified and strengthened; outsourcing that step removes the clarifying friction, while status-reporting has no such clarifying function and is pure transcription.
One level up
Identify which parts of a process are the actual mechanism of value creation before deciding what to automate — automate the packaging, not the cognition.
Where it stops holding
This stops working when a person's judgment and synthesis ability has already matured enough that first-draft generation by AI doesn't impair their ability to critique/improve it — i.e., for highly practiced writers the boundary may shift.
Detail
rule: Automate writing-as-reporting (status updates, summaries) with AI; never automate writing-as-thinking (new ideas, strategy, persuasive briefs) — start and end those drafts yourself.
rationale: Both the blanket 'never use AI for writing' and 'always use AI for writing' positions are wrong; the right boundary is the function of the writing, not writing as a monolithic category.
In their words
I really strongly believe that I do two types of writing at work. One is writing as thinking, and the other is writing as reporting
70% doc rule for collaborative buy-in
Source
Lenny's Podcast: Product | Career | Growth — AI’s third era: the rise of persistent AI coworkers | Tara Seshan (Product Lead ChatGPT Work) (August 30, 2026) · at 55:53 ▸
When this applies
when seeking collaborative feedback or alignment on any proposal
The takeaway
Share work at a deliberately incomplete stage to invite collaborative improvement rather than waiting for perfection, which actually suppresses input.
Why it works
A polished, finished-looking artifact signals 'closed,' discouraging others from engaging deeply, whereas a visibly unfinished artifact invites people to contribute and feel ownership, producing both better content and more buy-in.
One level up
The state in which you present work shapes how much others will invest in improving and endorsing it — visible incompleteness is a design choice, not a flaw.
Where it stops holding
This stops working when stakeholders need a fully vetted, authoritative document (e.g., legal/compliance review) where incompleteness would be read as unreadiness or risk.
Detail
rule: Write a doc to about 70% completion, then bring it to the people whose buy-in you need and co-develop it to 100% together.
threshold: ~70% completion before sharing
rationale: Very few great people want to interact with a perfectly polished idea; their new ideas bounce off it, whereas a doc with 'crags and rough edges' invites them to polish alongside you.
In their words
I previously had a manager who told me that the right thing to do is write a doc to 70% completion and then take it to the people that you need buy-in from and get it from 70% to 100%.