Six steps to become data-driven

The author of this article objectively analyzes and elaborates on the six steps of team data-driven. You may want to take a look.

When doing operations, should we focus on learning growth strategies or learning about potential targets?

This reminds me of many things. The results you get after deep thinking are often different from the public perception. Usually we think that growth strategy is very important.

Professor Yu Jun talked about the issue of scarcity. When looking for a product manager, we should look for one with strict logic, because strict logic is relatively scarce.

Basic product knowledge is easier to learn. So, by the same logic, when interviewing, most people will look for people who understand operational strategies and analysis, because such people are more scarce.

But there is an implicit assumption here: the data acquisition environment is also very good. So with a good growth strategy operation, you only need to continuously acquire data and continuously analyze it to continuously generate very good strategies.

Many managers think that they can be data-driven if they recruit good strategy analysts (they are scarce in themselves). However, everything is achieved by a team. Good analysts are just the tip of the iceberg. Only when the entire organizational chain starts to be data-driven and continuously empowers business personnel can we ensure continuous strategy output.

Hiring good growth strategy operations is just the beginning of data-driven operations.

Because the companies I have consulted recently are more or less unable to be data-driven due to these factors. The reason for this resistance is usually that they only see a certain slice problem or a certain node problem that cannot be data-driven. But according to what I wrote in my previous article, we should start with the big picture and start with the small details.

The solutions we often find are only partial solutions. If you really want to transform your team into a data-driven team, you need to sort out the overall obstacles that prevent the team from being data-driven. This process is very much like untangling a bunch of very tangled threads. You need to sort them out first, and then untie them one by one. There is no other way.

Secondly, any team reform is a gradual process. Apart from the issue of interests, the team member capability model, work process, and work habits all need to be guided step by step. Any rash action will lead to group rejection (if we regard the organization as an organism).

So I will give you a checklist and follow this logic to find the factors that affect growth drivers "under the water" of the iceberg.

Hopefully your organization will be able to transition to a data-driven process as well.

Data acquisition is the continuous empowerment of the business by the entire team and multiple systems, and usually we only see data analysts.

1. What should you think about before starting data-driven

1.1 Why Data-Driven

American scientists conducted a thought experiment: they scrambled the Rubik's Cube and gave it to a blind person to restore it. Assuming that the blind person is immortal and does not need to rest, and that he turns the Cube once per second, how long would it theoretically take him to restore the Rubik's Cube?

The answer is several billion years, which means that from the Big Bang to the present, it will take several billion more years for this to come true.

If we add a variable - every time a Rubik's Cube is turned, someone gives him feedback, telling him whether he is closer to the goal or further away from the goal, how long will it take for a blind person to solve the Rubik's Cube? The answer is two and a half minutes!

This thought experiment reveals a secret: iterative feedback is a powerful universal law.

The purpose of digitizing our data is to make all our strategies visible and to quantify the results. This means that every time we turn the Rubik's Cube, we know whether we turned it correctly or incorrectly, which can increase the speed of iteration.

1.2 What can data-driven do?

Data-driven means that the results can be quantified, and the overall business can be quantified. Data can only tell you the current situation, just like a patient goes to the hospital for treatment, and the doctor tells you that you have high blood pressure, but he cannot prescribe antihypertensive drugs for you. If we compare the human body to a business, data-driven can only tell you the current status of your business, and it cannot tell you the reasons for this status.

Of course, if your data base is very large, you can find the correlation between strategy and results by making some strategies and making some modifications and iterations. However, we still do not encourage you to do this. It is better to be data-driven and do user research and demand analysis.

So data-driven can only do the right thing and turn the Rubik's Cube correctly.

In fact, our business is much more complicated than turning the Rubik's Cube, because the implicit assumption of turning the Rubik's Cube is that the wrong and correct information feedback itself contains the strategic solution. That is, if you don't turn the Rubik's Cube in the wrong direction, you will definitely turn it in the right direction.

