How to Maintain a Healthy Requirement Pool? Source

Translated

Image source: Modern Requirements

Many product managers have such a pain: there are many miscellaneous requirements, many positions that need to be connected, and even a requirement often involves multiple positions. At this time, we need a useful tool to manage various requirements: the requirement pool. The requirement pool is to the product manager, just like the Gantt chart is to the project manager.

A requirements pool is not a simple listing of requirements. A healthy requirement pool allows users to intuitively see the progress of each requirement and which requirement to advance next; it can also help users diagnose problems in version iterations; it can also allow users to see what each position needs to prepare in the implementation of each requirement.

I. What is an Unhealthy Requirement Pool?

• The priority of each requirement is not marked;
• It does not involve how to cooperate with each position and cannot promote communication;
• The sequence of requirements is not clarified;
• No version planning;
• It schedules BUGs or does not record BUGs at all;
• The requirement pool is complex and takes a lot of time to maintain daily.
• ......

II. How to Maintain a Healthy Requirement Pool?

1. The header of the Demand Pool

• Priority: My priority habit is A +, A, B, Z. A + means to do it right away, A/B is a candidate, and a new A + will be appointed from AB after finishing A +. Z means to be suspended, and I can't do it for a while. I am not marking the priority directions for some requirements that I am unsure whether to do. EXCEL's custom sorting function can easily implement priority sorting.
• Requirements Module/Keywords: This makes it easy for requirements to be found quickly and for related requirements to be put together for planning. However, product managers responsible for a single module do not need this field.
• A detailed description of requirements.
• Postscript: We need to record important changes, such as technical difficulties, changes in requirement-side requirements, etc. To prevent forgetting, we'd better add the record time. Generally, my format is XXXXXX@181120.
• Progress: the lifeline of a requirement is often as follows: propose and discuss requirements → decompose requirements (often forming a flow chart) → communicate and estimate the time limit → schedule priorities → specific planning (often forming a requirement document) → schedule and complete. When maintaining the requirements pool, I divide the requirements into several states: requirements research, planning, plan confirmed, technology docking, development, and completion. And we can determine when we expect to reach what kind of stage according to the results of our communication with technicians.
• Product Owner: They record to who each requirement is distributed. Of course, if they only record their requirements, they don't need this field.

2. How to Evaluate Priorities？

We evaluate priorities from 3+1 dimensions: importance, urgency, roughly estimated time limit, plus a bug.

• The product manager is not alone in determining the importance and urgency. He needs to determine it through communication with the senior leadership and the demand side;
• We need to ask our technical colleagues to increase the requirement priority for the estimated time limit simply. It is better to record the estimated time limit given by the developers and the actual completion duration at the same time so that we can help understand our team's ability to complete the requirements;
• Bugs must be recorded in the requirements, but there is no need to schedule, and bugs must be solved as soon as possible.

Based on the evaluation of the above three dimensions, we marked the things to be done in the next two versions in the table.

Note: For user experience, we control the release frequency. Especially when your product is an app, each large version needs to be re-downloaded. Even the iteration that can be updated automatically should also control the frequency.

3. Why is such a Requirement Pool Healthy？

• We should review the requirements as a whole to improve the efficiency of iteration; Although each thing individually is of a very important and urgent level, the requirement will always be larger than our digestion capacity. And with the principle of prioritizing the important things, we must jointly review and select the most important and urgent agency projects so that the iteration can be carried out in the best direction for the whole project.
• We need to explain priorities and project progress to stakeholders, which can improve team transparency, make everyone understand each other, reduce complaints, and improve efficiency.

III. Who Maintains the Requirements Pool?

The maintainer is the product manager, but the data source involves development colleagues and the demand side of different departments. At this time, everyone needs to sit down and review the requirements quickly and efficiently, and in addition, there must be a decision-making leader present to prevent wasting time.

In front of everyone (especially in front of the leaders), it is also important that we carefully define each requirement again because sometimes the requirement will be cut off by the boss if it is not considered from the perspective of the product as a whole. So never let your development team get caught up in requirements that have not been seriously reviewed and waste time.

The work of a product manager, especially when they reach a certain level and start leading a team, requirement pool = TO DO lists. It is best for the product manager to go through the requirements daily and not let them be abandoned on the table.