So… What exactly is dogfooding? If you’ve worked in a tech company, you’ve probably eaten some dog food. Or to be more precise - 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. https://www.youtube.com/watch?v=cHUMaKWgfS0&embedable=true 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). https://www.youtube.com/watch?v=eiYoBbEZwlk&embedable=true 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 remains 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 of Dogfooding Even outside the context of the product itself, we’ve found that dogfooding has benefitted our company. A few examples: Company pride (or shame) - An intangible benefit to dogfooding is its 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 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 allowed us to dogfood in a unique way by deriving real benefit from the product as we build the product itself (sounds kind of meta when I read that back to myself). 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 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 we’ve tossed 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 testing 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 at Livecycle, I’ve put together a list of suggestions to keep in mind while developing your own company’s internal dogfooding policy: Develop a dogfooding strategy! Spend 5 minutes thinking about how you can best leverage your team’s talent, interest and day-to-day cadence to actually use your own product in a productive, authentic way Dogfooding is when the product can be used end-to-end as an end-user would, in an authentic way. Dogfooding is not the same as testing. Testing specific features one at a time is called R&D. Not dogfooding. Dogfooding should be a company-wide affair. 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. Many 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. The goal of dogfooding is not 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. There are many factors to consider when developing your dogfooding strategy. But what’s abundantly clear is the importance of investing the time to think it through. Because a solid dogfooding strategy will undoubdedly have positive effects on your users, your product, and your team. Also published here. So… What exactly is dogfooding? So… What exactly is dogfooding? If you’ve worked in a tech company, you’ve probably eaten some dog food. Or to be more precise - 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. https://www.youtube.com/watch?v=cHUMaKWgfS0&embedable=true https://www.youtube.com/watch?v=cHUMaKWgfS0&embedable=true 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. promotional marketing tool 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). SawStop https://www.youtube.com/watch?v=eiYoBbEZwlk&embedable=true https://www.youtube.com/watch?v=eiYoBbEZwlk&embedable=true Dogfooding in Tech - More Than Just a Marketing Play 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”. 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.” that that 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”. issued a mandate easily communicate 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? 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. Livecycle 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 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 remains 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. 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. High-level QA - 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 remains 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. User empathy insurance - 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. Product ideas - Other Benefits of Dogfooding Other Benefits of Dogfooding Even outside the context of the product itself, we’ve found that dogfooding has benefitted our company. A few examples: Company pride (or shame) - An intangible benefit to dogfooding is its 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 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. Company pride (or shame) - An intangible benefit to dogfooding is its 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. Company pride (or shame) - media 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 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. Better context for everyone - How We’re Taking Dogfooding to Another Level 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 allowed us to dogfood in a unique way by deriving real benefit from the product as we build the product itself (sounds kind of meta when I read that back to myself). 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 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 we’ve tossed 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 testing our product in more extreme dogfooding conditions will teach us a lot about what our product can do. Assumptions and Free Advice Assumptions and Free Advice In addition to sharing our experiences at Livecycle, I’ve put together a list of suggestions to keep in mind while developing your own company’s internal dogfooding policy: Develop a dogfooding strategy! Spend 5 minutes thinking about how you can best leverage your team’s talent, interest and day-to-day cadence to actually use your own product in a productive, authentic way Dogfooding is when the product can be used end-to-end as an end-user would, in an authentic way. Dogfooding is not the same as testing. Testing specific features one at a time is called R&D. Not dogfooding. Dogfooding should be a company-wide affair. 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. Many 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. The goal of dogfooding is not 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. Develop a dogfooding strategy! Spend 5 minutes thinking about how you can best leverage your team’s talent, interest and day-to-day cadence to actually use your own product in a productive, authentic way Develop a dogfooding strategy! Spend 5 minutes thinking about how you can best leverage your team’s talent, interest and day-to-day cadence to actually use your own product in a productive, authentic way Dogfooding is when the product can be used end-to-end as an end-user would, in an authentic way. Dogfooding is not the same as testing. Testing specific features one at a time is called R&D. Not dogfooding. Dogfooding is when the product can be used end-to-end as an end-user would, in an authentic way. Dogfooding is not the same as testing. Testing specific features one at a time is called R&D. Not dogfooding. Dogfooding should be a company-wide affair. 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. Dogfooding should be a company-wide affair. 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. Many 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). Many 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). before Remember that dogfood tastes bad. Sometimes it tastes really bad. The goal of dogfooding is not 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. Remember that dogfood tastes bad. Sometimes it tastes really bad. The goal of dogfooding is not 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. 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. There are many factors to consider when developing your dogfooding strategy. But what’s abundantly clear is the importance of investing the time to think it through. Because a solid dogfooding strategy will undoubdedly have positive effects on your users, your product, and your team. Also published here. Also published here. Also published here . here
