Many product students are in start-up companies, and they may not have enough right to speak, so they may develop direct docking needs. But what needs to be clear is that the product must meet the demand. The reason for the existence of the position of product manager is because of the existence of requirements. User requirements are not the same as system requirements, and I believe in the value of my own intervention in the development of requirements.
1. Definition of good demand
1.1 Sample of good demand
Before researching the needs, we need to have a good sample of the needs in our hearts, which can follow the GPSPAC principle.
- Goal: Why do you want to do it?
- Process: the organization and coordination required to achieve the goal;
- Scene: all possible conditions in the process (normal, abnormal);
- Person: the person/department involved in a specific scenario;
- Action: the judgment and action of people in a specific scene;
- Check: Checks for which action is required by the person (optional);
With a "standard" answer in mind, then when you investigate the needs in the complex business, you will not be led by the business, and you will follow your standard to guide the business to tell you what you want and seize the GPSPAC.
2. Obtain B-end requirements
Before obtaining requirements, it is necessary to clarify the background of requirements, clarify the value of requirements, and clarify the current status of the business. It is more important to identify the authenticity of the requirements and not to be led by the nose by the user. Don't just listen to one side of the story, just listen to both.
2.1 Obtaining Requirements
Define the context of the requirements
The demand background is the premise of the entire product design, and only by deeply understanding the problems existing in the background and the corresponding user pain points can we grasp the design direction of the product. At the same time, only when everyone recognizes the authenticity, effectiveness and value of this background, can we better promote the implementation of product solutions.
A complete requirements background generally consists of three parts: users, scenarios, and requirements. That is, what kind of scenarios users encounter, what kind of problems they encounter/or what needs or demands they have for the current product. Or go a little deeper, who, where, why, and in what way did what they did, and to what extent/what results were achieved.
5W1H specifically refers to:
- Why: Why
- What: An object or something
- Where: The location
- When: Time
- Who: The person or person responsible
- How: A method or procedure
In addition, the word "How Many" is sometimes added to further clarify the order of magnitude and scale. This approach encourages in-depth thinking about the selected project, process, or operation in terms of why, who, where, when, who, and how. For example, what products does the company produce? Where is this product manufactured? Why is this product made? When were these products manufactured? Who makes these products? And how are these products made? Wait a minute. This multi-faceted way of thinking can help us understand a problem or situation more holistically, so that we can make more informed decisions.
When designing products, we should use the sentence pattern of "user + scenario + demand" to repeatedly confirm whether the product background is accurate and does not deviate from the direction; This kind of sentence structure should also be used when introducing to developers to logically and clearly convey the value behind the feature.
Clarify the status quo
- Who will be uncomfortable if it is not resolved?
- How uncomfortable it is (it is better to have quantitative indicators, such as: how many people spend how much time and time to do it offline?) error rate, risk, etc.)
- How often you feel uncomfortable (frequency)
- How the current scheme works
Clarify the value of the need
- Where does this demand come from?
- What problem was solved?
- Are our current resources sufficient to accomplish this?
- What is the most painful pain point in this part of the business?
- Why didn't we do it in the past, we won't do it in the future, but do it now?
Note: For users, we only mine problems, not solutions;
2.2 The Value of Demand
Thinking about production efficiency
- The efficiency of the overall collaborative link is improved. (e.g., reduction of reimbursement to loan time, reduction of refund time, etc., management pain points)
- An increase in the output per unit of means of production or a decrease in the cost per unit of output. (e.g., the increase in the number of sales visitors, the increase in the number of customer service calls, and the pain points of operation)
- Decision-making difficulty is reduced or accuracy is improved at scale. (e.g., data reports, business diagnosis, intelligent tools, etc., decision-making pain points)
Different value definitions for different solutions
- Digitalization: qualitative (such as running through the process, full-link visualization), quantitative (such as feedback timeliness improvement, etc.).
- Automation: qualitative + quantitative, mainly quantitative.
- Intelligent: Must be quantitative.
Qualitative: Completing specific tasks or actions as an assessment method, such as running through the process, being able to see data, etc., is highly subjective.
Quantitative: To achieve a specific value as the assessment method, such as 1 million gm, 100 new customers, etc., strong objectivity.
2.3 Identify fake needs
真需求还是伪需求，want or need？
In English, it can be clearly distinguished: the pseudo demand is called Want, and the real demand is called Need. Users of Want will not necessarily pay for things, but users of Need will be willing to pay for things. Therefore, identifying the needs of the needs needs needs to be realized and satisfied first, reducing or not doing what needs.
In order to get the real demand, it is necessary to figure out what kind of purpose the user wants to achieve through the product, the product manager needs to jump out of the existing thinking and subjective judgment, and at the same time, he can not trust the solution directly fed back by the user, and constantly ask why, to dig out the real reason behind it. The following questions can often be asked about individual requirements to identify differences in requirements and then prioritize:
- Demand Intensity: Is the User Painful? How painful is it?
- Frequency of Demand: How often does it hurt?
- Duration: Does it persistently hurt?
- Breadth: How many users have similar pain points?
- Willingness to pay: How willing the user is to pay for this pain point.
A theoretical approach to discovering real needs
- There are many theoretical methods to mine demand, such as user research, data analysis, competitor analysis, and so on. Among them, user research includes core user feedback, questionnaire method, interview method, and field research.
- When analyzing the needs of customers, we must know how to ignore what they want and explore their real desires, so as to give better solutions, or what users really need.
Summary:
What is "pseudo-demand"?
- Lack of sufficient use scenarios, which seem to be useful but have no corresponding adaptation scenarios;
- dispensable, and does not solve the "incremental demand" of the core pain points;
How to identify pseudo requirements?
- In the demand collection stage, not only listen to the user's words, but also find the real usage scenarios and the motivation behind the words;
- Design the solution from the motivation, rather than taking the "design" proposed by the user as the solution;
- In the prototype stage, do user testing and listen to users' feelings;
- Important functions, grayscale online/pilot online, to avoid collective rollover;
3. How to manage B-side requirements
3.1 Judgment of demand priority
1. How can I tell if the project is urgent? Will you die if you don't do it in the short term?
2. How can you judge the importance of a project? "Will you die if you don't do it for a long time?
3. Priority = (importance + urgency) / R&D cost
4. Does it affect the continuation of the main process? If not, then there is relatively ample time for research;
5. Do I have to fix the functionality to meet the business needs? For example, if there is a problem with the data export function of the page, and the user cannot export the data, the data can be exported directly from the database and provided to the user, in which case the main process will not be affected.
3.2 Priority Criteria
1. High quality and high value: demand value first, that is, high-value demand is given priority;
2. Leaders are very concerned: high-level and "big noise" are considered as appropriate, that is, the needs of the boss and the needs of high pressure are moderately prioritized;
3. Reasonable allocation: small, medium and large demand should be reasonably allocated, that is, small, medium and large demand should go hand in hand on the basis of ensuring full utilization of resources (it is recommended that the proportion of 235 or 226 be allocated); Usually the value of the demand is proportional to the size of the demand;
4. All parties should be aligned: full communication and transparent allocation, that is, the arrangement of priorities needs to be fully communicated with all parties, try to reach an agreement, and synchronize the progress and priority with all related parties in a timely manner;
In conclusion, prioritizing requirements is an art, not just a technology.
3.3 Management of Demand Pools
Four-quadrant time management method of demand
P0 Important Urgent;
a. Solution: Do it immediately;
b. Saturation consequences: infinite increase in pressure, crisis;
c. Principle: The less the merrier, a lot of things in the first quadrant are because they are not well utilized in the second quadrant;
P1 is important and not urgent;
a. Solution: Have a plan to do it;
b. Saturation consequences: busy but not blind;
c. Principle: Concentrate on processing, invest in the second quadrant, plan well, tighten first and then loosen;
P2 is not important and urgent;
a. Solution: Leave it to others to do;
b. Saturation consequences: busy and blind;
c. Principle: delegate power to others to do it;
P3不重要不紧急;
a. Treatment: Try not to do it;
b. Saturation consequences: wasted lives;
Principle C: It can be used to regulate the body and mind, but it cannot be indulged in this quadrant;
The demand for P0 is controlled at no more than 25%;
P1 maintains long-term investment and reserves a certain amount of resources for each iteration (less than 20% is recommended);
Note: The priority of requirements is not static, whenever new requirements are added, or the business changes, along with the update of the demand pool, it is a rethinking of the business.
The type of demand pool requirement
1. Functional improvement requirements
2. Experience improvement requirements
3. Bug fixes
4. New functional requirements
5. Other needs
Adhere to the principle of wide entry and strict exit
Fourth, how to analyze the B-end demand
Step 1: Sort out the business departments, positions and responsibilities.
Step 2: Business process combing.
Step 3: Confirm the business process.
Step 4: 3W1H rule, dismantle the system function points.
Step 5: Issuance of system flow chart.
Fifth, the delivery and implementation of demand
Sorting out the logic and synchronizing it to development without errors is the basic work of the product, and the more complex the requirements, the more necessary it is. If you are worried that the product logic is not the best solution or feasibility problem due to the limitations of the product itself, you can communicate with the development leader/core developer in advance before the solution is completed. Otherwise, allowing development to play freely on the logic of the product is burying a pit for later iterations or future generations.
This article was originally published by @逸轩 on Everyone is a Product Manager. Reproduction without permission is prohibited.
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.