The Risks of Dogfooding and When Not to Dogfood

The practice of dogfooding or “eating your own dogfood” has been around long before the phrase was coined. After all, many products have been developed to scratch an itch. And today, dogfooding is a widely adopted best practice across many industries, with software development leading the path.

However, despite its popularity, there seems to be a lot of confusion about what it actually is and how and when it can be of value. In this post, we will take a look at what dogfooding is, its risks, and when to skip it.

‍

‍

The biggest myth that needs to be busted about dogfooding is that it is about testing your app. While dogfooding does a great job of uncovering issues in your app’s code and UX, this is just an added benefit rather than the main goal. The real goal is to put yourself in your users' shoes and see things from their perspective, building your empathy with your users and increasing your understanding of their needs and pain points. It is something that needs to be embedded in your culture to unlock its full potential.

Consequently, ideal dogfooding involves using your app in a real-world environment for the same purpose and in the same way your end-users would. Using your app through emulators and test devices, i.e. in a lab environment, is just testing. No matter how many bugs and crashes you find in this way, it does not help you see through your users’ eyes.

Likewise, adapting your app to be used for a different use case than it was intended for will not give you the whole picture. Again, you will find and fix many issues and identify areas of improvement in your app's experience and flow, but these might not be as important to your users as they are to you. This isn't to say that adapting your app for a different scenario is without merit, as long as you keep in mind that you are not your user. There can be what we can call "degrees of dogfooding" depending on how far removed your use case is from that of your users.

‍

‍

There are a number of inherent risks with dogfooding that can affect your results and steer you off course. This does not necessarily mean that you should forgo it altogether, but you need to be aware of them in order to mitigate them and put your results in perspective.

‍

Aligning with the wrong target audience

First and foremost, you need to define your target audience and determine how close your needs and pain points are to them. There is nothing worse than spending time and effort to develop and perfect your app only to find that your users hate it. You need to make sure that the feedback you get from dogfooding is in line with what your users think by actually communicating with them and soliciting their feedback. Otherwise, you risk building an app that works really well for your team but considerably less suited to your end-users.

‍

Increased familiarity with the product

Your team is a lot more familiar with your app than your customers are. They will know all your app's features, where to find them, and how to use them, but your new users are still discovering your app's value. Make sure you include your new team members and teams that are not closely involved with the app's development to get some fresh eyes and an outside perspective. The bigger and more diverse your dogfooding sample becomes, the more accurate your results will be. This will help you make sure that your familiarity with your app does not skew your vision, but you should preferably follow up with beta testing to validate your conclusions.

‍

Bias

It is natural for your team to be biased towards the app they are building; after all, it is the sum of their hard work! This bias tends to get stronger the closer your dogfooders are to the app's development. So, it pays to include teams that are a little less involved with development in your dogfooding program especially if you are a bigger company. However, following up with a beta test is the only sure way to get unbiased feedback before you launch to your users.

‍

Over-reliance on dogfooding

While dogfooding is a great way to improve your app's quality, it is not a silver bullet that will solve all your issues. Keep in mind that dogfooding is not a replacement for proper QA testing and that your dogfooders are not supposed to do the job of QA testing. In fact, as mentioned earlier, dogfooding is about understanding your users and the issues you uncover are mainly an added bonus.

‍

Once in a lifetime scenarios

Throughout your app's experience, there are events that, although your users will only do once, can have a huge effect on the customer experience. Things like the sign-up or on-boarding experience are frequently overlooked or forgotten in many dogfooding programs. Events like these might seem minor but play an integral part in your app's adoption and should always be streamlined. Try to periodically revisit things like your sign-up and on-boarding experience within your dogfooding program or through follow-up beta testing.

‍

‍

While dogfooding certainly offers enough benefits to outweigh the risks, it is best to avoid it altogether in some cases that are highly incompatible with dogfooding. In those cases, insisting on dogfooding your product will actually cause more harm than good by either, providing misleading feedback, affecting your team's productivity, or both.

‍

Specialized software

If you are developing an app that does a very specific or specialized job which you can't use or adapt, dogfooding it will obviously produce little results. In fact, it will likely do more harm than good by wasting your time and providing you with irrelevant results that are at best useless and at worst misleading. For instance, if you are developing an app that helps doctors diagnose their patients quickly and accurately, you definitely shouldn't dogfood it and try to diagnose patients. Unless you too are a doctor, of course.

‍

Immature product

When you release a new app that is still at the MVP stage, it is very normal for it to lack many features that you might find useful. Your app might do a great job of covering its basic uses cases, but without some features that extend its functionality or increase its productivity, it can end up being more of an obstacle than a tool.