Many product owners may encounter repeated rejections, challenges from business departments, and doubts from technical teams, which not only affects the progress of the project, but also easily undermines the self-confidence of product managers. This article summarizes the common reasons why product solutions are repeatedly rejected and provides practical strategies for dealing with them.
I remember once, there was a need, when it was time to complete the planned development, the PRD had not yet passed the product leader review, and was rejected three times, because the demand was more urgent, the leader even gave me an ultimatum.
I believe that many product people have similar experiences, and product solutions are challenged by business, rejected by leaders, and picked by R&D, and rarely can be reviewed at once.
Why is it difficult to review your product proposal repeatedly and repeatedly? How to improve the pass rate of product plans? Based on my years of product work experience, I summarized the following reasons and gave coping strategies:
1. The demand target is not clear
Once I attended a review meeting involving executives, when the product manager was interrupted as soon as he spoke, the leader directly asked, what is the goal of this requirement?
The goal of the plan must be clearly described, what value can this demand bring? This is especially important in the project establishment meeting or the review meeting attended by senior executives.
I have three suggestions for demand targets:
- Clarify who is most concerned about the requirements and goals. If the demand proposer is a business boss with the right to speak, or is strongly related to the OKR of direct and cross-level leaders, the demand target should be paid special attention to and taken seriously, and once it passes the review, it can often get more resource support.
- Clarify who is responsible for the goal and reach a consensus before the review meeting to avoid that no one is responsible for the results in the end. If the product goal is determined, but no one follows up after the launch, and the goal is not achieved or reviewed, it is easy to be anticlimactic. I remember when I was working at JD.com, there was a project management team that focused on following up on the ROI achievement of the project after it was launched.
- Value description quantifies with specific data. Demand goals need to have measurable metrics, and if you can’t measure them, you can’t improve them.
Take the demand goal of improving warehouse operation efficiency as an example.
Wrong goal: improve warehouse picking efficiency.
Correct goal: Through the system optimization of the picking path, under the same conditions, the number of orders sorted per minute has increased from 1,000 orders per minute to 1,100 orders, so that the sorting efficiency of the warehouse can be increased by 10%.
Clear demand goals are the first step and foundation.
2. The product plan is not well considered
The product plan is not well considered, which is the most problematic part of the review. If your leader pays attention to details and has strong professional ability, then it is especially important to pass the product leader review.
After 10 years of interaction design, why did I transfer to product manager?
After the real job transfer, I found that many jobs were still beyond my imagination. The work of a product manager is indeed more complicated. Theoretically, the work of a product manager includes all aspects of the product, from market research, user research, data analysis…
View details >
I have 10+ years of work experience in the workplace, and I have met many leaders, which can be roughly divided into two categories: one is to focus on the big and let go of the small, this kind of leadership pattern is high, the management team is large, and almost does not participate in the PRD review. The other type is more professional and detail-oriented, they will participate in almost all review meetings and make detailed evaluations of the plan, and once there is a situation that is not well considered, it will be questioned.
For example, in the inventory management of the WMS warehousing system, the outbound party deducts the inventory when it leaves the warehouse, but the inbound party has not received the goods, what should be done if the goods are lost in transit? Whether it is reported as a loss on the outgoing side or a loss on the inbound side.
In a similar situation, if not well considered, after the system is launched, there will be problems, which can be at best to fight with each other, and at worst it will bring economic losses to the company.
When writing a plan for the product, you should think more, think more, put in more effort, don’t have a fluke mentality, any needs are missing, the sooner you find out, the better.
Just like building a house, the cost of adjusting the problem is the lowest when it is found, and it is almost impossible to adjust it after completion, and the cost will be very high.
The same is true for the system, which is found in the scheme design stage and adjusts with the least cost, and then adjusts after going online, which is time-consuming and labor-intensive, and will also overdraw the product’s connections and reputation in the team.
I suggest that especially product novices, you might as well take the time to list the functions related to all upstream and downstream systems, and at the same time sort out all the functions of your product, put them in a table, and take them out from time to time to take a look. If you are familiar enough with your product and upstream and downstream systems, you will minimize poor consideration.
In addition, all possible exceptions, errors and other special situations should be taken into account. Because according to Murphy’s Law, anything that is likely to happen is bound to happen.
Even if you think very comprehensively and meticulously, and the technical review has passed, you will still find loopholes when entering the R&D and testing stages, because some problems cannot be predicted in advance, and can only be exposed during development and testing. After the problem is exposed, it is necessary to respond quickly and solve it, draw inferences from one case to another, first solve the current urgent online problem, and then find a way to cure it from the source.
3. The logic of the product plan is not rigorous
Sometimes, the product plan takes the scenario into account, but the logic is not rigorous, not meticulous, and even inconsistent, which is also very taboo, although it is not as serious as the second problem, but it is also easy to be challenged and rejected during the plan review.
To give a common example, for example, to make a file upload function, seemingly ordinary and general, it is not easy to describe clearly, without omissions and logical rigor. Especially for product newcomers, it is quite challenging. The details are as follows:
Error Requirement Description: Support uploading files in multiple formats.
Analysis: The requirements can be described as follows: “It needs to support uploading images, Word, PPT, pdf, txt, Excel tables and other format files, and it needs to support .jpg, . jpeg、. png、. doc、. docx、. ppt、. pptx、. pdf，.txt、. xls、. xlsx and other formats. ”
Also, is there a limit to the number of files and what is the maximum file size? How is the file upload progress displayed? What should I do if the upload fails? Whether to support breakpoint continuation, etc., these need to be considered, only in this way will the product plan be rigorous and clear enough, and it will be easier to pass the review.
These are not bad, if it is a large platform with hundreds of millions of users, maybe a small problem is not well thought out, which may bring huge losses.
For example, in January this year, Alipay’s “80% discount accident”, due to the wrong configuration of the marketing template, all payment orders were forcibly reduced by 20%, Alipay confirmed that it was a company liability accident, and no money was recovered, and the loss was expected to be as high as 100 million yuan in just 5 minutes.
A thousand-mile embankment collapsed in an ant nest. Therefore, any small detail of the product solution cannot be ignored, especially for large platforms.
Even the wise can make mistakes. It is difficult to avoid problems 100% of the product plan, but the problem can be exposed in advance as much as possible.
After I write the product plan, I will check it 2-3 times, usually every other day, whether the logic is rigorous, whether it can stand up to scrutiny, whether there are typos, and almost every time I check it, I can find some problems.
In response to the situation where the product plan is not rigorous, in addition to your own thinking and experience, you can communicate with team members, such as product colleagues, R&D, testing, and business, etc., and you can communicate and consult with them. In addition, you can also find internal colleagues to review each other.
When I write a product plan, if there is some logic and uncertainty in details, I will communicate with R&D, testing, and business in advance, and try to reach a consensus before the meeting to reduce disagreements and arguments in the meeting.
In addition to the above three points, there are also some tips that can help improve the pass rate of product plan review and reduce the occurrence of rejections.
- If the solution is very personalized, and the R&D is difficult to develop, then the product should try to consider the general solution. And try to control personalized needs, if the requirements are really unreasonable, the product should be able to block this part of the demand, instead of doing business microphones, otherwise the system is easy to get out of control later, and it will also affect the prestige of the product manager in the team.
- When you arrive at a company and take over a new product, you need to find various opportunities to learn and understand the product. I once joined a company and asked my testing colleagues for advice many times, because he has been in the company for a long time, and he understands many logic and details, which can allow me to quickly understand the current situation of the product and avoid missing key information or incomplete consideration in the plan.
- It is necessary to develop the habit of summarizing and reflecting, review what you have not done in place, and try not to repeat mistakes. When we participate in the program review more and have a certain work experience, we can basically summarize the laws and reasons, and we will be more handy in the future. In addition, participating in other people’s plan review meetings, you can absorb what others have done well, learn from each other’s strengths, and use them for your own use.
- People are the sum of social relationships, and in the process of dealing with business, R&D and leaders, they usually pay attention to accumulating their own contacts, do more things about network deposits, and do less things about network withdrawals.
Whether it is business, R&D, or leadership, in the process of communication, it is very important to establish a good relationship, if there is no foundation of trust in each other, every review meeting will be tense, always picking, looking for faults, arguing, and the communication effect will be poor. If there is a good foundation of trust, every meeting is respected, understood, and supplemented, the communication effect will naturally not be bad, and the work efficiency will be higher.
All in all, as a product manager, if you want to improve the review pass rate of product solutions, no longer be repeatedly rejected and challenged, you need to make a lot of effort, professional ability must be excellent, and always maintain an open mind of learning, growth and openness.
