黄继佳：利用 MVP 模型实现开发者增长 | DEV. Together 2021 中国开发者生态峰会

内容来源：2021 年 6 月 5 日，由 SegmentFault 思否主办的 2021 中国开发者生态峰会圆满落幕。会上，Google 平台及生态事业群开发者市场负责人发表了主题为《利用 MVP 模型实现开发者增长》的演讲。

分享嘉宾：黄继佳，Google 平台及生态事业群开发者市场负责人

速记整理及发布：SegmentFault 思否编辑部

大家下午好，很高兴听到大家的分享。我是来自 Google 的黄继佳，很开心有机会和所有做开发者生态的同学汇聚一堂。今天我分享的话题是《应用 MVP 方法实现开发者用户增长》。在梁迪老师后面谈 MVP 稍微有点紧张，但是我谈的 MVP 不是微软最有价值专家，而是最小可行性产品。

我先简单介绍一下自己。其实开发者、产品、技术布道、市场或运营这几个工作我应该算都有涉及，在三家公司：Google、微软和青檬网络，我希望把之前工作中的所得所想所感和大家交流探讨。我们毕竟是 MVP 的话题，这个话题其实也会逐步地迭代和变化。

我要讲的内容主要分为五个方面，基本上就是从开发者生态、开发者增长面临的挑战、应用 MVP 的方法以及怎样避坑，还有在路上的一些感悟。

构建开发者生态的挑战

首先，我想和大家分享一下开发者生态。高老板早晨也分享了一个视角，就是从团队的角度。我们其实有很多视角，如开发者关系、开发者市场、团队的构成等等。我要介绍的是开发者使用产品的视角。

最左边是开发者工具，也就是开发者用这些工具来构建软件。大家可以先把开发者生态放到软件的边界里，大家的产品是软件，而我们有开发工具。第二是开发者服务，即开发者软件产品里包含的服务，这里面包括阿里云，包括一些线上服务的厂商。第三就是开放平台，开发者的软件在哪里发布、在哪里供用户使用，这是开放平台。最后就是应用商店，能够帮助开发者很容易地变现，把软件和应用分发到最终用户进行测试。这个是开发者软件产品面向生态的四个方向。

开发者增长的挑战

那最大的挑战是什么呢？可能每一个维度都有自己的挑战。最统一的挑战就是开发者增长，大家也可以从今天拿到的调研报告中看到这方面生态的最大挑战是开发者增长。所以今天，我想分享一下在开发者增长这块我们面临的挑战和应对方法。

开发者增长面临什么样的挑战呢？我们可以总结为三个部分。

第一个，技术社区的碎片化。刚才在晋宇的分享中我们也看到了，各种各样的技术社区不断发展，也有不同的技术产品供开发者使用。所以这是第一个问题，如何让层出不穷的技术被开发者看到？

第二个，开发者是天然地反对被营销的。他不希望自己是被营销的对象，他要选择信任的产品或者服务去使用。

第三是不可持续增长。开发者可能很快用到了你的产品或服务，但是如果因为各种原因没有给开发者做好服务，他可能就会放弃使用你的产品或服务。

这就是我们看到的各种各样的挑战，这些挑战也在每时每刻发生着变化，如何应对这些不断变化的挑战呢？

应用 MVP 方法实现开发者增长

做产品或者做开发的同学可能会非常熟悉这个概念。2011 年，“最小可行性产品”概念诞生，即通过 MVP 的方法试错、迭代，来不断满足市场需求，并且快速地、廉价地失败，这是最重要的。我想这个和梁迪老师刚才分享的成长心态（growth mindset）是一样的。

现在很多企业在打磨产品的时候，利用 MVP 方法迭代推向市场。那我有个思考，就是能不能用 MVP 的方法迭代开发者增长引擎，让开发者增长做得更有效率，更符合市场的挑战，进而满足我们的商业目标。所以 MVP 可以解决两个问题，除了微软最有价值专家之外，还有其他两个问题，我们看看是不是能解决。第一个是开发者体验。如果开发者的体验不好，任何产品和服务都无从谈起，所以我们首先要看能否用 MVP 解决开发者体验问题。第二个是团队成长。我们每一个项目的执行、每一个开发者的触达都需要团队的工作、团队的协作，那我们如何用 MVP 的方法来迭代团队，让团队成长，这也非常重要，也是在座每一个人能够成长的非常重要的一块。所以我想从这两个方面和大家分享一下我的思考。

