How to keep up with demand for primary product operations?

The product operation here refers to chivalrous product operation , which only refers to product operators, not the product & operation sequence. This article is written for people who have just started working in product operations or are looking forward to joining product operations. If there are any deficiencies, please feel free to point them out.

The requirements for promoting product operations can be summarized in chronological order as: understanding requirements, communicating requirements, confirming plans, and product tracking.

Understand the needs

Understanding needs can be divided into: receiving needs, current status of needs, expectations of needs, involvement of needs, and benefits of needs.

Regarding receiving requirements, you must agree with them yourself

When it comes to receiving demands, every company has its own way and process. Even different product operation teams within the same company have different processes. This article won’t explain how to do this, but I just want to say that you should do your best to receive demands and receive the correct demands that belong to you. If it is not within your responsibilities, don't touch it (unless you are extremely interested in it and particularly want to know about this part). It is difficult to understand the requirements that are not within your responsibilities, and it is easy to be complained by the PM, and even become the scapegoat in the end; if the requirement is unreasonable (including requirements that you cannot convince yourself), you must not accept it, because it is obvious that you will be scolded by the PM next, and then. . .

Understand the current situation of demand and judge the authenticity of demand

• Why does this demand arise?
• What does the product look like now? (I believe that few product operators have a 100% understanding of the products they are responsible for. This is a pitfall)
• How are the demanders dealing with the current situation?
• Why does the demander raise this demand? for what?

However, here the product operation is required to have some understanding of the business. As a product operation, you must have some understanding of the business, or even understand the business better than the business itself. If you don’t understand the business, you will not be able to quickly understand the requirements, you will not be able to quickly get to the key points of the business, communication will waste time, and the business will question your professionalism.

Regarding demand expectations, initial product models

In fact, many times the demanders don’t know what they want (or the expectations given cannot solve their problems), they just feel unhappy and hope it can be improved. At this time, you must be cautious, understand the business, understand why the demander is making this demand, and then judge whether the demand is consistent with what the demander said.

If it is inconsistent with what the demander says, then you need to understand, use, and even investigate on the spot to obtain the most real needs. After obtaining the real needs, you must communicate with the demander (remember to communicate, otherwise you may easily receive complaints), and determine the most real needs after communication.

After confirming the demand, you can discuss with the demander to come up with an initial product expectation model and determine the expected schedule for business release. This is the initial stage, not the final one, so don’t make anything final with the demander.

Regarding the demand, the relationship is blamed

When communicating with the business side, you must consider the overall needs, try to consider the needs well, consider the complexity, pay attention to the departments and personnel that the needs will involve, and make sure to consider them completely. You can sort them out in the following directions:

1. What product changes are involved in this product requirement?
2. Does this product requirement involve strategic issues? Leader's consent is required
3. Are there other departments that have the same needs?
4. Are there any related similar requirements that can be improved at the same time?
5. If the product is launched, which departments will use it?
6. If the product changes will affect other departments

Regarding demand benefits, assess demand priorities

When many product operations people communicate product requirements with PMs, they are often asked by PMs: How many people have this requirement, and how much profit can the company get when the requirement goes online? Then the demand is more likely to be shot back, waiting for you to collect data and come back, or simply put it aside and give up.

In fact, as a product operator, you should have a clear understanding of every product demand and not push forward blindly. After all, we need to understand how many people will benefit from the product launch and how much profit it will generate. It is true that there are some product features whose benefits cannot be evaluated. In that case, you need to give an assessment based on the importance and urgency. By combining the importance and urgency with the demand and benefit, you can assess and classify the product requirements to be implemented. Urgent requirements should be promoted first, and important requirements should be promoted frequently. I believe that in this way, the PM will not be able to reject the requirements.

Communication needs

The demand communication here is mainly with the PM, but also involves communication with the demand side

The demand communication stage is the most important stage among these stages, and it also determines the assessment of your needs in the PM's mind, so you must pay attention to it.

1. The needs must be clearly understood
2. You must understand business usage better than the product itself
3. You must have a preliminary plan for your needs (even if it is just a rough outline, you need to know what you want to do)
4. Have expectations for product promotion after launch

During communication, remember not to be a mouthpiece. You should understand something yourself and make the PM and the demander think that you are indispensable. Of course, you are not omnipotent. If necessary, you can communicate with the demander and the PM together.

When communicating across departments between PM departments (PMs responsible for different directions and different products), try to communicate both parties together to prevent changes after confirmation.

There must be meeting minutes during the communication process, because this is the evidence you have confirmed and all parties must acknowledge it.

Confirm the plan

Confirming the plan should be the most satisfying time in the entire follow-up process, but it is also the time when there are more fights. At this time, you not only have to deal with the PM and the demand side, but also help the PM to deal with RD+FE+DA

Confirm the plan with the PM. This link is the stage where you spend the longest time in contact with the PM and get to know each other best. It is recommended that you think of a preliminary product plan before communicating, and communicate the new product plan with the PM based on the preliminary product plan.

During the product plan communication, you need each other at this time. The PM will provide you with a PRD (MRD) that you are relatively satisfied with. At the same time, during the plan confirmation process, the PM also needs you to communicate and confirm many details of the product plan. At this time, you must help confirm the product, because this is related to whether the product function is really practical.

You must tell the PM that you will be called for the requirements review, and you must be called for the requirements review (business review). If changes are required at this time, you must make them as soon as possible and do not postpone them to the technical review or interactive review. During the technical review, you should also maintain a good relationship with the PM and attend on time, because when you are not there, the R&D guys can "unscrupulously" cut requirements. You need to stand in the perspective of the demander and use your reasons to protect your requirements from being cut.

Once the review is scheduled, don't relax, because there may be urgent needs or demands from your boss at any time. At this time, you must understand what the demands are and decide whether to give in based on their urgency and importance. If you make any concessions, you must understand clearly why there is a delay, and you need the PM to help you send a delay email to the demander to explain the delay.

Product Tracking

The product is launched normally, are we okay? No, no, we still have very important product promotion work to do, and product effect tracking, and the product may have a second phase.

Synchronous training when the product is launched is a very difficult issue. Generally, there will be update notifications within the system + mass email notifications + work group notifications. It is best if the emails and system notifications are accompanied by operation manuals. If it is a large project, online and offline training may be required (this stage requires you to understand the product, it is recommended to go to PRD).

In the effect tracking stage, you need to create an independent feedback work group or a unique feedback channel after going online. It is recommended to use a separate channel and not mix it with other projects. Remember to communicate with PM+DA before going online to set up data collection points, set feedback cycles, pay attention to data regularly, produce product effect analysis reports in a timely manner, and prepare for the second phase of the project.

Mobile application product promotion service: APP promotion service Qinggua Media advertising

The author of this article @Lycom compiled and published by (Qinggua Media). Please indicate the author information and source when reprinting!