【SaaS播客】onboard4. 连线硅谷顶尖Product-Led Growth公司产品经理，聊聊如何打造一流PLG产品

作为一个产品经理，在我的日常工作中，在Jira、Confluence（都是Atlassian的产品）、Postman、Zoom(中国区给代理商之后是腾讯会议)这几个产品上工作的时间估计占近一半，所以能听到在这些公司工作的华人产品经理的分享是很兴奋的。另外过去一两年也有很多PLG Product-led Growth的声音，如Monica开场所说，伴随着的也有很多噪音。

我是后知后觉的在播客上找到Onboard的，这期是直播回放，来自2021年10月31日的微信直播https://mp.weixin.qq.com/s/ZBJK7oNoUJZryK2OIfMNPg，播客发表于2022年4月5日https://www.ximalaya.com/sound/518098835。所谓闻道有先后，也不算太晚。听了之后感觉很多观点都是之前有概念的，但从没有集中的回顾和总结过。于是借这次机会，通过飞书妙记将播客语音转文字，再复核修改了几次。因为原播客是没有字幕的，想要边听边看的可以点击 https://u3cexcdeqf.feishu.cn/minutes/obcnam7cc37p582331z3rmuz

以下文字记录基本从播客文字中复制，因为主要是Monica提问、Lingbo/Charlie回答，所以采取问题+我的总结的形式记录，尽量用原话、偶尔夹杂个人观点。以下，Enjoy！

问题：PLG产品有哪些特征？

总结：Lingbo定义的好看好用好玩，可能更本质的是B端产品C端化，以实际用户的价值为重、而不是购买者。所以对客户群体有要求，客户群体要能self service去用去玩产品。所以目前被定义为PLG产品的绝大多数都是面向设计、研发、产品人员的生产力工具，除了本文提到的几个外，还有Monica万字长文的Figma（最近刚被Adobe以200亿美金收购）。

问题：怎么定义metrics？然后你们的哪些产品功能会是围绕这个去做设计和优化的。

总结：

指标的定义是非常关键的，找到这个魔法数字是时也命也，对于Lingbo负责的Activation来说可能7天建3个ticket是有效的。但如果回到Monica的问题，在整个路径中综合考虑onboard activation retention conversion就很难了，Lingbo提到了这个指标是和后续购买有强相关性的，这可能是Data Analyst的能力了。在我前公司产品运营团队（相当于Growth团队）每季度会定义一个增长的指标，产品运营也基本上能够完成甚至超额完成。但问题是不能持续，相当于薅自己产品的流量羊毛，所以短期看是有价值的，但长期看很难衡量，有可能什么都不做随着时间也会增长。另外确实如Lingbo所说，要完成有统计显著性的实验很不容易，idea首先要对，然后要有足够的流量和时间。

Charlie回答的倒是一些更典型的显学。产品负责前期，销售负责后期。由专门的增长团队定指标、做试验、做运营。具体到Postman，user/team的onboard由产品负责，enterprise的onboard由销售负责。

JIRA Service Management，提供试用

截图.png

核心操作是创建ticket

截图.png

Postman Monitors功能，在sidebar上所以有较大的自然流量

截图.png

问题：大家去看所有这些PLG的公司都在往上面，就是现在都会有一个这个 head of growth 。这个 growth team 是 report 给谁，是在 product 下面还是 marketing 下面还是单独一个 team，然后你们平时跟她们是怎样合作的？

总结：

Lingbo提到了非常典型的一点，就是Growth团队是应该和产品团队在一起、还是一个独立的central growth团队。我遇到的也是类似，如果本身产品就在早期不稳定的话，交给central growth团队是没有意义的。因为产品本身还有些其它的优先级，Growth的需求往往排不上优先级。这一点和中台、（设计师等）共享资源都类似，在早期从0-1的时候，全职种的team在一起紧密合作是最有效率的。但是在后期从1-100的时候，就需要类似技能的team在一起做到可复制了。

