On June 5, 2021, the 2021 China Developer Ecosystem Summit hosted by SegmentFault came to a successful conclusion. At the conference, the head of developer marketing for Google’s platform and ecosystem business group gave a talk titled “Using the MVP Model for Developer Growth”.
Guest: Jijia Huang, Developer Marketing Director of Google Platform and Ecological Business Group
Sort and publish shorthand: SegmentFault Editorial Department
Good afternoon, everyone. I’m glad to hear your share. I am Huang Jijia from Google. I am very happy to have the opportunity to meet all the students who are doing developer ecology. Today I’m going to talk about MVP for developer user growth. Talking about MVP after Mr. Liang Di is a little nervous, but the MVP I’m talking about is not the most valuable expert of Microsoft, but the least feasible product.
Let me first introduce myself briefly. In fact, I have been involved in the work of developer, product, technical evangelist, marketing or operation. I have worked in three companies: Google, Microsoft and Qmoon. I hope to communicate with you what I have learned, thought and felt in my previous work. We are, after all, the subject of MVP, and that subject will evolve and change gradually.
I’m going to break it down into five areas, basically from the developer ecosystem, the challenges of developer growth, the ways to apply MVP and how to avoid pitfalls, and some insights along the way.
The challenge of building a developer ecosystem
First, I’d like to share with you a little bit about developer ecology. Gao also shared a perspective in the morning, which is from the perspective of the team. We have a lot of perspectives on things like developer relationships, developer markets, team composition, etc. What I want to talk about is how developers use the product.
On the far left are developer tools, which developers use to build software. You can start by putting the developer ecosystem on the edge of software. Your product is software, and we have development tools. The second is developer services, which are services included in developer software products, including Ali Cloud and some online service manufacturers. The third is open platforms, where developers distribute their software and where users can use it. This is an open platform. Finally, there are the app stores, which help developers easily monetize and distribute software and applications to end users for testing. These are the four ecological directions of developer software products.
The challenge of developer growth
What was the biggest challenge? Perhaps each dimension has its own challenges. The most unifying challenge is developer growth, and you can see from the research report that we got today that the biggest ecological challenge in this area is developer growth. So today, I’d like to share some of the challenges we face in the developer growth space and some of the ways we can address them.
What are the challenges to developer growth? We can summarize it into three parts.
The first is the fragmentation of the technology community. As we just saw from Jinyu’s share, various technology communities are developing and there are different technology products available for developers to use. So that’s the first question, how do you get all this technology out there to developers?
Second, developers are naturally opposed to being marketed. He doesn’t want to be the target of marketing. He wants to choose products or services he trusts to use.
The third is unsustainable growth. A developer may be quick to use your product or service, but if for some reason they don’t serve the developer well, they may stop using your product or service.
So these are the kinds of challenges that we see, and these challenges are changing all the time, and how do we deal with these ever-changing challenges?
Apply the MVP approach to developer growth
Those of you who do product or development are probably familiar with this concept. In 2011, the concept of “minimum viable product” was born, that is, the MVP method of trial and error, iteration, to constantly meet market needs, and fail quickly and cheaply, which is the most important. I think this is the same as the growth mindset that Teacher Liang Di shared just now.
At present, many enterprises use MVP method to iterate to market when polishing products. Here’s a question for me: Can we use the MVP approach to iterate the developer growth engine to make developer growth more efficient, more in line with the challenges of the market, and thus meet our business goals? So the MVP solves two problems, and in addition to Microsoft’s MVP, two other problems, and let’s see if we can solve them. The first is the developer experience. If the developer has a bad experience, no product or service will be available, so we’ll see if we can solve the developer experience problem with MVP first. The second is team growth. The implementation of every project and the touch of every developer need team work and team collaboration, so how we use MVP method to iterate the team and make the team grow is also very important, and it is also a very important part for everyone here to grow. So I want to share my thoughts with you from these two aspects.
Let’s start with the developer experience. The developer experience is an experience for developers, and the services, tools, and content we provide to developers need to have a loop or closed loop around the developer.
The first is Awareness. There are so many options out there that if the developer doesn’t even see you, there’s no way to introduce or use it. The second is to use it, it’s important to actually use it in the production environment. The third one is Advocacy, which is able to spread like MVP and Microsoft’s most valuable expert to support the product and service. These three blue circles are very important, they are the north star of the developer experience improvement, and they are also what we as the operation team and developer service team need to pay attention to.
For detection, the thing we need to focus on most is interaction. Is there interaction between the developer and you? This is the North Star. Have developers adopted your SDKs, services, and most importantly, what’s the North Star? It’s share, which is your share of the market for similar services. I think every team member needs to think about this question: What is the quota? The third is advocacy, enabling developers to advocate. What kind of situation can developers embrace? The developer must make money, because the developer as a person or a group of people, his business logic, thinking logic is actually the logic of the enterprise — he must be able to make money, and then the whole revenue aspect, must be continuously income. If you’re releasing something and the developer is losing money, they’re not going to be able to support you, or for a short period of time. These are the three Polaris that I think are very important.
So how to solve these three problems? I can share some examples. The first one is how to Awareness, Polaris is interaction, how to make more interaction for developers?
The first is content iteration, because touch developers need content, which is very important. We don’t want developers to be marketed, we need to provide valuable content, and what is valuable content? The starting point for an MVP should be the launch of the product. This product may have different functionality, it may be an iteration of the product, or it may be a different product. So the first and most fundamental thing is the launch of the product. In addition to the product launch, we need to iterate on the content we provide to developers, including the product launch plus technical details. For example, there are hundreds of products and hundreds of features. Should product release and detailed explanation be made for each feature and each product? It’s not. You need to see which ones are being used by the developers, and which ones give you more interactive and positive feedback before you invest in technical detail. Further, after we have finished the technical details, the third one is the sharing of developers. Is it to let tens of thousands, hundreds of thousands of developers, let each of them do the sharing? Not necessarily. You want to find the most important point for developers to share, and this is one of the more important features that we see complementing the technical details. Let developers share, but also have a purpose. This is the content iteration aspect.
The second is form. Content needs form. What form does the developer like that enhances the developer’s experience? The simplest is text and text, every developer may receive a variety of public account push, and there are a lot of text and text content, such as emails. And we are in the graphic above content also made some new attempt, such as graphic into gaming, such as the introduction of Android 11 new features, not word big is a new function, we need to let developers to interact, like the answer vies to answer first, allow developers to points, can green is correct, if is red is wrong, It’s an interaction. We also give small incentives to developers who participate in the interaction, which can lead to viral spread, which is the second form — gamified extension of content. The third one is concomitancy. Now that there’s a lot of content, gamification has been done, can there be concomitant? Actually sound is very important, sound is accompanied. Whether it’s during the developer’s commute, before bed, or at dinner, provide more comprehensive content in a concomitant way. This is a formal iteration of content.
Third, and very important, is the choice of channels. We’ve packaged developer content in different formats, so what channels are available to us? Do we have to use all the channels and send all the content directly to developers? If it is free, of course, but our team’s resources are limited, whether it is people’s time or the team’s budget, so we need to test which channel has the highest acceptance of our content. At this point, as with the COVID-19 vaccine, several phases of trial are required. In the first phase, three developers’ cases were put into the same channel to conduct a phase I clinical trial. When WeChat Weibo had feedback data, it was found that the third one was not good, but the first two were very good. Therefore, after WeChat Weibo, it was published to Zhihu, Sifen, Nugget and so on. And then in the phase II clinical trial, one story didn’t do as well as the others, and if we had to go on to make other videos, did we have to prioritize which one did better? So they eliminated another one in the phase three trial. At the end of the day we saw that at Station B, especially when production costs were high, we ended up using an example from Mihalyou, the developer of Primitive Gods. So this is where we get through a couple of trials and we’re able to pick and choose channels. These are some of the thoughts and attempts we have made in Awareness.
Second, use your common sense. It’s important that developers use your content, use your services and use your tools. The core metric is share, how you stand out from the other options, that’s very important. How do you do this?
I’ll also give you an example of an attempt made in Google’s Flutter project. In terms of share, the first is whether the tool you’re delivering to the developer is usable, which is very important, and if the developer doesn’t have a chance to use it, it’s not going to work. Of course, because of the mirroring issues with Flutter in China and so on, we had extra work to move it locally to make it easier for developers to use. Usability is fundamental. And then once it’s available, we can test it like we did before, do a couple of phases. We have Chinese language materials in the first phase, we have Chinese technical documents, and of course we have various localized materials in other countries, such as Korea, Japan, Indonesia, Vietnam. But if we’re doing developer services now, we’re going to have to think globally, and I think you’re going to be thinking globally, too. In which global markets do you invest in, whether you need to tilt your resources or reduce them, you need to go through the first stage of testing, and decide whether to increase your investment in this market through the feedback results. Therefore, we see that China’s share is growing very fast compared to the global market, so we decided to invest in the second phase, 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 Flutter’s developer growth in China, and we can also iterate on our final regional decisions in this way. Of course, this is country to country, but it’s the same concept for provinces and regions. This is an introduction organized by my team. Flutter now has many apps in use, more and more.
Third, it is very important for developers to know your product and use it, whether they can support you and speak up for you. The most important thing here, the North Star, is whether the developers are making money, whether they are making money.
Income is used in this revenue. Revenue was not used at that time because developers ultimately want net income. It’s not like he made $100 from your service, spent 90 on hiring, spent 20 on other operating costs, and ended up with a negative $10 return. That’s not good, he has to have a positive return. So I used income in the translation. So how do you monetize developers, how do you allow developers to use your product to create value for themselves — we did a project called Google Play Growth Star. We recruited about 200 successful developers across the country as seed users. We conducted a lot of offline activities for these developers, such as workshops, and gave them a lot of opportunities to try out new functions, hoping that they could make use of these functions to gain profits. In the background, we can actually see how developers are making money, and we can gather feedback from developers through numerous events. There are two aspects to this feedback. One is about the functionality of the product. We have a couple of features, and this is just a couple of features, and within those features, we’re iterating with 200 members of the Growth Star, and we’re sifting through them, and we find out which features are really going to help developers make money, and we’re going to push them, and we’re going to support them; Finally winning a few functions, in view of the developer’s services, content, tools, give to the developer, must be he can earn money, this way we do the countless function screening, finally found that developers can use and also be able to support you, this way can be very fast or the lowest cost to determine which blocks we push which blocks don’t push.
Having talked about the developer experience, I’m going to talk a little bit about thinking about team growth, because every member of a team needs to grow.
When I think of this question, I think the most important thing is what is the original intention of each team member and why they work here. I think for everyone, not just the developer growth team, but also the product team, the operations team, it’s an M and a C — the M is meaning, it has to be something of value and significance. I’m sure there’s no shortage of this in this room, and it’s very easy, because we’re helping developers succeed, and it’s not a particularly hard problem in our community of developers. C is for connection, which means that there are links, linking different resources, linking different people, learning from the growth of different people, including my own growth.
There is also a framework called MIC, and the “I” in the middle refers to your impact. Is the impact of your work changing or improving? There is a foreign framework that uses MIC to explain the initial intention or motivation of each team member. Of course, we also did some iteration. Impact is iterated into improvement, which is growth. Is every member of the team growing up? Not only doing meaningful, valuable and influential things, but also growing up, which corresponds to his personal growth, the growth of the work itself and the growth of his value. The third meaning of I is innovation. In fact, everyone loves innovation. I think it is also very important whether you can give the team more chances to try innovation.
To sum up, MIC is also a microphone, which aims to give everyone in the team a stage of their own and a space for them to do meaningful things, valuable things, and things with more links. In addition, they will continue to grow and have continuous opportunities for innovation.
How to screw up developer growth
Besides, I also thought about how to avoid potholes. Why do I think it’s important to avoid the pit? Charlie Munger talks about “contrarian thinking,” a way of thinking that he likes. Charlie Munger, 97, one of America’s richest men and Buffett’s best partner, uses a slogan — “Invert,” or “invert” — to represent the logic of his investments. I think each and every one of us can use the same logic when we think about developer growth. The growth of developers is how to mess it up, and if we don’t mess it up, then it will be okay, and even if it doesn’t grow, it won’t go down, right? Here are a few thoughts:
The first one is self-use and self-use. If you’re pushing a product or service to a developer that you don’t use yourself, it’s hard to convince people, so this is very important. I tell you a joke, that is, I have a classmate graduated from Beijing Medical University and became a doctor, and then he became the person in charge of eye surgery equipment, but he also wears glasses, and I asked him, “When will you do it?” He said, “Next year?” I said, “Well, after you finish, I will definitely go too.” This simple joke is to tell people that they must have used it before pushing it to the developer. This is convincing, but if you don’t use it yourself, how can you get the developer to trust you? That’s the first dimension. The second dimension is that when you use it yourself, you will find a lot of problems, and you will give the product team a feedback on whether they have really wade through all the thunder; If you don’t use it, you don’t know where Ray is, and you’re delivering something to developers that’s not right. Therefore, I think all of you in this room should ask your internal team to use it when you are growing as a developer, and then record the experience process of the developers and give feedback to the development team.
The second is output vs outcome. So what is Output? It’s that you might be doing a lot of work, each time there’s an increase in quantity, but it might not be valuable, there’s no outcome, and that would be fatal. So when measuring work, be sure to measure the outcome, not the output. Not how many tweets you send, how many newsletters you send, etc. You need to look at the outcome. So what’s the outcome? And I just mentioned a couple of things, which is — what is our North Star? Is there enough outcome in that indicator at Polaris, including an increase in outcome?
Third, know and act. We found a lot of new knowledge, new knowledge, new information from our developer community research, but we didn’t put it into action, which is very problematic. There are two scenarios here. The first one is whether we are doing developer interviews, surveys or questionnaires. When we design questions, we need to think about whether this question can be translated into our own actions. Most of the time, we are not only investigating the developer ecosystem, but also a variety of TOBs and TOCs. So if the results of this research can guide your actions, you should ask yourself. Otherwise developers are busy, because I’ve seen a lot of questionnaires, especially for developers, that can take up to half an hour to complete, which is actually not a good experience for developers. The second point is whether we can translate what we know, feel and think into action. This is very important.
That’s all I’m going to talk about today, because MVP is actually iterating gradually, every content, every North Star, every method. I have a WeChat official account “plus one sea”, in the 16th issue, I talk about MVP from the perspective of products, if you are interested, you can also pay attention to it. Finally, I hope you can discuss more and give more feedback.