The position of product manager often needs to communicate with R&D personnel, and in this process, product managers need to master certain communication skills, so that effective communication can maximize efficiency. In this article, the author summarizes some communication tips, let's take a look.

Product manager is a position that requires frequent communication with R&D personnel, with the title of "manager", but does not have the real power to command others. You can only rely on one mouth to sell your product ideas, and let the partners in the R&D department help you realize it.

If you're always in the middle of a product development process with all kinds of "fights", it must be something wrong with your communication style.

If professional technology is hard power, communication ability is soft power, and only by having both soft and hard can you become a qualified product manager.

1. Communication problems between products and R&D

As a product manager, what is the most memorable sentence that the R&D staff said?

"This demand cannot be realized. ”
"It's too big a change to do. ”
"There is no definition in this requirements document!"
"This has to be done all over again. ”
"This feature is not well designed. ”
"It's a third-party problem, and I can't solve it. ”
"xxx help me urge it!" - "Why do you want me to urge it?" - "You're a product manager!"
………

So, conversely, what is the inner monologue of the R&D person to the product manager?

(It's not an inner monologue.,Most of the R&D is a straightforward boy.,What's unpleasant is to spray on your face.,Never need to think about your feelings.,That's just such a dick!)

I want to change the demand again, I X!
What is the product manager doing all day long, the requirements are written so rubbish.
Why did I explain so much to you, but you don't understand, I don't bother to explain it to you.
Such a strange requirement has to be made for me to write code to implement it!
"This requirement is very simple, I don't care how to implement it, it will be launched tomorrow. "—you sand sculpture.
………

Programmers complained that some people at the conference said that product managers and programmers are like Tang Seng and Sun Wukong:

Tang Seng: "I want to learn the scriptures." ”
Sun Wukong: "Then you have to kill the monster that the white bone spirit has become." ”
Tang Seng: "You can't kill innocents indiscriminately. ”
Sun Wukong: "What should I do then?"
Tang Seng: "I don't care, I want to learn from the scriptures." ”

This passage vividly describes the contradiction between product and R&D, although the goal is the same to obtain the true scriptures (product launch), but the road to learning from the scriptures is always full of disputes.

Communication is an effective way to solve the problem of continuous diss between you and R&D, and mastering certain communication skills can allow you to peacefully coexist with R&D in a depressing space such as "cement lattice" and maintain a happy mood.

2. Share 10 communication experiences with R&D

1. Define the goals of teamwork

Research: "This demand development is expected to take two weeks. ”
Production: "It's such a simple function, does it take that long?"
Research: "You can see how complex the features you designed are, and there are a lot of changes involved. ”
Production: "I feel like you're in the box for me, and it can be done in a week at most." ”
Yan: "Then I can't do it. ”
Production: "Then I don't care, I have to go online in a week." ”
Yan: "You can't do this every time, how can you do it in such a short time?"
Production: "Where do I have every time, it's obvious that you deliberately estimate the time. ”
Research: "Then what can I do if you need to design such a stupid B?"
Production: "What do I need to design, do you want to teach me? I'm the product manager, I have the final say!"
Research: "You're a great product manager, if you can write code, you can write it!"
………

In the process of communication between the product manager and R&D, the two sides often argue because of differences of opinion, sometimes the argument is red-faced, fragrant, and even begins to make personal attacks, from denying the matter to denying that the other party has a problem.

In the end, I don't know what the issue of the debate is, and it turned into a completely meaningless "war of words".

Why is there such a meaningless "war of words"?

Because, without goal transmission, everyone does things in the same direction. R&D believes that making products is for product managers, not for customers, not for the company's performance.

For this reason, it is easy to say that the product manager thinks what is your product, and how I want to do it is my R&D. They don't fight each other in one direction, and they even fight each other in opposite directions.

Therefore, before making a product, you need to inform the R&D team what the goal of making this product is, what value can be brought to customers by making this product, and what benefits it can bring to the enterprise.

In this way, everyone can "think in one place and work hard in one place".

2. Talk about the cause and effect of the demand

Producer: "Why did you change this feature for me? Who told you to change it?"
Research: "I think it's more reasonable and logically simpler to change the data structure to this. ”
Production: "The problem is that if you change it to this, customers can't use it!"
Production: "The customer needs to do this function because of xxxxx. ”
Yan: "Ah, you didn't tell me at first, how do I know?"
Production: "Do you still want to talk about this kind of thing?"
Research: "Nonsense, I'm not a customer. ”
…….

In a demand decision-making chain, product managers have all the information from customers, sales, and leaders to understand why they want to design features. As a programmer at the end of the demand chain, because of the blockage of intelligence information, he can only care about the use scenarios of the product, so it is easy to make programs that deviate from reality and bring a bad user experience.

Therefore, when the product manager talks about the requirements for R&D, he must introduce why the function should be designed this way in combination with the actual use scenario of the customer, so that the R&D will not design the architecture according to his own understanding.

The best way is to tell a story: who, at what time, where, what did you do, what kind of problems you encountered, how you hope to solve them, and what consequences will come if you don't solve them.

After the story is told, the R&D will understand this function, and in the process of doing this development, it will know how to design its own program to better solve customer problems.

3. Develop the Xi of information synchronization

Production: "How does this feature look different from prototyping?"
Yan: "Didn't I ask you, did you change it like that? ”
Production: "When did I agree?"
Yan: "I don't remember, I asked you anyway." ”
Production: "Then I don't care, I have to do it according to the prototype." ”
Research: "Damn, you're not cheating me!"
………

It's normal for requirements to go back and forth during the development process. Why do these quarrels often occur? Because there is no evidence, there is no evidence, and each has its own reason.

No matter how small the requirements change is, it is best to update the relevant requirements documents as soon as possible and synchronize the information by email.

If something goes wrong with a product, even if it's for R&D reasons, the product manager needs to be held responsible. If there is a work email archive, then the responsibility is not "unlimited", but can be clearly defined.

At the same time, don't have unnecessary worries about "worrying about disturbing the leadership". For all work emails, it is recommended that you CC to your superiors. If it is an external email, or an email involving important and sensitive content, it also needs to be copied to a higher level of leadership.

On the one hand, it is to "carry the pot together", and on the other hand, it is also to ensure that if you are "stupid", someone can find and remind you in time.

4. Use empathy to make products

Research: "We evaluated this feature, and it will take at least a week to make it like this. ”
Production: "Then I don't care, this is something you developed, I just care about the function implementation." ”
Research: "I'd like to discuss with you how to implement this feature?"
"I'm not in the business of technology, how to achieve it is your business." ”
Yan: "It's just to talk to you and see if it's feasible to do this." ”
Production: "I said it, how to do it is your technical business, don't look for me." ”
Research: "Okay then!"
…….

In the process of R&D, it is true that R&D personnel do not have a good understanding of the function and have doubts about the implementation method. At this time, R&D wants to find someone to discuss with you, not necessarily to change your requirements, or just to communicate with you about the feasibility.

When you can think about how to achieve it from the perspective of R&D personnel, you can actively contribute your own ideas and ideas to explore better technical solutions together.

If you think about it from another perspective, you may also find that your requirements document is not detailed enough and the description is not clear enough, which is easy for people to understand and even misunderstand.

Therefore, don't draw too clear boundaries with R&D in terms of job responsibilities, everyone forms a team to solve problems together and ensure the smooth launch of products together.

5. "Porter" who does not act as an information

Research: "X worker, help me ask xx when their interface documentation will be available?"
"Can't you ask this question yourself?"
Yan: "Who told you to be a product manager, of course you asked." ”
"They said it's not that fast, it will take about a week. ”
Research: "Then you can help me ask, can you provide the interface of the xx part first, I'll take a look at it first." ”
"Can you talk about it if you have any questions?"
Yan: "I just thought of it. ”
"I'm not available, you can ask yourself!"
Research: "Then I won't do this function." ”
…….

How to work efficiently and maximize the value of your time? The first thing to avoid is to be a "transmitter" and "porter" of information.

The best way is to set up a group, encounter the corresponding problems @ the relevant people, what resources are needed @ the relevant people.

Try to avoid product or project matters, and have one-on-one private chats, preferably in a group or email, so that everyone can see them.

This can not only improve the efficiency of communication, but also reduce the risk of being unreminded due to a sudden short-circuit in your brain.

6. Use the leader as a "shield"

Research: "This requirement is a bit complicated, and the amount of work to change is too much. ”
"What are you trying to say?"
Yan: "Can you not do this?"
Production: "No way, the leader asked to do this, you have to change it to ask the leader." ”
Yan: "Okay, just because I didn't say it. ”
…….

Generally speaking, the people who communicate with you are at the same level, to put it bluntly, the people who work are small soldiers, you send orders, he works, and the boss pays money.

Therefore, when encountering problems that are not easy to communicate and solve, the boss "ends" out, and many problems will be solved.

Even if you put forward this requirement, you can also say that the boss wants it, and there will never be R&D personnel who really ask the boss, why do you want to ask such a requirement?

Of course, this "nuclear weapon" cannot be commonly used, let alone used indiscriminately, or it will lose its deterrent effect when it is really needed. It must be true that when there is no communication and stalemate, the boss must be "moved" out.

7. Be sure to be "resource-conscious".

Production: "Let's stop for a moment, this demand customer asked to change." ”
Research: "Ah, I'm done with the development and I'm ready to put it to the test." ”
Production: "That's no way, the customer said to change." ”
Research: "Why didn't you ask clearly at the beginning, but at this time to change it, didn't the previous ones be done in vain?"
Production: "I can't help it~"

……..2000 years later……….

Production: "Stop, the customer still thinks that the previous plan is better, and wants to change it back." ”
Research: "Damn, aren't you playing with me?"
Production: "Hey, let's be clear, it's not me who plays with you, it's the customer who wants to play like this." ”
Research: "It's that you don't understand what you need. ”
Production: "Am I a product manager or are you a product manager?"
Research: "You're a product manager, you're awesome!"
………

In the process of product research and development, the most fearful thing is to change the demand, and what is even more terrible is to change the demand back and forth.

At this time, the product manager must have a sense of "resources", every change in demand is costly, and he can't always turn the knife edge inward to develop a meal, but also have to reason with the customer several times to make the knife edge outward.

It is necessary to respect the work results of R&D personnel, and when it comes to changing requirements or even cutting requirements, try to explain to everyone why, and say a few more words about everyone's hard work.

At this time, if you put on a "landlord" mentality again, regardless of everyone's life or death, just collect rent and get results, sooner or later everyone must not hold high the banner of "down with the landlord's old wealth" and sacrifice you to the heavens to relieve your anger.

8. Don't get into the game of perfectionism

Production: "Can't you test such an obvious bug?
R: "I didn't show up when I was testing the environment!"
Production: "Now it's time for users to use it, and it appears, don't tell me about the test environment." ”
Yan: "Then when you accepted it, why didn't you find it?"
Production: "I just don't accept it, you have to ensure that the product is 100% fine, do you want to test it." ”
………

If you've been a product manager for a long time, you'll know that there are always problems in the process of a project, and even after testing for a long time, there will still be some very obvious or inexplicable bugs after the product goes live.

At this time, it is pointless to immediately dump the blame for R&D, thinking about how to quickly fix bugs and avoid similar problems in the future.

In the process of product development, there will always be some functional trade-offs due to limited resources and tight time. If you must force the R&D personnel to complete the product on time and with quality, it will definitely lead to resistance to the R&D personnel, and finally even if it is launched on time, the product quality is constantly small and difficult to fill.

If you can't guarantee that the product requirements are 100% unchanged and that there are no logical bugs, then don't ask for 100% error-free and bug-free development and testing.

9. Become a customer and urge the project to go online

Production: "How long will it take for this feature to be available?"
Research: "I also have to evaluate how to implement this function, I can't give time now." ”
Production: "Can you give me an approximate time?"
Research: "I can't give it. ”
Production: "It will be launched at the end of this month, can it?"
Research: "The time is too short to go online." ”
"At the beginning of next month, the customer will hold a press conference, and there will be superior leaders to visit and inspect at that time. ”
Production: "The time of the customer conference has been set, and it can't be changed. ”
Yan: "In that case, we can only work overtime on weekends." ”
…….

When evaluating the R&D hours of a project, the product manager is always worried that the R&D personnel will misrepresent the working hours and fool themselves.

What can be done in one day has to be done in three days. And where is the time when the customer asks to go online, if you can't go online on time, then the sales must not be like "you owe him money" and "urge you to death".

The best way to solve this problem is to turn yourself into a customer, explain why you want to go online in xxx time, what problems and risks will be if you don't go online, and there will be benefits to going online on time.

For example, the leader wants to come to inspect, the project funds must not be paid at the xxx time node, and the xx month xx is a special day, and the company needs to take this opportunity to promote and promote the product launch.

Of course, there will still be this situation: even if the knife is put on the neck and the R&D is killed, it will not be able to be put on the line within the time specified by the customer.

What should we do? Don't "force each other to die" in R&D, why should it be difficult for part-time workers.

If you're a customer, you can't have some other way to solve it.

For example, if the product can't be launched at the specified time of the leader's inspection, can you launch some core functions first, can you complete the development of the front-end page first, can you use the UI renderings to put it on to present the effect first, pass the leadership inspection first, and then slowly develop it later.

10. Must understand some technical language

Research: "It's not easy for you to design this function like this. ”
Production: "What's not so good to do?"
Research: "Every time I make a change here, I have to get the data from the backend interface. ”
Production: "Why can't we keep the data on the front end first?"
Yan: "Seems to work like this. ”
Research: "Also, can this data not be displayed in real time?"
Producer: "Why?"
Yan: "Because the calculation results are all returned to me by the backend, and the backend data is generated in the early hours of the same night?"
Production: "Why can't you just trigger this button and request data on the backend?"
"Why do you have to wait until the early hours of the morning to generate data, and can't you run a batch every 10 minutes?"
Ken: "Looks like that's okay. ”
…….

In the process of communication between product managers and R&D, in fact, the most discussed thing is not the business requirements, but the technical implementation details.

But if you don't understand some technical implementations, and don't know the terms and terms related to technology, there may be a "nonsensical" dialogue between chicken and duck.

Product managers speak in the vernacular, and R&D people speak in the dark. You say yours, he says his, and what he says is not the same thing, and in the end, if the dispute is over, it will be over.

A product manager may not be able to write code by hand, but you must at least be able to understand what R&D is saying and understand the technical implementation behind the feature.

If you don't understand anything, the R&D personnel say "the technology can't be realized", you have to go back and change the demand, and you have to thank the R&D for the reminder when you go back. was sold and helped count the money, just so stupid and sweet.

If you really want to encounter technical terms that you don't understand, just ask the R&D personnel, just go to Baidu, and slowly you will understand? Slowly, you will not be able to talk to R&D in the same cognitive dimension? Slowly, you will not be able to participate in the discussion and opinions on the way of technical implementation?

Of course, a situation to avoid: when you understand some technologies, think that your own technical solutions are more suitable, and ask R&D to do it in your own way, and finally there is a problem, you can only find the blame. Believe that every programmer is a product manager of their own code.

Final Words:

In fact, there is no need to communicate with R&D, and there is no need to worry about how to deal with different types of people, because you are always dealing with "needs".

As long as you stand in the user's perspective and communicate with the goal of launching the product on time, quality and quantity, there will not be so many arguments, let alone "saber rattling, war, and gunsmoke" in the office.

What experience do you have with R&D? Write it out and show it.

This article was originally published by @武林 in Everyone is a product manager, and it is forbidden to reprint without the permission of the author.

The title image is from Unsplash and is licensed under CC0.

The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.

How do product managers deal with R&D?