Eating your own dog food or "dogfooding" is the practice of using one's own products or services.
The origins of the term are somewhat debated, with credit going to an Alpo dog food advertisement, an internal email from Microsoft executive Paul Maritz, and a memo from former President of Apple, Michael Scott.
The Alpo dog food ad featured actor Lorne Green promoting Alpo dog food by claiming he fed the brand to his own dog, so it’s logical to assume “eating your own dog food” came from this ad. But regardless of its origin, dogfooding is now a popular term and practice in product development because it encourages product creators to focus on the customer experience.
Apple’s internal memo from the 1980s is a great example of introducing a dogfooding program to promote their new product — the Apple computer.
"EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers."
It’s easier to explore the practice of dogfooding through software engineering because the team members creating the software could easily be real users as well, so they’re more invested in the end user experience.
Dogfooding helps you find and address the root problem
Problem-solving is only effective when you’re tackling the true problem. Unfortunately, people tend to make assumptions about the problem at hand because they are too far removed from the issue.
Let’s say a bank has an app providing multiple services to the client: money transfers, loans, credit card transaction history, etc. The bank wants clients to use more of the services, so a product manager comes up with an idea to promote additional services right in the bank app through promotional pop-ups.
The product manager doesn’t use the app, so they assume the problem is that clients aren’t aware of the full suite of services. As a result, they come up with what they consider a straightforward solution — an in-app notification that encourages clients to use more app features. However, the “solution” might actually ruin the UX of the app, irritate the customers, and potentially give an advantage to competitors in the process.
Let’s imagine another bank has an overload of calls to their customer support line. Managers decide to implement a voice chatbot to reduce the load on staff.
The managers assume the problem is that there is not enough staff to cope with the call load, so they introduce a chatbot. But this doesn’t solve the problem. In fact, it annoys the clients who have to spend more time on calls.
I’ve seen both of these examples in real banking apps in the banks I worked for, and both were solving the wrong problem.
The first bank had a cumbersome flow for qualifying for loans: a client had to prepare too many documents and visit the bank multiple times. Building pop-ups in the banking app to let clients know about loan services didn’t have a good return on investment. The pop-ups did not lead to more loan applications, it just annoyed customers who used the app.
The second bank had quality issues in the app — it was crashing way too often, and that was the reason so many customers contacted the call center. Certainly, the investment in the chatbot worsened the situation as it could only help with typical scripted requests, not crash reports.
Both banks saw the failure of their hypotheses, but the money and time was wasted and the users were irritated.
Now imagine if the dev teams in both banks were using the dogfooding practice and were the first clients to use their apps. I bet they would have highlighted that the “solutions” brought in by the managers were solving the wrong problems, and that would have saved the money and clients’ loyalty by getting the solutions right the first time.
Benefits of dogfooding in software development
As soon as a software engineer becomes the first customer of the product or service, they begin to notice problems with the company’s product. Using the product regularly allows them to get familiar with common use cases, which gives them valuable insights into the software functionality.
Gitlab and 37signals are both good examples of tech companies implementing dogfooding practices.
Gitlab lists dogfooding as a company value:
“We use our own product in the way our users do to surface improvements that will lead to better customer results.
- Our development organization uses GitLab.com to manage the DevOps lifecycle of GitLab itself.
- Our entire company uses GitLab to collaborate on this handbook.
- We capture content and processes in Git repos and manage them with GitLab.
- When something breaks, doesn’t work well, or needs improvement, we are more likely to notice it internally and address it before it impacts our larger community.”
37signals went even further by building a product for themselves first:
“We built Basecamp out of desperate necessity. We needed it bad. Without it, we were embarrassing ourselves.”
While 37Signals originally built Basecamp for themselves, they stumbled into the practice of dogfooding when their clients showed interest in using Basecamp, too. “Based on feedback, and our own ideas, we’ve made thousands of improvements over the years, with so much more to come,” says 37Signals co-founder Jason Fried.
Dogfooding encourages real-time quality assurance because engineers don’t have to wait on feedback from customers. They are using the product, so they can incorporate their own findings into the development process.
Dogfooding limits of applicability
Any practice has limits of applicability: conditions where the practice is suboptimal or negatively affects the system. Employees at a dog food company would not benefit from literally eating their own dog food because they are not the target consumers (dogs). In other real-world applications, dogfooding is often limited by whether the people creating a product are also the target user and/or have the expertise required to judge the effectiveness of the product.
For example:
- Aviation engineers are not trained pilots, so they cannot practice dogfooding by flying the airplanes they are building
- Medical equipment is not produced by certified doctors, so medical equipment designers cannot practice dogfooding by using the instruments on patients
These limitations may be why dogfooding became so popular in software development — there is a higher likelihood that a software engineer would possess the knowledge and need to use the software they are building compared to other industries, like dog food.
But there are ways to mimic a dogfooding program in a company where the creators are not necessarily the target customer. A great example is the practice of Gemba Walks, “a process where employees of a company go to the place where the work is actually done.”
Teagan Pannel, Founder and CEO of Leanscape, puts it this way:
“If you want to improve your business, you need to learn more about your processes, your people, your customers, you need to go and see for yourself. Managers and business leaders today are often so separated from the actual work by corporate structures. They have not seen the process. They have not spoken to any customers. And they don’t even talk to the people who do the work daily.”
While seeing how the product is made and talking to customers isn’t direct dogfooding, it does open the door for dogfooding practices to emerge. As employees of every level become more familiar with the product and its customers, they can incorporate their experience into their work at the company.
So while it has some limitations, dogfooding — traditionally or in a similar scenario like Gemba Walks — can reduce alienation and increase engagement at work because the company employees see and feel how their efforts resolve real problems, the daily problems they witness.
Choose your dogfooding approach
If you decide that the dogfooding practice might benefit your company processes and culture, there are two approaches: revolution and evolution.
Apple used the revolution approach in 1981: managers replaced the typewriters in the office with Apple II computers. The employees had no choice but to use the product.
Enforcing such a change might yield undesired results if company culture resists the change. Introducing dogfooding will require slowly changing this culture. Managers must promote dogfooding and build employees’ interest in using the product. Good leaders are role models, they need to show the employees how they themselves use the product to encourage their employees to do the same.
The evolution approach demands a slow but steady pace. Taking employees’ feedback — and acting upon it — is a must. As soon as people see their voices ignored, dogfooding is doomed.
Regardless of which approach you choose, dogfooding can be extremely beneficial to your product management and development. After all, no one knows the challenges of a product better than the people who use it every day.
Ready to see what Qase can do for you? Sign up for a free demo and talk with our team about your needs.
To learn more about dogfooding at Qase, watch Vitaly's talk for Continuous Testing Meetup, Dogfooding: Eating our own cooking for quality assurance.
Special thanks to: Aleksey Petrov, Anastasia Menshikova, Ilya Menshikov.
References:
- How to Define a Problem in Engineering
- Problem Definition
- Engineering Problem Solving
- Engineers: Problem Solving in Society
- Problem Identification in Engineering Design
- A theory of implicit and explicit knowledge
- TRIZ
- Gemba walk
- Dogfooding
- Lean manufacturing
- Work alienation: A Pancultural Perspective
- Predictors of work alienation: differences between hierarchical levels
- Work centrality and work alienation: distinct aspects of a general commitment to work