But in most real-world situations, the actual state feedback will not give you a direct solution. (I will write another article about the complexity of this kind of edge variation.)

But doing things right over the long term can greatly increase the probability of doing the right thing.

Our ultimate goal is to do things right, but this is not the inevitable result of data-driven business. Data-driven business is the basis for doing the right things.

1.3 Is your business data-driven?

Before starting data-driven development, you need to understand that you need to think about three questions to see if your business can be data-driven.

This leads to our second chapter, three data-driven questions.

• The first question is, is your industry a growing industry?
• The second question is whether your business has a large number of users and commercial value, and whether the data-driven value can support the team costs.
• The third question is whether your business can be broken down into multiple independent small closed loops.

2. Conditions that data-driven development needs to meet

2.1 Growth generates strategy

Question 1: Is your industry a growth industry?

The number of users and data is the cause of the strategy, not the result of the strategy.

Many bosses think that the current business is not growing, so if I look for growth talents, will this solve the problem? This is what I mean by treating the symptoms rather than the cause.

First of all, you need to think about whether the industry is growing. Even if you put Zhang Xiaolong in the education industry, it would be difficult for him to grow. Let alone Zhang Xiaolong, even if Bruce Xiaolong or Lee Hsien Loong came, it would be useless.

So the bottom line of growth is that your business could have grown through existing channels, or by finding new channels to convert users.

Originally, users have needs but have not found channels, or the external environment makes users more and more. The first ceiling of growth is how many users there are in the market. However, many bosses do not think clearly about the big logic. They just go find people to acquire customers. They think that as long as I have a strategy, I will have users.

According to this example, if I invite Zhang Xiaolong, there will be growth, but it is not certain.

2.2 Organizational structure only exists when there is value

Question 2: Does your business have a large user base and commercial value, and can the data-driven value support the team costs?

Next, the first explanation is that you estimate how many users there are in this industry. The larger the number of users, the greater the value you will generate through optimization, and the more salaries and positions you will be able to offer.

The size of your business determines your organizational structure. If you have tens of millions of users every day, it is only valuable for you to develop a data-driven algorithm and strategy. If you increase your ARPU value by 1%, your user base will be so large. The value you create in a year is enough to support your algorithm engineers. The income they create may be far greater than their salary (usually this is the case for companies with large business volumes). If your business ceiling is small and there is no possibility of a large number of users, then you do not need to be data-driven, because this team and these talents cannot create this value, which means that this business cannot support such a team.

If you still have questions, you can read this article: Which type of company is suitable for the non-embedded analysis tool Growing IO

2.3 Business can be split into independent closed loop iterations

Question 3: Is your business one that can be broken down into multiple independent small closed loops?

Data has always been serving business: traditional enterprises use financial data and long-term business results data for business analysis, which is also data serving business. So from this perspective, it cannot be said that traditional enterprises are not data-driven.

The essence of Internet business is online: Today, Internet business is data-driven. The fundamental change is that the main process of business is online, business actions are online, and new features such as rapid iteration and emphasis on traffic are derived. Because all user behaviors are "online closed loops". Secondly, it is best that the systems that support your business are all online so that you can divide the business into independent closed loops. Apart from the number of users, you also need to consider three factors:

1. Large SKU volume: To put it simply, large SKU volume means content distribution and strategic recommendation. If your business has very little content, it will be difficult for you to find the meaning of dataization. It is mainly through dataization that leverage is generated through efficient matchmaking transactions. You must know that content also conforms to the power law distribution. Category management and content supply are very important parts of "growth hacking".
2. High transaction frequency: The transaction price and transaction frequency are inversely proportional. The higher the price, the fewer people will trade and the lower the frequency. The more you rely on the sales team. The higher the transaction frequency, the more user feedback you will get. True user value = number of active users * average transaction volume of the account.
3. The feedback cycle on the supply and production side is short: that is to say, the supply of demand must also be able to iterate quickly, because the iteration speed of the supply chain determines the "content" you can provide and the user value. Only in this way can rapid iteration generate greater value.

