Key takeaways
- QA checks if it works, dogfooding checks if insiders like it, user research checks if real users can actually use it.
- Your team knows too much to represent your users — dogfooding is a gut-check, not research.
- AI can speed up QA and simulate feedback, but it can't replace the team learning from watching real people.
- Sequence all three: continuous QA, dogfooding during development, user research at key decision points.
- Users increasingly attribute a mind to AI interfaces — perceived empathy is now a design dial you must observe, not assume.
Every product team wants to believe it understands its users. The uncomfortable reality is that most of what teams call "testing" measures something else entirely: whether the product works, whether it breaks, or whether the people who built it happen to like it. Those are all worth knowing. None of them tells you what a real user, with a real goal and zero context, will actually do.
Dogfooding, QA, and user research get lumped together as "quality checks," but they answer fundamentally different questions. Confusing them is one of the most expensive mistakes we see teams make — they run one, feel reassured, and skip the others. Here's how to keep them straight and use each where it delivers the most value.
Three methods, three different truths
The clearest way to think about this is by what each method can and cannot see.
- QA answers: does it work as specified? QA verifies the product against requirements. It catches broken flows, edge cases, regressions, and things that simply don't function. QA is essential and non-negotiable — but a product can pass every test and still confuse everyone who touches it.
- Dogfooding answers: does it work for people who already know it? When your team uses its own product internally, you surface friction that specs never captured. That's genuinely useful for catching rough edges early. The catch is decisive: your team knows too much. They know where the buttons are, why a flow was designed a certain way, and which corners to avoid. They cannot un-know it.
- User research answers: does it work for people who know nothing? This is the only method that observes real users encountering your product without your assumptions baked in. It's where you learn that an "obvious" label means nothing, that a step you thought was optional is a blocker, that the mental model in your head isn't the one in theirs.
Why dogfooding feels like research (and isn't)
Dogfooding is seductive because it's cheap, fast, and produces confident opinions. Everyone on the team suddenly has a view on the onboarding flow. The problem is that those views come from the least representative sample imaginable — the people who built the thing.
Real users don't share your vocabulary, your patience, or your context. They arrive mid-task, distracted, on a slow connection, with a goal you may not have anticipated. Dogfooding will never reveal that gap because your team has already crossed it. Treat internal use as a bug-catching and gut-check exercise, not as a substitute for observing outsiders.
Where AI fits — and where it doesn't
The obvious next question in 2024 is whether AI can shortcut any of this. AI is already excellent at accelerating QA — generating test cases, spotting regressions, triaging bugs. It can also draft synthetic user personas and simulate feedback. That's genuinely helpful for early-stage exploration.
But there's a trap worth naming. The value of user research isn't only the findings — it's the team learning from watching real people struggle. When your designers and engineers see a user freeze on a screen they were sure was intuitive, that observation reshapes how they build. You cannot outsource that learning to a model that summarises it for you. The insight arrives second-hand, stripped of the discomfort that actually changes behaviour.
There's a subtler risk too. Users increasingly attribute a kind of mind to AI-driven interfaces — they feel heard, understood, even cared for, whether or not that's warranted. That perceived empathy is now a design dial you can turn, and it changes how people trust and rely on your product. Understanding that effect requires watching real humans react, not modelling what you assume they'd feel.
A practical sequence for real teams
You don't have to choose one. You sequence them.
- Run QA continuously. It's your baseline hygiene. Automate what you can, and use AI to widen coverage. Nothing else matters if the product is broken.
- Dogfood during active development. Use it to catch the obvious friction before it reaches anyone external. Just label the findings honestly as insider opinion.
- Run user research at decision points. Before committing to a direction, and again before launch, put the product in front of people who've never seen it. Watch — don't just survey. This is where the expensive assumptions get caught cheaply.
The teams that ship products people genuinely love aren't the ones running the most tests. They're the ones who know which method answers which question, and who never let internal confidence stand in for watching a real user try to get something done.
Sources
- Don’t Outsource the Learning: Why Human-Led Research Still Matters in the Age of AI — Nielsen Norman Group
- The consciousness mirage in AI design — UX Collective
- What I’ve learned writing for billions of users — UX Collective
- Dogfooding vs. QA vs. User Research — Nielsen Norman Group
