In technology, we often use the term “dogfooding” (or “eating your own dog food”) to mean that we should use the products we make, in order to develop empathy for our customers and expedite fixing problems. In other words, we fix the pain we inflict on customers because we are inflicting it upon ourselves. This concept has been described by many writers; if you’re not yet familiar with the concept, I invite you to check out the Wikipedia page. I want to spend some time now talking about when dogfooding is appropriate and when it is not.
The apocryphal example of dogfooding gone right is in the development of Windows NT, where Dave Cutler forced NT to be self-hosting as soon as possible — in other words, having software developers use early builds of NT as their development workstations to build NT itself. This was a great way to flush out bugs and add features incrementally to the operating system as the developers needed them in order to do their own work! Dogfooding worked here because the needs of the customer overlapped with the (enforced) needs of the engineers, or what I call perfect congruence between use cases.
There are, however, many situations in which dogfooding can go wrong, particularly if there is not the same congruence. To take the metaphor literally: Dog food is delicious if you are a dog making food for other dogs. You can eat great quantities of it and improve it as you do so. It works less well if you are a human manufacturer of dog food. As a human, eating a lot of dog food would make you sick. It might lead you to the incorrect conclusion that the dog food you are making is unsuitable, when in fact you are not the target market at all.
In my experience, dogfooding is good for:
- Improving technical product quality and stability
- Building confidence in early prototypes and getting inspiration for future development by exercising your product with the same use cases your customers will have
- Developing empathy for customers if you are making a product for others yet you also have that function at your company. For example, if your software development team is making an ERP product for finance professionals, you probably have some finance professionals inside your company you can try it on.
Dogfooding is not good for:
- Making product decisions about what features to invest in. You are not your customer base. At best, you are one sample customer, assuming perfect alignment with your customer base’s use cases. As a product company, you build products for a market, not for a single customer.
- Trumpeting to customers how well you have used your own product. Customers could care less that you are using your own product. They expect you to already be doing so, if you can. Using yourself as a “reference customer” holds no water for them. They want to hear how your product can solve their use cases, and the only other third party they will listen to is possibly a peer in their market segment.
One special problem I’ve seen with dogfooding is that after a while, if the product you are dogfooding is good, you’ll want to rub it all over every problem. This is a mistake. It’s just like how leaving your dog at home alone with an open bag of dog food leads to horrible consequences.
At Chef, we call this the “Yo Dawg” phenomenon, after this meme.
Some of the places where Chef has done this inadvertently is in the overuse of the Chef DSL (domain-specific language). We all work at Opscode Chef, and love Chef, so in the past, whenever we needed a DSL, we reached for Chef’s. One example is Chef Provisioning, a product that has never reached a high level of adoption. In designing it around the Chef DSL, we immediately limited the possible market to those individuals who already know the Chef language, or want to learn it, rather than the market of those who need to do provisioning. Worse, some of the mechanics of Chef, like the deterministic ordering of a compile-execute model, translate less well to the provisioning domain and confuse users, even those that know Chef.
Dogfooding, used judiciously, can indeed make your products better. But do not simply apply it dogmatically because the idea appeared in a book. Neither dogfooding nor any other product development mantras substitute for the hard work of understanding how your customers experience and use your product, through customer interviews, UX research, and so on.