How good is the product manager in a programmer’s dream?

The conflicts between programmers and product managers in collaboration and communication are an eternal topic. Because the two have different knowledge systems and thinking structures, and focus on different things, it is inevitable that there will be some disagreements and frictions in the process of collaborative work, and there will be mutual complaints and complaints.

I believe that a healthy relationship between programmers and product managers should be based on trust, respect, understanding and a common community of interests. Without this premise, efficient collaboration becomes empty talk.

So what aspects should product managers pay attention to in order to maintain a high degree of tacit understanding and form a healthy collaborative relationship with programmers in their daily work? Today, based on my experience of switching between the two roles, I would like to talk about my own understanding. This is just my personal opinion. Welcome to criticize.

[[155107]]

Equality, respect and understanding are the first prerequisites

First of all, the product manager should be aware of the goals of the project/team and have the same interests as the programmer. All discussions, disagreements, frictions, and clashes of ideas should be about the matter, not the person. There is no necessary relationship of leader and follower, superior and subordinate. The relationship between the product manager and the programmer is an equal collaboration, and the fate of both parties is closely related to the product. Sometimes the emotions and efforts that a programmer puts into a product are no less than those of a product manager; the programmer's expectations and thoughts on the product are no less than those of a product manager, and sometimes even higher than those of a product manager.

For example, most product managers may consider elevators, escape routes, water, electricity, and electrical appliance access when designing a new house, but programmers will think more. They will pay attention to whether the room needs candles, emergency lighting, and reserved water after power and water outages.

Programmers are the actual implementers and creators of products/projects, and product managers are designers and connectors who help create products. They are members of the team, not outstanding individuals. Give up your idea of ​​changing the world, and make friends and teammates with programmers with an equal and respectful attitude.

Don't disturb, give programmers more time and space

One thing that programmers hate very much (even if you do it, they may not say it explicitly) is that when their minds are highly concentrated, they are building their thoughts with extremely high efficiency, and typing quickly, the product manager keeps running over and saying some irrelevant "points" to interrupt their thinking.

Yes, sometimes the broken thinking can not be continued, and sometimes even a key branch of product implementation logic is missing. There is no need to frequently show up to make your presence felt during product implementation. When he (the programmer) needs you, he will find you himself. Even if you find a product problem or bug yourself, if it is not a core, fatal problem, please write it down in a list first and send it to him.

Product managers must learn to make programmers forget about their existence most of the time, but step up when they need you most.

Friendly reminder: From 3 pm to the evening, programmers are most active in thinking and work more efficiently.

[[155108]]

Be responsible, dare to take responsibility, and don't be greedy for credit

One hurdle that all product managers cannot get around is "boss requirements". What are boss requirements? To put it bluntly, it means: the boss needs something like this, and the boss wants to do this. But the boss does not contact programmers, he contacts product managers. If you are just a forwarder of the boss's requirements, rather than a filter or gatekeeper of product requirements, you may be regarded as "irresponsible".

The boss's needs should be equal to the user's needs and the basic needs of the product. There are also reasonable and unreasonable ones, and there are priorities. When the product manager finds that the boss's needs are not too reasonable, the product manager should risk losing his job and argue with the boss, appealing to reason and appealing to emotion.

Once, my boss proposed an idea that almost overturned the current product architecture and technical architecture design. He thought it was very important and must be implemented as soon as possible. I think the first priority of the current product is to solve the basic functional problems and lay a good foundation for the product. When I was PKing with him, both of us were very emotional and almost slammed the table. The boss also said during the process, "I think you are very smart and very suitable to be a product manager, but you are a little stubborn and you don't see things as clearly as I do." But in the end, it turned out that the product foundation is very important for the sustainable development of the product, and it also provides a very good foundation for the subsequent iteration of the product.

I have to reflect on myself three times a day. The nature of a product manager's job determines that it is easy for a product manager to make mistakes. Once there is a problem with the product design, as the decision maker of the product, you cannot push the responsibility away, but must have an attitude and example of taking responsibility. However, being almost stubborn in the direction of a valuable product and not easily overturning or changing requirements is a manifestation of a product manager's courage and responsibility, and it is the most basic respect for the work of programmers.

When problems arise in product design/implementation, take responsibility instead of shirking responsibility; when resource support is needed, take it by force instead of by force ("by force" here means using the relationship between superiors and subordinates to exert pressure at every turn); when the product has achievements and breakthroughs, express your feelings instead of taking credit for them.

In the process of collaboration and running-in, it is more important to be responsible, dare to take responsibility, not be greedy for credit, and be kind than to be smart.

[[155109]]

Stop when you have enough, don't interfere

Many product managers like to take things for granted, especially those with a technical background. It is difficult for them to grasp the right degree and often say "this should be simple", "this should be implemented in this way", and some even go deep into the discussion of how to implement it technically when discussing requirements.

Knowing a little bit of technology helps you think from the programmer's perspective when communicating with him/her and assess the risks of implementing the requirements, but it also makes it easy for product managers to overstep their authority and intervene too much in the technical implementation plan.

Communicating with programmers offline before making demands can improve the rationality of your demands and your risk control ability, but don't discuss the details of technical implementation. Technology is what programmers are good at, trust them, and all you have to do is listen to and appreciate their solutions, don't overturn them, just make suggestions.

Spend more time with them

Most programmers need to participate in product requirements review and product communication during working hours, which does not leave them much time to write code, so they often work overtime at night. The work of a product manager is not limited to requirements design and document writing. Another important job is to be a "requirements implementation consultant." When product requirements enter the R&D stage, it does not mean that the product manager has nothing to do. When programmers are implementing product requirements, there will be some questions that need to be confirmed by the product manager. When he needs you, you'd better be by his side.

To put it bluntly, it means "spend more time with programmers working overtime." Spend more time with them, eat with them, occasionally treat them to a midnight snack, understand their working environment and status, think with them, and you will have fewer and fewer impulsive demands and more and more reasonable demands.

It is often said that no strategy is better than a strategy. It would be great if a product manager could downplay his role and appear in the right place at the right time.

The product manager is not a glamorous role, but just a member of the team, sharing the glory and disgrace, success and failure with everyone. Therefore, you bear the consequences of each other's changes. You are colleagues, teammates, and friends.