Manufactured Dogfooding
Invent internal reasons for every function to live in your product — quality follows hours logged.
- Difficulty
- Easy
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 91%
Yamashita's core answer for why Figma ships consistently high-quality software is not a process — it is hours. The more time internal people spend inside the product, the better it naturally becomes, because they fix their own friction to make their own day better rather than waiting for someone to file a bug. The trick is that most functions have no natural reason to use the product, so you must creatively manufacture one. Its companion mechanism is personal accountability: builders who have personally witnessed a user struggling fix things with a different quality of urgency.
Origin
Yamashita developed the personal-accountability half at Uber, where employees took Ubers to work and engineers on the driver app would see a driver struggling in person. He built the manufactured half at Figma, deliberately converting internal culture and rituals into Figma/FigJam usage on arrival.
Core principles
- 01Quality is a function of internal hours in the product, not of quality metrics.
- 02People improve what makes their own day worse — that motivation beats a top-down quality initiative.
- 03An engineer who has seen the problem fixes it out of embarrassment; an engineer handed a bug ticket does not.
- 04If a function has no natural reason to use your product, invent one.
- 05As you grow into segments unlike yourself, dogfooding stops covering you — and you must notice.
How to run it
- 1
Audit which internal functions actually use the product
Designers may live in it six hours a day, but PMs, HR, and leadership likely have no reason to touch it. Those are the gaps.
- 2
Rewrite a company ritual so it runs inside your product
Change the medium of an existing internal practice so it forces product usage. Yamashita moved Figma from a memo culture to a deck culture explicitly because decks get built in Figma.
Pro tip Look for rituals with the widest internal blast radius — planning docs, reviews, performance calibrations, interview debriefs.
Watch out Everyone moves memo-ward these days; the point is not the format's merit but the second-order usage it creates.
- 3
Ship internal templates through the functions that own the ritual
Build a great template for the ritual and distribute it through the owning function so adoption is automatic rather than voluntary.
Pro tip Figma's head of design co-built a performance-calibration template that HR distributed — instantly giving every manager a reason to be in FigJam.
- 4
Engineer direct exposure between builders and users
Increase the number of interaction points where the people building the product personally witness someone using it, so they feel a personal relationship with the end user.
Pro tip At Uber, everyone rode Ubers; an engineer on the driver app who watched a driver struggle felt embarrassed and personally accountable for the fix.
- 5
Flag where dogfooding stops covering you
When you start building features for organizations unlike your own, internal testing no longer validates them. Get explicitly creative about how you measure effectiveness for those users instead of assuming the old muscle works.
Watch out This is the failure mode Figma hit on branching-and-merging: they didn't use it much themselves, so gaps went undetected.
In the wild
One of the first things Yamashita did on arriving at Figma was push the company from a memo culture to a deck culture — the opposite direction of the industry trend — for the specific reason that decks get built in Figma.
→ The act of building decks internally forced PMs and others to encounter product issues themselves and get familiar with the tool; later, performance calibrations and interview debriefs moved into FigJam too, which came to dominate internal usage.
Figma built branching and merging for complex design systems — a workflow customers explicitly asked for and a very large investment. Adoption was weak. Causes included performance, the unfamiliarity of the workflow, and gaps Figma had not noticed because they did not use it much internally themselves.
→ Yamashita concluded that as Figma builds for organizations unlike itself, the strong internal-testing culture no longer guarantees quality — and new measurement muscles are needed.
Common mistakes
Assuming a top-down quality metric will find the problems
Defining a quality-experience metric and driving initiatives against it misses the thousand small frictions that only someone living in the product every day would notice and fix on their own.
Trusting dogfooding for segments unlike you
Internal testing only validates workflows your company actually performs. Enterprise or specialist features built by a company that doesn't use them will ship with invisible gaps.
Is it for you?
Best for
Product leaders at companies whose own employees could plausibly use the product but mostly don't — especially horizontal tools and collaboration software.
Not ideal for
Products your employees genuinely cannot use (clinical devices, industrial equipment, tools for a profession nobody internally practices), where forcing usage is theater.
From the transcript
“even for PM's like one of the first things I did when when I arrived was we're a little bit more of a memo culture…”
“that's the biggest thing the more hours people are spending inside your product internally I think it just naturally becomes better”
“the degree of motivation is so different if that engineer has somehow experienced a problem in some way”
“if someone building feels like they have some kind of personal relationship with the the end user”
From the episode
An inside look at how Figma builds product
Yuhki Yamashita (CPO of Figma)