Dogfooding. Hmm, maybe something my pet Labrador would love to chat about.
Thus thought I, when this topic first landed on my desk. Oh, how wrong I was!
The term ‘dogfooding’ has been in a coding lexicon since the late 1980s. It perhaps has its origin in the Alpo dog food commercials headed by actor Lorne Green. The phrase ‘eating your own dog food’ shows that one was proud enough of the products they built to use it on their own.
In the IT world, the use of the word ‘dogfooding’ can be traced back to Microsoft’s Paul Maritz who, in 1988, challenged the company’s employees to use the products they built. The idea behind it was very simple – if Microsoft’s own were not confident enough to use the software they spent hours making, why would someone else pay for it?
So, what really is dogfooding?
More importantly, how is dogfooding different than the normal QA tests that every product has to go through? Let’s clarify!
While both alpha and beta testing phases are important in software development, dogfooding is slightly different than both. While both processes – dogfooding and testing – involve using the software to see how it holds up in different use cases, the focus during alpha and beta testing is on finding code bugs and errors. Dogfooding, too, can help dig up errors in the product; however, the main focus here is to interact with the software as a user and find how the developers can improve upon the base infrastructure.
Let’s take an example here.
Say you were testing out an email client. During the QA phase you would look at how the client performs when handling bulk emails; if the spam filter is working well; if image-heavy newsletters are rendering well. These are known use cases that every quality check would include.
During the dogfooding phase, you spend days, weeks, months using the product. You are not actively looking for bugs, but trying to sense if the product you built is easier to use versus other email clients you have used in the past. Is the UI/UX easy to navigate? Are the features useful? Most importantly, how much do you itch to go back to your previous email sender? If you itch for a change, most probably your prospective users will, too.
How do you integrate dogfooding in your testing strategy?
Dogfooding can be used as a complementary and cost-effective testing strategy that works in tandem with your established alpha and beta testing process. Dogfooding can in fact, be used synonymously with internal beta testing.
Letting the internal team test out a new product before the end users is beneficial for two reasons:
- External users who come across major difficulties or bugs in your product will most likely stop using it. This effect is easily counteracted by dogfooding.
- Second, you will not only spare the customer support team a lot of heartache, but also help them prepare better for user queries.
What makes dogfooding a great beta testing strategy?
Google, that much-loved tech giant loves dogfooding. Here’s what they say about using dogfooding and beta testing on the Google Testing Blog: “We have a large ecosystem of development / office tools and use them for nearly everything we do. Because we use them on a daily basis, we can dogfood releases company-wide before launching to the public.”
When a name like Google stands behind a process, you know it has some merit. Here are some of the benefits of dogfooding during standard testing:
1. Allows you to scale quality testing environments with real-time feedback: Dogfooding helps developers flag the flaws in their original design. We know that it is very hard to exhaust a product in terms of testing – it takes months; and the whole process repeats itself when you add new features. When developers ‘eat their own dog food’, it helps widen the QA pool and look for nuances no one would have thought of.
2. No risk of losing customers: A lot of the time, businesses are under tremendous pressure to release a product. While timelines need to be adhered to, they cannot come at the cost of quality. By turning your company employees into users, you ensure that quality is maintained and no customer is irked or lost in the process.
3. Cuts down on development and support costs: What’s easier – shipping a half-baked product and then hiring a huge support staff to field customer calls and queries, or spending time and effort testing the product and then asking customers to use it? By using dogfooding as a beta testing standard, you can cut down on all these extra overheads.
4. Creates a collaborative environment and breaks down departmental silos: When every employee in the org uses their products, they have a better understanding of how things work. It will help the product team close the distance between them and the end users, and prepare your CSM team to handle incoming requests.
While these are some good reasons to use dogfooding, there may be instances in which it may not be a good fit for your company. A couple of them come to mind:
Scenario 1: When you have created a specialized software
If you create a software for a very niche target audience, then it may not be a good idea to have your team use it and send feedback. Let’s say you have a product aimed at doctors, then you cannot have someone who has no knowledge of medicine using the product and testing it.
Scenario 2: When your product is still in an immature stage
Dogfooding should be done only when the product enters a certain stage of development. If you have just created an MVP, asking your entire team to test it may not be a good idea. While you may receive a ton of feedback, it might end up creating obstacles in product development instead of speeding things up.
How to roll out a dogfooding program?
The first step is to create a product that users are going to love. In the world of SaaS, they say that you should create products that “solve your own problem”. Once you have this figured out, the rest is a 4-step process that I will list out below:
1. Secure the right buy-ins: Dogfooding is an org-wide exercise and it is important that everyone knows why it is necessary, and what are the expectations from them. Folks in non-technical functions like marketing or sales may not always know how to spot or report an error. A small crash course will help tons! Moreover, it will prevent your teammates feeling like they have been forced to do QA on behalf of the product/engineering team, and give up the right to use products and platforms they actually would on a daily basis.
2. Segment the testers: Different user segments would have different requirements from the same product. It is a good idea to segment your colleagues into buckets so you know what kind of requests are coming from the CXO-level users, and what are the main pain points of a mid-level manager. You can then choose to address these issues based on your internal priority list.
3. Set up a feedback mechanism: Going back to point #1, not every person in your company is a QA or an engineer, or even familiar with the process of reporting bugs, or raising a feature request. Create a feedback mechanism which is simple to use and help your co-workers familiarize themselves with it before you ask them to test the product.
4. Incentivize the process: Last but not the least, have fun with it! Gamification is a proven way to get people involved in serious tasks like hunting bugs 🙂 So, add incentives and giveaways for colleagues who report major issues, and whose feedback helps in improving the product.
5. Account for bias: At the end of the day, your colleagues and co-workers may have a bias towards the product because it’s their handiwork. Don’t forget to factor that in when you look at the feedback. In this case, your harshest critic is your best friend!
Eat the dog food, but don’t make it dinner!
I hope this piece has helped you understand the dos and don’ts of dogfooding during product development. Remember this though – dogfooding is not an alternative to alpha and beta testing, neither should it be the sole bulwark supporting your product development cycle.
Use it wisely and it can make a world of difference to your engineering teams. Now back to feeding the Labrador, I go!
