How developers understand users and needs

Many predecessors and books have said that developers, especially architects and technical managers, need to have business feelings. I have been trying to cultivate my own abilities in this field, but I often feel overwhelmed, it means either being inherent or accumulating 1.1 drops in the business world, and it's easy for us who spend the whole day in technical details. In fact, for us, the term business is too big and abstract, so that we do not know how to do it. I think it is better to narrow down the scope, it is more practical to clarify the users we want to serve and the needs for implementation. I remember when I was acquired last year, the new boss scolded us for not understanding the user's needs, and did nothing to do. Although I felt a little uncomfortable, I did not have much effort to examine the user and needs. Therefore, developers should start from users and needs to cultivate business feelings.

After reading su Jie's "Everyone is a product manager", he learned some methods and ideas about users and needs, and sorted out some of his own understandings as follows:

Real users

It is said that developers should go to the front-end to get in touch with the most authentic users, but there are only a few of them, or they are symbolic participants in the demand research activities organized by the Company (poor ), you can either treat yourself as a user, and developers treat yourself as a user. In the end, it is yy. How can it be a real user? I am a R & D Engineer, facing a lineCodeThe real user is a network provider, and the business environment is closed when no order is obtained. When a developer faces a requirement, they usually think like this: what is the interface process? What data will be involved in this process? How to use a service to package various actions in this process? Will there be performance problems? In this way, there are things related to real users, and they are considering the essence of the most primitive demand. Therefore, to realize that a real user is to break this mindset, jump out of the developer's circle, communicate with real users, and consider technical issues that are irrelevant.

Try to describe the user

A good way to understand users is to do user description exercises. Of course, it is difficult to describe user groups that are not suitable for users. We can start with a user group that we are familiar, for example, for ordinary Internet users, we are a group of internet users. We use a variety of network products, such as email, Im, and RSS. We can start with these frequently used products, describe your needs and experience. Why do some people (such as PD) feel a lot about products and can express their own opinions? In fact, they will pay attention to product considerations, not just stay at the usage level. I believe that this kind of practice cannot be immediate, but it is simple and feasible. Over time, I will be able to think more about problems at the user level, and I will have my own opinions on product understanding.

Four Dimensions of user research

Winwin user web character role creation and Application Practice Guide describes a four-dimensional user research method, as shown in:

The following sequence is generally used in research and practice:

1) Listen to the user's qualitative explanation: user interviews. Output demand list

2) Quantitatively speaking: Questionnaire. Help sort requests by priority

3) Qualitative Test: availability test. Help verify the feasibility of the requirement

4) Quantitative Analysis: data analysis. Help continuously improve products

The requirement comes from the user, and must surpass the user

The requirements mentioned here actually refer to the product requirements that need to be met, while the demand analysis actually refers to converting user requirements into product requirements. Technicians prefer to use the "tree trunk-branches-leaves" method, while the right method for demand analysis is "leaf-branches-trunk ", then the "trunk-branches-leaves" is actually the "Minute-total-points" method, because only in this way can our product requirements be loyal to users, the origin is the scattered original needs of users, and then the essence behind the needs can be seen through induction and structuring. Finally, based on the essence of our refinement, we will further refine it into a list of implementation and implementation requirements.

Get to know the details of products in your life

The actual control over users' research and needs is closely related to their attitudes towards life and the observation of the surrounding details. In this regard, they cannot read several books as they learn technology, if you work hard for a few days, you can improve your performance. You need to be considerate. Software products are only a very small subset of the total product set, so you don't have to stick to this, you can look at everything in your life, such as shops, elevators, restaurants, menus, etc, try to pay attention to these things that we normally get used to or are indifferent to, analyze their availability and ease of use, and even think about improvement solutions. It is hard to imagine that an engineer who does not care about his life and is immersed in technical details all day can provide unique insights on products and needs.

Some books and blog posts worth reference

12 books worth reading by the product manager

16 blogs worth reading by the product manager