The methods of demand collection, analysis, and iterative launch for B-end products are similar to those for C-end products. However, due to the diversity of roles of users of B-end products and the complexity of cross-departmental collaboration processes, demand management for B-end products has more pitfalls than that for C-end products.

As a B-side product operator, have you ever faced and dealt with this kind of problems:

• Sales complaints: Customers don’t buy new features, and the problems that really need to be solved are not solved;
• Customers are angry: a commonly used function is suddenly removed from the shelves and its use is interrupted; a function was promised but not iterated and launched on schedule;
• Customer service staff angrily complained: The scattered layout of product functions affects the efficiency of customer training; a function was suddenly launched, and we only found out about it when the customer asked about it;
• Operations is crying: Demand comes from customers, sales, services, risk control, legal affairs and other departments, and the collection, analysis and management are chaotic.

I have encountered all of the above problems, and there are many cases where I have fallen into the same pit. In this process, I organized this article to remind myself to remember it. If there is anything wrong with the summary, please point it out~

The pitfalls of B-side product demand management are mainly distributed in three stages: demand collection, analysis, and iterative launch:

1. Requirements Collection

Pitfall avoidance guide: Step 1: Collect demand collection channels, establish a shared demand feedback pool, and classify and manage demand according to demand type and iteration status, so that demand collection can be recorded in a timely manner without omission, and demand planning and progress can be clearly seen.

The sources of demand on the B side are divided into internal and external companies, which are broken down as follows:

There are many sources of demand, the feedback information is complex, the efficiency of demand collection is low, and errors and omissions are prone to occur. If the problems and demands fed back by the above channels are completely handled by the operations department, it will be difficult and stressful. If key demands are missed, it will also lead to customer complaints. Based on this:

1) Establish a unified contact person for each channel. For example, feedback from SMB customers is aggregated to customer service, feedback from KA customers is aggregated to customer success, and sales needs are aggregated to sales support;

2) The requirements are jointly maintained in a shared document by the contact persons of each channel, a requirement pool is established, and records are made in a timely manner. When a new round of review begins, the demand side is reminded and supplemented to avoid omissions;

3) For requirements that have been launched, requirements that have been tested, requirements that are pending, and requirements that have been confirmed in the current iteration, separate tables can be created for management;

4) Review and re-prioritize the demand pool frequently, and re-prioritize the demand pool as a whole based on the emergence of new variables;

The progress of each link is presented in the table as follows for reference:

The process in this table mainly covers the demand side, product side and operation side, and does not mention the technical side (such as review time, UI, development time on each side, test submission time, etc.).

Tip 2 for avoiding pitfalls: Promote the rules for initial screening of needs to the business side. When a need is mentioned for the first time, the person who provides feedback or the person who liaises with the need can initially screen the need and respond to the customer.

Simply accepting customer demands and promising support without principles will not necessarily gain customer approval. On the one hand, when customers raise demands, they are talking about solutions, but what we really need to understand is the customers’ pain points and provide feasible solutions.

On the other hand, whether a function can satisfy customers immediately is not necessarily the fundamental reason why customers pay for it. When a demand is first proposed, business personnel do not need to master demand analysis methods such as the Y model and 5W2H like the R&D side, but they can provide basic initial screening rules to help filter out many unreasonable demands in the early stages.

In addition, whether it is the business side or the R&D side, you should pay attention to the art of language when rejecting a request:

1. Don't directly object to the other party's ideas, but think about the problem from the other party's perspective and offer solutions;
2. If there are many options, you can start with the three most important points that can bring benefits to customers to arouse their interest;
3. When presenting a plan, you must state definite information, be brief and to the point, and do not revise it repeatedly to avoid making the other party feel disgusted.

2. Demand Analysis

Pitfall avoidance guide posture 3: Listen carefully to customer needs, but don’t follow them. Use the 5W1H1V method to dig deep into customer needs

Demand analysis refers to the transformation from problem to solution, or from user needs to product functions. Kai-Fu Lee, chairman of Sinovation Ventures, once said on Weibo: “Many engineers and product managers don’t understand that customers don’t actually buy a product, but they need to use a product to complete a task or solve a problem.”

There is a famous saying: "Customers don't buy drills, they buy holes." To go further, what users want to buy is not the holes, but the deeper needs reflected behind the holes. Behind user needs are goals and motivations, and deeper still are deep values ​​and human needs, namely Maslow's needs.

Therefore, in order to avoid information errors conveyed by middlemen, product operations should organize direct communication with customers when receiving demands. Taking the solutions proposed by customers as the starting point, they should use the 5W1H1V method to analyze the problems. First, list these six questions. After getting the answers, consider listing some smaller questions and conduct a comprehensive analysis and research on the problems, so as to generate newer creative ideas or decisions.

1) What — What can this product or feature do? What problem does it solve?

2) Where — Where will this product or feature be used?

3) Why (Purpose) — Why do you need this product or feature? What is the difference from other products?

4) When — When will this product or feature be used?

5) Who — Who is the product or feature designed for? Who will use it?

6) How — How to use this product or feature?

7) value — What is the value of the product?

Pitfall avoidance guide posture 4: When there are changes in requirements after communication, keep meeting minutes in time and update relevant documents; During the requirements assessment stage, all relevant departments must participate in the review and acceptance plan

In order to avoid fragmented customer demand feedback and improve the efficiency of demand communication, customers need to be guided to fully experience the product and point out any deficiencies. After the demand communication, if there are any changes, the document needs to be modified in time to avoid erroneous development due to historical documents; in order to avoid the solution not meeting user needs and causing waste of resources, the availability needs to be determined with the customer during the prototype stage.

In addition, there is more than one user role for the B-end product. When designing, reviewing, and launching functions, multiple parties need to confirm information. Here are a few examples:

1) For businesses involving risk control and compliance, the launch of related functions involves the establishment of review mechanisms or sensitive word libraries;

2) For product changes that existing customers can perceive, you need to synchronize with customer service and make sure to notify customers when the product is launched;

3) For customized needs of customers, if the design is for general needs, it will bring consulting and processing pressure to the business...

3. Iterative launch

Pitfall avoidance guide 5: Avoid product launch during peak usage hours

Don’t schedule the release of your requirements on Friday or close to the end of get off work just to meet the launch deadline. When problems occur, it affects the customer experience and it is difficult to gather personnel to solve them. The online time should be fixed as much as possible on non-Fridays and non-high-frequency product use time periods.

Pitfall avoidance guide posture 6: Demand side participates in online acceptance

In addition to testing and product acceptance, operations and demand parties must first accept the product before putting it online and guiding customers to use it, to avoid missing online requirements or having usage problems.

Pitfall Avoidance Guide 7: Preparation for Launch and Effect Evaluation

Before going online, carry out relevant team training and prepare online announcements and usage guidelines. If you need to launch a promotion online simultaneously, you need to prepare the content and activity materials for the online promotion in advance; and conduct effect evaluation through product data analysis before and after the launch, channel feedback, etc.

Demand management runs through the entire team. Product demand management is not just about recording demands, but also requires demand planning, implementation, and effect evaluation. Each team may have different demand management methods, and the most suitable methodology is the best. If you have also stepped on any pits, please leave a message to share~

Author: Product Operations and Principles

Source: Product Operations and Principles

Related reading:

How to operate the B side of the platform well?

Review of B-side operational activities: Find the purpose and users

6 indicators for good B-side operations!

For B-side operations, how to generate private domain traffic?