Conduct a data-driven experience review for your team

The author of this article is divided into three parts. The author's thoughts on starting data-driven and the review of the company's data-driven process some time ago, how to find data-driven talents, and how to implement KPI indicators in the end. Let's take a look together.

I will talk about another experience review of how the team is data-driven. Some of the content is supplemented because it was not mentioned last time, and some of the content is new insights and reviews from my recent consultations. So there is this article.

Although I am in a consulting role, if you are within the team and have sufficient management authority to make the organization data-driven, you can think along this dimension.

This article will be divided into three parts. The first is my thoughts on starting a data-driven company, and the second is how to find data-driven talent, and the third is how to ultimately execute KPI indicators. We will further discuss the three parts of organizational division of labor, personnel recruitment, and management KPI.

Because there are some angles that I didn't mention last time, which is very important, otherwise I wouldn't have to write another article. Note that this is not a repetition, but a new angle. Of course, some of these angles can be used in continuous data-driven.

I would also like to thank teachers Snow and Vincent for giving me the opportunity to practice, otherwise there would be no follow-up articles.

It also made me understand the impact of trust on the feasibility of transactions. During the Dragon Boat Festival, I read Naval's book "Naval's Treasure Book", which mentioned "builders", "the fourth kind of luck" and "responsibility and reputation". These are three viewpoints. I was deeply impressed by them.

With my current work experience, I will consciously pull myself away and look at work. After all, no matter how capable a person is, he still needs to rely on a team to complete business activities, so I call this "setting up a game" or "creating momentum." As long as the environment is right, the business incubated by the environment will gradually get better (provided that you are in a good track). I believe that through the optimization of organizational structure, power and responsibility incentives, and work processes, the business growth will be far greater than that achieved by individuals just doing it brute force.

Of course, this does not mean that you only need to focus on setting directions and goals, adjusting organizational structures, and sorting out work. What it means is that you need to consider input and output, consider which things you may need to take care of, which things require cultivating talents within the organization, and which things you can influence by adjusting the organizational structure. It does not mean that as a "builder" you only need to make major structural adjustments. The trade-offs, boundary determination, and model adjustments in the middle require practice.

Or maybe as my work progresses, I will gradually summarize the methodology. At present, I always have a reference system to judge decisions, which comes from the product manager's trade-off system. Everything is unified at the bottom.

So since 2019, I have been moving towards the so-called organizational growth direction. Systems make business grow. This is what Naval mentioned in "Naval's Guide" as a "builder". He believes that people who can complete the delivery of complex systems are more scarce. So I thank Snow and Vincent for giving me the opportunity to run the business myself, although they may not understand how grateful I am.

By the way, if you want to consult about organizational growth, you can contact me at any time. My WeChat ID is at the bottom of the article.

The second is the "fourth kind of luck" mentioned by Naval in the book, that is, if you have a reputation in a field and can provide a skill that no one else can provide, then extra good luck will find you. The example he gave is that you are the deepest diver. If a salvage agency finds a treasure shipwreck that only you can dive to, then you can also get a share of the pie because they have to rely on you to salvage it.

The third point is trust. For organizational change, there will be some things that leaders cannot see clearly for the time being, but Snow and Vincent are willing to trust me. After all, Vincent and I have been friends for more than three years. I will not ruin my reputation for this matter. Of course, this is also the reason why I will not repeat the same content every time I share with others, so as to be worthy of the audience. Back to the topic.

Because I recently consulted and helped this company start data-driven development, I also reviewed a previous judgment that was not quite accurate. There were problems with the organization and also with me. This made me re-examine these three things.

1. When to start data-driven

When should we start a data-driven workflow or what are the conditions for starting it? First, we need to know where to start it. The first is high-frequency daily work, including demand realization process, operation strategy, market launch strategy, etc. The second is low-frequency work such as planning or annual planning. The third is each employee's goals and their own to-do list, which also need to be data-driven.

Next, let's talk about when to start data-driven development. If you have solidified processes and clear content for the above processes, and have abstracted all of these contents into templates, then you can start data-driven development immediately. Note that in order to synchronize process solidification and what is a standard process, I have provided a version for your reference.

The second situation is that these processes do not exist, or are not very standard and clear. In this case, the first thing to do is to go through the process and create a template so that everyone can be familiar with the template content and logic.

