Eating your own dog food - Using your own product

Eating your own dog food - Using your own product

Daily short news for you
  • countless.dev is quite an interesting website as it compares the costs of using LLM models from different providers.

    Here, you can see all the popular large language models from providers such as OpenAI, Azure, Mistral... The pricing for each 1M tokens in input/output. Or you can even compare them with each other to find the cheapest provider or model depending on your usage purpose.

    » Read more
  • 1-2 years ago, Kubernetes (k8s) was suddenly mentioned as a phenomenon, probably because it was so powerful that everyone wanted to learn and use it. It is a tool for "Automating deployment, scaling, and management of containerized applications" - Yes! Sounds impressive, right? 🤤

    Back then, I was passionate about Docker, especially Docker Swarm, which is similar to k8s but on a smaller scale. Docker Swarm seems much less complex than k8s. And that was good because it was already meeting my usage needs at that time, while also reducing complexity and hassle.

    However, in the last 1-2 months, articles titled "Do you really need Kubernetes?" have been popping up more frequently. Indeed, k8s is very powerful but also overly complex. Why bother using a knife "to butcher an ox to kill a chicken"? Unless you anticipate the complexity when wanting to apply a technology. Another thing is that k8s consumes resources and power tremendously; getting it up and running is not just about setting it up, but you also need a lot of knowledge 😨.

    Oh, perhaps part of it is because the "big players" are focusing on Serverless, reducing the complexity in operations and instead focusing on application development.

    Besides that, the name WASM is also being mentioned a lot 🤔

    Do you really need Kubernetes in your company/startup? | dev.to

    Do You Really Need Kubernetes?

    » Read more
  • I used to praise Serverless endlessly, claiming that it optimizes costs down to 0 VND to maintain blogs and such. It's true! But alongside that, Serverless also has its dark sides that are worth paying attention to!

    The other day, I spent a whole day tracking down and fixing an issue just because I called the built-in function of Cloudflare KV. Specifically, the list function with a limit of 1000 - which means that a single call returns 1000 keys of KV. However, life is not as dreamy as it seems. The number 1000 is only theoretical. Sometimes it returns a few hundred, sometimes just a few dozen, and at times it barely returns a handful. This caused a congestion in the entire system. Well, it wasn't exactly congestion; rather, the system was "idle," having nothing to do, when in reality it should have been processing hundreds of thousands of keys 🥲

    » Read more

The Issue

Many years ago when I first started my internship, I worked at a company specializing in making products and then doing business based on those products. Nowadays, people often call it a Products company. The main product at that time was for business customers. Later, I learned it was the B2B model - that is, selling to business customers. Although I was directly involved in the product development phase, to be honest, many features that I created, I did not understand why they should be made.

B2B was too complicated for a fresh graduate lacking experience. I could add features as requested, but I couldn't explain why they should be done. "Oh well! Maybe I don't need to care too much," I told myself. As long as I can code, it's fine. For now, the focus should be on improving coding skills better day by day. The leaders are free to discuss and then hand down features, and soon they will be "done" in a flash.

At the same time, I was extremely puzzled as to why a senior in the team was willing to "argue" with the boss just because a button shouldn't be placed here, but must be over there? Why? Isn't the boss always right? Or at least if it's a request from the boss, we should listen! Right? Wow!!!

After many company transfers, I always worked in companies that made and sold their own products. It's like a hobby. This time the product still served mainly small and medium business customers, entrepreneurs... Once again as a developer, but what I cared more about was the technology, how to design the system to work, serve as many users as possible was important.