首先来看开发者体验。开发者体验就是面向开发者的体验，我们给开发者提供的服务、工具、内容需要有围绕开发者的循环或闭环。

其中第一块是察觉（awareness）。要让开发者知道有这么多选择，如果他根本都没有看到你，那后面的介绍也好，让他使用也好，都是无从谈起的。第二个是采用（adoption），他要能真正用到生产环境里，这非常重要。第三个是拥护（advocacy），他能够像类似 MVP 一样去传播，像微软最有价值专家一样去传播，去拥护这个产品和服务。这三个蓝色的圆圈非常重要，是开发者体验提升的北极星，也是我们作为运营团队、开发者服务团队需要去关注的。

对于察觉，我们最需要关注的就是互动。开发者和你是不是有互动，这是北极星。开发者是否采用了你的 SDK、服务，最重要的北极星是什么呢？是份额，就是在市场上同类服务里你的份额是多少。我想每一个团队的成员都需要去思考这个问题：份额是怎么样的？第三，就是拥护，让开发者能够拥护。什么样的情况开发者才能够拥护呢？一定是开发者赚到钱了，因为开发者作为一个人也好一群人也好，他的商业逻辑、思考逻辑其实也是企业的逻辑——他一定要能够赚到钱，然后整个营收方面，要一直持续不断地有收入。如果你发布的东西，开发者一直在赔钱，那他不可能拥护你，或者只是短期的拥护。这三个是我认为非常重要的北极星。

那怎么去解决这三个问题呢？我可以分享一下案例。第一个就是如何做察觉（awareness），北极星是互动，怎么做更多的互动给开发者？

首先是内容的迭代，因为触达开发者需要内容，这是非常重要的。我们不是让开发者被营销，我们需要提供有价值的内容，那有价值的内容是什么呢？MVP 最开始的起点应该是产品的发布。这个产品可能有不同的功能，也可能是产品的迭代，也可能是不同的产品。那第一个最基础的就是产品的发布。除产品发布之外，我们需要迭代给开发者提供的内容，包括产品发布加上技术详解。比如有几百个产品、几百个 feature，是不是每一个 feature、每一个产品都要做产品发布加上详解？其实不是的。你需要去看开发者究竟使用了哪些，哪些给你的互动反馈比较多、比较积极，这时候你才去投资来做技术详解。再进一步，我们做完了技术详解之后，第三个是开发者的分享，是不是让数万、数十万开发者，让他们每个人都做分享？不一定。你要找最重要的那个点，让开发者去做分享，这个也是我们看到能够补足技术详解的、比较重要的功能。让开发者做分享，还要有的放矢。这个是内容迭代方面。

第二就是形式。内容需要形式来呈现，什么样的形式是开发者喜欢的、能够增强开发者体验的呢？最简单的就是图文，每一个开发者可能都会收到各种各样的公众号推送，再比如邮件等有很多图文内容。而我们在图文内容之上也做了一些新的尝试，比如把图文变成游戏化的方式，如介绍 Android 11 的新功能，不是字儿大的就是新功能，我们需要让开发者去互动，就像答题抢答一样，让开发者去点，可能绿色的就是正确的，如果是红色的就是错了，这是一个互动。我们也给参加互动的开发者一些小的激励，可以形成病毒式的传播，这就是第二个形式——在内容上面的游戏化拓展。第三个就是伴随性。现在内容已经很多了，游戏化也做过了，那是不是能够有伴随性？其实声音很重要，声音是有伴随性的。无论在开发者通勤的时候，还是在睡觉之前，还是在吃饭的时候，都用伴随性的方式更全面地给他们提供内容。这是内容的形式迭代。

