
What is dogfooding and why we (too) often skip it
“Dogfooding,” or “eating your own dog food,” means using your own product or service as if you were a customer.
In software, it’s a litmus test: you expose flaws, friction, usability issues early in the process.
Some companies do it formally (internal versions, staff as test users); some do it informally (product teams forced to use the app in daily work).

But many skip it (or do it occasionally). Why?
1. It’s hard. You have to feel user pain.
2. Bias creeps in (you rationalize “that’s fine, users will manage”).
3. It costs time and culture change.
4. In some products, your team may not be the right “kind” of user (limits of applicability).
Still, the upside is huge.

Uber’s extreme dogfooding as a leadership signal
I recently listened to an episode of Lenny's podcast where Uber’s CPO described a ritual: he personally takes 700+ Uber rides and deliveries every few weeks. He screenshots every friction, every delay, every confusing UI prompt, then writes reports, tags teams, follows fixes to closure.
It struck me: that’s extreme dogfooding in action. He’s not just saying “use the product ourselves” he’s embedding in the user’s journey, feeling the bumps, discomfort, and surprise moments.
That anecdote from Uber’s CPO, Sachin Kansal, is a perfect example of dogfooding as leadership, not just engineering hygiene.
He doesn’t delegate “take a ride once in a while” he personally does 700+ rides. I was amazed when I first heard that. 700+ rides is insane!!! He screenshots every friction … tags owners and follows fixes to closure.”
He captures friction in the real world, writes 40+ page reports, tags owners, follows up with them to ensure they get fixed, and bakes “fix-its” into OKRs.
His “ship, ship, ship” mindset pushes fast cycles and relentless iteration. The goal isn’t perfection upfront, it’s iteration, learning, and adaptation.
This isn’t just symbolic. When leaders dogfood, they send a message: “I’m not asking you to do something I haven’t done.” Show, don’t tell. The rest of the org sees this is nonnegotiable.
So dogfooding isn’t optional, especially for people who lead products. It’s a mechanism for empathy, accountability, and institutional humility.
Dogfooding as part of the onboarding process
When I first joined Filestage (a B2B review & feedback platform for creative files like PDF, videos, images), they had a quirky onboarding task: take a photo of your desk and upload it for feedback.
At first glance, it feels playful but it’s brilliant dogfooding. Why:
They forced me to use the platform immediately, in my real environment.
I saw (and felt) friction: was the upload UI clear? Did cropping / orientation work? Did previewing the image feel buggy?
I experienced the feedback loop: how quickly did reviewers reply? Did the comments feel intuitive?
I became a user in my first hour. That made me care about the experience.
Because of that, I remember details in FileStage’s UX that many long-time employees don’t. I’ve flagged pain points even before noticing them in customer sessions.
More broadly, this small test teaches a few lessons:
Start dogfooding early: onboarding is often your best chance to force internal use.
Use lightweight tasks: you don’t need a full-scale dogfooding program out of the gates; even small forced tasks expose gaps.
Make internal feedback real: don’t let internal use be a checkbox. Act on the feedback you collect.
My Bumble experiments: why I dogfood beyond work
This is where I get a little personal but I think it illustrates the mindset shift I want to encourage.
I’m in a relationship, but I still build profiles on dating apps both male and female.
Yeah, I know. Technically that’s against the rules. But hey, sometimes breaking a small rule is the only way to understand the bigger picture.
My girlfriend nearly lost her mind when she saw the screenshots.
“Why do you have 500 matches?”
“Because I’m her, honey. It’s for research.” 👀
Why?
As a male user, I see what works, what’s confusing, what feels gamified.
As a “female profile,” I see how the volume of attention (too many likes, too much noise) changes interaction dynamics.
Suddenly, I can empathize with a user drowning in notifications, overwhelmed by choice, unsure how to act.
From these sessions, I get ideas: “What if we throttle notifications? What if the UI helps surface balance? What if we design for overload rather than scarcity?”
If I relied only on second-hand feedback (e.g. “women tell me they get overwhelmed”), I’d miss why - what's the flow, what's the micro-friction. But when I live it, I feel it.
So yes, dogfood beyond work. For me, it’s part of the creative research process.

Empathy, empathy, empathy
I’ve seen people spend years on a product and still not know how the core flows actually work.
How does that even happen?
Because they never use it end to end.
They stay in their lane, I’m dev, I’m support, I’m marketing and never cross over to see what the real experience feels like.
They don’t see what a user sees.
They don’t feel what a user feels.
It’s not because they don’t care. It’s because empathy fades quietly. You stop being curious. You stop asking “why does this feel this way?” You stop playing with the thing you’re building.
And that’s dangerous!
Because when empathy fades, assumptions take over.
Sales promises features that don’t quite exist.
PMs prioritize based on Jira tickets instead of real friction.
Designers tweak pixels without ever feeling the pain behind them.
Here’s the thing: it's very hard to understand a runner if you’ve never run.
You can analyze the data, look at their heart rate, pace, calories but until you’re out there, lungs burning, shoes soaked, and the app suddenly pauses mid-run, you don’t feel it. You don’t feel the frustration of losing your rhythm because of a notification that shouldn’t have popped up.
And you can’t understand a patient on the phone with their insurer unless you’ve been there sick, anxious, and trying to explain your situation to a chatbot that keeps looping you back to the same menu. When you’re in that state, clarity matters. Tone matters. Every word matters.
Dogfooding brings that empathy back.
It forces you to walk through the whole journey, not just the part you own.
To see the cracks that users trip over every day.
And to remember that every one of those cracks is a person’s frustration, not just a bug.

Okay so how do I dogfood?
It's simple. Here’s how:
Start fresh. Create an actual account. Go through a real flow. Report a problem. Try different features. Try unsubscribing. Try reporting an issue.
Don’t just click around actually live it.
See where you get stuck.
Notice the copy that feels off, the buttons that don’t do what you expect, the moments where you think “wait, what now?”
Document those friction points and share them with your team.
Bonus points: record yourself using the tool.
If it’s a desktop product, use Loom. If it’s mobile, turn on screen recording Apple makes it ridiculously easy (there’s probably something similar on Android, I wouldn’t know… sorry Google).
Talk out loud while you use it.
Describe what feels confusing, what makes sense, what annoys you.
Then share that recording with your product team.
You’ll be surprised how powerful it is to see and hear real frustration instead of reading it in a Jira ticket.
It’s raw, it’s honest, and it’s the fastest way to make everyone care.
Pick one core flow you rarely use and complete it as a “normal user.”
Find three pain points. Track whether they ever get fixed.
Then take it a step further.
Run a dogfooding week everyone in the company uses the product as if they were a customer.
Designers, devs, marketers, finance. Everyone.
No dashboards, no shortcuts.
Just real experience.
It’s amazing how quickly empathy builds when you’re the one trying to cancel a subscription at 11 p.m. on a Friday.