3. How to enable the team to start data-driven

In general, we will explain step by step how to make your business data-driven from five aspects: data, workflow, product architecture, organizational division of labor, and organizational mobilization. We will first talk about how to data-driven your business short-term needs. Several business parties will be involved.

If readers feel that they have no say in promoting several business units at the same time, I will talk about how to make the internal team data-driven.

3.1 The core logic is matrix division of labor

Because your business can be divided into multiple small closed loops with independent iterations, it means that your core indicators can be divided into many independent small indicators and distributed to various teams. This is the logic of reductionism. My big system can be divided into small systems. The sum of my small systems can be equal to my big system. If my small system grows, then my big system grows.

So let's look at just one indicator as shown below:

Facebook split its business into more than 200 independent closed-loop iteration teams

After splitting into a single indicator, a team is assigned to this indicator. This team generally does not rely on external iterations, taking into account that some software development systems are not developed by these engineers.

But it is definitely possible to independently undertake a demand. We can see that this indicator includes data analysts, engineers, product managers, and designers, so when they accept the demand, they can do demand assessment or demand iteration by themselves without relying on "external resources". The more supporters you include, the greater the possibility of your data-driven failure.

Let’s look at the team matrix for multiple metrics.

Indicators, roles, and departmental relationships

When you distribute multiple indicators to teams, you form a matrix of indicators and management.

Each indicator is driven by horizontal positions to drive its growth.

Note that we are talking about positions here, because when there are many indicators, there may not be enough natural people, but positions must be designed according to indicators. If your business is large enough and each indicator can support a team, then there will be one under each position.

It’s the same question I mentioned above. The number of users and the value of users determine how many people can support your team.

You may not understand how to divide it here, but you just need to know that you can build roles horizontally according to indicators and manage vertically. There are many other ways to divide it, which we will explain in subsequent articles.

3.2 The first priority for those who succeed is to find a replacement

No matter how much you want to be data-driven, the people in the small team mentioned above are indispensable. After finding the right people, you can do a good job in a direction or department. After all, managers can't roll up their sleeves and do everything themselves. They will be exhausted in the tedious daily life. So it is very important to find the right people. The second thing is what I said yesterday.

1. What does he do in business?
2. Where is the boundary of your cooperation?
3. Where is the limit of this person's ability?
4. From what perspective should this person be assessed?
5. How to judge whether this person is capable?

These issues need to be thought through clearly. So since finding a substitute is the most important thing, let's start with finding someone.

3.3 Key points for starting data-driven

We believe that recruiting people is the right thing to do. So what should recruited people do? We have summarized the following six areas. From data, workflow, product architecture, and organizational division of labor, only when these four areas are done well can data-driven be achieved.

3.3.1 Data availability

Data accessibility is the foundation of data-driven. If we cannot even obtain data in any business dimension, then this business dimension cannot be data-driven. Usually, the industry calls this team a data warehouse team. The core of the data warehouse team focuses on "data-driven decision empowerment" and "data-driven product growth".

The ability to obtain data is not simply reading and displaying, it is a system architecture for obtaining data. Many managers take it for granted that they can just find someone who can write SQL to obtain data.

However, this will cause your data acquisition to encounter bottlenecks at some point in the future. The faster your business develops, the faster this bottleneck will come. My suggestion is to have someone responsible for the construction of the data storage system and the early lightweight data extraction work.

Even in the initial startup phase, there must be a corresponding data architecture to meet the needs of obtaining data. Think about the final empowerment of the business side from the six dimensions of "data collection", "transmission", "storage", "processing" and "application". There is an initial team data empowerment architecture, and the entire data empowerment architecture will be gradually enriched from these six dimensions in the future.

