Food Is the Best Medicine

Dogfooding: Taking the medicine that transforms your product's constitution

Why do we keep building things users don't want?

A feature we spent months polishing becomes a headache the moment it launches.

The user response is ice cold. "What is this?" "Why do we even need this?" The metrics fall short of expectations, too. Retention is in the gutter, and the revenue we hoped for is nowhere to be seen.

We obviously worked hard on the product specs, so where on earth did it all go wrong?

Looking back, it's mostly the same pattern. The starting point was from the user's perspective, but we slip up little by little as we flesh out the solution. With every meeting, the provider's self-satisfaction creeps in: "Isn't this good enough?" Before we know it, it becomes a product that users neither want nor understand.

Sometimes we even build all the features perfectly, only to trip over the final copy. Terms like 'sync', 'renew', or 'guest mode'. They're familiar to the people making them, but the people using them have no clue what they mean. The moment we think, "They'll probably understand this much," we've already distanced ourselves from the user.

That's why we need a mechanism to constantly check, "Are we looking at this from the user's perspective right now?" We might cross-check each other during planning syncs or compare it against well-made third-party products. Among these, there is one method that is the most intuitive and powerful.

It's dogfooding.

Dogfooding: The fastest way to become a user

Dogfooding is simple. It's us actually using the product we built. It's taking off our provider badge for a moment and sitting in the user's seat.

It's effective at any point in the product cycle. When looking for improvements in an already launched feature. When doing a final sweep right before deployment. When all you have is a prototype. Even experiencing third-party services during the planning phase is a form of dogfooding in a broader sense.

However, one thing is certain. The earlier you eat it, the better.

If you find a problem after deployment, you have to do damage control. If you find it after development is complete, your schedule gets derailed. But what if you find it during the planning phase? The cost to course-correct is drastically lower. Late dogfooding acts as medicine, but early dogfooding is a vaccine.

How to eat: The food list and dogfooding meetups

You might think, "Can't we just use it frequently?" You're right, but the problem is that it doesn't happen easily. Just like knowing reading is good but never opening a book, or knowing exercise is good but never hitting the gym.

Our team turned this into a sort of study group.

First, we maintain a food list. We list up third-party products worth trying out periodically, or specific flows within our own product. Things like, "This week is the OO feature flow," or "This week is competitor A's checkout experience."

Second, we eat together. If you eat alone, you tend to just scarf it down. If you eat together, you chew carefully, and as different perspectives clash, you see things you wouldn't have noticed on your own.

Third, we reflect it in product improvements. We leave behind the discomforts, questions, and ideas we felt while eating right on the spot, and use them as seeds for planning.

There are many actual cases where this paid off.

It was when we were building a mini-game event feature. It was a simple structure where succeeding in a mission within the time limit made you eligible for a raffle. What kind of game would be fun, what difficulty level would be appropriately thrilling, whether a warning popping up when time is running out adds to the immersion — we decided all of this by playing it ourselves. The parts we had glossed over in the meeting room with "This should be enough, right?" felt completely different when we actually tried them.

It was the same when building a character-raising feature. There were things we could only see by playing it ourselves. "Why does an ad suddenly pop up here?", "Is it okay to click this button?", "Why does the waiting time feel so long?"

Things that looked perfectly fine on the product spec became blatantly obvious the moment we sat in the user's seat.

It's not perfect, but it's pointing in the right direction

Honestly, dogfooding has its limits. No matter how much we pretend to be users, we already know the planning intentions and understand the full context. We can't perfectly replicate a real user's first impression. That's why we have to use methods like VoC, user interviews, and surveys in parallel. Listening directly to the users' voices holds an irreplaceable value.

Even so, dogfooding definitely has its own distinct usefulness.

First off, it's fast. In the time it takes to recruit for interviews, draft questionnaires, and schedule them, you could eat dogfood more than ten times. You can start right this second without any extra resources.

And as this piles up, your constitution changes. When designing a feature, "How will the user feel about this?" comes to mind first. It's not just me; all the teammates eating together — product planners, designers, engineers — all end up looking in the same direction. We unearth great ideas for improvement, and we catch fatal issues before launch. There are immediate results, sure, but having the entire team aligned toward the user — that is the far greater harvest.

Try picking just one item for your food list at next week's team meeting. You can start from there.

It's okay if it feels awkward at first. Once you get a taste of it, you'll keep going back for more..!