"Recruiting demands" is an indispensable part of the work of a product manager (hereinafter referred to as "PM"). In the article, the author will combine his personal experience to talk about several key points in doing a good job in demand analysis, hoping to inspire some inspiration for friends who have just entered the industry and plan to enter the industry.
Requirement analysis occupies an important position in the product life cycle, which determines the degree to which the product is accepted by users after it is made. By observing the PMs I have been exposed to, I found that most people do similar things when conducting demand analysis. Therefore, several key points are summarized to form an operation method that can meet most needs.
Note: Since the author has been engaged in ToB products, the methods described in this article are only for such products and are not guaranteed to be applicable to ToC products.
1. Where does the demand come from?
Requirements are demands or suggestions put forward by some users in specific scenarios to obtain certain services or functions. It is an integral part of the product and the ultimate goal of the product. It can be a sentence from the boss, a complaint during use by the user, or a conclusion drawn after analyzing a bunch of data.
According to the author's observation, there are the following sources of demand:
1. Boss
You must pay attention to the needs put forward by the boss, not because the demand is the boss, but because it contains opportunities and traps, and it is difficult to refuse.
(1) Opportunity
- Through the needs of the boss, understand the boss's ideas and take this opportunity to gain a glimpse of the company's strategic development direction;
- compares your understanding of the product with the boss, finds the difference and thinks about the reasons;
- communicates with the boss about his product ideas and discovers the gap between himself and the boss;
- has done the things assigned by the boss and is appreciated by the boss (everyone understands this).
(2) Trap
- Not all bosses understand the product development process and business development, and they will be blindly commanded;
- Some requirements will disrupt the team's product planning and development rhythm, and if the PM is not handled well, it will be uninhuman inside and outside.
2. User (Internal colleague)
The author faces a colleague in the company, most of whom are colleagues in department use the system, and a small part are other PMs.
shows from the needs of colleagues in the department that they care about whether the system can meet a certain requirement, and usually give their solutions while making the demand. But it does not mean it is a real demand. A very famous case is that you want a fast horse, but Ford provides a car (please check it yourself if you don’t know). Therefore, PMs need to guide them to express their true needs in communication.
is responsible for other systems (business lines) PMs will also put forward requirements to meet some functions that need to be implemented across systems. Communication in this situation will be smoother because we have a better understanding of the system, development process, and technical boundaries.
3. Self-driven
requirements are usually generated based on the following three reasons:
- is derived through data analysis. Problems found by
- PM when using the system (usually the user has no perception). For example: The problem I found when I was working on the risk control system requires adding control switches to the pushed input parts. The function is to control the number of push inputs after the risk control model is adjusted or the new function is launched, and then open it after verification that there is no problem, allowing a large number of inputs.
- is proposed based on product sense. Product sense refers to the analysis of the market based on PM's understanding of the product and some demands that are beneficial to the future development of the product.
2. It is necessary to make regulations on the way to propose requirements
. Each demand proposer usually proposes requirements from his own perspective, either based on interaction, efficiency, or KPI, etc. This makes it more difficult for PM to grasp the importance of the requirements and understand the accuracy of the requirements content.
For example: The author once contacted a business department that I did not work in the same city as me.During the docking process, there were problems such as multiple people in the same department raising demands at the same time and the priority was unclear. After the demand was launched, users (non-demand proposers) reported that the demand was not practical, or many people waiting to use it after the demand was launched.
The author usually operates in three steps:
1. Determine the interface person and clarify his responsibilities
Interface person: communicate with the leader of the demand department, ask him to designate an interface person, and all the needs of everyone are summarized at the interface person and then submitted to the PM.
Responsibilities:
- collects the needs of colleagues in the department;
- filters out unreasonable and unnecessary needs;
- gives priority to requirements;
- submits requirements to PM;
- follows up on the requirements progress;
2. Determine the way to propose requirements
- submits them by email to ensure that all relevant people are well known and records can be kept.
- The first time it is after receiving the request. We must follow the 5W1H analysis method, communicate around the problems, and collect detailed information on the requirements.
- The second time is after collecting information and analyzing the requirements. PM will use its own understanding of the system to explore some detailed issues, some of which need to be confirmed with the demand party. There may be multiple communications during this period.
- The third time is after PRD is completed. You should tell the document content to the demand party and confirm for the last time whether you understand the demand accurately before reviewing. As for issues such as demand background, they must be clearly understood before the review meeting so that they can be told to everyone at the meeting.
- What: The demand side is the financial department, and the demand content is a new list in the financial system to display the details of a certain expense, and the list can be downloaded.
- Why: The previous alternative was to download it from another list in the system. Since it was not specifically displayed for such data (large amount of data), it needed to be screened and calculated manually. The screening calculation time is not long, and the author personally tests it to about 15 minutes.
- Who: The user is a colleague in the finance department (only one person), and other users of the system will not use this list.
- Where: When using the scenario is to reconcile with the partner every month, you need to download the list and then calculate certain amounts in Excel.
- When: Use it at the beginning of each month, counting the transaction volume of each fund type in the previous month, and the frequency of use is once a month.
- How: The list can provide accurate and complete data on time, that is, meet the needs.
- Importance: refers to whether the demand is in line with the company's strategic development, whether it is a strategic project on the product line, whether it is linked to the company's revenue, whether it meets the basic service of the product, etc. In short, there is no urgency in time, but it will have a significant impact on future development.
- Emergency: refers to whether the demand must be resolved immediately. If not resolved, it will continue to have or will have adverse effects. This type of demand is not necessarily important, but it is time-sensitive.
3. Department Leader's approval
must be approved by department Leader to ensure that it understands and recognizes the required content and priorities.
3. Requirements collection method
In a sentence summary, it is to ask more questions and communicate more, and understand the business and actual usage scenarios.
1. 5W1H analysis method
Many demand proposers do not understand the system. They only care whether the current problem can be solved. PM must understand the ins and outs of the requirements in detail so that they can propose solutions. Here we recommend the 5W1H analysis method to collect the required content.
(1) What (description) What is the requirement of
?
(2) Why (reason) Why does
have such a requirement? What were the previous alternatives?
(3) Who (user)
, or which department is it?
(4) Where (scene) What are the usage scenarios required for
?
(5) When (time) When will the requirements of
be used? What is the frequency of being used?
(6)How (check)
How to confirm that the requirement has been met?
The above questions require the demand party to clearly describe them, either by email or by interview. The method of collecting requirements can be selected according to your own habits, and the focus is on the collection of demand information.
2. Communication frequency with the demand side
The PM of ToB products must understand the business. The author was once responsible for the design of the financial system. Because he did not understand the requirements of the demand side for settlement, reconciliation, cash withdrawal and other operational scenarios (the demand side also did not understand), the design problems occurred and secondary development was needed.
If you want to have an in-depth understanding of the business, you need to maintain communication with the demand side. The author believes that after receiving the request, there should be at least three communications.
4. Requirements analysis and organization
1. Steps of demand analysis
Judge the authenticity of demand – analyze the business value of demand – evaluate the feasibility of demand – give priority to demand.
The author will use his own experience as an example to illustrate how to perform these four steps:
(1) determine the authenticity of the demand
The 5W1H of the demand is:
According to the author's judgment, there are currently alternative methods for this requirement and it is not difficult to operate. The demand is used at a low frequency (once a month) and the number of users is small (one person). Therefore, the business value of this demand is not high, which is a pseudo demand.
The author explained the unreasonable aspects of the demand to the demand side, and suggested that the download portal be added to the existing list, so that the sum of the amounts that need to be reconciled every month can be downloaded, which not only saves the workload of calculation after downloading, but also reduces the amount of data and reduces the use of resources during downloading.
Because the demand side insists on following the initial plan and cannot give a reasonable explanation, the demand is finally cut off.
(2) Analyze the business value of the requirements
This article can complement the authenticity of the requirements. Usually, the demand with very low business value is rarely used even if it is made.
According to the above examples, although it is a demand that invests manpower and consumes little time, its business value is just to save one person 15 minutes a month, which is not worth the loss.
In addition, PM also needs to have a clear positioning of the system's development direction, the functions contained, and the people serving. For background systems, planning and restraint must be required when adding functions and lists, otherwise the system will soon become redundant in functions, difficult to find, and inconvenient to use.
(3) Evaluate the feasibility of requirements
The purpose of this step is to judge the difficulty of the development of the requirements, and then give a general implementation plan, which needs to be completed by PM and development.
The requirements page in the above examples is simple in function, the required data is recorded in the data, and the interface is also provided, so there is no problem in terms of feasibility.
PM needs to have a certain understanding of the system it is responsible for, the abilities of the docking technicians, and the technical boundaries in code development in order to make a better feasibility assessment. Therefore, it is recommended that PM learn more technology to avoid the need to "change the APP theme color according to the color of the mobile phone case".
(4) gives the priority of the requirement
The author generally uses the four-quadrant rule and KANO model to judge the priority. These two methods are commonly used in determining priority. I will introduce them too much. Interested friends can query them by themselves (excellent PMs need to have query ability and self-study ability).
Four-quadrant rule:
as shown in the figure below. Important and urgent needs need to put down what you are doing immediately and concentrate on solving them. For example, the risk control system needs that the author receives must be launched before the compliance registration inspection to meet the compliance registration needs. It is important and not urgent. After understanding and analyzing the requirements, formulate a plan and then implement it step by step. Emergency is not important. If you can do it, don’t do it. If you do it, try to use time-saving and labor-saving methods to solve it. It is not urgent or important. This type of thing is mostly fake demand. Referring to the above examples of the financial department, it is decisively refused to drop it.
KANO model:
- Essential factors: functions that must be possessed in business processes to ensure that the process can proceed normally. When the function is missing, the user will find that the process cannot be completed. Therefore, this type of demand needs to be given priority.For example: When running the anti-fraud model in the risk control system, if the function of restarting the process does not occur after the call fails, there will be a failed call in the anti-fraud model link, causing the process to be interrupted.
- Expected factors: Such needs usually save users time and improve efficiency. The purpose of existence is to make the system operate smoother. There is generally no necessary factor for priority. For example: When the financial system makes monthly reports, if the system can unify the data that needs to be found and calculated from multiple places and display the calculated results, this will improve usage efficiency.
- Charming factors: is usually a feature that users do not expect, which can greatly improve user efficiency, optimize experience and solve users' needs for problems that are difficult to solve offline. This type of demand is not common in ToB products and is usually a must-have and expectant factor.
No difference factors and reverse factors: I think these two types of needs are pseudo-needs, which are time-consuming and energy-consuming but cannot improve user experience and efficiency. They should be rejected after encountering them.
2. Requirements sorting
The collection and sorting of requirements requires the use of the demand pool. There is no fixed template for the demand pool. The purpose of the establishment is to help PM evaluate and manage requirements. The template content can be established according to personal habits. The requirements in the
requirement pool are entered by the PM, and the recording does not need to be as detailed as when collecting requirements and analyzing them. The focus is on recording the status, priority, and schedule of the requirements.
The following is my demand pool template:
or above is based on the author’s idea of demand analysis, and there may be certain limitations. It is for reference only. Everyone is welcome to communicate and learn more!
Author: Bear who beats the soy sauce, official account (White Bear who beats the soy sauce)
This article was originally published by @全全全全全全全全全全全全全全全全全全全全全全全全全全全� Reproduction is prohibited without permission.
question picture is from Unsplash, based on CC0 protocol