The cost, scope, and category of data acquisition depend largely on the data system.

Most of us feel that the cost of data analysis is too high. To a large extent, this is the iceberg theory. In fact, the data acquisition architecture under the water surface is not well done and cannot provide a low-cost data acquisition solution.

What the initial data team does

At the beginning of the business, we provide more in the form of reports. For example, when your data warehouse team is just established, the business is in the initial development and in the initial stage of development. The composition of your personnel is in a running-in period, and the business is actually in an exploration period. Therefore, the data warehouse team actually provides more reports for you.

For example, in the beginning we may only need to focus on traffic data and business data, as well as the relationship between them. We can first link traffic and retention to know the value of traffic and the current product retention situation. When the business develops to a certain stage, we will slowly start to build data related to security experience.

In fact, it is gradually iterated with the development of the business, and there is also a change in the entire focus. The entire construction of the data warehouse will also be gradually iterated. So you have to pay attention to your key business . At a certain stage, what is its key business?

This corresponds to our key data source , because you know what you need, then you know what to collect. For example, there are tens of thousands of tables for products and R&D, and we cannot collect all of them into the "data warehouse", so you must have a certain scope. So here we actually use key business as a starting point to collect the corresponding key data sources.

At this time, we also need to standardize the management of metadata . The data warehouse produces a table, and the comments (description of each field) of the table are empty or inaccurate, and the characteristics of your table are also inaccurate. So when data analysts or relevant students use it, they find that what you do and what you produce are of little value.

Because the entire data is not very standardized, people don’t understand it. For example, there are many ways to name an order, and many business lines have records, and many tables have the name of this field. There are five or six fields, but people don’t know which one is the order field. In fact, this is a very painful point, so metadata normalization must be done in the initial stage of the data warehouse.

For the business graph, the data warehouse team must first understand the business before they can build the corresponding data and indicators. So when we first place an order, for example, we will first go through the entire transaction main link process, from the beginning of issuing and receiving orders to the completion of the entire link payment. We sort out the entire main link, and then for each main link, what are the specific business processes in it? In fact, this is how the data warehouse team sorts out the entire business graph, and we can extract the key points from it.

So this is business coordination. In fact, it is through this level that students in the data warehouse can better understand the business and understand what data can do from the perspective of the business and the user.

Then unified demand control is also very important in the initial stage.

Everyone talks about chimney-style construction. In fact, chimney-style construction should be viewed from two sides. It is not that chimney-style construction is bad, especially in the early stages of business development. Its verification-style construction can actually iterate and develop quickly if your entire standardization and many of your processes are actually OK.

In fact, chimney-style construction is still within a controllable range, but at this level we have to control the overall demand. In fact, it is OK to have some appropriate redundancy, because at this time, the caliber of our relevant data is uncertain, and the business is not clear about what our caliber is. In fact, we are also in a process of exploration.

This requires a unified indicator system . The unified indicator system is a very painful point for all data teams, or for our users. In fact, we will talk about it later.

So in this initial stage, the core focus is on these contents when they reach the development stage, the collection team development stage. At that time, our collection team looked at the ability of people and the coordination of the entire team. We already had a certain tacit understanding, and at the same time, we also had a certain amount of precipitation and accumulation in the development of the business. So in this, we will help users to do some corresponding analysis and apply some application-type products.

So at this level, for example, in the initial stage, we are more about helping users to quickly view data and make decisions, so this is mainly based on core reports and dashboards. When you reach the development stage, users need to do some refined operations, so we have to provide some related analysis products, as well as some strategic diagnosis and evaluation products.

3.3.2 Indicator decomposition capability

Can understand the business, provide feedback to leadership, calculate benefits, and weigh needs

If we have the ability to obtain data and have basic analysis of users, transactions, and customer acquisition channels, we will break down indicators for the business. The channel side should have clear traffic data for each channel, including business data brought by each channel, such as GMV, etc. Data that can be used to evaluate the value of the channel.