First, use direction or OKR to guide the team. Do not quantify data first. Only guide the team with goals and OKRs. To put it bluntly, you should first have qualitative goals and OKRs, do not quantify these goals, and then gradually quantify them. Usually, in this case, the ability model of the personnel is a bit difficult at present. With such a high intensity, both the process and the data are required, and the team members will not be able to handle it, so they will resist. Only one goal is achieved in each iteration, and the team is also clear.

To sum up, if you have a demand realization process, such as the one I provide, with clear demand review, product internal audit, and other links, and can achieve solidification and stable operation, then you can directly promote dataization in the process. If you don’t have a process, you can first build a data-driven process and then gradually start data-driven.

1. Product dataization is the foundation

First of all, Internet companies hope to implement or gradually automate their businesses through products. Controlling the quantification of product department demand is equivalent to controlling the data-driven development of nearly half of the business. Secondly, there are many downstream products with very high ROI. They involve the product design, UI design, R&D and testing of the product department itself. Controlling upstream demand is equivalent to improving the efficiency of all downstream links at once. The core of the demand realization process is the two yellow boxes, which require control of demand review and product internal review.

Secondly, when the product department starts to review the requirements, it can ask the business side to gradually become data-driven. Of course, this is a gradual process of adjustment. I know that many companies' business sides have product thinking, but they cannot explain a requirement from a product perspective. At this time, the product manager needs to intervene, communicate the requirements first, and assist the business side in writing the requirements document.

Therefore, whether it is the business side or the product manager who writes the requirements document, this step is definitely necessary. It is just a question of who does it. Considering that the capability model is started at the beginning, this step can be implemented by the product first. The purpose of this step is as follows:

• Clarify the needs of the business side, including the demand background and user groups.
• Clarify the functional scope of the business side's needs.
• Clarify the goals to be achieved by the business direction.

The first item is to make the product manager understand why or the original demands of the business side, and the user group must be analyzed. This is equivalent to the segment I have talked about before, the layered behavior, which user group you are working for. The second item is to define the boundaries. A function can be large or small. The last one is to reach a goal with the business side. In many cases, the business side may not know their goals clearly. Once the goal is clear, we will know whether it has commercial value or user value.

A good product manager should spend at least 50% of his time on problem discovery and demand balance. I even think 80% is not too much. The other 20% to 50% of his energy should be spent on demand realization.

A bad product manager spends 80% of his time on implementing product requirements, and may only spend 10% on problem insight discovery and demand trade-offs.

Because if you can't balance the priorities, you will have a lot to do, and you will have a lot of things to do, such as product design. When you are busy, your downstream will also be busy, because one demand requires four downstream links to realize it.

In the long run, the team will be lost in the process of doing things for the sake of doing them, and will not be able to gradually release business pressure based on business goals, which will lead to intensified conflicts between the business side and the R&D side. The business side thinks that there are so many requirements that they are too busy now, and the R&D side thinks that they are too urgent every time and have done nothing. In fact, a requirement is not implemented in full according to the process, the impact on the business is not clearly explained at the beginning, and there is no data feedback after the launch. In the long run, the team will fall into this state of being busy for the sake of being busy.

As Professor Yu Jun said, many people who ask on Zhihu whether product managers will be eliminated are those who only do demand realization. For products, demand realization is a basic skill, and what is more difficult is actually an invisible demand trade-off. The most difficult thing for product managers is the trade-off model. So finding the most important (insight) and the most urgent (trade-off) at the moment is what needs practice. But most startups don’t pay much attention to this. The business side will also say: What about trade-offs! Do it quickly! The business is so urgent! In fact, they themselves are not clear about the extent to which they have achieved it, and in which directions this demand will improve the business.

2. Process standards help management

There are four major benefits of process standards and data-driven. The first is data-driven, as shown in the business synchronization part, which companies usually skip. This is actually a link that cannot be skipped. Of course, it does not necessarily have to be executed by the business side, and it can also be done by the product manager. When a function is launched, what are its results and whether there are any subsequent data changes. This is the closed loop for the final launch of a function.

The second benefit is that with this, you can gradually ease the conflict between R&D and business, and gradually improve the influence of products and business, because good results will motivate the R&D team and clarify the value of their work.

The third benefit is that it can evaluate the business capabilities of the party that proposes the demand in the long term. This also explains why the demand document should be detailed to the specific person who proposes the demand. I know that many business parties in companies cannot propose requirements, or they will ask the business boss to propose requirements on their behalf. However, whether the requirements are reliable or not is ultimately a problem of the original person who proposed the requirements, because the source of the requirements is the person who proposed the requirements. If the source of the requirements is marked as the business boss, there is no way to analyze and evaluate their long-term demand proposal capabilities.

