Why you should be obsessed with dogfooding

What exactly is dogfooding?

If you’ve worked in a tech company, you’ve probably eaten some dog food. Or to be more precice - you’ve probably eaten your own dog food. Because the phenomenon known as “dogfooding” (or “eating your own dog food”) has become an accepted part of the product development process.

So what is dogfooding exactly? It’s the practice of using your own product or service.

A simple Google search will tell you that the term “dogfooding” probably comes from a 1970’s ad campaign from Alpo dog food. In a series of commercials, actor Lorne Greene feeds Alpo to his own dog. This became the accepted paradigm for using the products that you produce yourself. Another theory I’ve seen traces back to Clement L. Hirsch, President of Kal Kan dog food. Apparently, Clement would suddenly get up in the middle of a shareholders meeting, pick up a can of Kal Kan dog food, remove the lid and eat it to the astonishment of everyone present.

Both Alpo and Kal Kan Dog Food used dogfooding as a promotional marketing tool. Their goal was to exude a clear sense of confidence in the product to shareholders and prospective customers. And using the product themselves was an easy way to do so.

Using dogfooding as a marketing tactic has since been adopted by others outside the dogfood industry. One (crazy) such example is SawStop, a saw blade safety mechanism that detects contact with a human finger and instantly stops the blade before any damage is caused. To exhibit the reliability of his product, Inventor Steve Gass volunteered to put his own hand on a moving saw blade (don’t worry - everything worked out).

Dogfooding in tech - more than just a marketing play

It’s interesting then, that as tech companies began to adopt the practice (and terminology) of dogfooding for their own products, they used it for a lot more than just marketing. A few famous examples:

• In 1980, Apple president Mike Scott (no, not that Michael Scott) sent an internal memo to all employees with the subject “Typewriters”. The memo read as follows: “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.”
• In 1988, Microsoft manager Paul Maritz sent an email to Brian Valentine (a test manager for Microsoft LAN), with the subject line: “Eating our own Dogfood,” challenging him to increase internal usage of their products
• In 2002, Jeff Bezos issued a mandate to all Amazon employees (with the threat of immediate dismissal from the company) that all Amazon services be built in a way that they could easily communicate with each other over Web protocol. Meaning, if you were human resources and you needed some numbers from marketing, you had to get them using an API that would then be accessible to others. He was asking every team to decouple, define what resources they had, and make them available through an API. This dogfooding-oriented step is largely viewed as a critical one in the evolution of Amazon’s web services platform that we know today as “AWS”. The common denominator between these examples is that none of them used dogfooding as an outbound marketing tactic. In fact, until these stories were publicized years later, no one outside the company was aware that these internal policies were ever implemented.

What else is dogfooding good for?

So aside from marketing, what else is dogfooding good for?

It’s something that we think about a lot at Livecycle. Dogfooding is one of our core company values and we’re deliberately pushing the limits of how it can be applied and how it can beneficial to the growth of our company and our product. We’ve found that the benefits of dogfooding do indeed reach beyond marketing, as the stories from those other tech companies would suggest.

These are some of our key learnings that might be useful to other teams and companies who are looking to build an effective dogfooding strategy of their own.

Product-centric benefits to dogfooding

First and foremost, effective dogfooding should have a direct, positive impact on the product itself. For us at Livecycle, this has occurred in a few ways:

High-level QA - As an early stage startup, we’re constantly prioritizing our tasks and budgeting our resources. Without a dedicated QA team, a more deliberate dogfooding policy gives us the opportunity to quickly uncover bugs through wider usage of our platform. And while testing and bug-fixing is not the only objective of dogfooding, it is a benefit.

User empathy insurance - For our team, dogfooding has been beneficial not only for unit testing and feature-specific stability, but also to ensure that the product is remaining empathetic to actual users. Often, developers will test he specific code change and perhaps some related functionality surrounding it, but dogfooding gives the team the opportunity to zoom out and test real user journeys that take the actual user experience into account.

Product ideas - By insisting that our entire team use the product in real life, we’ve been able to generate lots of new product ideas. While some ideas can be offered theoretically, actual usage of the product as a real user gives our team the ability to “live” the product and come up with some really clever suggestions of how we might improve it going forward.