第三，也是非常重要的，就是渠道的取舍。我们给开发者的内容在不同的形式上做了包装，那什么样的渠道是我们可以使用的呢？是不是所有的渠道我们都要用，直接把所有的内容都发给开发者？如果是免费的当然可以，但是我们团队的资源是有限的，无论是人的时间还是团队拿到的预算等等，所以我们需要测试哪个渠道对我们内容的接受度最高。这时候就像新冠疫苗一样，需要几期试验。第一期把 3 个开发者的案例投入到同样的渠道里，做一期临床试验，等微信微博有反馈数据了，发现第三个不行，前两个非常好，所以在微信微博之后，把这个内容发到了知乎、思否、掘金等等。然后在第二期临床试验的时候，发现有一个故事没有其它表现得好，如果需要继续制作其他视频，我们是不是需要优选那个表现比较好的呢？所以在第三期试验的时候又淘汰了一个。最后我们看到在 b 站，特别是制作成本很高的时候，我们最后选择了米哈游的一个案例，米哈游是《原神》的开发者。所以这就是通过了几期试验，我们能够对渠道进行取舍。这是我们在 awareness 方面做的几个思考和尝试。

第二个，采用（adoption)。开发者一定要用你的内容，用你的服务和工具，这非常重要。最核心的指标是份额，你能不能在其他选择当中脱颖而出，这个非常重要。如何去做这个呢？

我也举一个例子，就是在 Google 的 Flutter 项目中做的一个尝试。说到份额，第一个就是你交付给开发者的工具是不是可使用，这非常重要，如果他根本就没有机会使用，那肯定是不行的。当然了，Flutter 在中国因为有镜像的问题等等，我们有额外的工作需要把它搬到本地让开发者能更容易地使用。可用是最基础的。可用之后，我们就可以像刚才一样做测试，做几期试验了。我们在第一阶段有中文版的学习资料，有中文的技术文档，当然其他国家也有各种各样本地化的资料，比如韩国、日本、印尼、越南。但是如果我们现在做开发者服务，其实也要放眼全球了，而且我相信大家也在放眼全球了。那你投入到哪个全球市场的资源，需要给倾斜还是需要减少，都需要通过第一阶段的测试，通过反馈结果来决定是不是要在这个市场加大投入。所以，我们看到中国的份额在全球的对比来讲，是增长非常快的，所以我们决定要做第二期的投入，比如参与开发者大会、举办 workshop、支持社区活动等等。这些都要很多的资源，包括人的资源、供应商的资源、预算等等。这个是 Flutter 中国开发者增长的几个阶段，我们也可以通过这种方式去迭代我们最后的区域决策，当然这是国家与国家，其实各个省、各个地区也是一样的概念。这是我团队组织的一个介绍，Flutter 现在有很多的 app 已经在用了，越来越多。

第三个，开发者知道了你的产品，也用上了，那他是不是能拥护你，能够帮你说好话，这个非常重要。这里最重要的核心、北极星是开发者是不是取得了收益，是不是赚到了钱。

这个收益用的是 income，当时没用 revenue 是因为开发者最终要净收益。不是说他拿到你的服务赚到了 100 块钱，招人花了 90，其他运营成本花了 20，最后收益是负 10 块，这是不行的，他一定得是正收益。所以我在翻译的时候用的 income。那么怎么能够让开发者有收益，怎么能够让开发者使用你的产品给他自己创造价值——我们做了一个项目，叫 Google Play 成长之星。我们在全国招募了大概 200 个做出海的开发者作为种子用户，针对这些开发者做了很多线下活动，如 workshop，也给他们很多新功能的尝试机会，希望他们能够利用这些功能获得收益。我们在后台其实也可以看到开发者的收益如何，我们可以通过无数活动来收集开发者的反馈。这些反馈有两方面，一个是对产品功能的。我们有若干个功能，这只是几个功能，在这些功能里，我们针对 200 多个成长之星的成员也在迭代，然后去筛选，最终发现哪些功能真正能够帮助开发者赚钱，我们就要猛推，我们要支持这些开发者；最后胜出的几个功能，针对开发者的服务、内容、工具，给到开发者的，一定是他能够赚到钱的，我们通过这样的方式把无数的功能做了筛选，最后发现开发者能够使用并且还能够拥护你，这样的方式能够很快速或者最低成本地来决定我们推哪块不推哪块。

刚才说到了开发者的体验，下面我再讲一下团队成长的思考，因为团队的每一位成员都需要成长。

想到这个问题的时候，我觉得最重要的就是每个团队成员的初心是什么，为什么在这工作。我想对于每个人，不只是开发者增长团队，包括产品团队、运营团队都一样，就是一个 M 和一个 C——M 是 meaning，就是一定要是有价值、有意义的事。我相信在座的各位应该不缺少这个，这非常的容易，因为我们在帮助开发者成功，这在我们做开发者社区的团队里，我想并不是一个特别难的问题。C 是 connection，就是有链接，链接不同的资源，链接不同的人，学到不同的人的成长，包括自己的成长。