But this time there was a significant change in my long-standing thinking. A major turning point for me because here I learned a lot more about how to make products. How to create useful products, with users, and how to sell them. Terms like MVP (Minimum Viable Product), KISS (Keep It Simple, Stupid), YAGNI (You Aren't Gonna Need It), Win-Win... appeared and jumped into my mind one by one. Gradually changed the thinking that the role of technology was no longer the top priority, instead, try putting yourself in the user's position to see how good your product is, see if you want to use it or not.

After some time, I returned to a promising product at another company. Apply what I learned. Temporarily put aside "expensive" technical debts, what I cared more about was the user experience, how they use the product, and from there propose more optimal solutions. Also during this time, I rebuilt my personal blog.

As I've shared with readers in many articles about the journey of making a blog. Initially, I just thought simply of creating a place to write, focusing on words, and believing that users would like that. Because it helps them focus more on reading instead of looking at other potentially distracting things. So the blog at that time had nothing but words. After seriously putting myself in the reader's position, I gradually visualized what they saw and what they needed. From there, continuously improve the website day by day. Honestly, the version you are seeing now is already the 4th or 5th version of 2coffee.dev!

The above can be summarized that I have learned many things about making products through using my own products. Today, my boss suddenly mentioned the phrase "Eating your own dog food" and challenged everyone in the company to know what it implies. Oh, turns out there's a phrase that expresses the long-standing thought that I've been applying.

"Eating your own dog food"

"Eating your own dog food" is a figurative expression, implying the use of one's own created product or service. The purpose is to better understand the quality, effectiveness, and experience that the product brings to users.

Simply put, you can imagine it like this, if you eat the dish you cook, you will know if it is delicious, salty or bland, or what needs improvement. In software development, when developers use their own products, they will discover bugs, see what is not good, and find ways to improve the user experience.

In reality, not everyone has the condition to use their own made products. For example, it may be a specialized product, intended for a specific group of users that lies outside our normal usage needs. Or you work in an Outsourcing environment, processing a part or a feature in a large product. Therefore, "Eating your own dog food" is not necessarily applicable in all cases but depends on each person, each environment. However, if you have the condition, try applying it because it helps you a lot in the product-making process.

Why should you "Eating your own dog food"?

Using your own product to understand it better. What's better than changing the working environment and starting by using the product to understand more about what is available. Or if you've been working for a while, using the product also helps in developing later features, anticipating the impact of new features... I always show caution before any changes, even the smallest ones in the product, don't dare or need to carefully consider when removing or modifying a previous feature. Because I'm not sure if it affects other features? Even some managers don't grasp the relevance because the product has gone through many people. At times like that, the best way is still to use the product to know the level of impact of the features with each other.

When focusing on the user role, we will have similar behaviors to users, will see reasonable or unsuitable things in daily operations, from there propose to improve product quality. Occasionally, I still read back the articles on the blog as a user, perform actions such as searching, commenting, evaluating articles... to find things that can be improved to bring the best experience for users.

Additionally, daily use also helps us spot issues early, before the end user. In many applications, a feature is integrated to report errors to the developer, allowing users to report bugs during use. In reality, when applying "dog food", I have been reporting many errors to the product development team with me. Sometimes even boldly propose a "Bug Hunters" title, or a reward like "Bug Bounty" worthy of what I have done. At times like that, everyone laughs out loud in the office.

Using your own product also indirectly enhances the reliability and credibility of the product. It will be very difficult to persuade others to use a product that even you don't use yourself. In case you still have the potential for normal use. And if you want to share a good application with others, you must be a regular user to see the need and also advise them on suitable features.

Conclusion

"Eating your own dog food" is placing yourself in the user's role to experience your own product, thereby improving many things from daily operations to enhancing the reliability and credibility of the product. What about you? What product are you making and do you use it as well as be ready to share it with others? Please leave your opinion in the comments section below! Thank you."

Premium
Hello

5 profound lessons

Every product comes with stories. The success of others is an inspiration for many to follow. 5 lessons learned have changed me forever. How about you? Click now!

Every product comes with stories. The success of others is an inspiration for many to follow. 5 lessons learned have changed me forever. How about you? Click now!

View all

Subscribe to receive new article notifications

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.
Author

Hello, my name is Hoai - a developer who tells stories through writing ✍️ and creating products 🚀. With many years of programming experience, I have contributed to various products that bring value to users at my workplace as well as to myself. My hobbies include reading, writing, and researching... I created this blog with the mission of delivering quality articles to the readers of 2coffee.dev.Follow me through these channels LinkedIn, Facebook, Instagram, Telegram.

Did you find this article helpful?
NoYes

Comments (1)

Leave a comment...
Avatar
Ẩn danh1 month ago
rất hay bạn
Reply
Avatar
Xuân Hoài Tống4 weeks ago
Cảm ơn bạn nha 🙏