Other benefits to dogfooding

Even outside the context of the product itself, we’ve found that dogfooding had benefitted our company. A few examples:

Company pride (or shame) - An intangible benefit to dogfooding is it’s ability to push the team to take pride in what they are working so hard to build. As Mike Scott said in his memo to Apple employees 40 years ago: “If word processing is so neat, then let’s all use it!”. This was similarly the driver for the media calling it an “embarrassment” in 2010 when 10,000 Microsoft employees bought iPhones, even though they had no development reason to do so. Usage and pride go hand in hand.

Better context for everyone - Better context leads to better results. Always. And dogfooding allows EVERYONE in the company to get a more nuanced understanding of the solution that is being offered to customers, even if their day-to-day roles are one step removed from the product itself. This kind of context initiates a process that ultimately leads to critical thinking, thoughtful questions, and a clearer understanding of what the company is trying to achieve. It lets everyone on the team do their jobs with better focus and more informed creativity, and for us, it’s produced some incredible and unexpected ideas from the team.

How we’re taking dogfooding to another level

The underlying assumption of any dogfooding policy is that the product can actually be used by the team in their day-to-day lives. Here at Livecycle, we’re uniquely positioned to do this because we are building a product that helps teams build products. Using our own product to actually build our own product has given us an opportunity to dogfood in a unique way by deriving real benefit from the product as we build the product itself.

And this internal effort is not limited to the confines of our team internally. We’ve been working with a remote development company on refreshing parts of our marketing site, and we’ve deliberately used Livecycle to manage that workflow. This experiment has helped us to test and validate part of our GTM strategy - positioning Livecycle with devshops specifically, and for remote team collaboration more generally. These real-life dogfooding sessions with our outsource partner have shown us just how beneficial Livecycle can be in these use cases.

As we look ahead, we’re trying to push the envelope even further with our dogfooding strategies. One idea that we’re tossing around is a “Livecycle binge” in which we run an entire development sprint exclusively through Livecycle. No email. No Slack. Only using our platform to communicate with one another and review PRs. And even though Livecycle is intended to seamlessly integrate with the other communication and project management tools, our theory is that test our product in more extreme dogfooding conditions will teach us a lot about what our product can do.

Assumptions and free advice

In addition to sharing our experiences, it’s also worth listing a few of the underlying assumptions and opinions we’ve developed around dogfooding do’s and don’ts. So here are a few things we suggest you keep in mind when developing your company’s internal dogfooding policy:

• Our assumption is that dogfooding is only possible when you can it so end-to-end as an end-user would do in an authentic way. Testing specific features one at a time is called R&D. Not dogfooding. Dogfooding should be company-wide. Not just for developers and product managers. Aside from the benefits of a more inclusive approach that we’ve already enumerated, this also helps avoid bias and emotional dishonesty. It’s hard to be objective about something that you spent so much time building yourself. So make sure to dogfood with people throughout the company, not just the small group of people who actually worked on coding and designing this version of the product itself.
• Lots of people claim that effective dogfooding can only happen before a product goes to market. This is a big misconception. Continuing to use the product after it’s publicly available has many benefits for your product and your team, as we’ve outlined above.
• Remember that dogfood tastes bad. Sometimes it tastes really bad. Dogfooding is not an excuse for you to show off how amazing your product is. It’s an opportunity to create friction with users and embrace deliberate discomfort. The goal is to help you see what’s NOT working, not to pat yourself on the back for what is.
• If you’re eating dogfood, you’re pretending to be a real dog. So if you’re dogfooding your product, pretend to be a real user. That means focusing on the entire user experience journey and not only on the shiny new features that were newly implemented. For an unassuming new user, the most important part of the process is the onboarding and initial setup. So to dogfood properly, make sure that you and your team are giving these “boring” parts of the product experience at least as much attention as the fun stuff. How you use dogfooding in your own company will depend on a lot of factors. But what’s abundantly clear is that it’s worth investing the time to think it through. Because a solid dogfooding strategy will have positive effects on your users, your product, and your team.