How to take demand analysis to the extreme?

Once you have a good product idea and have determined the user group, the next step is the needs analysis phase. How to accurately discover the essential needs of users is the key goal of this stage. The following are some experiences summarized from work, which I would like to share with you.

1. Organize ideas based on existing information

Summarize the demand research context document and summarize it in a catalogue style based on business scenario ideas. The content of the summary may be very consistent with the final product form, which depends on the depth of your understanding of the industry. The summary basically includes issues such as constraints and business scenarios. These are usually requirements that you are uncertain about, but classification is crucial, such as constraints, main business scenarios, and even requirements that cannot be judged as critical, that is, the importance of business scenarios is uncertain.

The following ideas can be organized with the help of mind maps. The ideas are: scenario - problem - solution

After the ideas are clearly sorted out, summarize the business scenario ideas in a catalog format in the demand research context document.

2. Go to research with questions

After the investigation is completed, write a research record as an original record. During the research process, users will answer your questions and may also describe other needs. If you have more than one survey user, there may be multiple answers to the same business scenario question. You can record them in the demand research context document as follows (Note: the first and second steps below are already sorted out in the demand analysis context document):

(1) Questions to be investigated (what to ask)

(2) How to ask (how to ask)

(3) User a :

User B:

User c:

User B:

User d:

…

Of course, there are many other ways to obtain requirements, such as work observation, situational interviews, user models (time-consuming, not suitable for small teams), scenario scripts , etc. These methods can be used reasonably according to actual conditions.

3. Summarize the research results into the demand research context document

The purpose of this process is to supplement business scenarios that were not thought of in advance, and even have requirements at the framework or presentation level. At the same time, compare the different answers of different survey users in the same problem scenario, summarize the key requirements, and mark the basic requirements, expected requirements, and exciting requirements.

4. Conduct demand analysis with the help of single demand cards

Analyze key requirements through single requirement cards (auxiliary analysis tools ). The key requirements here are generally requirements that are closely related to other businesses, and then record the analysis results in the corresponding question directory of the requirement survey context document.

The following is a single requirement card template from Everyone is a Product Manager . I personally find it very useful.

(The picture above is a template for a single demand card for Everyone is a Product Manager)

Of course, when conducting demand analysis, it is best to select several representative users, conduct in-depth mining and analysis, and indicate the basic attribute characteristics of the users, such as: personal background, marital status, income, skill (education) level, age, gender, family, work, hobbies, important users, equipment used, etc.

5. More in-depth analysis of requirements in the demand research context document

At this time, you can use mind maps, flow charts, state diagrams and other analyses as the basis for writing product requirement documents and designing product prototypes. Of course, at this time you can only write some things about the strategy, scope, and structure layers, and draw a preliminary simplified version of the main business scenario prototype. After that, you need to organize the product function specifications, product structure, and product information architecture according to the document, and use these to draw the product prototype.

6. Form a product demand record table

The purpose of the requirements in the product requirement record table is to record the point in time when a certain requirement in the product life cycle will be realized. Of course, if time is tight, you can record it first, and then use a single requirement card to analyze the feasibility of the requirement. Even if it is a pseudo-requirement, you can also record this requirement for later traceability. Remember, this table is just an entry display, presented as the result of the analysis, focusing on recording traces rather than analyzing the product, but it can simply evaluate the impact of the requirement on the R&D workload.

The following are the contents of the header of the product requirement record form:

• Header : Number, Role, Main Scenario, Sub-Scenario, Requirement Description, Type, Solution, Recorder, Record Date, Source, Status, Notes, Version Management
• Type : new features, feature improvements, interface, bugs, performance...
• Status : To be discussed, rejected, in demand, under development, released
• Version management : 3.0 3.0.1…… 3.1……

When judging whether a demand is a false demand, you can use the 5W2H method, that is, who (WHO), when (WHEN), where (WHERE), why (WHY), what (WHAT), how (HOW), and what (HOW MUCH) will be paid.

In the actual execution process of each of the above steps, there are actually many detailed considerations and output products, which will be shared with you in the following articles.