ExpertsFMThe design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)
Lenny's Podcast: Product | Career | Growth · March 1, 2026
5 Selected Lessons:
framework · 3 reasoning_pattern · 1 case · 1
Time-allocation shift from mocking to execution-pairing
Source
Lenny's Podcast: Product | Career | Growth — The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude) (March 1, 2026) · at 0:00 ▸ · at 6:32 ▸ · at 15:47 ▸
When this applies
when a downstream execution function (engineering, production, fulfillment) speeds up so much that the upstream planning function's old deliverables become stale before they're used
The takeaway
When execution speed increases faster than your planning speed, shift your time from producing final artifacts to real-time guidance during execution.
Why it works
If execution outpaces planning, time spent perfecting a static artifact is wasted because the artifact will be outdated by the time it's used; redirecting that time into live collaboration during execution preserves influence.
One level up
Re-allocate effort toward whatever phase of a process has become the bottleneck or point of leverage, not toward the phase you were trained to own.
Where it stops holding
This stops working when execution tools are slow or unreliable enough that detailed upfront planning still prevents costly rework.
Detail
procedure:
- Notice that engineers using multiple parallel coding agents can ship a scrappy version of any idea almost immediately.
- Stop trying to produce comprehensive mocks before implementation starts.
- Reallocate time: previously ~60-70% mocking/prototyping, ~20% consulting, ~10% coordination.
- Now: ~30-40% mocking, ~30-40% pairing/jamming directly with engineers, remaining time on implementation/polish in code.
benchmarks: {"old_mocking_pct":"60-70%","new_mocking_pct":"30-40%"}
rationale: Locking a design early blocks fast iterative engineering; better to let engineers 'cook' and guide afterward.
In their words
But now I feel the mocking up part of it is 30 to 40 percent. You're better off not locking that, letting them cook.
Vision horizon compression (years to months)
Source
Lenny's Podcast: Product | Career | Growth — The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude) (March 1, 2026) · at 6:32 ▸
When this applies
when setting any long-range strategic plan in a domain where the underlying technology or market is changing unpredictably quarter to quarter
The takeaway
Shrink your planning horizon to match the volatility of the layer beneath you, and replace polished long-range artifacts with lightweight directional prototypes.
Why it works
Long-range plans assume stable underlying capabilities; when the capability layer itself is shifting every few months, a multi-year vision becomes fiction rather than guidance.
One level up
Match the fidelity and timescale of your plans to the actual rate of change in your environment, not to organizational tradition.
Where it stops holding
This stops working when the underlying technology/market is actually stable, where long-range vision documents still provide real coordination value.
Detail
procedure:
- Recognize you cannot predict the model/product landscape years out.
- Create a 3-6 month directional vision instead of a 2-10 year one.
- Replace the polished vision deck with a prototype that points teams in a direction.
- Use this to keep many independent teams/agents moving coherently rather than randomly.
rationale: A shared directional prototype keeps distributed, fast-shipping teams efficient and coordinated even without long-term certainty.
In their words
It usually becomes a vision that's like three to six months out and isn't necessarily something that is like creating this like beautiful deck that's like beautifully storytold. It's sometimes just like creating a prototype that points people in the right direction.
Building trust through speed on early/rough releases
Source
Lenny's Podcast: Product | Career | Growth — The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude) (March 1, 2026) · at 24:19 ▸
When this applies
when shipping any imperfect early version of a product and needing users to tolerate its roughness
The takeaway
When you ship something unfinished, trust is maintained by the speed and visibility of iteration, not by the initial quality level.
Why it works
Users will forgive known flaws if they see rapid, visible, responsive iteration; what destroys trust is not imperfection but silence/stagnation after launch.
One level up
Trust is a function of the trajectory you demonstrate over time, not the snapshot you launch with.
Where it stops holding
This stops working when teams lack the capacity or commitment to keep iterating visibly after launch — shipping early then going silent actively degrades the brand.
Detail
procedure:
- Label the release honestly as early/a research preview and caveat known flaws.
- Ship because the benefits outweigh the current rough edges.
- Commit publicly to taking feedback and iterating quickly and visibly (e.g., tweeting fixes within a day).
- Never let a rough launch sit unaddressed — that is what destroys brand trust.
rationale: The way that you really lose trust around quality and releasing something early is if you release it early and then nothing ever happens.
In their words
The way I've heard you describe this is building trust through speed. Yeah, for sure.
Judgment/accountability as the durable human role even as AI absorbs execution
Source
Lenny's Podcast: Product | Career | Growth — The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude) (March 1, 2026) · at 27:36 ▸
When this applies
when assessing which parts of any job will remain human-owned as AI absorbs more of the technical execution
The takeaway
As AI absorbs technical execution, the remaining human value concentrates in accountability for decisions and resolving disagreements between stakeholders, not in raw taste or craft.
Why it works
AI can present options and data, but disputes between people about what should be built, and the liability for a decision, require someone to be accountable — a social/organizational function, not a technical one.
One level up
Look for the parts of a job that are inherently social/accountability-based, not purely informational — those are the slowest to be automated.
Where it stops holding
This stops working if AI itself becomes a legally/organizationally accepted bearer of accountability, or if disputes become fully resolvable by data alone.
Detail
approach: Separate 'can AI generate good options' from 'can AI own the decision and its consequences.'
signals:
- Disagreements between stakeholders about what should ship, which AI can inform but not settle.
- Need for someone accountable if an outcome is wrong, analogous to a radiologist signing off on an AI's read.
rationale: Someone still needs to be accountable for the decision, the same way an engineer is accountable for whether AI-written code actually works.
In their words
At the end of the day, someone has to decide what is actually going to get built and what actually matters
Using an AI agent to mine personal notes for self-knowledge and decision rubrics
Source
Lenny's Podcast: Product | Career | Growth — The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude) (March 1, 2026) · at 1:13:24 ▸
When this applies
when a person has years of unstructured personal records (notes, journals, meeting logs) and wants to extract implicit patterns or criteria they've never explicitly articulated
The takeaway
Feed years of your own unstructured personal records to an AI agent specifically to surface implicit criteria or self-knowledge you've been applying but never articulated.
Why it works
A long-running agent can read a large unstructured personal corpus and surface implicit patterns (recurring criteria, values) that the person has been applying but never stated explicitly, because humans are bad at introspecting on long accumulated history unaided.
One level up
AI's comparative advantage over humans can be less 'generating new ideas' and more 'synthesizing a person's own scattered past output into legible patterns.'
Where it stops holding
This stops working when the personal records are too sparse or inconsistent to contain a real underlying pattern, producing a fabricated or generic-sounding rubric instead of a genuine one.
Detail
situation: Jenny wanted to articulate what she personally looks for in design craft, something she and many others struggle to state explicitly, and had years of relevant unstructured notes.
decision: She had Cowork read through her interview notes and craft-related memos and asked it to produce a memo/rubric for assessing craft in interviews.
outcome: It produced a usable rubric and surfaced things about her own implicit standards that she 'wouldn't have realized' otherwise.
lesson: Long-running AI agents are well suited to introspective synthesis tasks on a person's own accumulated, unstructured records.
In their words
I just had it read through all of my notes, both like interview notes and other things that I cared about and memos and stuff like that I've written the past. And then it made me this rubric for evaluating that.