Postman的centralized growth team是新搭建的，分几个scrum或者pod，每个pod里面都会配产品经理、工程经理、工程师、data analyst、UX designer、以及centralized UX researching。很多metrics是growth团队和产品团队一起own的。Postman有两个增长和产品设计结合的功能，一个是run Postman collections in a Button，可以将API的使用者直接引导到Postman产品里来；一个是public workspace，可以让Paypal或者Twilio这种大公司生成自己的API portal；这是Postman增长飞轮里的关键一环。（Monica点评：PLG有两种dring forces，一种是公司内部传播的network effect，一种是向外传播的viral growth。）

Postman会提示免费额度已到期，这应该就是Growth团队负责的部分

截图.png

Run Postman collections in a button，共享的一种选项

我常通过JSON文件共享，效率也挺高的。

截图.png

Public Workspace，理论上可以直接将右下角的documentation link作为API文档嵌入到官网。

（但实际上由于国内访问较慢所以没有这么做。。）

截图.png

问题：付费转化从产品角度怎么去设计，怎么去evaluate？大概的conversion rate是怎么样的？

总结：

Atlassian很大程度上是时势造英雄，因为它很早在澳洲创立，只能在线卖到美国欧洲。引入free版本是非常晚的（可能2019年），因为free的东西客户就不珍惜，客户没有从中得到所需的价值。后来为什么又做free，因为涉及到monetization变现，因为之前产品只有1个版本，做差异化提供免费版可以培育不同付费意愿的客户。

这里Lingbo又提到了活跃度metric，只有track的这个metric是能体现出价值的才能保证公司不停地增长，如果track一些很虚化的metric那么最后是不sustainable的。这也是和我之前写的亲身经历是一样样的。

问题：check什么指标需要Sales去介入？有没有专门的enterprise版本，跟pay version之间是怎样的关系？

总结：

Atlassian一直track的是用户数量的增长，而不是版本的增长（从低价到高价）；sales介入都是由partner去做的。Asana有自己内部的会track每个大Account如Amazon。

Postman最早也没有enterprise version。因为SSO、IAM、User Group、安全、数据安全这些企业级的功能都是近期在做的。现在公司对outbound sales这块投入很大，sales也会看这些数据。如果你这个大的公司有一两个团队已经用 postman 产品了，这些 sales 肯定会 reach out 这些大的企业。Enterprise 付费和团队付费绝对不是一个量级的，另一个角度讲企业客户对产品的要求很复杂，和单一用户的需求不一样；买大的 enterprise level 的 plan 的 decision makers 也不一样。大企业CTO/CIO level的人，会关注API governance、API playbook、compliance、API portal、reporting、security；都需要有solution engineer去帮他们做一些脚本或架构设计的。

Postman的版本plan都是CEO定的，产品经理会定义负责的这块产品的free quota，然后单独的要付 add on 的额外付费。要考虑的是比如说我的定价怎么能够也用 growth flywheel这种方式或者PLG这种方式，能够前期让很多的用户免费用或者用低成本的用我的产品发现我产品的价值。所以和整个这个PLG这样的一个营销 strategy 能够一致，这是我考虑的一个问题。虽然可能我这是一个 outlier 一个 add on，但是我大的也是遵循就是公司这样的一个策略。

Postman没有sales去跟进大客户如Amazon，它的策略是让这些 developers 喜欢这个产品，能够认识到这个产品的价值，自发地去支持这个产品。Postman的基础功能是freemium，复杂功能会提供2周的free trial。像 JIRA 你可能要一个团队你才能感受到这个产品的价值。但是像 postman zoom 其实我一两个人，我其实就可以把产品用的比较好，就能体会到了可能到百分之七十八十的价值。Freemium 还是 free trial，其实不是那么一刀切的一个事情，其实是需要去可以结合起来用的。

像亚马逊说 pricing 就是 one way decision ，这改起来很难，所以一时半会也改不了。但是我觉得这里边即使是做 SaaS 的产品，当你产品多了以后，每一个 feature 或每一个产品做定价，这里边还挺复杂的。

Postman的定价，每个plan都有一定的的free quota，Enterprise的定价也是公开的。

截图.png

Charlie负责的Monitoring是可以通过Add-ons增值包的形式单独购买的。

截图.png

问题：你们考虑到有几种 pricing，当时具体的几个 pricing 方式，最后你们就怎么取舍的。

总结：

