How can product managers translate user needs into R&D needs?

Whenever a user request is received, one of the headaches for product managers may be how to transform user needs into R&D needs. How to understand the difference between the two and successfully transform the demand? In this article, the author has shared and summarized, let's take a look.

The game between product managers and R&D personnel is an eternal topic in the product industry, product managers say that R&D personnel do not understand business, and R&D personnel say that product managers do not understand technology, but paradoxically, every time a user demand is received, product managers need to rack their brains to turn it into R&D requirements, so that R&D personnel can know how to correctly implement the requirements.

1. The difference between user needs and R&D needs

User demand is the result of R&D demand, R&D demand is the process of user demand, the essence of user demand is "what to do", and the essence of R&D demand is "how to do". Sometimes, however, there is no correlation between "what to do" and "how to do it".

For example, the user requirement is to design a function that allows the user to change the mobile phone number bound to the current account to a new mobile phone number.

Without careful analysis, we can roughly translate this requirement into the following R&D needs:

1. Verify the old mobile phone number in the form of a verification code, and enter the new mobile phone number after the verification is passed
2. After verifying that the new phone number is different from the old phone number and has not been bound to another account, send a verification code to the new phone number
3. Verify the new mobile phone number in the form of a verification code, and change the old mobile phone number bound to the account to the new mobile phone number after the verification is passed

In the above R&D requirements, it can be found that if you don't see the last step, you don't know what function these requirements are to achieve, and this is just a very simple function, for complex business functions, especially the functions of multi-person division of labor R&D, many R&D personnel do not know what this function is used for, because in R&D requirements, sometimes some functional requirements are involved;

For example, the verification of the old and new mobile phone numbers mentioned above, or some design constraints are involved, such as judging whether the new mobile phone number is bound to other accounts mentioned above to prevent repeated binding, and these functional requirements and design constraints are all in order to finally correctly realize the user needs of "changing the mobile phone number", but their essence is not directly related to user needs.

For the definition of functional requirements and design constraints, interested readers can refer to the previous article "The Daily Work of Product Managers from the Top 10 Management-Overall Product Management".

2. Why do we need to transform demand?

The reason why it is necessary to translate user needs into R&D needs is that there is a considerable difference in the thinking of product managers and R&D personnel.

Product managers are often in contact with the business, so in the mind of the product manager, every time they think of the solution of the requirements, and the R&D personnel, in the daily R&D work, many are only responsible for the writing of a few interfaces or a few pages, most of the R&D personnel do not have a complete concept of the business form, so they are more concerned about what they need to do, as long as the R&D requirements are written in sufficient detail, they can develop the function without completely understanding the business form.

For example, if the product manager describes the requirements for development as follows: Since in actual business, users may need to change the bound mobile phone number, so such a function needs to be developed. So from the perspective of development, he will think that this function is implemented in this way: provide a page for users who have logged in, enter the mobile phone number, click OK, and modify the mobile phone number bound to the user's account to a new mobile phone number.

If you ask him why he didn't do mobile phone number verification and why he didn't judge the repeated binding of mobile phone numbers, they will say, "That's how the product is designed." ”

This is the difference between product thinking and R&D thinking, after years of dealing with R&D, I have summed up a sentence about their way of working, that is: try to do as much as possible, never do more, do not guarantee not to make mistakes, mistakes are the product manager's pot.

The reason for this way of working is that it is possible that a simple sentence in the product manager's requirement description requires several people to work on R&D for several days to complete, and in such a working environment, they don't have much time to think about the business level, so the product manager is required to write down the things that need to be done in great detail to reduce the thinking time of R&D personnel in the R&D process.

3. How to transform demand

When dismantling a user requirement into multiple R&D requirements, each requirement can be considered from one or more dimensions in user, permission, and verification.

The so-called "user" is a "person", we can analyze who has the appeal to change the mobile phone number and the reasons:

1. Account owner, reason for change: change mobile phone number
2. If you are not the account owner, such as someone who steals the account, the reason for the change: By changing the mobile phone number, you will keep the account as your own

From the above analysis, it can be seen that the real user of this demand should be the former, not the latter, so it involves the problem of "permission", if you do not limit the permission, so that the latter can easily change the mobile phone number, then it will likely cause immeasurable losses to the former, the key question is, how to make it clear that the user has the right to change the mobile phone number, which needs to confirm the permission through "verification", we can analyze again, which verification can be used to clarify the user's permission:

