26 As a programmer, you should also listen to the voice of the users #

Hello, I am Zheng Ye.

In the previous column, we have discussed several times about communication with product managers: you should ask the product manager why they want to do this product feature, and from the perspective of MVP (Minimum Viable Product), evaluate whether the current product feature is a good choice.

However, there is another question that may bother us: how do we judge whether the product features mentioned by the product manager are really needed by users?

Many times, the product manager asks you to implement a product feature, and you feel that it doesn’t seem right, but you can’t point out what is wrong. You want to express your own opinions, but you don’t know where to start. The reason why you encounter such problems is that you are missing a dimension: the user perspective. You need feedback from the real world.

Eating Our Own Dog Food #

No matter what a product manager does, they must have a foundation to stand on: serving the users. So, if you understand how the users think, you have the ability to judge whether the requirements given by the product manager are truly what the users need.

As a programmer, lacking the user perspective, you may never have the opportunity to be involved in discussions with product managers, because they can easily defeat you with a single phrase: “This is what the users want.”

Many programmers simply want to quietly write good code. However, for most people, it is unlikely they can write good code by being quiet. Only by constantly expanding their scope of work can they hit the “target”.

Today, we are discussing the idea of expanding your scope of work to “listen to the voices of the users,” rather than just listening to the product manager.

As a programmer, you may have heard the saying “Eat your own dog food.” This saying has several different origins, all of which relate to the idea that a company selling dog food uses their own product.

Starting from 1988, this saying began to gain popularity in the IT industry. Paul Maritz from Microsoft wrote an email titled “Eating Our Dogfood,” in which he mentioned the need to “increase the percentage of internal usage of our products.” Since then, this saying quickly spread within Microsoft.

Today, it has become a consensus in the industry to use your own company’s products. Setting aside some of the advertising factors used by large companies with this saying, continuously using your own products will provide you with an additional user perspective.

When it comes to finding faults and identifying problems, humans do not need training. You can instantly feel uncomfortable with something that doesn’t work well. Therefore, by constantly using your own products, you become the user of the product yourself, which will push you to constantly think about how to improve it. When discussing with product managers, you will naturally have more dimensions to consider.

For example, when discussing MVP earlier, I once shared an experience of working on a P2P product. In this project, I acted as a user and performed some operations on the platform. When using the product as a user, I discovered some unpleasant aspects.

For instance, the initially designed vouchers could only be used once. If the value of the voucher was relatively large and I didn’t have enough capital to cover it, I could only use a portion of the voucher, creating a feeling of “wasting the voucher.”

So, I suggested allowing the vouchers to be used multiple times. Soon after, the product was redesigned to accommodate this. This improvement was subtle, and if you were not a user, it would be hard to notice such a difference from a logical perspective.

When You Can’t Eat Dog Food #

However, not every company’s product is so “delicious”. The strategy of “eating your own dog food” is relatively effective for companies that have “to C” products. But sometimes, you don’t have the opportunity to use the product you are making.

I have worked with many overseas clients, and I have made many products that I didn’t have the chance to use myself. For example, I have worked on an audit platform for a five-star hotel. Besides having a slight sense of the interface, I had no idea about the usage scenarios.

If we don’t have the opportunity to use our own products, what should we do? All we can do is to find opportunities and go to real-life scenarios to see how users use our software as much as possible.

For example, when I was working on that hotel audit platform, I went to a five-star hotel with the client and watched them check each audit item one by one and record the audit results on our platform.

Those terms that I only saw when writing code were now vividly presented in front of me. Later, when facing the code again, it no longer looked like a rigid program, and my discussions with the product manager became more solid.

Some teams have a good awareness in this regard and proactively create opportunities for members of the development team to interact with users more.

For example, let the development team rotate with the customer service team. Answer calls, listen to user complaints, and even verbal abuse. You might feel very bad, but when you calm down, you will realize what problems your software has and how much impact it would have if the software is not well done.

At this point, you can also understand why sometimes many business people get furious with the development team, because they are the ones directly facing the “fire” from users.

