3 issues in ToB product operation!

When I was doing ToB operations before, I treated ToB products as ToC products, and I took a lot of detours. The products never got on the path of positive operation and did not make money. This also caused me to encounter a lot of trouble in the ToB operations.

After a period of recent reflection and the development of new business models, I realized that ToB operations are not as simple as mastering some skills.

In the past two years of work, I have stepped into many pitfalls in ToB product operations , which can be simply attributed to problems with thinking, cognition, and experience. These three problems made me cry a lot. I also hope that these three problems can help you get rid of the embarrassing situation of switching to ToB operations.

By chance in 2018, I joined an excellent domestic AI company and started working on SaaS product operations. At the beginning, I had no clear concept of SaaS products and ToB products. Moreover, from the C-end operation of an education company to the B-end operation of enterprise services, in my mind, there was still an indicator centered on the number of users.

Over the course of more than a year, most of the work I did was ineffective for the final results. To the point that later on, I couldn't find my place in the team and had to change my position through internal transfer. Then I encountered another thing that made me even more embarrassed.

Now that I think about it, due to my immature thinking, I will still face the current dilemma or other problems if I change positions or jobs. Only if I figure it out first can I better display my talents.

1. Lack of depth of thought

The earliest SaaS product was not suitable for users, so our team modified the product to make it more suitable for C-end users.

After the product went through the PFM stage, I believed that the product could be promoted on a large scale and acquire customers, so the team also set the number of users as the North Star indicator. Sadly, this goal only focuses on the number of users, but not the value that users can bring, nor the greatest contribution of users to the company.

This is also related to the business logic of the product, because the goods are not sold directly to users, but through the monetization path from traffic to advertising. This path seems very reasonable, but it is also very unreasonable.

Because the Internet has developed to the stage of private domain traffic, the value of the traffic retained on each PC or M-end is very low, and its value contribution to advertisers is also very low, which results in the entire link not being able to flow well.

At the beginning, my understanding had not yet risen to the level of business logic and was only at the KPI stage.

I believe that as long as I complete the tasks assigned to me by the company through various means, I will be an excellent person and the team will be an excellent team. It is also KPI-oriented, which makes me only focus on the completion of KPI and forget the value that KPI can contribute to the ultimate goal of the team.

Although I exceeded my KPI, it was still a waste of resources for the team, and the input-output ratio was not proportional.

Focusing on personal gains and losses resulted in me having less say in the team and being gradually marginalized. Of course, being marginalized and having some stupid workplace survival skills, it’s a miracle that I can survive in a medium-sized company.

According to my emotional intelligence logic, I may only be suitable for working in a small company, which may be better for now.

2. Refusing to go to the front line

The essence of ToB operations is to sell products to users and let them pay with real money, rather than wasting their precious time that they cannot feel, or letting users contribute their due value to help you complete your KPI or obtain valuable information to improve your business.

Moreover, the decision-making process of ToB is relatively long, and many of the users reached are not capable of making decisions.

In the process of operations, I only relied on contacting product users through the Internet. I felt that I knew these users very well, and all operations plans and actions were designed around these users. It seemed that the operations were correct, but I only pleased the bottom-level users who could be reached, and did not think deeply about the needs of the decision makers who made the product purchases.

During the operation of ToB products, the interests and conflicts between product users and decision-makers should be considered. In the operation plan, certain nodes should be tilted towards product users, and certain operation actions should assist decision-makers in making decisions.

Reaching product users too often through tools will prevent decision-makers from making up their minds to buy.

If you want to understand the needs of both parties, you must go to the front line to meet the customers and be humiliated by them twice in the communication meeting. It is inaccurate to only bring information that has been processed by their minds through sales and pre-sales. Only by going deep into the front line can we have a deeper understanding of user needs and the conflicts between the two parties.

Operations personnel always think of themselves as high-end positions in the Internet industry. In fact, there is no difference between operations personnel and sales personnel. Don't think too highly of yourself - if you think too highly, you will fall badly.

I completely refuse to go to the front line to meet customers, because I think operations staff should sit at their workstations, think about the general direction of the product, and strategically determine the development direction and life cycle of the product. Moreover, operations staff have the most creative ideas and should not focus on communicating with users.

It was this idea that kept me away from front-line users and the true development direction of the product.

When there is not enough input information, don't even think about top-level strategic issues. ToB operations are industry operations. If you don't have sufficient understanding of industry information, it's easy to go astray.

Due to the lack of depth in one's own thinking, one's understanding of the product and past experience and judgment are prone to major errors, which is also a major pitfall in ToB operations.

In order to accomplish something, I chose to change departments. At first, I was applauding myself for my wisdom, but now it seems that I did jump into another pit. The main reason for jumping into this pit, I personally think, has a lot to do with unclear cognition and reuse of experience.

3. Cognitive Issues

The fundamental problem of cognition is the lack of understanding of products and customers, but these two directions are the foundation of good operations. There is a saying that goes, "If the foundation is not solid, the earth will shake."

In fact, it is equally practical in operations work. If you don't even understand the basic problems, you can only piece together the operations skills circulating on the Internet. Occasionally, you can produce good results, but you can't do product operations well.

In terms of product awareness, I did not consider the product's monetization path and target audience, nor did I consider how the product would be sold, which led to me being extremely passive in my work later on.

If you are looking for a ToB-related job, this may be of great reference value to you. If you are already engaged in the operation of similar products, I think you should expand more things instead of just focusing on the number of users in front of you.

