Product requirement analysis work is the beginning of a series of product work. As the saying goes, a good start is half the battle. In order to ensure that you have a good start in this work, the author summarizes 5 typical pitfalls in the process of product requirement analysis and provides some targeted advice based on his own experience and lessons learned.
Requirement analysis is one of the daily tasks of a product manager. As a preparation work for product prototype design, requirement analysis largely determines the direction and scope of subsequent product-related work, and its importance is beyond doubt. Therefore, a qualified product manager should have certain methods and strategies in requirement analysis.
Today, based on his past experience in requirement analysis and some observations, Long Ge shares 5 common pitfalls in requirement analysis work. Whether it is for Long Ge himself or for you who are reading this article, it serves as a reminder and motivation.
1. Treating oneself as the user#
This is probably the most common pitfall that product managers fall into.
From the perspective of requirements, product managers are the spokesperson for user needs. At this time, the product manager actually combines two identities:
- The user who proposes the requirements
- The person who organizes the requirements
Generally speaking, at the beginning stage of requirement analysis work, product managers can maintain a certain level of clarity and can reasonably distinguish the source of requirements. As the product requirement analysis work progresses, whether it is user research or competitor analysis and related requirement analysis work, product managers will become more and more familiar with user needs. Product managers will gradually become more confident in requirement analysis.
However, due to the sense of achievement generated by long-term immersion in product research work, product managers will gradually and unconsciously confuse these two identities, treating themselves as typical users. They will start to propose requirements based on their own needs rather than user needs, and even ignore user research and judge the reasonableness of requirements based on their own preferences.
In this situation, product managers tend to become stubborn and self-centered, firmly believing that they are not substituting their own will for others, thus causing unnecessary deviations in subsequent product work.
To address this, Long Ge offers two strategies:
Strategy 1: Integrate into the user group and regularly communicate the results of product requirement analysis with users#
Long Ge's experience suggests at least two such communications. One is when the product requirement framework is completed, this communication can filter out deviations and errors in direction; the other is when the detailed product requirement analysis is completed, this feedback can filter out deviations and mistakes in details.
After these two rounds of communication and feedback, there will be basically no low-level or fatal deviations, effectively avoiding falling into this pit. At the same time, the errors discovered through these two rounds of feedback can be recorded and reflected upon to understand why mistakes were made at that time.
Strategy 2: Equalize the relationship between oneself and the user, and do not consider oneself as a god#
The product is ultimately for the users. Whether a certain function is needed and the strength of the requirement should not be determined by the product manager, but by the target users.
Product managers need to adjust their mindset and remember that their responsibility is not to dictate requirements, but to discover user needs and then use their professional skills and knowledge to turn the discovered user needs into standardized and refined requirement documents.
Respect the voice of the users, because what you want is the success of the product, not the success of your so-called requirements.
Whenever you stubbornly insist on a requirement that you think is correct, remember to think of Long Ge's words in a timely manner.
2. Being led astray by users#
The path of requirement analysis for product managers is full of pitfalls. The first pit that product managers who have successfully passed the first pit will encounter is being led astray by users.
Although product requirements ultimately come from users, qualified product managers should know that users are mostly non-professionals. They tend to be short-sighted and may provide surface requirements that seem like requirements but are not real needs (it's complicated~).
If you are not attentive and sharp enough, it is easy to be led astray by users, even though it is not the intention of the users to provide such requirements.
For this pit, Long Ge gives you a tip: ask why.
Users have reasons for their short-sightedness because they want to solve a problem. They are just finding a solution that they think is reasonable within their knowledge range. If you take this solution as a requirement, you will be led astray, even to an absurd extent.
Based on the above analysis, you will find a fact: you can uncover the true needs behind the surface needs of users by asking "why" (Why do you need this feature? Why do you want to do it this way?). Once you find the real needs, you will naturally avoid being led astray.
Here's an example (an example that product managers have heard countless times, so Long Ge will just briefly mention it, for those who don't know, you can search or ask someone):
Product Manager - Ford: What else do you want?
User: I want a faster horse.
Product Manager - Ford: Why do you want a faster horse?
User: Because I want to be faster and save time.
Product Manager - Ford: I have created something called a car, which is much faster than a horse.
This pit tests the professionalism of product managers. You cannot be lazy, you need to be attentive, and you need to dig out the real needs from the surface needs of users.
3. Trying to do everything at once#
Product managers have established a good relationship with users and can see through the real needs behind the surface needs. At this point, the third pit comes - trying to do everything at once.
At this point, product managers have collected a lot of requirements, each of which is a genuine need, and they all seem important and indispensable, but there is a vague feeling that there are too many of these requirements and it seems overwhelming.
The reason for this phenomenon, in most cases, is the lack of classification and prioritization of requirements. Regarding this pit, Long Ge has a suggestion:
Use the KANO model (Long Ge won't go into the details, young people can solve it themselves).
The KANO model classifies requirements into the following three categories:
- Core Needs: Long Ge also calls them basic needs. Without this type of requirement, there is no need to continue the product. For example, a music player that cannot play mp3 files.
- Expected Needs: Optimization based on basic needs. With this type of requirement, your product will be more user-friendly. For example, a music player that can automatically download and display lyrics that perfectly match the currently playing song.
- Excitement Needs: Meeting the psychological motivation behind core needs. This type of requirement usually makes users feel excited about the product. For example, a music player's song rankings or enhanced sound effects.
This order is not randomly written by Long Ge. Generally speaking, when developing a new product, core needs have the highest priority, followed by expected needs, and then excitement needs.
4. Being influenced by leaders#
Having successfully passed the third pit, congratulations, you have now come to the fourth pit - being influenced by leaders.
With the requirements you have discovered, organized, classified, and prioritized, you confidently report to your leaders, expecting their approval and recognition. However, you will always encounter situations where your ideas are rejected, even though you may think you are right.
Mysteriously, you are being influenced by leaders and come up with a requirement that the leader approves but you may not fully agree with.
For this pit, Long Ge's strategy is as follows: it depends.
If the leader is knowledgeable, in general, the leader has more experience and can see things beyond your scope of accumulation, experience, and lessons learned. They may give you some advice that goes beyond your understanding at that time, but you should listen to them.
In another situation, if the leader is not knowledgeable and also assertive, it is likely that you will encounter a situation where you disagree with their opinions but are hesitant to speak up because they are the leader.
In this case, Long Ge's advice is: try to speak up. Organize your reasons and be confident. Believe that you didn't come up with an unnecessary requirement out of thin air. Explain your logic or arguments to the leader. If your reasons are sufficient and correct, the leader has no reason to insist on something wrong, after all, a good product makes a good company.
Of course, if you have tried more than three times and the situation remains the same, then you really need to think about it.
5. How to develop#
After dealing with leaders, you come to the last pit - how to develop?
You may say, isn't it simple? Just develop the core requirements.
In fact, if you have done product requirement analysis, you will find that there are actually many core requirements.
Regarding this issue, Long Ge has the following insights:
Strategy 1: Clarify the purpose of the product to be launched this time#
Not all core functions need to be included. The focus of core functions varies in different product periods or version plans. You need to clarify the main problems of the target users to be solved in this period or version, which is the main purpose of your product for this period.
For example, in the first version of a music player, the first problem to be solved is to be able to smoothly and correctly play mainstream audio formats on the market.
Strategy 2: Make the functions MVP (Minimum Viable Product) around this purpose#
This MVP does not refer to the MVP in the NBA, but the Minimum Viable Product. The scope of this MVP is determined based on the purpose of Strategy 1 and is a subset of core functions. Therefore, these two strategies are used in conjunction.
Divide the MVP based on the purpose of this period, and then carry out productization work based on the MVP with the minimum workload, shortest time, and lowest risk to verify the feasibility of the product. If the verification result is correct, then continue to expand; if it is not correct, adjust the strategy as soon as possible and start again.
There are two criteria for judging whether the MVP is qualified: the first criterion is "completeness", which means that with these functions, the purpose of the product can be achieved; the second criterion is "necessity", which means that the specified functions cannot be reduced, otherwise the purpose of the product cannot be achieved.
The road of product requirement analysis is full of pits, and one can easily fall into them.
As a qualified product manager, you need to be familiar with the location, size, and shape of these pits. You also need to be quick and agile to fill or bypass the pits in a timely manner. Only then can you successfully move on to the next stage of product work.