But the nature of user growth is to trade redundancy of testing for certainty of growth, so a lot of testing ends in failure, following the logic of the failure hypothesis, and very little of it ever comes out on top. However, the HVA bootstrap logic done by the user growth team is also a product feature that needs to be implemented by the product team. At this point, instead of designing the product main framework experience, we design the entire HVA boot logic according to the user growth methodology. Because people have different underlying thinking logics, work habits, and methodologies, there may be some contradictions when it comes to implementing user growth logic through product teams. So how do we resolve these contradictions? It can be solved according to the following logic: if you are doing the product body experience framework, there is no doubt that you should follow the thinking of the product team; But if you're doing HVA boot logic, you have to do it according to the user growth team. In fact, both the product team and the user growth team have the right idea, but without a sound design in the organization, many of the contradictions at the project execution level are irreconcilable.

To solve problems at the level of project implementation is always to press the gourd and float the gourd. Only by going deeper can we really solve problems. I cite some of my previous experiences to illustrate some of the problems caused by poor organizational design. As mentioned above, due to the different fields, the underlying logic and methodology of doing things are also different. When people have differences, they can not understand each other, and they will only feel that each other is unprofessional. In this case, the user growth team is at a disadvantage. Because the development of the product team and its methodology has been very mature, the role of the product team is also relatively recognized. As a new field, many people don't know much about what user growth does, and even think that user growth is to attract new users and acquire new users. Even for teams that are doing user growth, many are still in the groping stage without a mature methodology. As a result, user growth teams often look unprofessional to other teams, because everyone sees things from their own perspective. To do a product, the user growth team is definitely not as professional as the product team; In marketing, the user growth team is definitely not as professional as the marketing team; The user growth team is definitely not as specialized as the other teams for anything other than user growth. In a company, if other teams say the user growth team is unprofessional, they mean something else, which is understandable, because there is specialization. However, if other teams say that the user growth team is not specialized in the area of user growth, then it is worth a careful discussion to see if the experience, thinking, and methodology of the other team qualifies them to make this claim. In the organization design, we must be in line with the idea of professional people doing professional things, through a reasonable coordination mechanism, to give full play to the resultant force. In addition to the contradictions caused by the differences in the underlying logic, methodology and professional fields of work, the user growth team and the product team also have contradictions caused by performance traction.

This happened to me once. As I mentioned before also, if the company to the user growth team with many relatively senior personnel to design, promote growth projects, and give product team was armed only with a relatively shallow senior product manager to handle all the growth of demand, and he only spent about 50% of the energy to do related to the growth of function, That entry-level product manager becomes the bottleneck in the chain. People's abilities take time and project experience to develop, and in this case, even if the entry-level product manager tries to give 100 percent of his or her energy (and it isn't), it will limit the organization's ability to perform at its best. Of course, for the product team, there are all sorts of legitimate reasons for this arrangement. I can only say that I can understand this arrangement, but I cannot accept it. That's why, in Chapter 1, "Organizational Assurance for Growth," I repeatedly emphasize the importance of having a closed-loop product manager in a growth team. No matter which is the closed loop product manager team or user growth from product team BP form the FT, it doesn't matter, because the core product manager is the user growth performance and the promotion of growth to 100%, and the user team performance, determined by user growth, head of the team, take up user growth team blue-chip and promotion places. If a company wants to do well in user growth, product team is very important. Without the foundation and guarantee provided by product team, growth is water without source. However, if you just set up a professional user growth team, without a reasonable design in the organization, it will not produce synergy. With organizational assurance, the user growth team and the product team understand the differences in each other's approach and respect each other's professionalism, so that the synergy can be fully leveraged to maximize growth revenue.