Your team is not a sample: where dogfooding stops working

Three methods, three questions

Nielsen Norman Group published an article by Therese Fessenden in August 2026 taking apart the assumption that internal use tells you a product works. Dogfooding, QA and user research are not three intensities of the same activity. They answer three different questions, about three different populations.

According to NN/g's framing, dogfooding means using your own product internally to improve it. QA testing is a structured, systematic evaluation of whether the product works as intended, aimed at reliability. User research is a structured approach to gathering data from customers or representative users about whether the product is usable and actually meets their needs.

Stated as questions: dogfooding asks whether this holds up when we live inside it. QA asks where exactly it breaks. User research asks whether somebody who does not work here can get the job done. Those are not redundant. Each catches a class of problem the others structurally cannot see.

A crash on an obscure code path is a QA finding. Performance degradation that only appears under sustained real-world use is often a dogfooding finding. A feature that works flawlessly and that nobody can find, or a label that only makes sense if you attended the kickoff, is a research finding, and it will not surface in either of the other two.

The curse of knowledge is not a soft problem

The reason internal testing cannot substitute for research is cognitive, not procedural. NN/g points to the curse of knowledge: once you know how a system works, you lose the ability to accurately simulate not knowing. Your team's mental model of the product is fundamentally different from a new user's, and no amount of good intentions closes that gap.

The classic demonstration is a 1990 Stanford study in which participants tapped out the rhythm of well-known songs and predicted how often listeners would identify them. Tappers estimated around 50%. Listeners got about 2.5%. The tappers could hear the melody in their heads and could not imagine it being absent from anyone else's.

That is exactly what happens when a product manager watches a colleague breeze through onboarding. The melody is playing in everyone's head in the room. It is not playing in your users'.

This also explains why asking the new hires only works for about a fortnight. New employees are a genuinely useful source of feedback on confusing terminology, right up until the curse of knowledge sets in, which happens fast.

The upper bound, and why the inference runs one way

The sharpest idea in NN/g's article is that dogfooding gives you a usability upper bound. The inference is asymmetric, and getting the direction wrong is the expensive mistake.

If your own team struggles with a flow, real users will struggle more. That is a valid and useful signal, and you should act on it immediately.

If your own team sails through, you have learned nothing about your users. Your team had context, motivation, institutional vocabulary and someone to ask. The absence of internal friction predicts nothing about the presence of external friction.

Most teams treat internal success as evidence. It is the one direction the method cannot support.

When dogfooding actively makes things worse

NN/g raises a risk beyond the method simply being limited: internal feedback can confound research data and, in some cases, directly contradict what user research found.

The failure mode is familiar to anyone who has presented findings internally. The study says users cannot locate the export function. Someone in the room says they use export daily and it is obvious. The room now has two conflicting data points and tends to resolve toward the one attached to a colleague with organisational standing.

That is not a data problem, it is a governance problem, and it needs a rule set in advance. Internal feedback and research findings do not go into the same bucket. Employee opinions are stakeholder input, not evidence about users. When the two conflict, research wins on questions about users and dogfooding wins on questions about reliability. Nobody gets to overturn a research finding with an anecdote about their own usage.

Products with heavy internal use are the most exposed. If your company runs its own operations on the product, the internal user base is loud, expert and completely unrepresentative, and it will happily set your roadmap if you let it. I have seen this play out most sharply on security tooling built for analysts under pressure, where the team's fluency with the product bore no resemblance to a new analyst's first shift.

What dogfooding is genuinely excellent at

None of this is an argument against dogfooding. It does several things no other method does as cheaply.

It surfaces bugs at real scale and over real duration, across device and environment combinations no QA matrix will enumerate. It catches slow-burn problems that only appear after weeks of accumulated data. It builds genuine empathy in people who would otherwise never feel their own decisions. And it makes obvious gaps impossible to ignore, because the team feels them daily.

It is a strong supplementary signal. NN/g's position is that it belongs alongside QA and research, never in place of either.

A working split

1. Assign each question to one method before the release. Reliability goes to QA. Endurance and environment coverage go to dogfooding. Comprehension, discoverability and task success go to research.
2. Treat internal success as a null result. Only internal failure is actionable evidence from dogfooding.
3. Keep two logs. Internal feedback in one, research findings in the other, never merged into a single prioritised list.
4. Run small and often on the research side. NN/g's long-standing guidance is that a handful of participants surfaces the majority of usability problems, so the constraint is scheduling, not budget.
5. Recruit people who have never seen the product. Comprehension questions require genuine ignorance, and your organisation no longer contains any.
6. Use new hires immediately or not at all. Their first two weeks are the only unbiased window you get.
7. Write down the rule for conflicts while nothing is on the line, not in the meeting where a finding is being disputed.

The point

The distinction that matters is the one NN/g lands on: dogfooding tells you what your team thinks of the product, and research tells you what your users experience. Both are worth knowing. Only one of them is about the people paying you.

The teams that get burned are rarely the ones that skipped testing. They are the ones that tested thoroughly, internally, and mistook a ceiling for a floor. That distinction gets sharper as more of the interface is generated rather than drawn, because reviewing AI-generated interface decisions is an internal act too, and it proves nothing about the people who will use the result. Getting that split right is a standing part of how I run research inside a project, and you can see more of that work here.