Eat Your Own Dog Food: I Wrote This Article Using VoiceDoz

I didn’t type a single word for this article.

Every sentence you are reading now was spoken to VoiceDoz, which helped me organize my thoughts.

So, I want to talk about an old saying: Eat your own dog food—use the product you created yourself.

A Saying That’s Been Overused

This phrase was first promoted by Microsoft, and its meaning is straightforward: those who create products should use their own products.

This principle is well understood. It’s indeed unreasonable for someone to create a product and not use it themselves.

However, what I want to emphasize is not this aspect. “You should use it” is the baseline, not the highlight. Treating it as a noteworthy experience is too superficial.

What truly changed my perspective on this saying was this past month—I used VoiceDoz as my daily voice input tool while simultaneously making improvements based on my experiences.

During this process, I discovered that the real value of dogfooding lies not in the act of “using,” but in encountering insights that testers will never report and that you wouldn’t think of when writing requirements.

Let me give you a specific example.

A Detail I Never Considered While Coding

The core of VoiceDoz is to transform your spoken words into clean, coherent, and usable text.

Speaking is different from typing. Typing involves thinking before you type, while speaking is thinking and speaking simultaneously. Therefore, spoken language naturally contains a lot of “impurities”: filler words, colloquialisms, and repetitions.

VoiceDoz doesn’t simply convert speech into text verbatim—if it did, the screen would be cluttered with “um,” “that,” and “you know,” making it harder to use than typing. Instead, it applies a layer of AI refinement to remove these repetitions and filler words, leaving behind clean content.

Sounds clear, right? It wasn’t until I used it daily that I encountered a problem.

Repetitions in speech actually fall into two categories.

The first type is correction. For example, I might start saying, “We have a meeting on Wednesday,” then halfway through change it to “No, Thursday.” This type of repetition should be removed—only “Thursday” should remain.

The second type is emphasis. If I repeat a point three times, it’s not because I’m verbose; it’s because I want to emphasize it. If you treat this repetition as an impurity and remove it, I lose the very information I care about most.

The problem lies here: both are “repeated words,” but one should be removed while the other should be kept. How does the program know whether I’m correcting myself or emphasizing something?

If it removes the wrong one, I lose information. If it keeps the wrong one, it becomes verbose.

This distinction was something I never thought to ponder while sitting there writing code. In a developer’s mind, “remove duplicates” is a clean-cut requirement, a matter of logic.

It was only through daily interactions with the tool and repeatedly encountering situations like “Oh, I meant to emphasize that; why was it removed?” that I realized there was a delicate balance that needed to be precisely calibrated.

I spent considerable time refining this, ultimately deciding not to pursue a perfect judgment where the “program always guesses correctly”—that’s unrealistic. Instead, I made it a tunable balance: the output can lean towards “refined summaries” or “faithfulness to the original text.” This allows users to choose based on their current context rather than forcing a single answer.

This Is What Developers Can Never Provide

Looking back, why was this detail something I didn’t think of while coding, but encountered immediately when using the product?

Because the developer’s perspective and the user’s perspective are two completely different viewpoints.

When writing code, I think about “how to clean up the speech”—that’s a function. When speaking, I think about “how to accurately express this meaning”—that’s an intention.

Some requirements only exist in the moment of “speaking with genuine intent.” You can’t think of them while sitting in front of an editor because, at that moment, you have no intent; you only have functionality.

The true power of dogfooding is that it forces you to switch from the developer’s perspective back to the user’s perspective. It’s not about “testing” your product; it’s about truly becoming a user of your product, using it with real needs, and then encountering those insights. Those insights are things that will never appear in a testing report.

I previously mentioned in Founder’s Playbook that some things founders must personally engage in, not to complete a task, but to gain firsthand experiences that can only be obtained through personal involvement.

VoiceDoz is a proactive product; its lifeblood is judgment, and that judgment comes from being present.

Eating your own dog food is the simplest and most concrete form of “being present.”

Conclusion

Using your own product every day yields the most direct reward: the improvements are immediately noticeable.

It’s not something you see in the data; it’s when I say something, and it responds smoothly today compared to yesterday—I instantly know.

And the best evidence is this very article.

Every sentence you’ve read so far was spoken by me and organized by VoiceDoz.

Is it easy to use? I don’t need to ask testers—I use it every day, including right now.