--- title: "Dogfooding is a friend and a liar" description: "Using your own product can reveal where it breaks, but it cannot prove that customers understand it, need it, or will pay for it." canonical: "https://www.rickblalock.dev/scratch-notes/dogfooding-is-not-customer-discovery/" date: "2026-08-26" updated: "2026-08-26" author: "Rick Blalock" --- # Dogfooding is a friend and a liar > Using your own product can reveal where it breaks, but it cannot prove that customers understand it, need it, or will pay for it. Published: 2026-08-26 Catalog: SN-008 [Ben Vinegar recently pointed to a recurring lesson from indie game postmortems](https://x.com/bentlegen/status/2091511818355147204): > I recommend people look at indie game postmortems (there’s a lot on Reddit, YouTube) > > A recurring theme: “It turns out I was just making games for other indie game devs, and I found out too late they don’t actually buy games” i.e. The people admiring the work are not the customer. Ben's reply was to [Sunil Pai’s joke](https://x.com/threepointone/status/2091167009669075314) about an AI agent factory that can make anything but is “mostly using it to improve the factory.” It's pretty funny but also the kind of truth that is a little painful (Like watching HBO's Silicon Valley and realizing you've been a part of some of those episodes in real life). The "factory" is impressive. It is doing real work and getting better at doing it. The missing part is an outcome anyone outside the factory wants. i.e. Nobody cares. Software teams with a bit of product psychosis fall into the same loop. They build something technically excellent, try to use it every day, improve it quickly, and treat that activity as evidence that a market exists or that people think it's good or cool or useful. This is where dogfooding starts becoming a detractor. A buddy of mine recently had a visceral reaction to the word "Dogfooding" because he had never heard of it, so here's an obligatory definition in case it's new to you: Dogfooding is the practice of using your own product inside the company. Bugs interrupt the builders’ work. Rough edges become difficult to ignore. The product has to survive daily use internally, first, instead of an outside demo. It's useful for sure. Dogfooding shows where a product breaks under sustained internal use. ***It says little about whether an outsider understands it, has the same problem, or will pay.*** [Nielsen Norman Group describes internal use as a kind of usability upper bound](https://www.nngroup.com/articles/dogfooding). If employees struggle, customers will probably struggle too. However, employee success does not carry the same weight. Why? **Employees know too much.** They know why a term was chosen, where the configuration lives, which warning can be ignored, and what the unfinished behavior is supposed to become. When something goes wrong, they can message the person who built it. In their mind an issue can be small and easy to fix while to the user it looks insurmountable. Thanos saying, ‘You're not the only one cursed with knowledge.’ Researchers call this the [curse of knowledge](https://authors.library.caltech.edu/records/zgwcn-vap73/files/1831894_1_.pdf?download=1). Once we know something, we struggle to predict how someone without that knowledge will interpret the same situation. Better-informed participants in the original experiments could not fully set aside what they knew when estimating the judgment of less-informed people. Employees also use the product under different conditions. They may be expected to use it, receive it without paying, and tolerate instability because they know what is coming next. A customer may need to migrate data, persuade a manager, pass a security review, train a team, or put their reputation behind the decision. In business software, the daily user may not be the buyer or the person carrying the risk. Internal feedback can gradually shape the roadmap around the company itself. Employees are available, articulate, and unusually fluent in the system. Their requests are easier to collect than the problems of customers who have not adopted the product or gave up before anyone talked to them. **There's always tradeoffs** [PostHog has a pretty good post about this tradeoff](https://posthog.com/product-engineers/dogfooding). Dogfooding works especially well there because PostHog builds tools for companies that resemble PostHog. The company still warns that too much internal feedback can lead a team to build what it wants rather than what its users want. Of course there are caveats and nuances: Sometimes the builder really is a good first customer. [Paul Graham has argued that strong startup ideas often come from problems the founders have themselves](https://paulgraham.com/startupideas.html). Starting with your own need can establish that the problem exists and give you unusually deep insight into a solution. That doesn't mean they can't fall in the trap that dogfooding becomes harmful when a product / quality practice is mistaken for market-validation or they fully understand or can empathize with that market. This is nothing new btw. Perhaps it's amplified in this era of AI Agents but check out Eric von Hippel’s research on [lead users](https://web.mit.edu/evhippel/www/books/sources/Chapter8.pdf) that gives this conversation some useful boundaries (1988)! "Lead users" experience needs that will later become common and have a strong reason to solve them. Their experience matters because they are ahead of a real trend. But that still does not mean every personal frustration points to a market but it can be an indicator. A founder may be a real first customer, a "lead" user even. Their experience is still a starting hypothesis about a market. This is why “you are not your customer” is worth keeping in mind. The phrase turns personal preference into something to test. It stops the team from trying to simulate another person from inside the building and gives unexpected behavior a more useful meaning: there is something left to learn. ***A better take is: You may be a customer. You aren't the market.*** Keep dogfooding. Let the product interrupt your day and fix what breaks. Then [go outside the building](https://steveblank.com/2012/03/29/nail-the-customer-development-manifesto) and watch someone who does not know the vocabulary, cannot message the builder, and has to decide whether the product is worth the cost. --- [All Scratch Notes](https://www.rickblalock.dev/scratch-notes/)