In order to avoid being hacked by programmers, product managers need to pay attention to these scenarios.

In the internet industry, people are keen to discuss "programmers chop product managers". Although "chopping" is more of a teasing meaning, it is a way to relax work; However, this is not a joke after dinner, but reflects the antagonistic relationship between product managers and programmers. Many times, product managers and programmers are like rivals, and the product development process is like a war, always fighting for each other. The essence of "chopping" is that programmers express their dissatisfaction with product managers, and it is also an emotional catharsis.

In the process of product development, the antagonistic relationship between product manager and programmer will seriously affect the progress of the project. Once the antagonistic relationship between product managers and programmers is made public, it will easily lead to team distraction. This antagonistic relationship often breeds some extreme things, and swearing and fighting are not uncommon.

Here are some scenarios where programmers want to lay off product managers. These scenes are the scenes I used to communicate with many programmers who were not satisfied with the products. These scenes will be expressed by the communication words of the product manager. Through these scenes, to analyze the reasons for this antagonistic relationship. As a contrast, how should product managers avoid and deal with this antagonistic relationship?

This statement is the most disliked by programmers, and it is also the easiest to annoy programmers. This sentence is synonymous with cutting working hours and overtime in the eyes of programmers. Of course, they don't like it. And they also hate the conclusion that a non-technical person gives a technical difficulty to a technical person. Jane is not simple, and technicians need to do technical evaluation to draw a conclusion.

This kind of remarks will make programmers feel that product managers are unreliable. Everyone is usually more resistant to learning from others. You have to have a reasonable and clear reason to learn from it. In the words of a programmer friend of mine, you can do whatever WeChat does. It is better to go to WeChat to make products.

Every product, under the surface UI, has complex business logic behind it. If the product manager only asks programmers to follow a product, it is difficult for technicians to do it, because they also need to understand the logic and process behind it. Of course, this should be the job of the product manager.

This is the wrangling. Although the product manager has the word "manager" in his name, he has no right to be a manager, and of course he can't order the cooperative technicians. The implication of this sentence is also to refuse to discuss. Programmers also need a sense of participation and teamwork.

This is questioning the ability of others, and no one will like it. If the solution proposed by the product manager is not understood by the programmer. Then it shows that the explanation and documents of the product manager are not excellent enough, concise enough and unclear enough. Making programmers understand requirements is the basic job of product managers.

In the development of Internet products, it is quite common to modify requirements and insert new requirements. This is a very unpleasant thing for programmers. This kind of operation usually interrupts the programmer's thinking, and it is very painful to be interrupted. Of course, this will also affect their development efficiency. What is even more frightening is that the repeated revision of the requirements will make them feel that their labor achievements have not been respected, and at the same time they will have doubts about the future of the project. Repeated revision of the scheme also shows that the product manager's design has not been strictly demonstrated, or the details are not controlled enough.

Programmers hate repeated urging. After the nodes of the project are determined, the technicians will strictly abide by the nodes, and the products should also trust the nodes. Of course, when time is tight, repeated urging will also increase the pressure on programmers and make them very upset. At this time, urging is to add to the jam.

Overturning the pot will lead to the team falling apart and people's hearts will be uneven. No matter what the problem is, it is the responsibility of the team. Don't put the blame on someone. Especially when the project returns to work, it is very embarrassing for colleagues with bad mentality. Therefore, we should strive to be cause-and-effect oriented, not responsibility oriented.

Programmers are also part of the team and have the right to know the background of requirements. At the same time, understanding the background of requirements is also beneficial for programmers to develop programs better.

It is most unrealistic for product managers to draw cakes for programmers, which will only arouse everyone's disgust. Programmers like practical things, and imaginary things will only lead to white eyes.

Any requirements passed to programmers need to be planned and standardized. If a requirement is communicated orally, it will easily lead to the mismatch between the developed function and the requirement. At the same time, the lack of relevant records and documents may cause the loss of demand. For programmers, this may be the risk of delay, overtime, rework, responsibility and so on. This is the taboo of teamwork, and it is also the embodiment of unprofessional project management.

The above scenario may appear once, and the programmer will follow our thinking. But this will gradually change the programmer's mentality, and eventually cause the gap and contradiction between product managers and programmers. If these scenarios occur, the product manager needs to handle them carefully so as not to affect the normal progress of the project. Of course, it is best not to have these scenes. As a product manager, our ultimate goal is to ensure that products are delivered on time, with good quality and quantity.

When product managers cooperate with programmers, product managers need to pay attention to cooperation and mutual understanding. In the related work of product managers, the most important thing to avoid is to raise the threshold. Bargaining is the root of all contradictions. Many times, product managers have to consider problems from the perspective of programmers. For example, for products, it may be to change requirements, but for programmers, it may be more concerned about overtime caused by changes in requirements.

Product managers often pursue the ultimate in products in their work. Pursuing the ultimate is a good thing in itself, but don't be overly paranoid. We also need to consider the status quo and resources of the team and find a balance between extremes and reality. After all, without Steve Jobs' team, making products like Steve Jobs will only drag down the team.

In the process of product development, it is inevitable that there will be project anomalies such as demand change and scheme change. This is the first part of project management. How to deal with project anomalies and test the communication skills and project management skills of product managers. The product manager needs to complete the exception handling of the project while ensuring the efficient work of technicians.

Of course, in the work of a product manager, the root of the contradiction is not always the product manager. Sometimes, it may also be caused by the personality or attitude of some programmers to work. At this time, the product manager should know that as the lubricant of the team, he has the responsibility to promote and coordinate everyone's work. If the contradiction is irreconcilable, it is necessary to ask questions as soon as possible, control risks and avoid "reluctant" actions.

Sometimes programmers privately evaluate the product managers who work together, and always add "I feel that I can also be a product manager". Behind this sentence, the product manager did not let the programmer feel the value of product work. In this context, it is difficult for product managers to get the attention of programmers, and it will also lay the foundation for many arguments. What do you think is the value of our work? In fact, it is very simple, that is, to keep the work information transparent. Reflect our work related to demand and products in our communication or documents.

It is essentially the work style and emotional intelligence of product managers that programmers want to "cut" product managers. In my working experience as a product manager, I summed up the following four points that need attention and avoidance. These four points can all correspond to the above scenarios, and it is the easiest to change the programmer's mentality slowly.