Product Manager Methodology: Requirement Analysis

Original

The core of the product requirement analysis stage can be summarized as two sentences: "Can this requirement be implemented? What should it look like?" Based on this, requirement analysis can be divided into the requirement collection stage and the requirement analysis stage.

I. Requirement Collection

In the product requirement collection process, different measures need to be taken according to different types of requirements.

• The first type is that product managers discover new product requirements by capturing the discontinuities in life and conduct product design from scratch. I call it product requirements.
• The second type is that product managers or their superiors dig out new requirements by understanding users and analyzing competing products. The product extends its functions from 1 to N, which is commonly known as the ecological closed loop. Its essence is to improve the utilization rate of traffic. Since users of the product are often of the same type and have similar needs, we also need to consider what other related needs this type of user may have, and I call it functional requirements.
• The third type is that product managers and their team members propose improvement plans to optimize the product, which also belongs to the process from 1 to N. Its purpose is to optimize the user usage and payment experience to achieve the growth of product users or revenue, and I call it iterative requirements.

1. Product Requirements

There are mainly two ways to find product requirements:

• First, be sensitive to life, observe the pain points or unpleasant life experiences of oneself and people around in work and daily life, and conduct logical thinking to determine whether the problem is worth solving.
• Second, frequently pay attention to the latest information in various industries, understand market trends, and look for possible opportunities. You can also read industry analysis reports or product analysis articles written by others to dig out industry pain points.

The main difference between the two methods is that the former is an internal excavation, while the latter is an external analysis. Their common point is to find the discontinuities in life, thus discovering new requirements.

2. Functional Requirements

Functional requirements are also divided into two categories:

• One is the strategic requirements proposed from top to bottom, which are commonly the requirements thought up by leaders and the new requirements added due to the adjustment of the company's strategy. The former often occurs in small companies where leaders have the final say, and the latter occurs in large companies with more standardized processes.
• The other is that product managers and their teams deeply understand the business scenarios through product experience, data analysis, competitive product analysis, user research, so as to deeply understand user behavior and actively dig out user needs.

3. Iterative Requirements

Iterative requirements mainly include product optimization, data, technical, operational requirements, as well as less frequent ones like customer service and financial requirements.

II. Requirement Analysis

For requirement analysis, first of all, it is necessary to deeply understand the requirements, and form a full understanding of the requirements, scenarios, and users through systematic analysis of the requirements. Then, calm down and ask yourself a series of prepared questions to judge the authenticity of the requirements, and avoid wrong judgments caused by thinking traps and cognitive biases, which may lead to the waste of development resources. After that, analyze the existing solutions, understand the situation of market competitors, which is convenient for formulating competitive strategies and learning from competitors to build the product prototype. Finally, analyze the industry structure, establish a systematic understanding of the industry, and prepare for the product to enter the market.

Requirement analysis is a key step in product development and one of the keys to product success. Only through systematic requirement analysis can we comprehensively understand the expectations and needs of customers and users, and provide accurate directions and guidance for design and development.

In this process, we need to adopt a comprehensive and in-depth method to sort out and analyze the requirements, establish a systematic understanding of the requirements, and thus make wise decisions in the design and development process.

1. What problems do users encounter? Analyze user pain points

First of all, it is necessary to clarify what problems users encounter, that is, user pain points, which are the basis for meeting user needs. By analyzing user pain points, we can understand what users need and what problems they encounter. Understanding this information can help us determine the design direction of the product and which functions and needs the product needs to meet.

2. In what scenarios do the requirements arise? Construct requirement scenarios

User requirements usually arise in specific scenarios. By constructing requirement scenarios, we can better understand how user needs are generated, dig out the motivation for the requirements, and better empathize with the user role, thus optimizing the product design. It should be noted that the constructed requirement scenarios not only include the environment where the user is located, but also include the user's attributes and the problems the user is facing at that time.

Since the requirement scenario generally appears in the user story as the background of the occurrence of the requirement, the image of the protagonist must be three-dimensional.

3. When do users generate requirements? Judge the value of the requirements

After clarifying in what scenarios the requirements are generated, we can judge the time when the requirements are generated. In addition to better improving the requirement background to achieve the purpose of optimizing the product design, we can also further analyze the duration of the requirements and the frequency of their occurrence according to the time when the requirements are generated, so as to judge whether the requirements are worth solving and their priority.

