Huang Jijia: Using MVP Model to Achieve Developer Growth | DEV. Together 2021 China Developer Ecological Summit

content source: On June 5, 2021, the 2021 China Developer Ecological Summit hosted by SegmentFault came to a successful conclusion. At the meeting, the head of the developer market of the Google platform and ecological business group delivered a speech on the topic "Using the MVP Model to Achieve Developer Growth".

Sharing guest: Jijia, Google Platform and Ecological Business Group Developer Market Leader

shorthand compilation and release: SegmentFault Editorial Department

Good afternoon everyone, I am glad to hear your sharing. I am Huang Jijia from Google. I am very happy to have the opportunity to gather with all the classmates who are doing developer ecology. The topic I shared today is "Applying MVP Method to Achieve Developer User Growth". It was a bit nervous to talk about MVP behind Teacher Liang Di, but the MVP I talked about is not Microsoft's most valuable expert, but the smallest viable product.

Let me briefly introduce myself. In fact, developers, products, technical evangelism, marketing, or operations should be involved in these tasks. In three companies: Google, Microsoft and Green Lemon Network, I hope to share my thoughts and feelings from my previous work with you. . After all, we are the topic of MVP, this topic will actually iterate and change gradually.

The content I want to talk about is mainly divided into five aspects, basically from the developer ecology, the challenges facing developer growth, the method of applying MVP, how to avoid pits, and some insights on the road.

The challenge of building a developer ecosystem

First of all, I want to share with you the developer ecology. Boss Gao also shared a perspective in the morning, that is, from the perspective of the team. We actually have many perspectives, such as developer relationships, developer markets, team composition, and so on. What I want to introduce is the perspective of developers using the product.

On the far left are developer tools, that is, developers use these tools to build software. You can first put the developer ecology in the boundary of software. Your product is software, and we have development tools. The second is developer services, that is, the services included in developer software products, including Alibaba Cloud, including some online service vendors. The third is an open platform. Where is the developer’s software released and where users can use it. This is an open platform. Finally, there is an application store, which can help developers easily realize their cash and distribute software and applications to end users for testing. This is the four directions of the developer's software products facing the ecology.

The challenge of developer growth

What is the biggest challenge? Perhaps each dimension has its own challenges. The most unified challenge is the growth of developers. You can also see from the research report you got today that the biggest challenge in this aspect of the ecology is the growth of developers. So today, I want to share the challenges we face and how to deal with the growth of developers.

What are the challenges facing developer growth? We can summarize it in three parts.

first one, the fragmentation of the technical community. We also saw in Jinyu’s sharing just now that various technical communities are constantly developing, and there are also different technical products for developers to use. So this is the first question, how to make the endless technology available to developers?

second, the developer is naturally opposed to being marketed. He does not want to be the target of marketing, he has to choose trusted products or services to use.

third is unsustainable growth. developer may soon use your product or service, but if the developer fails to provide a good service for various reasons, he may give up using your product or service.

This is the variety of challenges we see. These challenges are also changing every moment. How to deal with these ever-changing challenges?

Apply the MVP method to achieve developer growth

Students who are doing product or development may be very familiar with this concept. In 2011, the concept of "minimum viable product" was born, that is, through trial and error and iteration of the MVP method to continuously meet market needs and fail quickly and cheaply, which is the most important. I think this is the same as the growth mindset shared by Teacher Liang Di just now.

Many companies now use the MVP method to iteratively push their products to the market when they are polishing their products. Then I have a thought, that is, can we use the MVP method to iterate the developer growth engine to make developer growth more efficient, more in line with market challenges, and to meet our business goals. So MVP can solve two problems. In addition to Microsoft's most valuable experts, there are two other problems. Let's see if we can solve them. first developer experience. If the developer's experience is not good, no products and services can be talked about, so we must first see if we can use MVP to solve the developer's experience problem. second is team growth. The execution of each of our projects and the reach of each developer requires teamwork and teamwork. Then how do we use the MVP method to iterate the team and let the team grow? This is also very important, and everyone in this room A very important piece that can grow. So I want to share my thoughts with you from these two aspects.

First look at the developer experience. Developer experience is the experience for developers. The services, tools, and content we provide to developers need to have a loop or closed loop around the developers.

The first piece is awareness (awareness) . To let the developer know that there are so many choices, if he doesn't see you at all, then it's impossible to talk about the introduction or let him use it. The second is adoption (adoption) , it is very important that it can be used in the production environment. The third is advocacy , he can spread like MVP, spread like Microsoft's most valuable expert, to support this product and service. These three blue circles are very important. They are the north star of the developer experience improvement, and are also what we need to pay attention to as the operation team and the developer service team.

For detection, what we need to pay most attention to is interaction . Does the developer interact with you? This is the North Star. Has the developer adopted your SDK and service, and what is the most important North Star? It is share , which is how much your share is in the same service in the market. I think every member of the team needs to think about this question: What is the share? The third is to support, so that developers can support. Under what circumstances can developers support it? The developer must have made money, because the developer, as a person or a group of people, his business logic and thinking logic are actually the logic of the enterprise-he must be able to make money, and then the entire revenue, There must be continuous income. If you publish something, the developer has been losing money, it is impossible for him to support you, or just short-term support. These three are the North Stars that I think are very important.

