ExpertsFMWhat happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams)
Lenny's Podcast: Product | Career | Growth · June 21, 2026
5 Selected Lessons:
heuristic · 3 case · 1 reasoning_pattern · 1
Verification burden scales with role-blurring
Source
Lenny's Podcast: Product | Career | Growth — What happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams) (June 21, 2026) · at 1:00:07 ▸
When this applies
when a previously specialized task becomes accessible to many more roles via automation
The takeaway
When automation lets non-specialists perform specialist tasks, the organization must invest proportionally more in automated verification to replace the confidence that specialization used to provide.
Why it works
As more disciplines contribute directly (because AI lowers the skill barrier), the aggregate confidence in output quality can't rely on each contributor's specialized training, so verification infrastructure (automated checks, specs) must absorb what used to be guaranteed by role specialization.
One level up
Removing a skill bottleneck shifts risk downstream to verification; plan the verification investment before, or alongside, removing the bottleneck.
Where it stops holding
This stops working when verification itself can't be automated for a given domain (e.g., nuanced design judgment), leaving a residual need for expert review regardless of role-blurring.
Detail
approach: Recognize that role-blurring from AI access increases the surface area needing verification, and invest more in automating verification across those adjacent workflows (design, data science, etc.).
signals:
- non-engineers checking in code
- multiple disciplines all contributing to the same surface
rationale: PMs are no longer bottlenecked by engineering bandwidth, but confidence in their output now depends on better automated verification.
In their words
I also think we need to do more to keep automating these other portions of the workflows. For sure we focus a lot on coding, but next when you think about like design or data science, like those are starting to be the next areas I think are good opportunities for us.
High agency paired with high accountability
Source
Lenny's Podcast: Product | Career | Growth — What happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams) (June 21, 2026) · at 0:00 ▸ · at 34:40 ▸
When this applies
when you grant any team broad autonomy to pursue initiative in a fast-changing environment
The takeaway
Freedom to act must be matched one-to-one with ownership of the outcome, or autonomy degrades into unaccountable motion.
Why it works
Autonomy without an explicit hypothesis and ownership for outcomes leads to unaccounted drift; pairing freedom with a stated hypothesis keeps initiative aimed at results.
One level up
Decentralize decision rights only alongside decentralized responsibility for results.
Where it stops holding
This stops working when people are given agency but no clear hypothesis or success criteria, turning freedom into aimless activity.
Detail
rule: Give people freedom to cook, but require a stated hypothesis and accept accountability for the outcome.
threshold: Every initiative should come with an explicit hypothesis of what it's trying to solve.
rationale: Without accountability, high agency becomes directionless; without agency, accountability becomes micromanagement.
In their words
We say with high agency is also high accountability. So it's all about making sure folks have that freedom to cook. But then it's also like, okay, what's the accountability for it? What's the hypothesis of what you're trying to solve?
Measure outcomes, not activity — don't forsake motion for progress
Source
Lenny's Podcast: Product | Career | Growth — What happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams) (June 21, 2026) · at 39:38 ▸
When this applies
when choosing a productivity or usage metric for any team under pressure to show activity
The takeaway
Continually ask whether your chosen metric is still serving the outcome you actually care about, and be willing to change it.
Why it works
Metrics like lines-of-code or tool usage measure action taken, not whether that action advances the actual goal; a metric that was once a good proxy can stop correlating with outcome as conditions change.
One level up
Any proxy metric decays in validity as the environment changes; treat metrics as provisional, not fixed truth.
Where it stops holding
This stops working when there is no reliable proxy at all available and you must rely on qualitative judgment, or when changing metrics too often prevents any stable tracking over time.
Detail
rule: Focus on whether output is driving the intended outcome; revisit and adjust metrics as the landscape changes.
threshold: If a region has low 'number of sellers' but items are being successfully found (because of power sellers), don't gate expansion on the wrong metric.
rationale: Early Facebook Marketplace used 'number of sellers' as an expansion gate, which would have blocked a region that was actually succeeding via power sellers; the team fixed the metric instead of blindly following it.
In their words
really don't forsake motion for progress because if you're measuring like, you know, like tool user usage, then you're measuring the action, but is it really making whatever the end outcome of yours like important?
Managers must be part-time ICs ('player-coach')
Source
Lenny's Podcast: Product | Career | Growth — What happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams) (June 21, 2026) · at 48:21 ▸ · at 52:54 ▸ · at 1:03:45 ▸
When this applies
when a leader risks losing touch with the actual work their team does, especially amid rapid tool/process change
The takeaway
A leader's credibility and decision quality depend on firsthand, continued contact with the actual work, not just dashboards.
Why it works
Giving new managers IC time before full people-management responsibility lets them build deep product/codebase fluency and rapport without the competing burden of supporting others, and continuing to ship PRs as a leader keeps them 'in the flow' so their judgment about the product stays grounded.
One level up
Authority without direct contact with the work erodes judgment over time; stay a practitioner, not just an overseer.
Where it stops holding
This stops working when the organization is too large or the manager's domain too far from any hands-on contribution to be meaningful, or when IC time trades off critically needed people-management bandwidth.
Detail
rule: Every manager starts as an IC and continues to do some IC work part-time even after taking on management duties.
threshold: Give new managers time (e.g., a quarter) to learn codebase/product before layering on full people support responsibilities.
rationale: New-team feedback showed appreciation when leaders are also hands-on; it also builds rapport and prevents leaders from losing touch.
In their words
I actually think as a leader, if you actually start as IC first without the worry of supporting people
Cowork's small-business bundle emerged from noticing latent demand
Source
Lenny's Podcast: Product | Career | Growth — What happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams) (June 21, 2026) · at 25:22 ▸ · at 27:53 ▸ · at 31:48 ▸
When this applies
when a product's incidental use by an unexpected audience reveals an underserved need
The takeaway
Treat your own delight with a tool as a signal to test with an adjacent underserved audience, then let their actual usage (not your assumptions) define the resulting product.
Why it works
Fiona personally felt relief using Cowork for a disliked task (expensing), recognized the same pain was common among small business owner friends operating on thin margins, and onboarding them surfaced further unplanned use cases and bugs, which led to a dedicated bundle ('Claude for Small Business').
One level up
Latent demand is discovered by watching what people do with a product beyond its intended use, not by asking what they want.
Where it stops holding
This stops working when the adjacent audience's workflow is too different for the tool's core capability to transfer, or when personal anecdote isn't validated at scale before investing.
Detail
situation: Fiona disliked business expensing but found Cowork made it effortless; she knew small-business-owner friends struggled with the same low-margin administrative burden.
decision: She onboarded several small businesses directly, watching them use Cowork in unexpected ways (e.g., finding lost menus, market-rate pricing analysis).
outcome: This led to the launch of Claude for Small Business, bundling plugins that business owners previously had to search for individually.
lesson: Personal delight + awareness of an adjacent audience's pain point + direct observation of real usage can surface a new product line.
In their words
I thought, if Claude Cowork is so good at helping me do my little business travel expense, this would be huge for it.