How do product managers deal with programmers

People often ask me, "Hi, Fejer!" How do you write Alibaba's demand document? "But rarely hears people talk:" Hey, buddy Hello! How does the product manager deal with programmers? "You go back and think about it a little bit, and you get three things in your mind:

1 Many product managers are programmers before, so very understanding of what a programmer is a state;

2 Many product managers still stay focused on their own product planning, design itself, the lack of teamwork with the thinking;

3 Many product managers, in fact, have to deal with the practical skills of programmers, experience, but did not value and share.

In fact, in many product research and development systems, product managers and programmers because of the way of thinking, focus on the scope, functional responsibilities of the differences, resulting in communication difficulties. How to better build a smooth bridge with the programmer is also a problem that every product manager needs to think about.

Generally speaking, product managers and programmers have a rough reason to communicate:

1, the information asymmetry;

Product managers are generally focused on: business needs, business strategy, strategic direction, product planning, operational data, overall revenue, target tasks and so on. Product managers often in accordance with the company at this stage of the situation, as well as market competition, to do some product strategy or some product planning, initiation, implementation.
So in this process, the Product manager plays the role of translation: "Market demand, business needs", become: "Product Requirements", all the information around the needs itself. Why do you need it? What do you need? What needs to be done first? Based on what kind of thinking to push product implementation, from a balance of interest to obtain space growth indicators to achieve another benefit balance.

Programmers are different, a lot of times the programmer gets the message that there is a requirement, it may be a small demand, a product requirement, or a requirement, and then a list of requirements, and then the product manager will let the programmer see what "requirements" can be implemented through code changes, which are needed to be developed and implemented, What is a technology or framework or is not possible because of cost reasons.
So in this process, programmers play the role of translation: "Product Requirements", become: "Technical language" evaluation, all the information around the development of the requirements itself. How do you develop these requirements? Is the communication database added field? Call interface? Develop new interfaces? Need to develop components? Re-structure the engine? To fulfill or support these needs?

That's when the problem comes, and in many cases we just use the programmer as a tool to write code, to manipulate the computer's requirements through a programming language.

2, communication language asymmetry;

When it comes to the language of both communication, it must be troubling the product manager itself. Product manager's language is: "description", "Describe", I have also seen a lot of product managers, many people's demand for documents is flying all over the text, a paragraph description + description, do not say that the programmer can not see clearly, may be a period of time even their own can not see clear. In addition to written language, Product Manager communication language is also vague, there is not much logic to organize, often always try to tell a demand, the programmer's computer terminology interrupted.

The language of the programmer is more technical. Many product managers have technology, technical background, but many product managers do not understand technology. So at this point, when the programmer is explaining or answering a demand, it will say the variables, functions, and implementations that they are accustomed to. So many product managers hear: "Sdk, Webshell, select, API, components, Plug-ins, controls," and so on, will be foggy,

At this time the problem comes, in many cases, we are in our own position, in our own world, think others know what they are talking about? Actually? Everyone is listening half, communication is not completely in place.

3, the angle of thinking asymmetry

Product managers think of the product itself, the technical details, technical performance does not have much say. Many product managers have the business logic to implement, regardless of whether the programmer is using: C + +, Java, PHP, Python, find open source code changes, or write their own does not matter. As long as the programmer in the agreed time, the agreed business logic can be developed, product managers will not take into account the current server configuration, the programmer's hands on the task configuration, technical capabilities of the situation, to be the result. And very willing to think that the team of engineers are the world's best engineers, want to do what can be done, for technical reasons and can not support the implementation of the requirements can not be accepted.

The programmer thinks the angle is somewhat different, I also see the programmer itself to the product pursues the perfect to the demand the background, the significance to study to understand; but many programmers still stay on the list task like to do one of the realm, do their own play. Programmers consider the way programs are implemented the same request is get or post, programmers consider the performance of the code, so take a different scenario to implement the requirements, consider the request concurrent volume pressure and security. But in many cases, the programmer's understanding of technology leads to some business requirements that are not met, not because they are not implemented, but because they realize that it is waste code or that the architecture is imperfect.

Then the question comes up, in many cases, who is leaning on the position to think about the problem? I've had a lot of situations before. Programmers say business needs are unreasonable in terms of the program, and product managers say programmers are negative about the strike and bully.