How to solve these three problems? I can share a case. The first is how to do awareness. Polaris is interaction. How to do more interaction for developers?

The first is the iteration of content, because it is very important to reach developers who need content. We are not letting developers be marketed. We need to provide valuable content. What is valuable content? The initial starting point for MVP should be the release of the product. This product may have different functions, it may be an iteration of the product, or it may be a different product. The first and most basic thing is the release of the product. In addition to product release, we need to iterate on the content provided to developers, including product release plus technical details. For example, there are hundreds of products and hundreds of features. Is there a product release plus detailed explanation for every feature and every product? Actually not. You need to see which ones are used by the developers, and which ones give you more and more positive interactive feedback. Only then do you invest in detailed technical explanations. Going a step further, after we have finished the technical explanation, the third one is sharing by developers. Should tens of thousands or hundreds of thousands of developers be allowed to share with each of them? Not necessarily. You find the most important point and let the developers share it. This is also the more important function we have seen that can complement the technical details. Let developers do sharing, but also be targeted. This is the content iteration aspect.

The second is form. Content needs to be presented in a form. What kind of form is preferred by the developer and can enhance the developer's experience? The simplest is graphics and text. Every developer may receive a variety of official account pushes. For example, there are many graphics and text content in emails. And we have also made some new attempts on the content of graphics and text, such as turning graphics and text into a gamified way, such as introducing the new features of Android 11, which are either big words or new features. We need to let developers go Interaction is like answering a question and asking the developer to click. Maybe the green one is correct, if it is red, it is wrong. This is an interaction. We also give some small incentives to the developers who participate in the interaction, which can form a viral spread. This is the second form-the gamification expansion on the content. The third one is concomitant. Now that there is a lot of content and gamification has been done, can it be accompanied by it? In fact, sound is very important, and sound is accompanied by it. No matter when developers are commuting, before going to bed, or when they are eating, they are provided with content in an accompanying way more comprehensively. This is the form iteration of the content.

Third, and very important, is the choice of channels. We have packaged the content of developers in different formats, so what kind of channels can we use? Do we have to use all channels and send all the content directly to the developers? If it’s free, of course, it’s okay, but our team’s resources are limited, whether it’s human time or the team’s budget, etc., so we need to test which channel has the highest acceptance of our content. At this time, just like the new crown vaccine, several phases of trials are required. In the first phase, three developer cases were put into the same channel, and a phase one clinical trial was conducted. After the feedback data on WeChat and Weibo, it was found that the third was not working. The first two were very good, so after WeChat and Weibo , Posted this content to Zhihu, Sifei, Nuggets and so on. Then in the second phase of the clinical trial, it was found that one story did not perform as well as the others. If we need to continue to produce other videos, do we need to select the one that performed better? So in the third phase of the trial, another one was eliminated. Finally, we saw that at station b, especially when the production cost was high, we finally chose a case of Mihayou, which is the developer of "Original God". So this is after several phases of trials, we are able to choose between channels. These are a few thoughts and attempts we have made in awareness.

The second one is adoption. Developers must use your content, use your services and tools, this is very important. The core indicator is share. Whether you can stand out among other choices is very important. How to do this?

I also give an example, which is an attempt made in Google's Flutter project. Speaking of shares, the first one is whether the tools you deliver to the developer are usable. This is very important. If he has no chance to use it at all, then it definitely won’t work. Of course, because Flutter has mirroring problems in China, etc., we have extra work to move it locally so that developers can use it more easily. Available is the most basic. After it is available, we can do tests as before and do several trials. In the first stage, we have the Chinese version of the learning materials and the Chinese technical documents. Of course, there are also various localized materials in other countries, such as South Korea, Japan, Indonesia, and Vietnam. But if we are doing developer services now, we actually have to look at the world, and I believe everyone is also looking at the world. Then, whether the resources you invest in the global market need to be tilted or reduced, you need to pass the first phase of the test, and use the feedback results to determine whether you want to increase investment in this market. Therefore, we see that China’s share in the global comparison is growing very fast, so we decided to make the second phase of investment, such as participating in the developer conference, holding workshops, supporting community activities, and so on. These require a lot of resources, including human resources, supplier resources, budgets, and so on. These are the stages of the growth of Flutter's Chinese developers. We can also iterate our final regional decisions in this way. Of course, this is a country and a country. In fact, each province and each region is the same concept. This is an introduction organized by my team. Flutter has a lot of apps already in use now, more and more.

Third, if the developer knows your product and uses it, it is very important whether he can support you and speak good things for you. The most important core here, the North Star is whether the developer has made profits or made money.

