Recently, in a product communication group, product managers exploded again. The reason was that one of the product managers mentioned that after the launch of his company's product, the functions were not consistent with the business. The tester

  blamed the "blame" on the product. It is believed that the product is not ready for

As a result, the product managers began  HE Tuber to complain crazily about the testers of their respective companies in the group. I saw "unanimous external communication", but I didn't see anyone reflecting on how the product manager should accept the test to avoid such a thing from happening again.

1. Does the product manager need to accept the product?

The answer to this question is yes, the product manager must do the acceptance inspection. As for its necessity, let’s take a look

 at the consequences of the product manager not doing the acceptance inspection

.

According to the deviation between product and design, it can be divided into three types:

1) Does not match

This situation refers to a situation where the product deviates from the design, but it is innocuous and may not even be adjusted according to the original design.

For example, a Toast prompt that was originally supposed to have a red level was developed to a yellow level. Since both red and yellow have warning meanings in the system, this deviation is not unacceptable.

2) Generally inconsistent

This situation refers to a large deviation between the product and the design, which may have affected the use of the product.

For example, a content that was originally prompted through a pop-up window was developed into a Toast prompt that is automatically hidden after a certain period of time. This prompt copy appears after waiting for a long period of time (such as uploading a large file, or when the system processes a lot of data). ).

During this period, the user's eyes may leave the product interface. The pop-up prompt allows the user to see the execution results after returning, while the automatically hidden Toast prompt may be missed by the user.

3) Serious discrepancy

This situation refers to a serious deviation between the product and the design, which has seriously affected the use of the product.

For example, the design constrains that a mobile phone number can only register one account. When registering, the registered mobile phone number cannot be successfully registered. However, this step was missed during development. When registering, the same mobile phone number can be used to register multiple accounts, resulting in the system failure when logging in. An error occurred due to the inability to identify which account to log in to

.

This situation is not necessarily caused by the inconsistency between the product and the design, but rather that the product design itself is inconsistent with the business, and the product exists to serve the business.

Therefore, once the product has problems that are inconsistent with the business, every problem may be fatal.

3. Changes in requirements

If the product design is inconsistent with the business, the business needs to be adjusted by adjusting the wrong demand implementation, which will inevitably bring about changes in demand.

4. Rework

When errors in design or implementation are discovered, the original work results need to be overturned and redesigned and developed.

5. Falling behind schedule

Regardless of demand changes or rework, the originally planned progress will fall behind.

6. Shifting the blame

When something goes wrong, everyone feels it is not their responsibility and starts blaming each other.

2. Why don’t product managers like to do acceptance inspections?

Since product manager acceptance is so important, why don’t product managers like to do acceptance?

The process of product design is a process of exploration and creation, and it is a fun process for product managers. When most product managers complete product design and hand it over to R&D, they will have a feeling of "This is the best thing I can do so far." "Great design" and "There can't be a better design solution than this".

The acceptance is different. Although the design is delivered and the product is accepted, the product manager will think that his design is very clear and no one should misunderstand it. There may even be a feeling of "My design is so great that I was asked to give it to you". The idea of ​​​​finding faults with your own design.”

2. Take it for granted that this is the job of testing

Some product managers think that after the design is handed over to development, they have no business of their own. At most, they can help developers clarify some doubtful areas during the development process, and other subsequent work has nothing to do with them.

The development time of a general version is determined by the R&D department. When determining the version time, the R&D department will only take into account the testing time, but not the product acceptance time. The product manager does not have enough time for acceptance, and the acceptance will have no effect over time. There is no habit of acceptance. Once the test is passed, it goes online.

3. The difference between product manager acceptance and testing

When problems arise after the product is launched, the first one to bear the brunt is the tester, followed by the product manager. In the end, it is easy for the two to "pass the blame" to each other.

The reason is that the company or department has not clearly divided the scope of responsibilities of the two in product acceptance and testing. In the end, only the manager can determine the person who should bear the responsibility. Generally, if the manager is the person in charge of R&D, he will assign the responsibility to It is blamed on the product manager's failure to do a good job in acceptance, and the manager as the product owner will think that the testers' testing work is not done properly.

Therefore, the two departments of product development often "fight", which is one of the reasons.

Regarding the differences between product manager acceptance and tester testing, I have roughly listed the following points. You can refer to them based on the actual situation of your own project.

After reading the above comparison, you may have an idea that the product manager's acceptance seems to be very casual, with no clear standards, no quantitative tools, or even clear goals.

Indeed, there are no relatively unified standards and methods in the industry for clarifying product manager acceptance. It relies more on the product manager's personal experience and acumen during acceptance.