The above three verification methods can verify the user's identity to some extent, in this case, which verification method should be chosen, which needs to be trade-off, we can analyze it like this:

Through the above comparison table, we can find that "account password verification" is the first to be excluded, and among the remaining two verification methods, we can find that the result of "face recognition verification" is the most accurate, and the cost of counterfeiting is also the highest, but at the same time, the operation threshold is also the highest, and it can only be operated on the mobile phone, and relatively speaking, the mobile phone number is more convenient and fast, so most products will choose to verify through the mobile phone number.

However, we will find that no matter which verification method, there is a possibility of fraud, and the accuracy of the verification results cannot be 100% guaranteed, so in this demand, double verification can also be considered, such as verifying the user's identity through mobile phone number + face recognition, but this is too cumbersome, then you can consider the user's current IP location and frequently logged in IP when the user verifies the mobile phone number Whether the territory is consistent, if it is inconsistent, then consider allowing the user to perform face recognition, if the territory is consistent, then verify the mobile phone number.

Of course, no matter how to prevent it, it is nothing more than increasing the cost of counterfeiting, and it cannot completely eliminate fraud, therefore, for some more secure information and operations, there should be another "lock", for example, the payment application will require the user to set a separate payment password to distinguish between login operation and payment operation, so as to increase security.

In addition to the verification of "permission", the new mobile phone number that is about to be bound also needs to be "verified", mainly to verify the following points:

1. The new phone number is different from the old phone number
2. The new phone number has not been bound to another account
3. The new phone number is correct

Therefore, through the above analysis, we can try to translate this user requirement into the following R&D requirements:

1. When the user clicks "Modify Mobile Phone Number", the "Verify Old Mobile Phone Number" page is entered, and the user sends a verification code and verifies the verification code
2. When the verification is passed, determine whether the IP territory of the current operation is the same as the IP territory that the user often logs into, if it is the same, enter the "Verify New Mobile Phone Number" page; if not, it is necessary to determine the device that the user is currently visiting the page, if it is a PC device, then the QR code will be displayed, and the user will scan the code through the mobile phone to enter the "Face Recognition Page", and if it is a mobile device, it will directly enter the "Face Recognition Page"
3. If you need to perform face recognition, go to the "Verify new mobile phone number" page after the face recognition verification is passed
4. Enter a new mobile phone number on the Verify New Mobile Phone Number page, verify that the new mobile phone number is different from the old mobile phone number, and the new mobile phone number is not bound to another account, and then send a verification code to the new mobile phone number
5. After the user enters the verification code of the new mobile phone number and clicks Submit, and at the same time verifies that the old and new mobile phone numbers are different, the new mobile phone number is not bound to another account, and the new mobile phone number verification code is correctly passed, the bound mobile phone number of the account is updated to the new mobile phone number

You may feel very strange about the 5th requirement, why the 4th requirement has been verified once, and it needs to be verified again, because the user may have sent the verification code and changed the mobile phone number, so before binding, you must verify the eligibility of the new mobile phone number again and then bind it.

Write at the end

At this point, the core content of this article has been finished, and finally I want to talk about that many times product managers are complacent and feel that they have sorted out the R&D needs of a user clearly, but when it comes to the review, it is still easy to be scared, on the one hand, too many words are easy to make people feel that they can't find the point, in addition, Chinese culture is broad and profound, and different people at the same time may have different understandings of the same sentence, and even the same person may have different understandings of the same sentence at different times.

In such a situation, in addition to minimizing some unnecessary text as much as possible, sometimes a simple flowchart can explain a seemingly complex logic clearly, for example, you might as well try to replace the above R&D requirements with a flowchart, you will find that it is much more intuitive than the above pile of text, for R&D, they want the product manager to get to the point, rather than writing the requirements like a novel.

If you are interested in the main points of drawing flowcharts, you can refer to the previous article "Why do you always say that you can't understand the flowchart development?"

That's all for this article, thanks for reading!

Columnist

Product Jin Li, public account: Product Jin Li (ID: IMPM996), everyone is a product manager columnist. A product manager who is not a proper business and his product design.

This article was originally published by Everyone is a Product Manager and is prohibited from reprinting without permission.

The title image is from Unsplash and is licensed under CC0.

The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.