In addition to creativity, execution, and methodology, what other skills are essential for great operations?

A product project team usually includes members of the following trades (the staffing may increase or decrease depending on the specific situation and different periods): product, design, R&D, testing, operation and maintenance, operations , marketing, business, and channels.

In the early stages of product development, product and R&D students will take the lead in creating the product from scratch and ensure that the product is completed as required. After the product is launched, the daily management and data indicators will become the responsibility of operations. How many "0"s the product's user base can have depends on how much operations, marketing, channels, and business can do.

In the process of conquering the market for our products, we will receive a lot of feedback on functions and needs from users. Sometimes, in order to further improve product data, we will also put forward product iteration requirements for our own operation projects. At this time, we need to put forward requirements to the product, schedule the technology, and interact with the UI... What follows is a long but necessary communication that we have to face.

Princeton University, a famous American university, analyzed 10,000 personnel files and found that "IQ", "professional skills" and "experience" only account for 25% of the factors for success, and the remaining 75% is determined by good interpersonal communication. In addition, the survey results of Harvard University's Career Guidance Group showed that among 500 men and women who were fired, 82% were incompetent at work due to poor interpersonal communication.

In order to avoid being fired, it is particularly important for operations personnel to establish good communication with other team members.

Anyone who has worked in operations knows that there are three types of people in the company who we need to communicate with frequently, namely product, technology, and UI (with a small number of business and channel people). The following explains the communication methods one by one, hoping that it will be helpful for promoting communication in the project.

1. How can operations communicate well with products?

Since the two positions of operations and products came into being, the relationship between the two has always been the most delicate, and it is very easy for them to look down on each other. If the company separates operations and products into separate departments, each led by a different leader, it is estimated that they will keep an eye on each other and start a fight whenever there is a problem:

From an operational perspective, the product takes up so many development resources, and most of the time the functions produced are as useless as shit, and we have to clean up their mess every time and be their scapegoat.

From the product's point of view, apart from giving out small prizes and holding events, and bringing in a wave of freeloaders who are of no use to product development, the operations department doesn't seem to have any major effect. Can't they do something that affects the product and shocks the industry like me...

One problem that may arise when operations and products do not see eye to eye is that operations projects cannot be promoted on time, product functions have no subsequent operations management, and even the most core product daily activity data will decline. Regardless of who is responsible, precious time is wasted on complaining, so who benefits in the end?

There are two ways to break this situation: expensive and free. If the company's budget allows, the operations team can recruit product managers , and the product team can recruit operations staff. If you don't want to spend more money, you can streamline the organizational structure and set up a product division system with full staff for each product line. This can motivate employees' sense of responsibility and enthusiasm for products better than a large department system that divides work by function and assigns tasks. (It seems that adjusting the organizational structure is not easy), or we in operations can lead by example and communicate well.

1. Language communication on the same channel

The operations department's daily work mainly involves creating content, writing plans, and writing PPTs, while the product department's work involves analyzing user needs, analyzing the functions of competing products, writing requirements documents, drawing prototypes... The different tasks we do determine the different carriers and methods of our communication.

Operations should use the right operations to communicate with products. You can't just take this plan and go there. You also need to write a product requirements document (MRD). This is a document that can quickly let the product know our needs and what they need to do. The details of the initial communication do not necessarily have to be clearly stated, but the interaction requirements of the core functional points must be stated.

2. Tell us about the benefits, don’t take credit

Operations start from the optimization of details, while products involve larger iterations at the product level. The essential goal of all operations and product work is to maximize the value of the product, but the means and ways of thinking are different.

When an operations person communicates with a product manager about the functional requirements of a project, he or she can clearly inform the project of the benefits of the product he or she is currently responsible for. The benefits that product developers care about are nothing more than having more people using their products, or proving that the functions they have developed are conducive to the core target data of the product. For example, if your project directly reuses a function of the product team, and then when establishing the project, you directly thank a product manager for his functional support, communication will probably be smoother.

3. Learn with an open mind and don’t get emotional

Psychology has found that when people notice a sign of individualism in their leader, they will become indifferent or even hostile. On the contrary, leaders who stay behind the scenes and are less visible will be more widely respected.

Pulitzer, the founder and publisher of the New York World, once told his editors that if an order he issued during an emergency violated the newspaper's policy, the editors could ignore it. Learning to be humble is definitely a matter of "one step back, the sky will be broader" in interpersonal relationships.