This revenue used income, and revenue was useless at the time because the developer ultimately wanted net revenue. It's not that he made 100 yuan for your service, 90 for recruiting people, 20 for other operating costs, and the final income is negative 10 yuan. This is not good, he must have a positive income. So I use income when translating. So how can you make developers profitable, and how can developers use your products to create value for themselves-we have made a project called Google Play Growth Star. We have recruited about 200 developers across the country as seed users. We have done many offline activities for these developers, such as workshops, and we have also given them many opportunities to try new features. We hope that they can use these features to gain benefits. . In the background, we can actually see the developer's income, and we can collect feedback from developers through countless activities. There are two aspects to these feedbacks. One is on product features. We have several functions, these are just a few functions. In these functions, we are also iterating on more than 200 members of the growth star, and then we will screen, and finally find out which functions can really help developers make money, we have to fiercely. Push, we have to support these developers; the last few features that won the service, content, and tools for the developer, must be the one that can make money for the developer. We use this method to bring countless features After screening, I found that developers can use and support you. This way, we can quickly or at the lowest cost to decide which one to push or not to push.

I just talked about the developer experience, let me talk about the thinking of team growth, because every member of the team needs to grow.

When thinking about this question, I think the most important thing is what the original intention of each team member is and why they work here. I think that for everyone, not just the developer growth team, including the product team, and the operation team are the same. It is an M and a C—M is meaning, it must be something valuable and meaningful. I believe that everyone here should not lack this. It is very easy because we are helping developers succeed. In our team as the developer community, I think it is not a particularly difficult problem. C is connection, that is, there are links, links to different resources, links to different people, and learns the growth of different people, including their own growth.

There is also a framework called MIC. The I in the middle refers to your 160de88404006f impact (impact) impact of your work has changed or improved. There is a foreign framework that uses MIC to explain the original intention or motivation of each team member. Of course, we also did an iteration, and iterated impact into improvement, which means grows . Does each member of the team have growth? Not only do meaningful things, valuable things, and influential things, but also grow. This growth corresponds to his personal growth, the growth of the work itself, and the value Growth. The third meaning of I is innovation (innovation) , in fact, everyone loves innovation, whether you can give the team more opportunities to try innovation, I think this is also very important.

To sum up, MIC is also a microphone. It is to allow everyone on the team to have their own stage, to have a space for everyone to do meaningful things, do valuable things, do things with more links, and continue Growing ground, there are continuous opportunities for innovation.

How to mess up developer growth

In addition, I also thought about how to avoid pits. Why do I think it is important to avoid pits? Mr. Charlie Munger once talked about "reverse thinking", which is a way of thinking that he admires very much. Charlie Munger is 97 years old, one of the richest people in the United States and Buffett's best partner. He mentioned a slogan-"invert" (reverse thinking), which is the logic of his investment. I think each of us can use this logic to think about the growth of developers. Corresponding to the growth of developers is how to screw it up. If we don't do the screwed up thing, then the result should be okay, even if it doesn't grow, it won't fall down, right? Here are a few thoughts:

first one for self-use and self-use. If the product or service you push to the developer is useless by yourself, it is actually difficult to convince others, so this is very important. Let me cite a joke, that is, one of my classmates became a doctor after graduating from Beijing Medical University, and later he became the person in charge of eye surgery equipment, but he still wore glasses himself, and then I asked him "when do you do it?" I said "do it next year" and I said "Okay, when you are done, I will definitely go there too." This simple joke is to tell everyone that they must be used by themselves and then push to the developers. This is convincing. If you are useless, how can you make developers trust you? This is the first dimension. The second dimension is that you will find many problems when you use it yourself, and you will give a feedback to the product group. Did he really pass all the mines? If you don’t use them, you don’t know where the mines are. , Then the product you deliver to the developer must also be problematic. So I think everyone in this room who is doing developer growth must ask the internal team to use it, and then record the developer's experience process and give feedback to the development team.

second is output vs outcome. What is That is, you may do a lot, each time there is an increase in the amount of work, but it may not be valuable, there is no outcome, which is very terrible. So when measuring your work, you must measure the outcome, not the output. It's not how many Weibo posts or newsletters you post, etc. You have to look at the outcome. What is the outcome? I actually mentioned a few points just now, that is-what is our North Star? Is there enough outcome in the North Star indicator, including the improvement of the outcome?

third one, know and act. We found a lot of new cognition, new knowledge, and new information from the developer's community survey, but we did not apply it to our actions. This is very problematic. There are two scenarios here. The first is whether we are doing developer interviews, surveys, or questionnaires. When designing problems, we need to think about whether this problem can be transformed into our own actions. In many cases, the content of our research is not just the developer ecology, but various To B and ToC. If the results of this research can guide your actions, you have to ask yourself. Otherwise, the developers are also very busy, because I have seen a lot of questionnaires, especially for developers, it may take half an hour to answer, this is actually not good for developers. The second point is whether we can transform our knowledge, feelings and thoughts into actions. This is very important.

The main content I shared today is probably that, because MVP is actually iterating gradually, including every content, every North Star, and every method. I have a WeChat public account "plus one to go to sea". In the 16th issue, I talked about MVP from a product perspective. If you are interested, you can also pay attention to it. Finally, I hope everyone can discuss more and give more feedback.