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" 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.
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.
"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."
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.
Comments (0)