I’m in the fourth quarter of Denver’s Creators Camp
What is requirements management?
Requirements management is a very important skill for product managers. Simply understood, it means that product managers record all requirements and prioritize existing requirements according to the strategic goals of the company. What to do and what not to do, what to do first and what to do later.
Why do requirements management?
Because there are so many demands on product managers in the company. If you don’t manage requirements, you can have a lot of problems. Let me give you two examples:
- The team worked overtime to do a lot of requirements, but when they did it, they looked at the data and found that some features were not being used at all
- The business side makes a request, the product manager receives it, doesn’t think it’s important and doesn’t schedule it. It was forgotten as time went by.
How to do requirements management?
1. Document all requirements
This means that you need a place to keep track of all requirements so that they are not lost. It could be an online collaboration tool, or it could be an Excel sheet. This place to record requirements is called the requirements pool.
In the requirement pool, we need to record: originator, requirement description, requirement purpose, requirement source, affected users, usage scenarios, user demands, requirement status, incoming version and priority.
And the priority here is what we’re going to do, we’re going to rank the requirements. The caveat is that. Requirements are a dynamic process, and what is low in priority now is likely to become high in the future.
2. Prioritize requirements
First, we need to establish a criteria for prioritizing requirements. My approach is to analyze requirements in terms of importance and urgency.
First things first. What are the most important requirements that must be completed? It varies from company to company. My own ranking is based on two dimensions: business value and user value.
Business value refers to those functions that directly bring profits to the company, reduce operating costs, and achieve the long-term strategic goals of the company. User value refers to features that improve user experience, improve user efficiency, and solve user pain points.
Based on these two dimensions, we can draw a four-quadrant map, classifying all our requirements into different quadrants according to the two dimensions of business value and user value. For products with high commercial value and high user value. We should do it right away. The second priority is the demand of high commercial value and low user value; Or the demand of low commercial value and high user value should be determined according to the actual situation of the company.
After breaking it down in terms of business value and user value, we continue to analyze it in terms of emergencies. In general, bugs are the most urgent, and requirements that no one uses are the least urgent. Thus, we can obtain four quadrants according to the two dimensions of critical and urgent, corresponding to P1 (critical and urgent, highest priority), P2 (Critical and not important), P3 (important but not Critical), P4 (Not Critical and not important) plus P0 bugs and pseudo requirements. We can divide all needs into these six categories.
Here’s an explanation. In many cases, the team does not necessarily finish P2 first and then do P3. We sometimes have to do urgent things first, depending on the situation of the company.
In addition, in practical work, we will encounter too many demands at the same level and do not know how to choose. This is a case by case analysis. Here I add two strategies for prioritizing requirements:
-
Whether normal use is affected. If this function is not done, can the product still be used? If it doesn’t work, do it first. If it works, it can be postponed when resources are scarce.
-
The value is determined by the user base and usage times. In particular, the usage base and frequency of core users. (Functions that have been launched have data, while functions that have not been launched have to make predictions by themselves)
3. Plan the version based on your requirements.
The goal of versioning is to have an outcome for all requirements. Should I put it in this version or the next version? Again, the next version. I usually plan releases quarterly. If the requirements cannot be filled within a quarter, the relevant personnel (usually the person who proposed the requirements and the affected colleagues) will be informed that the requirements will not be completed for a short period of time. Also, if the requirements for future plan versions change, inform the relevant personnel immediately.
Note: When planning releases, there will be many temporary requirements in the future, so do not over-schedule one release. Especially those P3, P4 requirements. Also, when replying to the requestor, do not give a specific time, but a vague date. Like, next month or the month after that.
In field case
The hardest part of requirements management is prioritizing requirements. So here’s a practical example, which is a classic interview question about requirements priorities:
In 1998, QQ began planning, Beta1 in February 99, Beta2 in May 99, Beta3 in August 99. Beta1 can only implement 3 features which would you choose? 1, cartoon avatar 2, not eavesdrop safe communication 3, chat room 4, very small.exe file 5, skin skin 6, super fast 0.5 second response 7, chat record manager 8, voice 9, video 10, see who online 11, file transfer 12, QQ expression.
What would you do? According to this, we can order by importance and urgency.
Critical emergency screening
In this case, the 12 requirements were all designed based on user value. So let’s first make a selection according to the importance and urgency:
- (P0) : Chat room (3), see who’s online (10)
- Important but not urgent (P1) : cartoon avatar (1), Uneavesdropping safe communication (2), Skin skin (5), response over 0.5 seconds (6), Chat record manager (7), QQ expressions (12)
- Not important, not urgent (P3) : small. Exe file (4), voice (8), video (9), upload file (11)
Thinking logic
Tell me why I sorted it this way. First of all, users registered QQ, but adding friends is a trouble, and the chat room is to solve this problem, let everyone chat in a strange chat room first, and then have a good impression of their friends. So the next time you want to talk to someone after you’ve friended them, is it better to know that they’re online? Otherwise, you might have an awkward situation where you chat with 10 people and no one replies. So these two needs are important and urgent.
As for why I put 4, 8, 9, 11 as unimportant and not urgent, I think about it this way. At that time, THE QQ installation package was not large and had few functions, so there was no need to optimize it. However, voice, video and file, based on the broadband network at that time, could not achieve a good experience, so I think it can be put in the later.
Requirements 1, 5 and 12 are all entertainment functions that allow users to “play”. But if it’s about which feature users see the most, it might be the profile picture. After all, the first thing you see when you chat with someone online is their profile picture.
Requirement 2 is a very important function, but to be honest, I don’t know the difficulty of doing it at that time, and Tencent is still in its infancy at this stage, so I will do this function later.
Requirement 6 is to improve user experience. But how much is that boost worth? If you don’t optimize, users can’t use it, or some low-end users can’t use it. Then this requirement is very important. Otherwise, there’s no need to rush to optimize.
Requirement 7: At that time, everyone was surfing the Internet in Internet cafes. Even if a record manager was made, no one could see the record. Because Internet cafes will clear data every time they restart. And if you do online storage, it will be very expensive. So I’ll put that requirement on the back burner.
So, in general, pick the three with the highest priority, and I would pick 3, 10, 1 or 3, 10, 6