Managing requirements is a fundamental task that every product manager must face. How can you effectively prioritize and schedule different requirements? How can you organize your work in a more structured way? In this article, the author draws on personal experience and relevant theories to explain what requirement management entails and how to implement it effectively. Hopefully, this guide will provide you with valuable insights and practical solutions.
As a B2B product manager, one of my primary responsibilities is demand management. In my daily work, I face the challenge of supporting multiple internal business lines while providing highly personalized custom services to external customers. This means my demand management work must address various complex scenarios, such as balancing internal and external demands, coordinating multiple business lines, and collaborating with several development teams.
In this article, I will combine my own work experience with relevant theories to explain what demand management is and how to carry it out effectively. Whether you're a product manager or someone interested in demand management, I believe this article will provide valuable insights into your work and learning.
1. What is Demand Management?
First and foremost, it's important to clarify one point: demand management is not just about managing the priority of demands. True demand management involves the entire lifecycle of a demand, including six key aspects: demand generation, demand analysis, demand prioritization, demand development and testing, demand validation, and demand closure. Therefore, only by focusing on all six aspects can we achieve truly comprehensive demand management, which is essential for ensuring its effectiveness.
Next, we will break down these six aspects to analyze and explain how to implement demand management. Please read carefully through each section to fully improve your understanding of demand management processes and solutions.
2. Demand Generation
2.1 Demand Sources
For a B2B product manager, there are many channels for demand generation. The main sources include:
Business departments
External customers
R&D (Research and Development)
Product team
Operations team
Maintenance team
Upper management
The reasons behind demand generation from these channels are as follows:
Business departments: When defining business goals, if they find that product features cannot support the achievement of these goals, demands arise.
External customers: New business partnerships or the optimization of existing ones can lead to demands.
R&D department: When technical upgrades or architectural adjustments require collaboration from product managers, demands arise.
Product team: When a product manager drives the development or restructuring of product features, demands arise.
Operations and maintenance teams: Issues encountered during daily operations or user feedback can lead to optimization demands.
Upper management: Participation in forums or discussions with senior executives can also lead to demand generation.
2.2 The Process of Demand Generation
Let’s take the most common and typical demand source—the business department—to analyze the underlying logic of demand generation.
First, business goals are the starting point for demands. To support its growth, a business defines certain objectives. In order to achieve these objectives, a business creates corresponding strategies or action plans. During this process, they may discover that the existing system capabilities do not support their strategies and goals, resulting in business pain points.
Business pain points are the obstacles encountered during the process of achieving business goals. However, different individuals within the business may have varying understandings of these pain points. Senior management typically has a clearer understanding of the pain points and their impact on business goals, whereas front-line employees might focus more on operational or personal aspects. The stronger the connection between the pain points and business goals, the more attention they receive, making them more likely to generate business needs. Pain points that have little impact on goals, are tolerable, or are not even recognized by the business, rarely result in demands.
Business needs stem from pain points and reflect a perceived gap. If the business can resolve this need internally through process optimization or manual intervention, no demand is generated. Only when the business cannot solve the issue internally and must rely on external support (i.e., the product manager) does it turn into a business demand.
In summary, the transformation from business goals → business strategies → business pain points → business needs → business demands represents the underlying logic of demand generation.
Three conditions must be met to generate a business demand (MRD):
The current system does not support the business strategy or plan.
The business believes the pain point must be addressed immediately.
The issue cannot be resolved internally and requires the assistance of the product team.
By applying this logic to other channels, we can see similar processes. For instance, external customers may generate demands due to new business growth goals, R&D may generate demands to enhance cost-effectiveness, and the operations team may generate demands to improve user experience.
3. Demand Analysis
As product managers, we take on demands from various channels and invest significant effort in fulfilling business requirements. However, issues often arise such as demands being canceled midway, the delivered solution not meeting business expectations, or failing to achieve the desired results. While these issues can stem from multiple causes, one of the most critical factors is the product manager’s incorrect analysis of business needs.
What is Demand Analysis?
Demand analysis involves identifying the true need and filtering out false demands by analyzing the process of how the demand was generated. This process involves understanding the journey from goal → strategy → pain point → need → demand. So, how do we conduct effective demand analysis? Below are two commonly used methods that product managers rely on in their daily work.
Method 1: Using the 5 Whys to Analyze the Demand Generation Process
First, we perform high-level demand analysis, focusing on the demand generation process. The formation of a business demand and its communication to the product manager usually undergoes a lengthy process with multiple decisions, during which information may inevitably get distorted. By using the 5 Whys method, we can analyze whether any issues exist in the process, ensuring that the demand is genuine and reliable.
When analyzing the demand generation process, product managers can ask the following questions:
Is the business goal reasonable? Is it set too high or too low? Is it measurable?
Is the strategy to achieve the business goal the correct path?
Are the business pain points real? Do they come from senior management or front-line employees? Is the current system incapable of addressing the pain point, or is it a case of user error? Does it truly affect the business strategy?
Is the business need a real reflection of the business pain point? Does it need to be addressed immediately?
Is the proposed solution the only one? Is it reasonable? Can the business not solve the issue internally?
After going live, will this help achieve the goal? How much will it contribute to the goal? Is the cost-benefit ratio reasonable?
These questions are just starting points, and product managers are encouraged to analyze from different angles and stages in practice, thus honing their demand analysis skills.
Method 2: Scenario, Role or System, and Process Analysis
Next, we move to a more detailed level of demand analysis, focusing on the content of the demand. First, we use the Scenario, Role, and Process method to map out the business process, which helps us design a correct, reasonable, and executable business flow. Then, we use the Scenario, System, and Process method in combination with product architecture capabilities to translate the business flow into a correct, reasonable, and efficient system flow. Through these two methods, we can produce both business process diagrams and system process diagrams, which are critical elements for a product manager’s design plan.
Case Study:
Business Background: Our company operates a logistics platform, providing logistics services and warehousing solutions to both large clients and small to medium-sized customers in the logistics market. As such, we need to sign contracts with our clients and manage contract documentation as proof of logistics agreements.
First, we map out the business process using the Scenario, Role, and Process method. We discovered that the contract signing process for large clients differs from that of small and medium-sized clients. The process for large clients is more complex and lengthy, while the process for smaller clients is relatively simplified and standardized.
Finally, using the Scenario, System, and Process method, we designed the system flow. (This example is simplified by the author. In real business scenarios, the system roles and business flows would be far more complex. For more details on how to create business and system flows, readers can refer to BRD and PRD writing standards for further learning.)
4. Demand Priority Management
On the surface, managing demand priorities seems to be about ranking and selecting which demands to fulfill. However, the essence lies in aligning the goals of various departments such as business, development, and testing, while efficiently and rationally utilizing resources to ensure the goals are achieved.
As the primary person responsible for demand priority management, product managers face several key challenges when coordinating goals and distributing resources:
Balancing and ranking goals across multiple departments:
Demands come from multiple channels, each with its own objectives—whether it's business, product, development, or operations. It is difficult to prioritize and balance goals across different departments.Balancing and ranking goals across multiple business lines:
When managing demands from different business lines, it becomes more complex if they are at different stages of development or vary in scale. Prioritizing between different business lines is challenging (this issue is similar to the first but even harder).Resource allocation for concurrent goals:
While demands have a clear order of priority, in practice, multiple demands often run concurrently. How to allocate resources and ensure the achievement of multiple goals is a difficult task.Handling urgent and ad-hoc demands:
Urgent and ad-hoc demands can disrupt the existing priority order, requiring the list to be re-prioritized and resources to be reallocated. Managing both pre-scheduled demands and urgent needs simultaneously is a tough challenge.
From these challenges, it is clear that demand priority management tests a product manager’s ability to communicate and coordinate across business lines and departments in complex scenarios.
Next, I will introduce two methods for managing demand priorities: Quantitative Analysis and Qualitative Analysis. It is important to note that demand priority management is a highly complex task, and these methods can only serve as tools to assist. To truly excel, product managers must first develop excellent coordination and communication skills, and then apply these methods effectively.
4.1 Quantitative Analysis
If the evaluation of priorities is based solely on personal judgment, it will be difficult to get all stakeholders to agree on the priority order. To avoid the influence of personal preferences or biases, we can adopt more scientific approaches, such as the comprehensive scoring method (or weighted sum method) to quantify demand priorities. The steps are as follows:
Step 1: Define the criteria.
When selecting and formulating the priority evaluation criteria, communicate fully with other departments to ensure that the criteria are widely accepted.
Example: At a certain company, the priority evaluation criteria include "goal type, demand source, importance & urgency, and benefit type." Under each criterion, there are subcategories such as:
Goal Type: Company strategic goals, business strategic goals, product goals, optimization goals, etc.
Demand Source: Business department, external clients, development department, user experience team, etc.
Importance & Urgency: Important and urgent, important but not urgent, not important but urgent, not important and not urgent.
Benefit Type: Business growth, efficiency improvement, experience enhancement, innovation, etc.
Step 2: Define scoring standards.
Create a scoring system for each criterion and subcategory through discussions with other departments, ensuring it is widely accepted.
Example: In the same company, there are four criteria, with a total score of 80. Each criterion is worth 20 points. The breakdown is as follows:
Goal Type: Company strategic goal – 20 points, business strategic goal – 15 points, product goal – 10 points, optimization goal – 5 points.
Demand Source: Business department – 20 points, external clients – 20 points, development department – 10 points, user experience team – 5 points.
Importance & Urgency: Important and urgent – 20 points, important but not urgent – 15 points, not important but urgent – 10 points, not important and not urgent – 5 points.
Benefit Type: Business growth – 20 points, innovation – 15 points, efficiency improvement – 10 points, experience enhancement – 5 points.
A few notes about scoring standards:
The comprehensive scoring method is more commonly used than the weighted sum method because the criteria tend to be independent of each other, making different weightings impractical. For example, it’s hard to decide whether goal type or demand source should carry more weight.
The scoring values for each criterion are kept equal for the same reason. Assigning one criterion more weight (e.g., 30 points for goal type and 10 for demand source) would be unreasonable.
The weighted sum method can be used when criteria can be clearly ranked in importance, allowing for something like A30% + B20% + C20% + D30% = 100%.
Step 3: Scoring the demands.
Score each demand based on the criteria and calculate the final score.
Example: For the same company, the final scores for demands are as follows:
Demand A: 60 points;
Demand B: 75 points;
Demand C: 30 points.
Additional notes on scoring:
You must thoroughly understand the demand’s goals and benefits before making an objective, accurate judgment.
Regularly review and evaluate the scoring results, as the external environment changes constantly. For example, a non-urgent demand might become urgent, or a business goal may turn into a company-wide strategic goal, affecting the scores.
4.2 Qualitative Analysis
Relying solely on quantitative analysis cannot address all issues, as it doesn’t cover every scenario. To ensure that demand priority management is comprehensive, reasonable, and flexible, qualitative analysis is also needed.
Qualitative analysis is more of an instinctive judgment based on experience. I believe that qualitative analysis largely stems from accumulated experience in managing priorities. Here are some tips based on my experience:
For demands with short development cycles, try to integrate them into other related projects or find opportunities to fit them into existing work.
Combine product and research demands with business demands to achieve multiple goals through a single demand.
When designing a product plan, consider the long-term product roadmap. Persuade the business team to accept a longer but more reasonable solution that fulfills both business goals and the product’s long-term objectives.
Focus on "important but not urgent" demands to prevent them from becoming urgent.
For long-cycle demands with tight launch deadlines, implement them in batches or stages.
For urgent demands from the boss or clients, avoid blindly executing them. First, communicate with them to understand the background and reasoning, as you may find that the demand is false or not actually urgent.
When resources are tight and you cannot launch as expected, consider using temporary operational or offline solutions to manage the situation.
Prioritize external client demands over internal ones. This is because customer-centric demands help prevent complaints or customer loss, while internal issues can often be resolved internally.
Online bugs should not be managed through the demand pool; they must be fixed immediately.
5. Requirement Development and Testing
Once a requirement enters the development and testing phase, many product managers may believe their role in requirement management is finished and all that's left is to wait for the product to go live. However, this isn't the case. If issues such as delays or development and testing quality problems arise at this stage, they can still affect the delivery of the requirement. Thus, requirement management remains essential during this phase!
Next, we will discuss in detail the requirement management responsibilities of product managers in both the "requirement development" and "requirement testing" phases to ensure smooth delivery.
5.1 Requirement Development
During the requirement development stage, product managers should focus on two key aspects:
Monitoring whether development is proceeding as planned and identifying any risks.
Ensuring development quality to guarantee high-quality delivery.
First, regarding the first aspect, product managers should be well-versed in project management skills and apply them to the ongoing management of requirements. For example, they can organize daily stand-up meetings for product, development, and testing teams, as well as weekly project meetings and requirement progress communication sessions. By regularly checking development progress and issues with the R&D team, they can identify risks early and take timely action to avoid delays.
Next, regarding the second aspect, although product managers do not participate directly in development and cannot take responsibility for code quality, they can still help establish a well-structured development process to ensure high-quality delivery. Recommendations include:
Adding a "technical solution overview" and "detailed technical solution" review step in which the product manager participates to ensure the technical solution aligns with the product’s goals.
Introducing a "code review" step where an architect reviews the code to ensure its quality. (Note: If your company does not have these processes, product managers can propose process improvements. If that's not possible, one can only hope for the best.)
5.2 Requirement Testing
During the requirement testing phase, product managers should focus on two key aspects:
Monitoring whether testing is proceeding as planned and identifying any risks.
Ensuring the testing quality to guarantee high-quality delivery.
First, regarding the first aspect, follow the same approach as in requirement development (5.1). Product managers should simultaneously oversee both the development and testing progress, as well as any issues.
Second, to ensure testing quality, recommendations include:
Adding a "test case review" step in which the product manager participates to ensure all functional scenarios are covered.
Requesting that testers document and report issues found during testing, tracing the causes of these issues to improve the quality of the product, development, and testing processes.
After testing is completed, the product manager should conduct an online acceptance review.
6. Requirement Validation
This stage is often overlooked by product managers. Many believe that once the requirement goes live, their job is done, and they care little about whether the requirement’s goals are achieved, thinking this is the responsibility of the business department. However, this mindset often leads to missed opportunities for success. As product managers, we must "begin with the end in mind" and always remember the original intent of the requirement. In the requirement validation phase, we need to ensure the requirement's goals are fully realized. Only in this way can we reap the fruits of success and make the journey of requirement management more complete and fulfilling!
Next, we will discuss what requirement management tasks product managers should undertake during the requirement validation phase.
First, product managers should focus on and participate in the formulation and execution of the "three plans": the gray release plan, promotion plan, and operation plan. Although these plans technically fall under the responsibilities of the business team (the demand submitter), they are crucial in determining whether the requirement can deliver the desired business outcomes.
Product managers should take the following management actions:
Gray Release Plan: Collaborate with the business team to set gray release goals, scenarios, and timelines to quickly validate the usability and feasibility of the product solution during the gray release phase.
Promotion Plan: Collaborate with the business team to set promotion goals, scope, and timelines to ensure the product solution can be replicated and achieves the expected business outcomes.
Operation Plan: Collaborate with the business team to develop a stable, long-term, and efficient daily operational process to ensure the product solution continues to deliver stable business results. (Note: Although these plans have an order, it's best to develop them simultaneously to avoid disconnection between them.)
Second, while formulating and executing these three plans, a business data metrics system should be established. This system should include measurable metrics to assess the project's progress and performance. The metrics should be objective and quantifiable to better monitor and evaluate project progress and business results. It’s recommended to refer to Amazon's approach of using Input, Output, and Observation Metrics.
Lastly, product managers should iterate on the product solution or adjust the plans. By monitoring and analyzing the business metrics system, they can identify issues in the product solution, gray release, promotion, or operation plans, analyze the root causes, and formulate solutions. Timely adjustments to the plans or iterations of the product solution will ensure ongoing success.
7. Requirement Closure
Requirement closure is the final stage of the requirement management journey. Typically, only individually initiated or large projects have this phase, while other requirements conclude after successful validation. The core tasks in this stage include preparing the requirement closure document and organizing a closure meeting to complete the project.
As a product manager, you are responsible for drafting the closure document and organizing the closure meeting. Next, we'll explain how product managers can manage requirements effectively in these two areas: “closure documentation” and “closure meeting.”
Closure Documentation
The closure document primarily contains four key components:
Reviewing the Objective: Rewriting the initial goal of the requirement.
Evaluating the Results: Assessing the current outcomes and determining if the goal has been exceeded, met, or not achieved.
Analyzing the Causes: Identifying the reasons for any discrepancies between the actual outcome and the original goal.
Summarizing Patterns: Reflecting on what worked well and what didn’t, and drawing lessons from the analysis of causes to guide future work.
Closure Meeting
The closure meeting should involve relevant stakeholders from the business, product, development, and testing teams. During the meeting, participants read and discuss the closure document, share insights, and promote team growth by learning from the experiences and patterns identified.
Key Points in Requirement Closure
There are several points to focus on when handling requirement closure:
Be Objective: The closure document should be factual and accurate, without distorting the truth.
Focus on the Issues, Not Individuals: When discussing problems, emphasize the issues themselves rather than assigning blame to individuals.
Learn, Don’t Blame: The purpose of the closure meeting is to summarize experiences, lessons, and patterns, not to hold anyone responsible or complain.
Summarize Both Successes and Challenges: Reflect on both positive and negative experiences—recognizing challenges faced and lessons learned will help prevent repeating mistakes in the future.
8. Conclusion
Requirement management is a crucial part of a product manager’s daily responsibilities. This article has covered how to effectively manage requirements through six stages: requirement generation, analysis, prioritization, development and testing, validation, and closure. To excel in requirement management, readers must continually practice and apply these strategies, accumulating experience and optimizing their approach. Hopefully, this guide provides useful insights, and readers are encouraged to leave comments and share their experiences!
9. Case Study: The Scheduling Dilemma
Here’s the story: I had a business project that required collaboration with other development teams. However, after the review, the development team responded that they didn’t have the resources at the moment and would schedule it once resources became available. The reasons they gave were primarily twofold:
Compared to other business line projects, this project has lower returns, so we’ll do it later.
(Translation: The project is too small, and the results aren’t impressive. We only want to work on big projects.)If you want this done, the business lines need to coordinate among themselves to determine the project priority.
(Translation: There are limited resources. Let the business lines compete for priority, and we’ll work on the winner’s project.)
As a product manager from a smaller business line, have you encountered this situation? Did you feel small, helpless, and pitiful? Let me share how I addressed and solved this issue.
Addressing the First Reason: "Lower Returns, So We'll Do It Later"
First, you need to understand the development status of each business line and where your business line stands. With a clear understanding, I handled it as follows:
Different business lines naturally vary in market size, which is an inherent trait. Comparing returns across business lines is unfair. Although our business line's market size is smaller, we serve key top-tier clients and are part of the company’s overall important markets. Hence, size is not the only criterion for evaluating returns; the project's significance to the business's development should also be considered.
— (Translation: I don’t accept your scheduling logic. If we follow your approach, smaller market business lines will always rank last, and their projects will never be scheduled.)Our business line has moved from the "early-stage large-scale construction" phase to the "functional iteration and optimization" phase. Last year, we completed large-scale foundational construction, and now we are focusing on supplementing and optimizing that work. Projects at this stage are typically small with lower returns. This is a natural stage in the product lifecycle, and it’s expected that we will be in this phase for a while. Everyone needs to have a clear understanding and consensus on this.
— (Translation: Understand the different phases. Work in this phase has its characteristics. Are we just not going to do any projects in this phase?)
Addressing the Second Reason: "Coordinate Project Priority Among Business Lines"
This is a common excuse from development teams, and many product managers will let the business teams handle horizontal coordination. This approach is actually incorrect. Here’s how I responded:
Each business line is responsible for its own development and has no obligation to ensure the success of other business lines. Each business only knows what’s most important to itself.
— (Translation: Which business would sacrifice its own development for the sake of another business line? It’s all about self-interest. So if both businesses think their project is most important, what should we do?)Managing demand priorities should be the responsibility of the platform-based development team, not individual businesses. Each business line’s demands should be managed separately, and resources should be allocated in advance based on estimated demand. This helps avoid resource conflicts among business lines. Otherwise, businesses will complain about unreasonable resource allocation, which could hinder their development.
— (Translation: Recognize your responsibility, don’t pass the blame. Passing the buck will backfire, so it’s better to manage the requirements properly from the start.)
That’s how I dealt with the issue, and you can adjust your strategy based on your own situation. Give it a try! While this example involves product management and development, the approach can be summarized and applied to different companies and roles.