All data in aggregate is crap, segment or die ———Google analytics Avinash Kaushik

All the aggregated data is meaningless, either split it up or die.

The fourth benefit is that only when all content is white-boxed can the entry threshold for newcomers be greatly lowered. After new products are admitted, they can receive demand, and they can quickly understand the background, population, and goals of the demand, which makes it easier for them to weigh and design.

3. My review of the consulting service company

Finally, I reviewed my own and the other party's problems when I consulted this company. If you want to drive your company's data, you also need to do this checklist. Of course, if you are the CEO, you also need to do this checklist, but the CEO's main responsibility is to think about how to do it and who to let do it, but it is not for me to do it myself.

My main job is to make the company's organizational structure and work processes data-driven. Now let's review the previous confusions in the work sequence.

Company background section:

• What is the company's business process like?
• What is the company's organizational structure and personnel division of labor?
• What is the company's product structure like?
• What is the detailed process of the product, including the core user process.
• What are the current personnel workflows and collaboration tools?

Data part:

• Has the business been broken down into relevant indicators?
• Whether the traffic source statistics tracking has been completed.
• Whether the overall ability to obtain data indicators is available, and which data indicators are still not available.
• What is the current data situation, how to iterate later, and whether there is an iterative process.
• What are the data synchronization processes and mechanisms among various departments?

Implementation part:

• If data-driven, who in the organization needs to be involved?
• How do I cooperate with these people and where are the boundaries of my work?
• The current organizational structure and personnel roles do not support me to do this.
• Does the current workflow need to be optimized for data-driven development?
• What is the implementation path of organizational drive? How many stages does it go through? What are the goals of each stage?

If you are a complete outsider who does not understand the business, then you need to think about the following aspects when you start to be data-driven. The first part is mainly about the company background, because we want to make the current company data-driven. You can abstractly think of it as going from point A (starting point) to point B (end point), so it is important to understand the current situation. The second part is the data-driven part, which is how the various roles in the organization are doing from data acquisition to distribution. How to do it. The third part is implementation. How to leverage and drive several key roles to lay out the tasks.

Mistakes I made in practice:

Over-optimism about the support from stakeholders.

When I first took over, I went straight to the sixth step, which was to directly disassemble the business and split it into various indicators. At that time, I thought that with the indicators, I could extract data. During this process, a product manager came to assist in explaining the business process and product details, and the whole process was explained verbally. After I finished the split, I found three problems.

The first problem is that no one has implemented this data dashboard because the R&D data personnel are busy responding to requests. The second problem is that since my role is consulting, I don’t know who to ask to confirm whether it is the data indicator required by the demander. The third problem is that many companies do not have corresponding positions in their organizations. So I don’t know who to show the indicators to.

If the name is not right, the words will not flow; if the words are not flowing, things will be difficult to accomplish.

My core position is still consulting, which means setting directions and goals, finding the right people to do it, and controlling their processes and results. In general, data drives a system, which needs to be data-driven from upstream demand to products. The downstream of the product is mainly for execution, which is not so data-driven. This involves multiple business stakeholders.

When I was sorting out the work of the departments at the beginning, some basic processes were easier to promote from the perspective of ROI if the heads of each department contacted me. However, since my title was not determined at that time, it was difficult to drive them to do things. Or because some departments of the company were developing rapidly, there was no clear head, which made it difficult for those who contacted me to promote internal work.

I don’t know how to get the content I want by asking questions, and due to the division of labor, I don’t know who to ask these questions.

One problem is that I don’t know how to quickly break down these large parts that I need to understand into questions to ask the business side. This is obviously a technical job, and I also need to make the other party understand why I want these contents, and what is the purpose and significance of my asking them to do so. After all, they are already accustomed to the current working method. Change, changing habits is usually very difficult.

Overly optimistic assessment of organizations and people.

The initial plan was to gradually build a data acquisition visualization system, and then directly promote the dataization of organizational work. Now it is found to be difficult. After investigating the product department, it was found that the staff had no goal understanding and data extraction insight capabilities, and even the demand process was still relatively extensive. Moreover, in terms of salary, product is a relatively higher-paid position compared to marketing and operations.

If the product does not have a sense of goal-driven, it is difficult for other departments to have a sense of goal-driven. This may make the original one-step process split into two steps. We are at the stage where we have not established a workflow. We first let the organization understand the relationship between its own affairs and goals, first do OKR guidance, and then gradually quantify the data.

