Let Us Now Praise Dogfooding Because it is Dead
In 1988 Paul Maritz, a manager at Microsoft, wrote an email to Brian Valentine, a test manager, with the subject line: “Eating our own Dogfood.” Microsoft was working on a new operating system for networking systems. Maritz thought using their own product for Microsoft’s internal network needs would help push them to make a better product. There were several other companies that held this “practice what you preach” mentality which contributed to their success including Apple’s push to switch all employees from typewriters to computers.
Within the same era that dogfooding was coined, technology companies were in their infancy. Bill Gates imagined a future where you could look across at an office building and see every desk equipped with a computer. Tech companies were just beginning to shift the landscape of office culture.
R&D teams had access to office buildings full of employees who had never been exposed to computers. This unique context enabled internal user testing, which is why it was possible to spend so much company time on what was essentially QA. New employees could serve as a good enough proxy for potential customers because everyone was having to to make the same leap and adjustments in their habits and behaviors.
Take the system-wide menu bar introduced by Apple in the 80’s. This design—still in use today—was the result of an insane user-testing schedule. Every day they tested a prototype on a new employee who had never used a GUI (graphical user interface). They’d immediately adjust their prototype based on that feedback, often spending all night preparing the next prototype.
Eating your own dog food was not a subtle marketing trick or a PR fix (as it was for proving that dog food no longer contained horse meat in the 70s). Dogfooding was actually a path to shifting a company’s internal decision making to focus on an external audience.
Donald E. Knuth, creator of TeX—the typesetting system most commonly used for typesetting math formulas—provided this clear explanation of his design philosophy and explains the shift in his own thinking:
Thus, I came to the conclusion that the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. The separation of any of these four components would have hurt TeX significantly. If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important.
—Donald E. Knuth, “The errors of TeX”
Knuth’s participation and contributions to user-facing products (the user manual) shifted his point-of-view. His experience is in-line with the thinking behind dogfooding. But this application clearly had an impact on his point-of-view. He was more equipped to discover and solve the design problems at hand because he had changed his own way of making decisions.
Dogfooding in the early days led to successful product-market-fit because of a unique context. But the work of the technology industry has expanded to such a degree that we’re designing for a wider audience. This is something to be celebrated! The interfaces we’re designing for aren’t the admin interfaces referenced in Martiz’ original dogfood email. We need to look further—beyond our own experiences and beyond even what we can think up at a standing desk— to discern the context our users actually inhabit.
If stakeholders within a company see themselves as the user, how can designers, developers, product managers and other members of the team effectively design for an external audience?
Today in tech, dogfooding is often short-hand for kicking the tires on an app. It’s one level up from collecting analytics on users’ clicking behavior. Dogfooding has become a one-word rationale for making poor product decisions and violates the false-consensus effect. Remember, you are not the user.
It’s always a challenge to make the people building a product more aware of the problems faced by the audiences they’re designing for. The apps being developed now are for user populations whose environments don’t match the context of most Silicon Valley offices. If stakeholders within a company see themselves as the user, how can designers, developers, product managers and other members of the team effectively design for an external audience?
This one is a gimme—user research. This week I came across this Thoughtworks blog about how dogfooding has become an excuse for not doing user research. This sucks! Don’t make this mistake! Instead, include your developers in user research. It’s a cheaper way to achieve the same internal effects and to get your whole team on board with making a product for an external audience.
Many who take our user research workshop find it much easier to go back to their companies and convince the powers that be to include developers in the research phase of a project. If your boss could use some convincing, attend our workshop to learn how you can implement more effective research techniques at your company.
Thanks to Erika Hall, Zachary McCune and Rena Tom for help with this revision
