Fast Food: The Reality of Eating Our Own Dog Food

Fast Food: The Reality of Eating Our Own Dog Food

The good, the bad, and the ugly in making the employees of our company use the product we are building

Eat your own dog food sounds creepy. Dog food looks bad, smells awful, and tastes like something only dogs should eat.

Still, we often hear an executive manager proudly use this phrase when talking about the product her company builds. It’s so common that we don’t even bother to stop and think:

• What is the value we get from making the employees of our company use the product we are building?
• Why are we so fanatic about it?
• Does it justify the cost and effort involved in making it happen?

The way I see it, dogfooding our own product is like consuming fast food.

In this post, I will explain my perspective by listing the good, the bad, and the ugly aspects of eating our own dog food.

The Good:

Let’s start with the positive side. What are the advantages of making the employees of our own company use the product we are building?

1. Instant Feedback:

Calories! Our body needs the energy to function. Without it, we will starve and eventually die. Fast food gives us instant energy. It might not be the best kind of energy for our body, but it’s better than nothing. The same is true for product feedback. Our colleagues will give us instant feedback. It might not be the best product feedback, but it’s definitely better than building a product with no feedback at all.

2. Accessible:

It’s everywhere! Fast food can be found on the street, at the mall, at gas stations, everywhere. We just need to stop and grab it. The same is true for dogfooding our product. The employees of the company are there, just one email/slack message away.

3. Inexpensive:

Money on the floor! Fast food is cheap. The same is true for dogfooding our product. We only need to ask/tell the employees of our company to use the product. No special incentives or promotions are required. There is no cheaper or faster way for getting people to use our product.

4. Direct:

In our face! Fast food is either good or bad. I usually know to which bucket it falls right after the first bite. The same is true for dogfooding our product. Our colleagues will provide us with quick and direct feedback. Usually, it’s either they enjoy using the product, or they curse us every morning for making them use it. In the latter case, they will be very generous and detailed in describing their suffering.

5. Risk-Free:

What happens in Mcdonald’s, stays in Mcdonald’s! With internal users, we can allow ourselves to expose and get early feedback even on half-baked features. Quality issues, performance issues, and even security issues can be temporarily overlooked. Naturally, this is not the case with external users, even within a Beta program.

6. Customer Centricity:

Think like a customer! Having all employees of the company use the product adds business context and a pragmatic approach to many discussions and decisions that are made across different departments. The sales department is the most natural example, but although it may sound weird, I have seen how discussions in HR and Finance become more effective by the fact that using the product on a daily basis makes everyone customer-centric.

7. Killer Showcase

See how I am eating it myself! When talking with a customer or a prospect, being able to demonstrate the value of the product through a real personal use case is the ultimate tool. It creates engagement that no other demo technic can match.

8. Company Values:

Put our money where our mouth is! We should never ask our customers to trust us and use our product unless we genuinely believe that the product is stable and valuable. And if we believe that the product is valuable to our customers, it must be valuable for us as well.

The Bad:

Now let’s switch sides and move to negative. This is not really a list of disadvantages, but more like a list of things that we must remember when dogfooding our own product.

1. User Profile:

Are you talking to me? Receiving quick and direct feedback from internal users is great. But we must always ask ourselves if those users represent the target audience of the product. Note that business titles aren’t sufficient here, as “IT Manager” in our company might be different than “IT Manager” in a much larger/smaller company or a company from a different industry. My tip here: regardless of dogfooding, do user persona mapping. Assuming you have well-defined personas, assessing how well an internal user fits into one of the target personas shouldn't be difficult.

2. User Motivation:

I didn’t even know I had this problem! Another issue with internal users is that they don’t always use the product to solve the same problem you designed it. After all, in many dogfooding scenarios, the users didn’t really know they had a problem or were looking for a tool to solve it. They were simply told that they have to use the product. The result might be frustration from the forced users, as well as irrelevant product feedback.

3. Sales Cycle:

There ain’t no such thing as a free lunch! Internal users don’t buy the product. They are getting it for free. This means that we don’t get a chance to test our product strengths & weaknesses in a sales cycle. Even in a successful dogfooding, several important questions will remain unanswered: What is the best way to explain the pain our product solves? How to discover and quantify that pain? what are the differentiated value props of our product? what is the best way to provide prospects a demo/POC of the product? What is the right packaging and pricing strategy?

4. Implementation Process:

We are cooking with gas while they are cooking with a candle! The way a product is implemented internally is very different than the way it’s implemented by real customers. The main difference is that while internally we have an army of product experts, a real customer will typically have a smaller implementation team with much less experience with our product. The fact that we managed to achieve high adoption and engagement with the product internally, doesn’t mean we can expect the same great outcome when the implementation is done by a real customer.

The Ugly:

Finally, there are the big mistakes we might do when dogfooding our own product. When any of these happens, we are probably on the wrong path and that’s when we must stop and rethink the whole dogfooding idea.

1. Size Matters

Super Size Me! Things that work smoothly in our small/medium company might not work at all in a large enterprise. it simply works differently there. From the initial deployment (especially if our product has technical pre-requisites or integrations with other systems) to onboarding users and granting them permissions (based on strict per department policies), and all the way to how the product is actually being used. Don’t be surprised if a process that was completed internally in few hours, requires multiple approvals and takes few months and in a large company.

2. Forgetting Why

Choose your battles! Dogfooding goes sideways when we are doing it for the wrong reasons or even worse when there is no alignment in the company for why we are doing it. The most natural misalignment is when the IT department is pushing to implement the product in a way that will generate the most value for employees, while the product and R&D departments are pushing toward implementation that is more aligned with what real customers (in many cases a different type of companies) would use the product for. They will also push for using the new shiny product features that might not be fully ready for prime-time usage, which again is in conflict with giving internal users the best service and product experience.

3. Getting Addicted

Bad habits are easy to develop and hard to live with! Be aware of the addictive nature of dogfooding. I have seen cases where we started doing it as yet another mechanism to collect feedback (leveraging the unique advantages) but gradually made it the sole feedback mechanism, completely giving up on product validation and real market feedback. The clear sign that you are getting addicted is that your “go-live” plan for new features involves an “internal release” immediately followed by general availability, skipping important phases like a beta or an early adopters program. This means that all the early feedback you have is based on internal users, which might result in bad decisions like wrong MVP scope, wrong quality standards, wrong perception about feature complexity, and many more. We must always remember that our data-driven product roadmap is only as good as the data we feed it.

“The problem is when that fun stuff becomes the habit. And I think that’s what’s happened in our culture. Fast food has become the everyday meal.” (Michelle Obama)

Conclusion:

When we are dead hungry or just need some comfort, a nice burger with a pile of french fries is completely OK. It’s fast and easy and it won’t kill us. But let’s not confuse it with a real meal which is what our body needs in order to be strong and healthy.

The same applies to having the employees of our company use the product we are building. We will definitely get a sugar pump in the form of direct feedback and some quick usage trends to play with. But let’s not confuse it with user research and market validation done on real customers which is what our product needs in order to be strong and healthy! Thanks for reading.

‍