Partner's questions:

Work content information does not support data drive.

Unfortunately, when I went there, there was no one who could understand the overall business. From the perspective of work division, the CEO should not have explained it to me, so I didn’t understand the background of the organizational structure and business division. This caused me to become like a "Warcraft" player. I could only see the next few steps after taking one step. Every time I understood something, I found that there was still a follow-up situation. Of course, this also had the problem of not having good documentation.

The other party’s organizational structure does not support data-driven.

In terms of organization and roles, it is still more like a traditional software development company. Secondly, each department lacks a person in charge. Of course, from a promotion perspective, it is not likely that I can directly promote the people in each department in terms of efficiency, so it is necessary to improve the organizational structure, personnel decision-making, and persons in charge.

The process environment does not support data-driven.

No data support team can continuously transform the business side's data extraction needs into data dashboards. Because data extraction is a systematic project, it requires long-term empowerment from the team. Of course, you can treat the symptoms at the beginning, but if you are a data-driven business, it is always a good thing to consider the construction of systematic data early and continuously reduce the cost of data acquisition.

The personnel model is also not data-driven.

At present, I have investigated the product department and found that it is still oriented towards doing things. They do things just for the sake of doing things. They are not able to clearly explain the impact of what they do on the business and goals. Not to mention finding various impacts for quantitative analysis. And the relevant work processes are not standardized. There is no such awareness. Fortunately, there are always one or two people in the team who have this awareness. As long as the conscious people can make a model, it is easy for them to imitate, but it is difficult to explore from 0 to 1 by yourself.

2. How to cultivate the team's data thinking

First of all, I think the talents that any company can recruit currently are the best talents that can be recruited currently. I think the analogy made by the product manager of the company I currently serve is very appropriate.

Currently, we do not have a system to continuously empower the business to provide data, and we lack workflows and some organizational roles. For example, a restaurant does not have good cooking utensils, high-end knives, or the cooking processes that high-end chefs are accustomed to.

At this time, you find a high-end chef. We can compare all employment relationships to transactions. What does the high-end chef want to get when he comes? He must be able to practice his professional cooking skills. You ask him to buy cooking utensils and sharpen knives first. Once the restaurant collapses, he will not be able to use his experience in the new company, because large restaurants provide a good cooking environment and chefs only need to spend their energy on cooking.

So don't look for some very high-end people when you are very young, because they can't match. Because even if he comes, he can't play well. You are building a cooking environment, and he requires you to practice cooking skills well. Readers, don't use Cai Chongxin to refute me, and we are not Jack Ma. As I said in my self-introduction, using probability theory to explain the world, Jack Ma is a low-probability event.

The second is that good talents are easily attracted by other offers. I once worked in a company with about 400 people. At that time, it was not easy to recruit people. The first-tier large companies would cut back on one offer after you sent it out.

It's the same as what I'm doing in a big company now. What I always want to express is that the people you recruit are the best people you can recruit at the moment. Big companies also have troubles. Every time we send out an offer, we are afraid that Alibaba, Tencent, and ByteDance will send us an offer. Only products such as Douyin, Tik Tok, and WeChat are not too afraid that no one will accept the offers they send out.

Third, my colleagues who worked in the Internet finance company at that time finally found jobs in Kuaishou, Ctrip, JD.com, Baidu, etc. Some of them even became product directors of O2O business. So my reflection now is whether it is these people who are not good enough or the company. Why do the same group of people go to better companies? It proves that they have no problems and can be trained to become the backbone of large companies.

So why were the leaders not satisfied with them at that time? I think it was because the company was not good enough. The company did not have an environment to cultivate people. Once people pass a certain threshold, their abilities are actually affected by the company environment to a large extent. Of course, people's basic qualities must exceed a threshold.

To sum up, corporate recruiters should not try to recruit a particularly talented person. From a transaction perspective, you have to pay much higher than the market price for such a person. If you pay 30% more, he will not come considering the hidden costs such as the risk of project failure. Only when you take the business to the next level and gain the influence of the next level, you can recruit talents that can be absorbed by the next level.

This reminds me of a saying by Konosuke Matsushita: the most important job of Matsushita is to train people. Because any business is done by people, if you train good people, the business will naturally move to the next link, and better talents will emerge. Moreover, in most cases, the development speed of personnel is faster than that of the company. This also explains why our Internet finance company product personnel all go to large companies.

