Before collecting requirements, it's crucial to confirm their sources, which generally include product planning, business needs, user feedback, and market or competitor demands. Now, let's explore the author's insights.
Several methods for requirement analysis are summarized here, including the 5W1H method, user story mapping, Maslow's hierarchy of needs, the KANO model, the four-quadrant rule, and the RICE principle. Since B-end products involve complex role management processes, with most requirements coming from the business side, the 5W1H method and the RICE principle are the most commonly used approaches for B-end requirement analysis.
Before performing requirement analysis, it is necessary to collect requirements. Common methods include user interviews, questionnaires, focus groups, business rotation internships, data analysis, industry research, and competitor analysis.
I. Product Planning Requirements
These are based on the company's strategic direction and product positioning. Product planning involves sorting out the product architecture from a broader market framework and understanding the product’s goals and boundaries.
During the planning process, the product architecture will be continuously refined and adjusted. This can be broken down into three levels, using a customer service instant messaging system as an example:
Level One: Sort out the roles involved. A customer service instant messaging system can be divided into client, customer service, and operations ends, mainly focusing on ensuring customers can promptly contact customer service to resolve issues.
Level Two: Identify the modules involved in each role. The system includes an H5 chat page for customer communication, customer information management, conversation management, basic settings, etc.
Level Three: Break down each module. For example, conversation management can be divided into online conversations, waiting for access, transferring conversations, responding to transfers, ending conversations, waiting for evaluation, customer evaluation, conversation history, and frequently used phrases management. Each demand is gradually broken down to create the product architecture.
II. Business Requirements
When entering a new business, business requirements are collected by sorting out the business process. The first step is to clarify the business organization chart to understand the management system, functional units, and future planning. User research is then conducted to outline the current business processes.
The first basic element in the business process is roles. Roles allow for division of labor and cooperation, enabling the completion of specific value goals. Next are activities—each role has specific tasks to perform, and those tasks lead to outputs, ultimately achieving a goal.
For business requirements, the best method is to rotate through business operations and conduct user research. When conducting user research, the five-step method is useful:
Clarify the research objectives: Understand the business model, features, goals, and plans. Identify current pain points.
Choose the research subjects: Select stakeholders at each node based on the organizational structure.
Design the research framework: Create different questions for each stakeholder based on the objectives.
Execute the plan: Send the framework to participants beforehand to allow for preparation. Gradually guide the conversation during interviews. Afterward, stay in touch for follow-up.
Summarize and output results: Organize the content into user interview records.
During this process, conduct a full scenario analysis by answering who, when, where, what, and how:
Scenario elements: Map out the business process in as much detail as possible.
Full scenario: Identify corresponding user requirements.
Boundary determination: Identify which parts of the scenario need system support and which can rely on manual processes.
Through this, business requirements can be extracted.
III. User Feedback Requirements
User feedback should be organized into a demand pool based on priority. Users often provide solutions rather than actual needs, raising the question: should we follow their solution?
We must act as problem solvers, not just messengers. The "13 elements 5-step method" can help dig deeper into needs:
Who?: Who proposed the need, who will use it, and who will be affected?
What?: What problem are they trying to solve? Is there a need for further clarification? How frequently does the problem occur?
Why?: Ask why—what’s the core pain point? What’s the intensity and actual value?
Possibilities?: Are there alternative or complementary scenarios? List all potential features and check for more specific cases.
How to solve?: What are the feasible solutions? What are their costs? Which is best? What are the pros and cons of the solution for users?
By addressing these questions and describing the scenarios, the requirement can be confirmed and included in the demand pool.
IV. Market and Competitor Requirements
First, deeply experience competitor features by organizing a function checklist and understanding user paths. Analyze the interaction points between different modules. After studying competitor products, evaluate how their features could be applied to your product.
After gathering requirements, demand management will take place. Requirements are divided into functional and non-functional needs, where functional needs include business and user requirements. Prioritization typically involves the RICE principle and the value-cost model to create a version iteration plan.
The RICE Principle:
Reach: How many users requested this?
Impact: What is the value for users?
Confidence: How confident is the product manager?
Effort: What is the standardized difficulty and development cost?
In B-end products, requirement scheduling is based on comprehensive analysis, and the decisions depend heavily on the product manager's experience and capability.
