Eat Dog Food, in Moderation Only

Clement Lang Hirsch was pretty eccentric, even by LA billionaire standards. In the thirties, Clement decided he wanted to get into greyhound racing, and bought his first furball for $2.50. Discount dog was perhaps a dubious value, quickly falling into duress. Rather than put him out to pasture, the enterprising Mr. Hirsch started feeding Fido a steady diet of human-grade ground beef, and the dog miraculously returned to racing form. Within a year, Hirsch had started Kal Kan Pet Food, which became the largest independent producer of pet food in the US, eventually effecting a tidy exit to Mars Inc. in 1968. That’s hardly the most interesting thing about old Clement. Neither is the fact that he turned around and founded another dominant national brand (Stagg’s chili) and sold it to Hormel by 1996.

No. The most interesting thing about Clement Lang Hirsch is that he began each of his Kal Kan Pet Food shareholders’ meetings by cracking open a can of his dog food, and eating it. In 1988, Microsoft manager Paul Maritz sent Brian Valentine, test manager for “Microsoft LAN Manager,” an email titled “Eating our own Dogfood” – challenging him to increase internal usage of the LAN Manager. From there, usage of the phrase spread through the company, the industry, and the world. Whether Paul had heard the stories about Mr. Hirsch’s kibble consumption, we’ll never know. Nevertheless, in the pantheon of silicon valley psychobabble, “eating your own dogfood” has been insufficiently mocked. Aside from the obvious benefit of experiencing the pros and cons of your offering from the user’s perspective, “dogfooding” leads to a complicated relationship with The Truth, and that’s what we’ll be talking about today.

“It is as easy to deceive oneself without perceiving it
as it is difficult to deceive others without their perceiving it.”
— François duc de La RochefoucauldMaximes (1664)

The paradox so elegantly encapsulated by M. Rochefocauld 350 years ago is that self-deception is deceptively easy. Our biases towards our own creations are nearly insurmountable. Sure, living with your product every day exposes you to its strengths and flaws. The danger is that it simultaneously obscures their consequences.

Imagine if you could force your customers to engage with your product completely. They would use all of its features, send bug reports when they run into problems, and enforce likewise usage across their team. It would be a dream.

The reality is that the problems aren’t “the problem.” Missing features aren’t “the problem.” Adoption is the problem. Retention is the problem. Exception resolution is the problem (do you use your customer’s customer service pathways? I don’t think so.).

Dogfooding by corporate mandate reinforces the idea that product evolution is “the answer” to “the problem.” The real “answer” is invariably that customer experience needs to be improved. Organic needs demand to be met. Dogfooding creates, by its very mandate, synthetic needs born of synthetic experiences.

This is not to say that companies shouldn’t use the products they sell. It’s to say that dogfooding doesn’t replace listening to your customers. They don’t need to “just get it.” You need to “get it.” The fact that something works internally does not mean that its use in practice solves the real-world problems of the people who hold your future in their hands.


3 Recipes for Better Dog Food

The mission? Empathize with your end user. How? Give these meditations a shot:

  1. Would I have encountered this problem if I wasn’t forced to be here? Second-order problems are easy to focus on. They’re discreet engineering challenges that fit neatly onto a Kan Ban board. But if your attention is being spent on bugs that you’ve only experienced because you gritted your teeth through a whole bunch of customer-non-starters, that effort is being wasted.
  2. Is using this product keeping me from getting the REAL solution to market faster? Employees in organizations all over the world are cursing their owned software because v1 is so ineffectual that it’s actively inhibiting development of v2. Recognize when it’s time to focus on the blue ocean and cut ties with your wake.
  3. What level of proficiency and adoption can I expect from my sweet-spot users? Is your good experience with your product due to the fact that everyone at your company is using it? What’s the experience like with real-world adoption numbers? How gracefully does your master-planned system deal with the horror of interaction with systems outside your walled garden? What’s the experience like when the rest of your enterprise stack wasn’t specifically chosen to play nicely with your product? How proficient can you reasonably expect your super users to be? How about the folks they need to teach – 80% of your installed user base? What’s the experience like now, when you’re at a more realistic level of proficiency? Is the value proposition still holding up? Can you improve that experience WITHOUT the crutch of training? Knowing what you know now, would you really buy this product and force your entire company to use it?

Get the Urbach Letter in your inbox.

  • This field is for validation purposes and should be left unchanged.