I would like to share some additional views on personnel growth. I used to dislike a leader in the company because he unscrupulously protected people in the team. I think unscrupulous favoritism is a kind of doting on people in the team. Of course, this is a difference in management philosophy. But one of his actions made me change my mind about him a lot, that is, he organized people in his department to study.

You should know that most companies will not spend money on the growth of their employees. This kind of growth and training is a long-term investment, and too many companies think it is not worth it. They just treat employees as consumables. But if your company is still willing to train you, it proves that your company at least has plans for your long-term development, and you should thank them, because there are really not many such companies.

Usually, the most basic factor for the growth of personnel is the business growth rate, which is only the basic factor. However, whether personnel can grow with the business depends on their growth rate. The first secret of growth rate is motivation, and the second secret is method. Motivation includes what kind of workplace person you want to be and what kind of changes you want to make to the business. And the method is that you need to have a good thinking model.

You probably know how to do something professionally. So a lot of work is a necessary condition for a person's growth. But it is not a sufficient condition. He needs to read professional methodologies and do things in a professional way. Secondly, in the process of practice, digest and absorb, and keep thinking. So Yu Jun said that reading, thinking, and practice, the lowest link of the three determines your upper limit.

The two companies I recently consulted both had very busy people, but they didn't make any progress. They were repeatedly training in the lower dimensions, but the key is that they don't know what the higher dimensions are. They don't know that they don't know, which is terrible. If you are interested, you can read another article of mine: Master a better thinking model to stand out in the workplace

For example, a product manager may just implement requirements at the beginning, but if he continues to do only implementing requirements, he will be worthless. Even if he has a lot of things to do, he will still be worthless.

Because what is more valuable is to weigh the priorities of the needs, know which ones to do first and which ones to do later, and then do demand planning, know what to do in the future, and then implement it on the basis of planning, and know how to implement a plan. This requires a product manager to constantly improve the difficulty and complexity of his work.

The same can be said for all industries. If a product manager just repeatedly makes demands and completes basic demand realization, he will not grow. Sometimes being very busy and having no method is not a good thing.

One thing that needs to be explained is that reading here does not mean reading books, but refers to the channels to obtain professional methods and improve thinking models. Chatting with experts is also possible, but some people do not have such resources. For example, Mr. Yu Jun once said that the reason why high-level bosses grow fast is because they can communicate and learn with experts from all walks of life, so they naturally grow fast. However, low-level brothers do not have such opportunities. They do not have the opportunity to chat with experts, but they can learn from the books written by experts.

3. Some views on KPI

When a workflow and organizational structure are not data-driven, they cannot be driven directly by KPIs. For example, if there is no data dashboard and no process for continuously acquiring data, then there is no way to monitor the process. If the process is not well done and cannot be controlled, then how can the result be controlled? It is meaningless to drive by indicators because you can only issue indicators and you cannot optimize indicators through data.

In the case of a stable data-driven workflow, with a certain amount of data, indicators can be measured, because too small a data volume will not be accurate. KPI targets are not very meaningful. If the amount of data can be estimated, then the issue of KPI allocation method is involved.

First of all, I want to say that there is nothing wrong with being driven by KPI, but don't rely on KPI to be driven by a few points, because the achievement of future goals has a certain degree of uncertainty and unpredictability. Indicators will lead to deformation of actions to achieve indicators. Take my previous article to illustrate this matter. A coffee shop estimated its GMV for the next quarter, so how can it be sure that this GMV is reasonable? It has no way to be sure.

However, this will lead to over-operation of personnel. For example, when I go to drink coffee, he will not care about my needs and will only recommend me high-priced products. This will help him achieve his KPI. This short-term achievement of KPI will hurt the business in the long run.

One method here is the 50% mechanism used by Facebook, that is, everyone can submit KPIs, and each business, each quarter, or half a year will be evaluated to see whether you have completed your indicators or not. It does not matter whether you have completed it or not, but in the long run your indicators should be completed half of the time and not completed half of the time. If your indicators are always completed, it proves that your KPI is too low.

Another way to implement KPIs is to look at the confidence level. Since most businesses have natural growth, there is a confidence level for increasing the delta value. For example, the confidence level for increasing the delta value by 10% is different from the confidence level for increasing the delta value by 80%. Performance with different confidence levels can be incentivized in batches.

Author: Arun's Growth Research Institute

Source: WeChat public account "Arun's Growth Research Institute (ID: arungrowth365)"