As operators, we can come up with all kinds of interesting creative ideas and thoughts. The product logic is better and we have a better understanding of all the data and interfaces of the product. For small project operations, it is indeed possible to independently complete the writing of product requirement documents, but for large product iteration requirements, it is best to learn humbly and not be emotional. If you can discuss and cooperate with the product, it is estimated that better results can be achieved. At least when communicating with technology, you will think more clearly about all the details of the product.

4. Leverage leadership, not conflict

Once I was giving a presentation in Shenzhen and someone asked me, “How can operations better communicate across departments?” My advice at the time was, "You can try to solve the problem by yourself first. If you really can't solve it, in order to avoid conflicts, you can send an email to copy the department leader, and then ask the leader to help advance the project. At that time, I saw a salesperson on Tieba who copied the email to the vice president, and then the product immediately solved the problem. Haha! If you are popular, there may be another better way."

In order to leverage the leadership for project recommendations, you need to inform the leadership in advance and let them guide you on what to write in this email. What operations need to do is to inform leaders of the project background, project benefits, project status, current demand issues, and then prioritize the needs (which functions must be done, otherwise the project cannot be completed), and what kind of product support they hope to get.

2. How can operations communicate well with design?

When optimizing/developing a certain function of a product, after the operations and PM complete the prototype of the function, the UI needs to carry out visual design for the text and interactive modules on the prototype.

For users, in this age of appearance, aesthetics is the key to determining whether they will use this feature; for operations, the visual effect of the function directly affects the project data, so the communication between operations and UI directly determines the quality of the function and the quality of the project data.

In theory, as long as we draw the prototype and give it to the designer, we just need to wait for the drawing to be completed and receive it. But the reality is that when working on a project, the following situations often occur during the cooperation with the UI. I wonder if you have the same problem:

• UI doesn’t care about the logic of the function, but only focuses on the aesthetics of the product. For example, the thumbs-up next to the voting button was originally meant to highlight the button as “support”, but UI said that this would make the page look crowded, so it was simply changed to the text “support”.
• The page effect designed by UI kids is not satisfactory and does not meet the operational expectations. It needs to be reworked and modified.
• c. In order to make the functions more interesting, operations and products can often communicate new ways of interaction, but the UI guys are reluctant to make changes as they feel it is unnecessary.
• d. Product, operation, and UI are all very satisfied with the visual appearance of the page, but my direct supervisor thinks it is not good enough and needs further design revisions.
• e. The visual of the function is done, but the function is not online yet, and the UI guys keep urging the progress.

Good cooperation is based on respect and communication, and you must trust the other party's professional level. What do UI designers fear the most?

What they fear most is that the page they designed will not be put online, which means that the value of their work is not recognized, and the work is just a PSD lying on the disk. In essence, they also hope that their work can be seen by more users, but they need operations to give them more motivation for continuous modification. Therefore, usually, when there is a need for modification, operations can try to circumvent and communicate persuasively using the following methods.

1. Early participation and effective design

Operations can involve designers in the early stages of function design, and they can consult their suggestions when drawing prototypes with the product. After all, they are professional designers and have seen more interaction methods and pages than us, so they may be able to come up with a better way to present functions. Of course, the most important thing is that the early participation of the designer can save time in repeatedly explaining the interaction of each button in the prototype during the subsequent page design process, and the designer can also better understand the thinking behind the placement of each button at the operational level.

2. Persuade indirectly and give affirmation

Behind every designer there is a group of gods who give advice: “It doesn’t look good if you do this. Enlarge the text in the upper left corner, darken the color, and the whole style is not flat enough.”

No one likes to be denied. If you have your own opinions on the visual design of the product, the best way to communicate is "If you fill this button with blue and change the color of the page, will it look more comfortable? Of course, this is just my idea. After all, I am not as professional as you, and you may have a better modification plan."

Positive employees are all working towards a good result. Everything can be discussed based on good communication. Of course, the premise is that there should not be frequent modifications due to mistakes in one's own prototype.

For those who have better interaction and improvement requirements, you can first give affirmation to his work before proposing your own modification requirements. "The current design is very good. After communicating with the product, I think that this button may become a bouncing ball, which may be more in line with the style of the entire page. I wonder if you think so too?"

3. Group communication and progress sharing