Charlie: 作为B2B SaaS，我倾向于可能更多的是以这个 value-based 去做定价。但这里边更复杂的怎样找到方式去measure你产品提供的 value，这是比较复杂的问题。如果你 pricing 变动的话，其实像我们下一年要变 price，那现在这个月初就已经跟客户进行沟通、充分的沟通，提前给用户时间。如果你想买下一年的话，你现在可以以现在的价格买下一年的这个plan，你可以提前 lock in，给现在的用户这样的机会。

Atlassian有一个strategy and operations team，它就是在统筹一些pricing，还有帮助大家测试，等于是给大家提供一些 operational 的支持。作为上市公司pricing还要在股东大会上沟通。Atlassian的产品基本上是比所有的产品都低。但是他的一些定价的策略是什么呢？因为总是能开发出来新功能，那么这些新功能可能会打包成 add on 然后去给他加价。当然并不是说主要的目标是为了挣钱，而是说发现这个基本功能是大部分人需要的。那么这 add on 可能只是小部分人才有这个付费意愿。所以那我们就把它单独做成一个付费的东西，让别人来付费。然后他也基本上是没有 discount 的Atlassian，他所有的定价都在网上都是公开透明的，包括 enterprise 定价都是公开透明的，这点其实是跟Asana的还有其他的公司都不一样的地方。

问题：低价策略是不是也跟你的产品属性相关呢？

总结：

Founder最开始头脑就非常清楚说我们这个公司的 mission 是想 unleash the potential for every team on the planet 对不对？是想给全球各个团队都能带来这个好处。那么当你考虑到这个 volume 的时候，那你这个价格必然是要低的，因为很多团队是支付不了这么多钱的，所以这时候高定价就是off the table 的一个option了。那么Atlassian当时的策略就是说我这个产品我是一个开放的生态圈，我base这个产品定价很低。那么当你生态圈有很多附加的功能的时候，你可以去charge你的钱，就好像我们买一个手机，然后你也可以给 App 去付费。所以这个时候他也给大家更多的选择。这是他的商业模式的一个考虑。那么Asana实际上对比看来就不一样了，因为他就是一口价嘛很多时候。

像Asana这种，我觉得他当时也没有那么多的样本可以去参考。可能大家就觉得这个价格差不多就这样了，也没有那么多的。比较有意思，就这个东西。第二点是 science，大多数最初的时候都不是science。然后他说是绝对低价还是相对 value，一定是相对 value 的低价。

问题From Neo：PLG的生态，你们觉得在亚太是可行的吗？

总结：

Charlie：用户本身有很多相通的地方，就是 human nature，无论是你是在哪个国家的用户，其实都有很多一致的地方。PLG我相信肯定你一个产品好的话，有价值的话，不论客户在哪个地方，你把PLG这些东西做完善了就肯定会有效。但具体到具体的策略，你根据你的产品的一个形态或者具体的市场，你会分析怎么去做对吧。如果你只用PLG的话，你做好了，你可能不用销售或专门的这个销售团队或者 channel 也能做，但是很有可能混合的模式、hybrid 模式会更好。你有专门的，尤其你的很多客户是大客户的话，你利用 channel 利用销售，我觉得效果会更好。

Lingbo：PLG不是新概念，也不是点石成金的手段。Idea is cheap，大家想法很多时候都是一样的。机遇是很大的一个部分。另外一部分就是这个团队的执行力怎么样。那么能不能针对这个当地市场的情况，能够快速地去调动团队的能动性。然后大家能心往一处使。具体怎么做要看这个产品面对的用户是什么。developer 可能有 developer 的做法，然后协作的软件有协作软件的做法，可能云平台有云平台的做法。所以这个还是要团队大家一起集思广益吧。针对你要进入的是中国市场、一线城市还是东南亚市场还是印度，这个可能都是不一样的。你要招的人可能也会很不同。

Monica：任何的事情都要动态的去看。很多事情就是已经是个彻底的差异，还是说一个阶段性的一个差距，我觉得这个东西首先我们得要去明确了。越是接近头部的用户，他跟国际的差距其实是越小的。那所以从阶段性角度来看的话，其实为什么我一直的观点就是我觉得PLG什么也好，大家都是服务，尤其在中国这种环境更要服务好这些头部的用户，他不是说大厂，而是说自己能力很强的 developer 群体。