1. What is the source of demand?
First, it comes from users. At this time, we must consider a problem: the scene; We can also try to analyze the scene from several key factors.
Based on what environment: subway/office/indoor/public * * * occasion/walk/night/outdoor ... Go deep into the details around the scene.
Based on what users: what characteristics, such as identity, income, region … ..
Based on what behavior: behavior or operation process, such as shopping process, operation habit, behavior cognition, etc.
Scenario analysis is to consider what kind of specific environment (time, place, situation), what kind of user motivation, what kind of goal you want to achieve, and the relationship between people. Record truthfully. If there is deviation or missing information, the subsequent analysis will be biased.
Can also be supplemented by user interviews, questionnaires, user feedback and other user research methods to collect and supplement information.
Teacher Su Jie shared the "Y Theory" of needs analysis.
The process of "requirement analysis" is to experience "1->; 2-> 3 ",transforming" user demand "into" product function ".
The higher the "y", the more solutions there are, and the lower the "y", the more purposes behind it. "1- user demand" is mostly manifested in the user's solution, which is often not good, but the good "three-product function" must be transformed from the user's demand, not imagined. So "listen to users or not listen to users" is the same meaning, and it is more accurate to say "listen to users, but don't follow them" At the same time, don't misunderstand "creating demand". You can only create a solution that meets the needs of users-product features, not user needs.
1->； 2, by asking "why", gradually sum up, 2-> 3, by asking "how", gradually deduce. Various auxiliary information will be used in the process, such as data, competing products, industry and so on.
The process of tracing "2- product demand" back to "4- Maslow demand" is optional, and the dotted line is only for the completeness of this theory. If you are interested, every product demand can always reach Maslow's level. How to choose the point of "2- product demand" depends on the positioning of the company and the product.
Secondly, it comes from within the company, such as company leadership, market, operation, products, development and so on.
In addition, the demand may come from Party A, which is the source of demand I am currently in contact with, and of course it may also come from other channels.
2. Demand analysis
With the demand, we need to analyze the demand, because not all the needs, we have to do, there are many factors to consider. For example:
1. What is the reason for the demand?
2. What scenario does the requirement solve?
3. What is the population base to meet the demand?
4. What is the value generated by demand? Including business value, user experience value, etc.
5. How to meet the demand? If you want to develop, what is the workload and development cost?
6. How important is demand? According to 1-3, 1 is the most important.
7. How urgent is the need? According to 1-3, 1 is most urgent.
8. How to evaluate the achievement effect of demand? Is it data? User feedback? Business income? Or something else?
According to the above analysis, if we decide to do it, we will consider the priority of the demand next. There are seven ways to temporarily define the priority of requirements:
1. carnot model method: basic demand >: expected demand > incentive demand.
2. Matrix analysis: important and urgent >; Important is not urgent > urgent is not important > neither important nor urgent.
3. Economic benefit method: high economic benefit and urgent functional demand? > functional requirements with high economic benefits but not urgent? > emergency functional requirements with low economic benefits? > functional requirements that are not urgent and have low economic benefits.
4. Pre/post-demand analysis method: What is the priority of pre-demand? > the priority of job requirements; The importance and urgency of early demand? > the importance and urgency of late demand
5. Give priority to meeting the needs of core users (28 principles)
6. Give priority to meeting the needs of core business (maximize the use of resources)
7. Satisfying the input-output ratio of core business takes precedence over the maximum demand (maximizing ROI).
There was a way to read it online before: scorecard, and how to use it.
1. Make sure you have a reliable theoretical basis and a plan for the next version.
2. Before the priority evaluation, all the factors that need to be considered in this version should be listed in the scorecard.
The establishment of scorecard needs parameters and weights. If you just take a blank sheet of paper when reviewing the requirements, the result is estimated to be not much better.
Give a chestnut:
In the above example, the features that affect the running efficiency are given the highest weight, because the purpose of the next version is to improve this part.
3. Determine the most relevant functions of this version.
If you use a scorecard, missing every function may make the results deviate from the normal track. Scorecards are suitable for the list of functions to be completed that have been preliminarily discussed.
4. Divide 100 points on the scorecard into various functions.
This score of 100 means that these functions have great influence.
Give a chestnut:
In graphic information, the score of user interaction is 90, which means that its release will have a great impact on user participation. Then calculate the priority of graphic consultation: 90 * 20%+90 *10%+50 * 30%+20 * 40% = 50.
After all calculations are completed, a priority list is obtained.
Tip:
If you want to lower a specific category, you can add a "negative weight". For example, the risk implementation category has a negative weight (-20%). So when calculating the score, subtract this item; The characteristic of "risk implementation" is to lower the priority.
Scorecards can be changed in each version. Its categories and weights should be adapted to your environment to ensure that you focus on the main ideas of this version.
When creating a scorecard, remember to consider the needs of other departments.
Our responsibility is to take care of users' needs, but often users need not only new functions, but also more "innovation". Sometimes products lack usability, stability and good performance, so it is very important to optimize the existing functions.
This is a tool for evaluating priorities.
For example, if operational efficiency is the theme of the next version, your scorecard should support this direction. The "Health Monitoring" function in the above table has a low score except "Operating Efficiency", but this is the direction of the new version, so this function immediately gets the highest priority. On the other hand, sometimes you need to list the needs of colleagues in other departments in the scorecard. Although it doesn't meet the theme of the next version, the scorecard will tell them that you really consider their needs, which is also conducive to team building and efficient work.
Now share a teacher's opinion on the evaluation standard of demand priority, and establish the standard in two situations. For start-ups, from 0 to 1, it is more about the boss's decision+the user's core needs first, but it is not time to set the standard. Most companies are under great pressure of income, demand accumulation, constant bugs and limited R&D resources. Today, I mainly talk about how to establish standards in this case.
First of all, product managers are required to have a sense of "quantification". When a demand comes, should it be done, should it be done immediately, and what are the benefits of doing it? Everyone has a set of rhetoric, how can we unify our thinking and reach an agreement? It is to "quantify" the effect that needs to be achieved as much as possible and speak with objective data. This "quantitative" dimension can be business income, user increment, active number, registration transformation and so on. Compared with the same dimension, the highest one wins.
Secondly, the product manager is required to be "abstract". These requirements may vary. Optimize the interaction today, adjust the layout tomorrow, support new projects in the background, and insert various bugs in the middle, which is easy to be overwhelmed. If you are a headache, you can never evaluate your priorities. Therefore, you need to classify the existing requirements list uniformly and abstract the * * * relationship between requirements. At the same time, this "* * *" should also be quantifiable, so it is not recommended to divide by platform, such as App or PC station, or by project. After all, the requirements and objectives of each project are different and cannot be compared, but try to divide them by energy indicators. This quantitative index must match the previous paragraph.
There are also some unquantifiable requirements, such as experience optimization requirements, such as fixing bugs. How to arrange them? There are some basic criteria for judging bugs:
1. Bugs with logical loopholes should be dealt with first.
2. The impact on users is high in order of magnitude and high in priority.
3. Bugs involving PR layer should be dealt with first.
4. Bugs involving policy risks are given priority.
For the requirements of user experience and basic function level, it is suggested to schedule according to the following principles:
1, in each version continuously, take out about 15% of the workload and schedule development at the level of optimizing experience.
2. Plan in advance which experience functions to optimize, so that developers can know fairly well.
Finally, product leaders need to define priority standards according to specific quantitative objectives, such as dividing A, B and C according to intervals, where A is greater than tens of thousands of orders, and so on. When the demand comes again, it can be placed in the corresponding interval, and the priority can be confirmed accordingly.
If the demander is vague about the demand himself, how can he communicate? Several steps are outlined:
1, let the other party know what the goal of this requirement is?
2. Confirm whether this target has energy? The idea of quantitative deduction is given, and whether this idea is reasonable and whether the data target is reasonable is judged according to experience and logical deduction. For unreasonable goals, it is recommended to think clearly before continuing communication.
3. After determining the demand target, if there are multiple targets, let the other party first make clear which one needs to be solved most at the current stage.
4. If the feedback is "all important", let the other party give the logic behind it. Why, if you can't satisfy yourself, you should give priority to it in the case of insufficient resources?
5. If the development cost is high, first give a quick trial and error scheme with low technical cost, and then decide whether to continue the development according to the data to provide a better scheme.
3. How to fully express the demand?
After the requirements are collected, all kinds of requirements need to be visualized and put into the requirements pool. There are two ways to express requirements, one is to describe a single requirement with a single requirement card, and the other is to manage multiple requirements with a feature list.
1. Single demand card
The core of this card is to let developers know the descriptive information (WHO/where/when/why) and the urgency of each requirement. It is an original user requirement, mainly a requirement attribute statement. The following figure is a template, which explains in detail the contents to be filled in each column:
Take the yellow car as an example. Recently, I saw a discussion on whether the navigation function of Xiaohuangche APP should be added on the Internet (in fact, I think this demand is false), so its single demand card should be filled in as follows:
2. List of requirements
This list integrates multiple requirements, and each item corresponds to the content of each requirement card. Compared with a single demand card, the demand list is usually the product demand after analysis, which is biased towards R&D time cost and cost performance.
The case is as follows:
Individual demand cards and demand lists not only focus on expressing requirements, but also involve some requirements management contents. Moreover, in the face of the demand that may pop up at any time, how to evaluate the cost performance of the demand and selectively bring it into the demand pool is also something that product managers need to consider.