As the initiator of the function, the operation department must ensure that information is not communicated among technology, products, and design parties. Don’t become a messenger and run around all the time, otherwise you will have no energy to think about other things to achieve data goals. Group communication means setting up a project discussion group, allowing UI designers to coordinate with technical staff on page layer distribution and image cutting logic, and allowing designers to respond to technical staff regarding color RGB data in a timely manner.

Then the technicians can synchronize the development progress in the group at the first time, and the designers can also better understand the development progress of the entire project, so they will not think that the operation has shelved their page design work.

3. How can operations communicate well with technology?

After the UI designer creates the page, the operation department needs to take it and the product requirement document completed by the product team to the technical department to seek scheduling. In order to avoid asking about progress every day, worrying about a certain requirement not being met, and repeating testing and submitting bugs endlessly, and to ensure the smooth launch of the project, operations staff need to pay attention to the following issues when communicating with technology staff.

1. Provide sufficient explanation to motivate students

Programmers like to call themselves "code farmers". It would be a tragedy if you really regard them as Internet migrant workers who are only responsible for writing code. Technology and operations are not the same department. They only have a cooperative relationship, not a leader-led relationship. Operations should never unilaterally push down demands, say that they want to do something, and tell R&D that they have to achieve it in this way and that it must be completed at a specified time.

Why are more and more technical students now able to transform themselves into product managers or even start their own businesses as CEOs? Because reliable R&D personnel with ideas and ambition are definitely not people who just take on jobs and do their work mechanically.

They also have their own understanding and ideas about the business, and can sometimes provide better solutions from a professional technical perspective. The prerequisite is to let them fully understand the ins and outs of this demand. The background of this demand is not only to know what we are going to do, but more importantly why we are doing this: the current product demand is determined by my operation after research and analysis. Is my explanation clear enough for you to understand? Then from the perspective of R&D, could you please see if there are any other hidden problems? Do you have any better solution? Let’s discuss this together.

2. Clarify the requirements and don’t change them easily

Operations work is extensive and trivial, often requiring "multi-threaded task parallelism" and frequent dealings with various users. Therefore, operational thinking is relatively divergent and requires considerable flexibility. This is a major feature of operational work and also the biggest problem in communication.

It may be possible to communicate about adding and modifying new requirements during the functional design phase. However, if the requirements are changed during the development phase, the friendship with technical classmates will probably be in jeopardy.

Therefore, clarify the requirements and do not make changes easily (the requirements that are icing on the cake should be completed in the next version). The technical development documents and pages provided should be the final version. The bigger the changes, the greater the possibility that your project will be squeezed out by other project schedules. If the project cannot be successfully implemented, the designer will probably be anxious with you.

3. Module communication to settle problems

Technical personnel deal with data codes, basically working in a single process. In order to improve the efficiency of coding per unit time, they basically need to be in a "flying" work mode. Sometimes they write until they are so high that they forget about everything else and are completely immersed in the world of code.

If the operations staff interrupts him every few minutes to change something here, fix something there, or ask a question... the R&D train of thought will be interrupted, and these single-threaded students will most likely go crazy. So operations and technical communications must use tools to manage demand. Put all generated requirements and suggestions into a project management tool. For example, JIRA is a very commonly used tool (large companies basically have their own development requirements communication tools). Summarize a batch of requirements and communicate with R&D regularly to determine priorities and schedules.

If it is an urgent demand, or a major bug occurs (for example, users cannot log in), you can ask R&D to handle it at any time, but try not to report the demand piecemeal, especially do not use instant communication methods such as QQ or phone to report the demand to R&D. It is easy to miss something, difficult to count and feedback, and it also causes disturbance to R&D.

An operator who can communicate is a good operator

The essence of communication is to let him know what you want, and you know what he wants. That is, everyone in the team should take the initiative to understand the work content of other team members on the premise of their own work. Not only should they communicate more with technical, design, and product colleagues, but also with the marketing and channel departments to know in advance the points that can help them improve their data.

The goal of operations is to maximize the value of the product. No matter what means are used, as long as they are reasonable, legal and do not violate company regulations, there is no problem. But if you always think about taking advantage of others and taking advantage of them, it may work for a while, but it will not work in the long run.

The best way to communicate and cooperate is not just simple coordination or help between departments, but to make all participants have common interests, be willing to share, and clearly distinguish between rewards and punishments. If the product is well made, everyone should have contributed, and money should be shared and team building should be done as needed. Everyone knows that there is no harm in working with you. Over time, reliable people will be willing to continue to cooperate with you, and your reputation and workplace credibility will be established.