On the transaction side, you can see retention, activation, active composition, and transaction categories; on the user side, you can see high-value users.

This process requires someone who can break down business indicators and has the ability to do so. However, it is recommended that core management should try to break down the indicators. Or they should be able to quickly understand the logic of this breakdown. Breaking down indicators is mainly to have a rational data and "dose" understanding of the main influencing factors of the core business, rather than an emotional one, such as knowing that it has a great impact.

This can help leaders see the business more clearly. At the same time, I have found from my work experience that many leaders want to see numbers, but in fact they don’t understand the previous link, that is, they are not very clear about which indicators they should see and what they reflect. As a result, every time they are given data, they still feel that the data is not enough. But they can’t say what is enriched.

The last logic is that once you have data, you can evaluate the conversion rate of a function. You can then calculate the revenue, and the data evaluation can estimate the users of this demand. With the revenue estimate and user value, you can weigh the priority of the demand. So you have a basic data-driven environment.

3.3.3 Requirements Development Process

Everything starts from the source. Most of the core values ​​of Internet companies are to convey value to users through online products or software products. Then the quantitative management of demand is the real beginning of data-driven.

If the previous two steps: acquiring data capabilities and breaking down data capabilities are like cleaning the house, then starting with data-driven quantification of needs is truly like welcoming guests.

That is, the subsequent new requirements will be determined by quantitatively weighing priorities to determine which functions to develop first and which functions to develop later. This will truly achieve data-driven, effectively weigh priorities through quantification, and gradually relieve business pressure.

At the same time, it can motivate developers to a great extent and reverse manage the business side. Here I want to prove why the business side should put forward requirements and write requirement documents. I have worked in small companies before. These companies often have one-sentence requirements, which are different from truly complete requirement documents. The difference is not in the number of words, but in explaining the problem clearly. We believe that writing documents has the following benefits:

1. It is helpful for the business side to organize the demand content. Writing itself is a kind of thinking and reverse output, so in the process of writing, it helps to organize the business side's ideas. The demand background, the target users, the current situation, the pain points, so what functions to do, the problems to be solved, and the estimated benefits can be well sorted out and thought out.
2. It is helpful for the business side to define the scope of requirements. Usually the business side will frequently change the requirements. In addition to not sorting out what they want, the usual situation is that the two sides have not reached an agreement on the scope of requirements. There is a deviation between the business side and the product side in the functional scope of the solution. Therefore, writing out the process and general rules and functions will help the product manager and the business side to quickly reach a consensus on cognition.
3. It helps product managers understand the needs of the business side. Even if the business side determines what they want, there may be deviations over time. And if the needs are verbally stated, the product manager needs to be forced to remember them. Such communication is very inefficient.
4. The existence of the document itself is valuable. Whether the requirements are passed or not. For the requirements that are passed, the subsequent product manager will know what requirements were iterated under what circumstances before. At the same time, the demand side can also understand which user requirements have been met and to what extent. Newcomers know which requirements have been rejected in the past, why they were rejected, and whether the conditions are not met now, so they don’t have to waste time raising them again. Or if the conditions have changed, they can also think about the requirements that were originally rejected.

Many people would argue that the business side is too busy to write requirement documents. My view is that once a requirement is initiated, it has to go through multiple stages involving personnel such as product, design, R&D, testing, data, etc., which takes up the time of these personnel. Compared to the cost of these personnel, describing the requirements clearly and quantifying them is actually a way to improve efficiency.

There is a saying that people who raise wrong demands are better off not raising demands, because it still takes up resources. It is better to pay such people and do nothing than to raise demands.

Secondly, if a requirement is not worth writing, it is basically not worth developing. Because the amount of writing for each node increases exponentially, from the requirement document, to the product requirement document, and then to the code.