还有一个框架叫 MIC，中间的 I 是说你的影响力（impact），你的工作的影响力是不是有变化、有提升。有一个国外的框架就是用 MIC 来解释每个团队成员的初心或者动机。当然我们也做了一下迭代，把 impact 迭代成 improvement，就是成长。团队的每个成员是不是都有成长，不只是做有意义的事、有价值的事、有影响力的事，还要有成长，这个成长对应着他个人的成长、工作本身的成长、价值的成长。I 的第三个意思就是创新（innovation），其实每个人都爱创新，你是不是能够给团队更多的机会去试创新，我觉得这也非常重要。

再总结一下，MIC 也是一个麦克风，就是要让团队的每个人拥有自己的舞台，能够有一个空间让大家做有意义的事，做有价值的事，做有更多链接的事，并且在持续地成长，持续地有创新的机会。

怎样搞砸开发者增长这件事

此外，我还思考了一下怎么避坑。我为什么觉得避坑很重要呢，查理芒格（Charlie Munger）先生讲过“逆向思维”，这是他很推崇的思考方式。查理芒格今年 97 岁，是美国首富之一，也是巴菲特最好的搭档，他提了一个 slogan——“invert”（反向思考），这是他投资的逻辑。我想我们每一个人在思考开发者增长的时候，也可以用这个逻辑去思考。和开发者增长对应的就是怎么搞砸这个事，如果搞砸的事情我们都不做，那结果应该还可以吧，就算不增长也不至于往下掉对吧？这里边有几个思考：

第一个是自己用和自己不用。如果你推给开发者的产品或服务，你自己并没有用，那其实很难说服别人，所以这个非常重要。我举个笑话，就是我有个同学从北医大毕业后做了医生，后来他做了眼睛手术设备的负责人，但他自己还戴个眼镜，然后我问他 “你什么时候做”，他说“明年做啊”，我说“那好，等你做完了之后，我肯定也去啊。” 这个简单的玩笑话就是告诉大家一定是自己用过的再推给开发者，这个才有说服力，如果你自己都没有用的话，怎么让开发者信任你呢？这是第一个维度。第二个维度，就是你在自己用的时候会发现很多问题，会给产品组一个反馈，他是不是真正地把所有的雷都趟过了；如果你不用的话，你根本不知道雷在哪，那你给开发者交付的产品肯定也是有问题的。所以我觉得在座各位做开发者增长的，一定要要求内部的团队用起来，然后把开发者的体验过程记录好，给开发团队有所反馈。

第二个是 output vs outcome。Output 是什么呢？就是你可能做得很多，每一次工作都有数量的增长，但是它可能并没有价值，没有 outcome，这是很要命的。所以在衡量工作的时候，一定要衡量 outcome，而不是 output，不是你发了多少篇微博、发了多少篇通讯等等，你要看 outcome。那 outcome 是什么呢？刚才我其实也大概提了几点，就是——我们的北极星是什么？是不是在北极星的那个指标有足够的 outcome，包括 outcome 的提升？

第三个，知道和行动。我们从开发者的社区调研里发现了很多新的认知、新的知识、新的信息，但是我们并没有把它应用到行动当中，这个是很有问题的。在这里边有两个场景，第一个就是在做开发者的访谈也好，调研也好，问卷也好，我们在设计问题的时候要思考一下这个问题能否转化成自己的行动。很多时候我们调研的内容不只是开发者生态，可能是各种各样的 To B、 ToC，那这个调研的结果是不是能够指导你的行动，要问一下自己。要不然开发者也很忙，因为我看到过很多调查问卷，特别是给开发者的，可能要半个小时才能答完，这个其实也是对开发者体验不好的。第二个点，就是我们是不是能够把这些所知所感所想转化成行动，这个是非常重要的。

我今天主要分享的内容大概就这些，因为 MVP 其实也在逐步地迭代，包括每一个内容、每一个北极星、每一个方法。我有一个微信公众号“加一出海”，在第 16 期专门从产品的角度讲了 MVP，如果大家感兴趣的话也可以关注一下。最后希望大家能够多多探讨，多多反馈。