The Extreme Dog-Fooding Loop
Use your own product at scale, document every flaw with screenshots, then personally drive the fixes to closure.
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 4
- Confidence
- 95%
A closed-loop discipline for leaders to feel their product the way real users do, then convert that felt experience into shipped fixes. The differentiator is not just using the product but the follow-through: writing detailed reports, tagging the owners, and staying on the fixes until they ship. Kansal has personally done 700-800 driver/courier trips and writes up to 40-page reports on what's broken.
Origin
Sachin Kansal, Chief Product Officer at Uber, developed this over 8+ years personally driving and delivering on the Uber platform. 'Dog fooding' is a widely-used industry term; Kansal's contribution is taking it to an operationalized extreme with mandatory documentation and follow-through.
Core principles
- 01Using the product is the easy, fun part; documenting and fixing is the painful part that creates impact
- 02A leader dog-fooding, not just individual PMs, sets the cultural norm
- 03Screenshots and tagged owners turn anecdotes into accountable action items
- 04Follow-through is what separates impact from doing it 'just for fun'
- 05The felt emotion (joy or outrage) is a motivator you carry back to the team
How to run it
- 1
Schedule real usage at real volume
Set aside half a day or a full day, once or twice a month, to actually do the hardest version of the job — drive rides, deliver food, carry the groceries up the stairs. Kansal does 10-12 rides/deliveries per outing.
Pro tip Ride as a passenger daily too — you get a 30-minute one-on-one interview with a driver and can watch how they actually use the app in context.
- 2
Capture evidence in the moment
Take a lot of screenshots as issues surface, because it's very easy to do the session and then forget the details or only use them anecdotally in a conversation later.
Watch out Anecdotal recall without evidence produces vague feedback that can't be prioritized or acted on.
- 3
Write it up in a living document
Maintain a standing document per surface (driver doc, rider doc, Uber Eats doc). After each session, add everything you learned that is not ideal, attach the screenshots, and tag the specific people who own each area.
Pro tip Keep one document per product surface and append to it over time so patterns and recurring issues become visible.
- 4
Prioritize, then personally follow through to the fix
Route issues into the normal prioritization process (not everything you flagged is actually a good idea), then stay on the ones that matter until they ship — develop 'positive impatience' calibrated to severity.
Pro tip Calibrate impatience to severity: a flaw you hit in 10 trips has hit millions of drivers, so escalate proportionally.
Watch out If you flag issues but neither you nor your team follows up, it becomes a moot point and you were just doing it for fun, not impact.
In the wild
On his fifth or sixth-ever drive, ~8 years ago, Kansal picked up a woman at 7am heading to San Jose airport. She got in the car leaving her suitcase on the curb, silently expecting him to get out, load it, and open the trunk. He hadn't internalized that unspoken part of the job.
→ A 'somber' ride that built lasting empathy — he says he has never since forgotten what it feels like to be a driver, and he uses that emotion to demand his team build with that empathy.
Features that looked great on a MacBook or Zoom screen in the office turned out to make no sense once the phone was mounted 3 feet away in a car moving at 45 mph. The physical context completely changed the design.
→ Surfacing this only-felt-in-context failure justified reworking features that had passed office review, feeding the internal fix pipeline.
Common mistakes
Dog-fooding without documentation
Doing the sessions but only recalling issues anecdotally means nothing gets prioritized or fixed; the learning evaporates. The screenshots-and-write-up step is what makes it actionable.
Flagging issues but not following through
Kansal is explicit that if you report problems and no one follows up to fix them, 'then it's a moot point' — you did it for fun, not impact. The leader must stay accountable to closure.
Is it for you?
Best for
Product leaders and PMs at companies whose product they can personally experience, who want to build genuine end-user empathy and a fix-it culture
Not ideal for
Leaders who will collect feedback but not commit organizational resources to closing the loop — it becomes theater
From the transcript
“I take a lot of screenshots and then I come back and I write documents”
“I have a driver document. I have a rider app document. I have an Uber Eats document.”
“I will tag people because I know who works on what and then I'll just send people my thoughts on what we think we can…”
“but I do follow through on the things that I reported and make sure that things that should be fixed get fixed”
“So I develop a bit of an impatience that we have to fix it.”
From the episode
Why Uber’s CPO delivers food on weekends
Sachin Kansal