Finally, it is not recommended to ask the business side to quantify the requirements document right away. It is better to have the assistance of product and data analysts. Note that it is assistance rather than writing. After the product and data analysts fully understand the requirements, they can give the business side some writing suggestions on the fixed document format, including data extraction and some suggestions on which data to use to verify the requirements. The ultimate goal is to allow the business side to independently complete the verification of data extraction and independently write the requirements document.

3.3.4 Product and R&D divestiture

If the first three items are basically met, then the fourth item is a logically inevitable result. If your demanders can quantify their demands, you can quantitatively evaluate the demands. After the evaluation, there must be products and development that can meet the demands, and at the same time, data monitoring of these demands can also be done well.

Therefore, if you want to be data-driven, it is best to make corresponding changes to the organizational structure. The core idea is to let operations and business needs and long-term user value needs go through two stacks, and gradually realize the division of labor in a small closed loop on the R&D side.

We believe that indicators, functions, and corresponding development are related. Of course, this is not absolute. But we try to make them independent closed loops (although there may be some connections), but they are generally independent in trend.

The overall segmentation logic has been explained in the section 3.1, where the core logic is the matrix division of labor. I would like to make a statement from another perspective. The general idea is to bring together marketing-oriented functions such as landing page tools, operation engines, delivery engines, message reach centers, etc., which are more inclined to operations and sales, into the growth product R&D team. Another category will be inclined to the long-term construction of user value. Let’s take e-commerce as an example, such as categories, products, and store management, and those that are more inclined to core values ​​will be the responsibility of another R&D team.

Of course, the most important thing in this process is to plan the product architecture diagram with the R&D leader and the product leader, because only with the architecture diagram can you know which functions can be merged and given to similar development and product teams.

From a data-driven perspective, the core is to prioritize quantifying business needs and the results after the needs are put online, because the scope of needs usually involved by business demanders is limited.

Of course, they will also put forward demands that are biased towards long-term user value. In the book "The Light of Operation: My Internet Operation Methodology and Confession", the author said: The product team is responsible for defining and providing long-term user value; while the operation team is responsible for creating short-term user value and helping the product improve long-term value. In terms of team division, the business side's demands for short-term iterations are basically much higher.

3.3.5 Team Collaboration Tool

How teams collaborate to drive demand realization.

If the first four items are met, the business side is willing to use data to quantify requirements, and product development is willing to undertake these requirements. Then the remaining question is how to transmit the requirements through the system from beginning to end to the state of demand synchronization, and how to synchronize information between teams. This involves tools for team collaboration, which include but are not limited to the following:

Requirements management tool: mainly responsible for recording the requirements documents proposed by the business side, including the status of the requirements after they are subsequently launched.

Document synchronization: product manager requirement documents, R&D documents, data documents, etc.

I will not go into details about IM tools, email tools, R&D demand follow-up tools, test management tools , etc. In short, the management tools should follow the principle of minimum availability. Secondly, the team should use similar systems to communicate as much as possible, and merge them if possible, so as to reduce the threshold of information dissemination to the greatest extent.

In a medium-sized company I worked for before, I found that some people in the company were used to using QQ, some were used to using DingTalk, and some were used to using WeChat, which made it difficult for the team to find each other. The demand UI was maintained on Tower, and some people maintained the product on Excel, while others maintained it on ZenTao. The demand was scattered, so of course it was impossible to achieve a unified review.

Therefore, data-driven can make everyone's information consistent as much as possible. At the same time, the quantification of requirements and a good review process can improve the team's work efficiency. Don't think that this process-based approach is inefficient, and it is far less efficient than the business side directly pulling the product and R&D development. However, this process can ensure that valuable requirements can be continuously developed first.

Walking correctly and steadily is more important than walking fast.

Once the process is in place, the entire team can move quickly and steadily through their familiarity with the process.

3.3.6 Organizational Capabilities

Data-driven development involves many departments and requires extremely high organizational mobilization capabilities