In a B2B business, you cannot survive by simply focusing on the number of users. Only by monetizing can one have a higher value of existence.

During the job transfer process, people are eager to get out of the current pit and do not have a clear understanding of the other team. Since the team's products are aimed at programmers, the team decided to expand the developer base, build influence among developers, and monetize by reaching out to developers.

The so-called developer operation still takes a big detour and does not sell products directly to users.

This kind of logic is often seen in ToC product operations. After all, the user of ToC and the purchasing decision maker are the same user. However, the product logic of ToB is not like this. Even if the user thinks the product is easy to use, the decision maker may not support the purchase.

For example, for MySQL and Oracle databases, companies would rather find a large number of programmers to use various open source and free components than to purchase higher-performance enterprise server databases.

This problem also exists in developers' products. Even if our products are very useful to developers, two extremes are likely to occur when users actually pay. Strong companies may develop related products on their own.

For them, data is the core and they are unlikely to use a commercial product. Moreover, the learning cost of the product is extremely high, and it can only provide solutions and private deployment to users. The money that users pay for solutions and private deployment is enough for the component team to solve the problem through self-research.

For a team that is not very strong, the boss thinks that hiring a programmer will solve all problems. Now you actually want to buy commercial software, which must mean that you are not strong enough.

Moreover, the product is not completely open source. Programmers spend time learning a product that cannot be actually used in a production environment. They would rather spend their time on completely open source components.

Moreover, the path to monetization by cultivating user habits is very long, and the company is not completely determined to do such a thing. Even if it makes up its mind at the beginning, it may not be able to stick to it.

As a bottom-level employee, it is impossible to give reasonable suggestions, and the boss is more willing to listen to the conclusions and experiences of people from other larger companies, or the ideas of professional training instructors. Once someone says that something is difficult to accomplish, the boss is easily shaken, and the people executing at the bottom quickly become passive.

Therefore, ToB products must consider the product's money-making model. The most direct method is the most effective, and you should never try to cultivate user habits. Only by completing transactions quickly can the value of operators be reflected. The conflicts between product users and decision makers should be thought through carefully, and it should be considered comprehensively whether it is necessary to persist in the product.

Otherwise, as a ToB operator, you will be like me, because the monetization path of the product will fall to the bottom due to the changes in the top-level framework.

In my subsequent interviews, I gradually discovered that ToB companies would examine the sales brought by operations personnel, including positions in Alibaba and JD.com. They value your monetization capabilities, business sense, and logical thinking of the entire operations framework, and rarely consider the number of users of the product.

When doing product operations, you must do work that contributes value to the company's core indicators, otherwise you will be eliminated quickly.

IV. Experience Issues

Friends who are accustomed to the operation methods and skills of C-end products must pay attention to the issue of reusing their experience in B-end products. I also relied on my experience in C-end to do B-end, which was also the biggest failure in my operation work in the past two years.

Especially for product operators in some small companies, the way their products grow is relatively simple, which is only channels, channels, channels! There is basically no such thing as data-driven operations. As long as we can find ways to increase user growth, the company’s KPI will be achieved.

The B-side has a different logic. The customer acquisition cost of the B-side is much higher than that of the C-side, and the products of the B-side pay more attention to the user's renewal rate. The cost of attracting new customers is very high, but renewals are profitable.

Therefore, it is particularly important to examine users’ use of the core functions of the product and user feedback, so it becomes imperative to use data to drive B-side product operations.

The process from the B-side leads coming in to the customer transaction is a long one, and it is rare to expect users to take the initiative to make a transaction. The conversion funnel in this process and the key behaviors in the funnel have become operational necessities.

However, most companies do not have systematic B-side operation tools, which causes operations personnel to fumble around in their work. The key nodes of user retention and conversion are purely guesswork: maybe, probably, possibly, these words should not be uttered by operations personnel.

However, in the B-side operation work, it has become a real situation.

Whether it is the small companies I have seen or the medium-sized companies I have experienced, the user conversion on the B-side relies solely on the personal initiative of the business. There are very few links that the operation can control, which also leads to very few processes that the operation personnel can participate in and control. Based on past experience, the B-side operation is responsible for acquiring customers.

Thinking about it now, it is still very sad to be a B-side operator.

I think that as a B-side operator, you should first abandon the theoretical application of the original AARRR model and give priority to thinking about the product's monetization path; then think about the product's payment ability and conversion path; and finally think about traffic acquisition.

Moreover, operations should have more involvement in the user conversion path, and the best way is to use handy tools or build an SOP for B-side conversion.

I am also very grateful to my former employer for its tolerance, which allowed me to figure out these things at work. Now I have recorded them down and share them with everyone so that everyone can avoid detours in the process of transitioning to ToB operations.

There is a natural reason for the existence of ToB operations, but now everyone is still in a chaotic state, and operators need to grope their way across the river together.

I also don’t like to attribute all the reasons to the company’s poor leadership or market environment. Objective factors do exist, and the value of operations lies in finding a viable path among various failures, leading products and business models to the market, creating value for the company and achieving self-growth.

Unfortunately, I realized it too late. At the beginning of my work, I attributed the poor product experience and the narrow user group of the product to the reasons. All the solutions I found as excuses for myself ultimately hurt myself and made me shed bitter tears.

Author: Zhang Mu

Source: Operations Officer Zhang Mu