4, the examination standard asymmetry;

Who doesn't pee, huh? What can you do to me. When product managers and programmers have complete communication or misunderstanding, in extreme cases, one side will strike. This time is mainly 2 roles of the different assessment criteria, so in many cases appear very helpless.

The product manager is likely to examine the program and the time on the line, the data after the product on-line, and the engineer examines is the program performance, many times the product manager urges the anxious urgent, but the programmer day time is limited, still has to slowly the frame development, the programmer development Time is few, the unknown implementation bug has not considered is to be responsible for.

This time the problem comes again, Product Manager every day anxious! Supposed？

The above is I combined with years of work experience summed up, of course, these 4 major factors in a lot of common factors in the introduction. Of course, the process will be due to many product managers or programmers themselves (personality) communication skills, attitude, EQ and other factors caused by the communication does not advocate, affecting each other's tacit understanding.

In fact, careful analysis, product managers and programmers in the process of dealing with whether the common factors or personality factors, it is not so difficult to imagine. After some effort, we will always find some quick ways to build bridges with programmers. My opinion is as follows:

1, to see the project level, do not just look at the demand itself.

The above mentioned points whether: "Information asymmetry", "communication of the language asymmetry", "thinking angle asymmetry" or "assessment of the standard asymmetry" is our common several objective privacy. A number of factors extracted from the analysis, found or due to the point of view of our station problem caused by a high degree of inconsistency.

Product managers just see their own business needs, planning the needs of the product, and then put a lot of things to programmers to do, it is still standing in the role of the demand side. So if it's really a project manager at the level of consciousness, it's a lot more of a sight to look at.

This time you think about the need to do this project, does the programmer understand why to do? Do you have an important understanding of the priorities of these requirements? As a product manager, what do I do with a way of expressing programmers? Is it necessary to define the point of time? How big is the current programmer's resources and server situation allowing them to do? How to pull their enthusiasm to complete this project better? What applications or concessions do you need to help programmers when appropriate?

For a product manager, the same thing can be done and a result will be obtained, but the middle process is likely to be completely different. Therefore, because the thinking angle only from the end of a demand for the death of grinding foam up to the point of view of the project to consider the joint risk points, time points, the effect is completely different.

2, from understanding the programmer to start, transposition thinking will be better.

have been asking a question: "What is a programmer a group of people?" "and ask yourself:" What kind of a product manager is a group of people? "Same, a little funny, a little childish." From the laborer to the expert, from csdn to go out of the software workshop, found a lot of very good programmer's voice.

What kind of a programmer is a group of people? Cut like a watermelon with a knife:

Write PHP

Write Java

Write Windows C

Write Liunx C.

Write C + +

Programming Level General

Programming level is OK

Programming level.

Programming Level Master

Frame Cattle

Database Cattle

Diligent

Lazy in thinking

It's not JavaScript.

Positive

Like to delve into ...

It doesn't seem right because you can't find a good way to communicate with your engineers. And many of these are external conditions that are changing. See a lot of friends a year through several major project level suddenly mengjin, attitude, some characteristics also become completely different. This time you need to understand and master the programmer, as the people in the workplace, and we like the common needs of some characteristics.

The following 4 points:

1 is not particularly want to be affirmed, to obtain respect;

Understanding, affirmation and respect. These 3 words may be very empty but indeed a very good prescription. Quiet down to the programmer, listen to their voices, their complaints, perhaps the distance between product managers and programmers is not so far away.

Although many times we speak the virtues of respect, but really understand the heart, the implementation of action, performance in the attitude of the completely different. Real, you are not a word, a line of true understanding, affirmation, respect for programmers, programmers are aware of.

2 do not want to give the product to provide their own advice, not just to do a programming machine;

Many programmers are passionate about products and have unique ideas about products, but most of them are limited to technical scenarios where product recommendations are often overlooked. I believe many programmers want to participate in the product, through their own expertise to change the product, and then polished a perfect product.

So product managers can also give programmers a bit of space to play, especially in technology innovation, product needs technology-driven aspects, at a commercially controllable level let programmers play the role of the vanguard. So programmers will be able to shoot