Why do we constantly need to understand how users use the product? Because user feedback is feedback from the real world. Not listening to user feedback can easily create a false sense of satisfaction. Do you remember the example of the king of Qalansuwa in “Why the World and Your Understanding Differ”? He only received good news.

We need to create a valuable product, and this “value” is not valuable to the product manager but valuable to the users. Huawei’s CEO, Ren Zhengfei, once said, “Let those who can hear the sound of gunfire make decisions.”

What products we make is not fundamentally decided by the product manager, but by the users. Only by hearing the “gunfire” and being on the front line, can we be more qualified to judge whether the requirements given by the product manager are truly what the users need.

When the Product Doesn’t Have Users Yet #

If your team is working on a new product that doesn’t have real users yet, what can you do? You can try the method of “user testing”.

I have previously worked on a project for an overseas client. Because the project was in its early stages, I was sent to the client’s site. As soon as I arrived, the client excitedly told me that they were going to conduct a user testing and invited me to participate. At the time, I was a bit perplexed because our project hadn’t started development yet. How could we conduct user testing for a project that had nothing? Well, they had only created a few pages and started testing.

Looking at it from today’s perspective, I have already mentioned the concepts of lean startup and MVP, so it should be easier for you to understand now. Yes, they wanted to obtain user feedback at minimal cost.

How did they conduct the testing? First, they did some preparation work. They found several ordinary users who represented different types of people. They set up a camera as a recording device to capture the entire user testing process. They also prepared some forms to list the questions they were concerned about.

Then, the user testing took place. They introduced the purpose and process of the testing to the users and provided some basic information. Then, the users were asked to perform several tasks.

During this process, the testers would timely ask the users to describe their feelings. If the users encountered any problems, the testers would appropriately intervene, ask about the issues, and provide assistance.

Finally, the users were asked to rate and evaluate the product they used. The testers’ main job was to observe and record the users’ reactions and find any parts that had an impact on their usage. The purpose of user testing was to see how users would use the website and what impact the website’s design would have on their usage.

After the testing session ended that day, everyone gathered together to organize the user feedback they received. They discussed the designs that had certain impacts on the user experience, made adjustments, and then conducted another round of user testing.

For me, it was a memorable afternoon. It was the first time I experienced users up close. Their concerns and ways of using the product were quite different from my assumptions. When designing the system later, I had more influence because as a developer, I had a different perspective than the product manager.

Lastly, I want to mention a common issue among programmers: the lack of a “common language” with the product manager.

They usually speak in business language, while we, as programmers, primarily speak in computer language. These are two different fields and it’s difficult to communicate. Earlier, when discussing code, I mentioned the need to write code using business language. In fact, this practice is the “Ubiquitous Language” in domain-driven design.

Ubiquitous Language means not only using it when writing code but also having everyone speak the same language, which should come from the business and the domain model we build together.

By doing so, we can reduce ambiguity in communication. Therefore, if you want the project to progress smoothly, invite the product manager and sit down together first to establish your common language.

Summary #

Today we discussed an important topic: listening to user feedback. This is a skill that is generally lacking among development teams, or more accurately, it is often ignored. Therefore, the concept of “eating your own dog food,” which may seem obvious, is repeatedly emphasized and has become a classic in the IT industry.

In today’s lecture, I introduced different approaches to “understanding user needs,” but ultimately it all comes down to one thing: finding ways to get close to the users.

Whether it’s being a user yourself, finding opportunities to interact with existing users, or creating users when there are none, only by listening to the voices of real users can we avoid overconfidence or biased trust in product managers. Whoever is closer to the users has the right to speak, regardless of their role.

If there is only one thing you can remember from today’s content, please remember: get closer to the users.

Finally, I would like you to reflect on your actual work and think about what problems you have discovered by getting closer to customers, or what difficulties have arisen from not getting close to customers. Feel free to share your thoughts in the comments.

Thank you for reading. If you found this article helpful, please feel free to share it with your friends.