4. Why is this requirement proposed? Dig out the user's motivation

The way to uncover the user's motivation is simply to dig out the requirements until an emotional connection with the user is established, that is, to judge whether one has also had similar requirements. If you have the same requirements as the user, you can dig out the user's motivation (fundamental needs) through self-emotional analysis (cognitive review); for the requirements that you have not encountered, you cannot make a relatively objective judgment through subjective understanding. You need to ask the person who proposed the requirement, understand their behavior logic, adjust your self-cognition to improve the user's mental model, and then dig out the motivation for the requirement.

5. Which users will generate requirements? Define the target users

Defining the target users is a key factor in successfully developing a product that meets user needs. The target users need to be continuously adjusted, and at this stage, it is only necessary to determine the scope of the target users, that is, which people are likely to become the main audience group after the product is launched. We can look for the target user group by analyzing the motivation for the requirements, that is, to infer which users have the same motivation for the requirements.

6. How to meet user needs? Conceive the business process

Any product starts with an idea, but the idea in the mind will inevitably be taken for granted. Only by implementing the idea into actual operation can we truly evaluate its feasibility from the perspective of an outsider and prepare for drawing the business process diagram. Specifically, tell a user story to describe how users achieve their goals by using the product.

7. How much cost is needed to provide services to users?

According to the conceived business process above, analyze the aspects in which the product needs to incur costs when providing services to users and estimate the approximate amount. At this stage, the investment should be divided into construction costs and operation costs for estimation:

• Construction costs include aspects such as product technical construction, server leasing, and team building, which are essential investments in the initial development of the product;
• Operational costs include aspects such as advertising promotion, customer service, and data analysis, mainly for product market promotion, customer service, and operation analysis in the early operation and later stages of the product.

8. Judge whether users have this requirement

Judge whether users have this requirement, that is, find out the false requirements. In a narrow sense, false requirements refer to non-existent requirements, that is, mistaking user appeals as requirements to be solved. In a broad sense, false requirements refer to requirements that do not need to be solved, such as requirements that are not universal; requirements for which there are existing solutions; and requirements that users do not want to solve.

9. Two types of requirement solutions

There are two types of requirement solutions: One is that users solve the problems by themselves, and the other is that competing products provide services. Analyzing the way that users solve the problems by themselves is relatively simple. The key point is to study how to make users change their behavior habits and accept the new requirement solutions. Relatively speaking, the analysis of competing products needs to be more comprehensive. On the one hand, we can understand the current market competition situation. Knowing oneself and the enemy ensures victory in every battle. On the other hand, we can obtain inspiration from the business processes and functional designs of competing products, visualize the requirement solutions, and draw them into wireframes.

III. Industry mapping for market entry

The purpose of industry structure analysis is to systematically think about which aspects need to be involved in the implementation of the solution, and provide a theoretical basis for the product to enter the market by establishing a systematic understanding of the industry. Industry structure analysis is divided into three steps: Understand the basic information of the industry by analyzing the industry overview; clarify the product's spatial position by sorting out the industrial structure; clarify the product's time position by sorting out the market life cycle. The role of the requirement analysis link is mainly to judge the value of the requirements and design corresponding solutions. This process can be very complex or relatively brief, and it can even be directly omitted and jump to requirement management. The fundamental difference lies in the workload of requirement implementation.

IV. Cognitive-based requirement judgments

The essence of requirement analysis is to make assumptions based on cognition and then give judgments. Its core is to continuously deepen the understanding of requirements, adjust the cognition of requirements, and make one's assumptions as close as possible to objective facts to draw more accurate judgments. Finally, carry out product design and strategic formulation according to these judgments. Requirement analysis is very important. The value of subsequent work is based on the correctness of the assumptions. If the result of requirement analysis is wrong, the product will inevitably fail. However, requirement analysis is not overly crucial either because no one can consider all influencing factors at once, and the agile development form of Internet products also reduces the cost of trial and error.

As long as the general direction is correct, as long as continuous fine-tuning is carried out later, the product will tend to be perfect. It is important to analyze with a falsification mindset and conduct a review with a verification mindset.