LLenny's Podcast
← All frameworks
LeadershipFiona Fung (Manager of the Claude Code and Cowork Teams)

Leader Dogfooding for Product Pulse

Live and breathe your product as a real user (or meet customers) and trust the anecdote over the dashboard.

Difficulty
Easy
Time to result
~ongoing to results
Steps
4
Confidence
86%

Fiona Fung's signature practice is relentless dogfooding: leaders should use the product they build every day to keep a real pulse on the intended experience, because living only in metrics and dashboards loses touch with how the product actually feels. When you can't use the product yourself, meet customers instead. She trusts specific anecdotes and edge-case repros as much as aggregate data — often they reveal growth blockers the data hides.

Origin

Fiona Fung, a practice rooted in her Visual Studio editor team ('use the VS editor to build the VS editor'); she invokes Jeff Bezos's line to trust the anecdote over the data when they conflict.

Core principles

  • 01Use the product every day to keep a pulse on the experience you're trying to enable
  • 02Dashboards and presentations alone cause leaders to lose touch with the product
  • 03When you can't use the product, meet customers to get the same signal
  • 04A vivid anecdote or edge-case repro can outweigh aggregate data

How to run it

  1. 1

    Use the product daily as a real user

    Personally use what your team builds every day — even small PRs or manual testing — to keep the touch-and-feel of the experience.

    Pro tip Ask the AI to help you design a manual test plan that covers the cases, which also rebuilds your confidence to ship.

  2. 2

    If you can't dogfood, meet customers

    When it's genuinely hard for you to use the product, substitute regular customer visits as the channel for direct signal.

  3. 3

    Mine your own edge cases

    Pay attention to the weird failures your particular usage surfaces — they can become reliable repros the team couldn't otherwise get.

  4. 4

    Weight the anecdote against the data

    When a specific anecdote conflicts with the aggregate metric, take the anecdote seriously rather than dismissing it.

    Watch out Don't get too lost in metrics, dashboards, and presentations at the expense of lived product experience.

In the wild

Slow LTE in Chile

When Facebook Marketplace underperformed in Chile, a three-person research trip bought local Android phones. On landing, Fiona saw the LTE connection was far slower than in the US and the Marketplace feed barely loaded — a growth blocker invisible in aggregate data.

The hands-on anecdote surfaced a concrete load-time growth blocker that the regional metrics alone had not explained.

Common mistakes

Leading only through metrics and presentations

Relying on dashboards and decks without using the product makes a leader lose the touch-and-feel for the experience they're supposed to be improving.

Dismissing anecdotes in favor of the data

When data and a vivid anecdote conflict, ignoring the anecdote (per Bezos, trust the anecdote) can hide real problems like a device- or network-specific growth blocker.

Is it for you?

Best for

Product and engineering leaders who want to stay connected to the real user experience as their teams scale

Not ideal for

Cases where a single anecdote is treated as proof without any corroboration, risking overreaction to noise

From the transcript

even me doing PRs it's less about what it is I'm fixing, it's more about me

51:00

if you're leading a team where it's really hard for you to use the product, then meet with customers.

1:07:00

I think it was Jeff Bezos that said if you have the data and you have an anecdote, trust the anecdote over the

1:08:00

the LTE connection was real was much slower than what we were used to in the US.

1:08:00

From the episode

What happens after coding is solved?

Fiona Fung (Manager of the Claude Code and Cowork Teams)