Dogfooding refers companies using their own software. According to Wikipedia,

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 company’s product. From there, the usage of the term spread through the company.

Dogfooding is a great idea, but it’s no substitute for usability testing. I get the impression that some products, if they’re tested at all, are tested by developers intimately familiar with how they’re intended to be used.

If your company is developing consumer software, it’s not dogfooding if just the developers use it. It’s dogfooding when people in sales and accounting use it. But that’s still no substitute for getting people outside the company to use it.

Dogfooding doesn’t just apply to software development. Whenever I buy something with inscrutable assembly instructions, I wonder why the manufacturer didn’t pay a couple people off the street to put the thing together on camera.

6 thoughts on “Dogfooding

  1. I usually think of not-invented-here applying at the component level, below the product level. For example, not trusting a software library and writing your own. But at the product level, you should use your own stuff, as long as you’re in your target market.

    If your company makes office chairs, everyone from the top down should sit in one. But I would make an exception for target market. I could see, for example, a company that makes cheap office chairs providing its employees with better chairs. But if the company is buying chairs in the same price range that it sells because the competitor’s chairs are more comfortable, that’s a problem!

  2. Dogfooding not only has the potential to improve product testing (feedback potentially coming earlier, with greater frequency, and with more circumstantial data [secrecy and disruption concerns would be less for internal investigations]) but the potential to encourage workers to see the products as important to everyday life (“my job has meaning” and perhaps even “I have a responsibility for product quality even if I am not directly involved in production”). The marketing benefit is also obvious (along the lines of “we treat you like one of us–because some of you are!” and “it’s good enough for us”).

    Another potential pitfall (other than only applying use to “technical users”) would seem to be providing better support and not recognizing this factor when evaluating the quality of the product. Such is effectively the same as having a “technical user” readily available to help (when such is not available for most of the external users). Even the more prevalent application of best practices internally should be considered.

    (A company that produces office chairs probably has more awareness of what types of chairs are best suited for what types of roles [as well as likely having better “support” in being able to change chairs] and how environmental conditions like temperature and humidity and desk/table height influence the utility of specific chairs. Even if such information is provided to customers, one often does not want to limit one’s customers to only those who follow best practices–not only because general best practices might not be best in a particular case but also because a potential customer might be unwilling to apply best practices for good reasons [e.g., change costs] or bad [“this is not an item on the checklist I have to sign off on”].)

    Along similar lines, the internal environment might be considerably more homogeneous than the external environment. This factor should also be recognized. (“Why are we getting so much negative feedback from customers? None of our 39-42kg female employees had any complaints about our chairs!”)

  3. This is mostly a matter of naming, rather than conceptualisation, yet… I tend to see “dogfooding” and “user testing” as two totally distinct processes, with different goals and I have an hard time thinking a professional might get them mixed up.

    When I invite my team to write for example an application based on our own API, I want to make sure that the API exposes all the functionality needed for the application interfacing with it. In other words what I – who am not an native English speaker – call **usefulness**.

    When I do hallway testing, by asking other programmers not involved in my team to use that API, I want to test how user friendly the API is (naming, documentation…). In other words I want to test the **usability** of it.

    That said, I believe too much dogfooding is unhealthy: it warps your perception, and tends to make criticisms from the outside less important than they really are. I also noticed that using too much of your own stuff prevents you to be exposed to alternative paradigms and solution to the same problem. There’s a lot to learn by using your competitors’ products! :o

  4. When my daughter was in kindergarten, she used to beta-test interfaces for an electronics company. They wanted kids that had just learned how to read, but hadn’t been corrupted by exposure to many interfaces yet.

    By the time she hit first grade, she was all washed up. They didn’t want her any more; they were looking for their next crop of kindergarteners. Such is the world of tech.

  5. Maybe I’m too much of a programmer. When you mentioned “inscrutable assembly instructions”, I was thinking of SSE, not IKEA.

Comments are closed.