Dogfooding Isn't Optional
If you're managing the product but you're not in the product, you're flying blind with a nice dashboard.
It's easy to stop using the thing you're building.
Not on purpose. You just get busy. You're in Jira, Figma, Slack, Looker, Amplitude, Google Docs and seventeen browser tabs you swear you'll close later. The actual product becomes something you look at in a demo or pull up when a stakeholder asks a question. You're managing the product but you're not in the product.
It's like being a raid leader who hasn't logged in since the last expansion. You can read the patch notes. You can study the DPS charts. But when the team wipes on a boss mechanic, you're not going to know why because you haven't felt the fight.
The gap
I've worked with PMs on mobile games who didn't really game. Smart people. Good with data. But when the team debated whether a progression loop felt rewarding or punishing.. they didn't have an instinct to draw from. They had a chart. And charts don't feel things.
I've seen the same thing with consumer apps. A PM who knew the funnel inside out but hadn't gone through the onboarding flow as a real user in months. The data said it was fine. The experience said otherwise. But nobody in the room had the experience to push back on the data.
This isn't a character flaw. It's a workflow problem. The daily work pulls you away from the product and toward everything around the product. You end up knowing more about the Jira board than the thing the Jira board is supposed to improve.
How it happens
Data tells you what happened. It doesn't tell you what it felt like.
A funnel might say 40% of users drop off at step three. Okay. But why? Was it confusing? Was it slow? Did it feel like the app forgot what they just did? The dashboard can't answer that. It can only point at the number and shrug.
Customer feedback is better but still filtered. People report what bothered them enough to say something. They don't report the ten small moments of friction they absorbed before giving up. The weird load time they waited through. The screen that didn't feel right but they couldn't explain why. The moment where they thought "this is kind of annoying" and then just.. moved on.
Users have the patience of someone trying to cancel Comcast. They'll sit through an unreasonable amount of friction before they finally give up. And when they do quit, they don't leave a note.
You only catch that stuff by living in it.
What gets missed
The friction nobody files a ticket about. That's the big one.
Users are weirdly tolerant. They'll work around broken things for months before saying anything. They'll develop habits to avoid the parts of your product that don't work well. They'll close the app and reopen it because that's faster than navigating back. None of that shows up in a support ticket. It shows up in behavior.. if you're looking. And you're only looking if you've felt it yourself.
There's also the emotional layer. Data can tell you a feature is being used. It can't tell you whether it feels good to use. Going back to the games example.. data might say session time is up. But is that because players are engaged or because they're stuck grinding through something that isn't fun? Those look the same in a chart. They feel completely different in the game. One is flow state. The other is "why am I still doing this."
PostHog's team put it well: it's easy to deprioritize a "small UX bug" when you have big strategic features to ship. But those small bugs compound. Like tech debt but for the experience itself. And the only way to feel the compound effect is to use the thing regularly. Not as a quarterly audit. As a habit.
What changes when you're in it
You start catching things before they become tickets. Something feels off and you go look at the data to confirm.. instead of waiting for the data to surface it three weeks from now.
You develop opinions. Real ones. Not "the data suggests" opinions but "I tried this and it's annoying" opinions. Those opinions make you sharper in every conversation because you're not just interpreting numbers. You have a point of view grounded in something you actually experienced. Suddenly you're the person in the room who can say "yeah I hit that bug on Tuesday, here's what actually happens" instead of "let me pull up the ticket."
The order of operations flips. Instead of "what does the data say" as the starting point, it becomes "does this feel right" and then checking the data to confirm or challenge that instinct. That's a better way to work.
Microsoft figured this out in 1988 when Paul Maritz sent an email literally titled "Eating our own Dogfood" pushing the company to use its own products internally. Simple idea: if we won't use it, why should anyone else? Decades later and it's still a discipline most teams have to actively protect. You'd think it would be obvious by now. It is. People just forget.
Making it stick
The pushback is always "when am I supposed to do this." Fair. You're already buried in sprint planning, stakeholder updates and twelve fires that weren't on the roadmap.
Here's what works for me: block two hours on Tuesday (optional) and Friday (mandatory) every week to use the product. Not review the product. Use it. Go through flows. Try the thing you shipped last week. Hit the edge cases your users are hitting. Be a person using the app, not a PM auditing it.
Take notes while you're doing it. Not formal notes. Just what felt off, what surprised you, what took longer than it should have. Then connect the dots for your users. That friction you felt on Tuesday might explain the drop-off you've been staring at in Amplitude for two weeks.
This isn't extra work on top of prioritization. It makes prioritization better. You stop guessing which issues matter because you've felt which ones matter. Two hours a week is a small investment for the kind of instinct that takes months to build from dashboards alone.
If you're ever out of things to test on your own app, use that time to test competitors or similar products. The muscle is the same. You're training yourself to notice what works, what doesn't and why. Think of it like scrimmaging against another team. You're not switching sides. You're getting sharper for your own game.
The point
Data is essential. Feedback is essential. But they're the check, not the baseline.
Your own experience is the baseline. It's what gives you instinct, context and the ability to feel when something is off before anyone reports it.
Without it you're interpreting a product through numbers that only tell part of the story.
Open the app. Play the game. Go through the flow. Buy something. Break something. Get confused by something.
That's not extra credit. That's the job.