Finally, we will find that promoting data-driven teams requires cooperation from the demand side to products, UI, R&D, data engineers, and analysts. So logically, according to the matrix management method, we will find that this person must be able to influence or manage: demand side to products, UI, R&D, data engineers, analysts and many other departments. This means that the higher the position, the easier it is to promote this matter.

This can be done because it can separate some personnel from the group under each director to form an independent small closed loop for growth or business.

Next, let’s talk about what happens if you don’t have such great administrative power but want to influence your team to be data-driven, or to put it more bluntly, you want to be more professional and at least quantify your data to improve your workplace value. You only need the support of two people, or just one person.

Then you only need an engineer to accept your quantitative needs and a data analyst to help you extract data.

However, whether this environment is feasible depends largely on your relationship with the team and whether the team management has such space. In extreme cases, if there is no data analyst, if the engineer is very cooperative, he can also help you obtain some business data, but the problem is that because there is no tracking tool for the launch, you still have no way to quantify the demand for new users.

But you can analyze the users on the product first. At the same time, you may not be able to analyze the relationship between behavior and business data without tracking tools. In this case, the best way is to learn data analysis skills, make some achievements through this small team, and switch to a mature company as soon as possible.

Finally, let’s summarize the six reasons why teams cannot be data-driven. They are logically related. If your company team cannot be data-driven, it is not possible to make your team data-driven by simply finding a growth officer or an analyst. It is a systemic problem. Only when every link is empowered by data can the final business be put on the data track.

This process is like unraveling a ball of thread. You need to see the crux of the problem as a whole, and then understand which thread to untie first and which one to untie later . It is useless to directly use scissors or untie the largest thread (the biggest data-driven sticking point)!

The difficulty lies in planning the path and breaking it down step by step. We must believe that each effect is caused by a cause, and this cause is caused by the previous cause. We must find the cause layer by layer and solve it step by step. So we follow the logic and follow the following data-driven method:

• Step 1 : You need to have data and be able to see the data, which is the basis of data-driven. You need a data warehouse colleague to continuously maintain the data collection and visualization capabilities.
• Step 2 : Once you have the data, you need to gradually understand which data to look at, what their changes mean, and what the relationship is between them. These can be broken down by the growth product manager or product manager in the early stage, and analysts can continue to maintain them in the later stage. Of course, if you have a data analyst at the beginning, that's also good, but you must hire a data analyst after the data warehouse is basically built, otherwise he will not have any data to obtain.
• The third step is to gradually quantify the needs and the effects after going online, evaluate the priority of needs through quantification, and schedule resources through quantified needs. Therefore, you need to centrally review and manage needs.
• Step 4 : To respond quickly to the business side after the requirements are reviewed and approved, a separate stack is needed to solve the business side's needs. This can quickly achieve the quantification of requirements and the quantification of effects. Secondly, after all, the business side has worked hard to write the document, and telling him to wait for the schedule will greatly undermine the overall driving force.
• Step 5 : How do you work in this process? You need to lay out tools for everyone to collaborate on information before starting the demand, including tools for managing demand from beginning to end. After completing these five steps, you can basically receive quantitative demand from the business side.

However, all of this is based on the fact that the leaders are aware of the importance of data quantification and are willing to promote it from top to bottom . Because too many departments are involved, the top-down promotion is the fastest.

These five steps are logically deduced from cause and effect. Each requirement to be handled by the next layer is caused by the logic of the previous layer. It is like unraveling a thread. Only when all the problems are solved can the data be driven.

If two cars with speed of light are coming towards us, then according to the relative speed they should be twice the speed of light, but no speed will exceed the speed of light, then this will only be true if time changes.

I quote this thought to illustrate that logical reasoning is inevitable and a pleasant thing. To be a team, you must do logical derivation, right, that is, breaking the stitches.

Author: Arun's Growth Research Institute

WeChat official account: Arun's growth study club (ID: arungrowth365)