Issue #6 - PLG 产品的设计原则

上一期聊到 PLG 的核心是好产品，而什么是好的产品让我想起 Jesse James Garrett 那本经典的《用户体验要素》，这本写于 2002 年的书放在今天去看依然经典。在 Garrett 的书中，用户体验最底层是战略层，即用户需求，好的产品首先要满足用户的需求，解决用户的痛点，用现在的话来说就是要有 Product-Market Fit。PLG 实际上又让我们回到起点去关注产品本身，回头去看 PLG 的出现其实也有一定的必然性。

B2B 产品的销售模式经历过 3 个阶段：

80–90 年代称之为 CIO 时代：软件的销售对象主要是企业内部的 CIO，他们负责购买各种第三方的软件。当时考量一个产品是否要购买的关键要素是这个产品能否与公司内部的其他系统相互集成，对 CIO 来说这样的产品更加容易维护。
21 世纪之初则是管理者时代：这个阶段软件的销售对象主要是针对团队的管理层，管理层购买软件的决策因素是 ROI，即购买这个软件是否能够帮助团队达成既定的目标，如果可以，那么价格是否便宜。
如今则是用户时代：软件不是被销售给对方的，而是有用户自主发现并且自助购买的，因此人们说「Softwares are bought, not sold」

销售对象的改变使得产品 Go-to-Market（GTM）的策略也在不断的变化，经历过 4 个阶段：

Field Sales：简单理解就是「地推」，销售代表在线下约见 CIO，给客户演示产品的功能，代表们花费很长的时间在见客户的路上。
Inside Sales：此时销售代表更少的约见客户，而是坐在办公室里通过打电话给从各种渠道获取的销售线索，以 Oracle 和 Salesforce 为主，他们从各种渠道购买销售线索，然后一个个打电话。
Marketing：随着互联网的普及，线索的获取越来越容易，销售代表不可能每个线索都打电话或者发邮件过去询问，效率太低，随着搜索引擎的成熟，通过 SEO 等市场的方法，让市场部先验证一下这个线索是否有效，然后再交给销售代表去跟进。HubSpot、ExactTarget 是这方面的高手，前者依赖于 Content marketing 获取了大量的线索。
PLG：随着互联网的发展，人们获取信息的方式更加容易，Leads 数量的增多依然需要大量的销售代表，那有没有一种更加低成本并且可规模化的方式来获取客户呢。Atlassian 在创世之初就使用这样的模式，因为他们没有足够的销售于是就在网站上让用户自己付款购买软件，而这样的模式随后被证明是有效的。

销售对象和 GTM 策略的改变有着非常明显的时代特征，上世纪 80–90 年代互联网还没有普及，也没有 Google 这样的产品，人们获取信息的方式非常有限，即便有很好的产品出现，客户也难以察觉，线下销售就成为人们获取软件的渠道。随着电话成本的降低，电话成了更好的 GTM 的渠道。21 世纪互联网飞速发张，Google 成为人们访问互联网的门户，搜索引擎的崛起和广告成为主流，人们发现信息的渠道也更加多样化。

在互联网时代以前，软件市场相当于是卖方市场，因为信息匮乏，购买软件的人并不知道市面上有哪些软件可以选择，销售代表可以抢占先机来获取用户；互联网普及之后，信息快速普及，同时软件市场上也开始出现大量的同类产品，市场转化为买方市场，买方有了更多的选择，因为所有的信息都很容易获得，产品本身成了购买者关注的重点，与 PLG 成为主流。

PLG 有一个明显的特点就是「可规模化」，虽然 Content marketing 也可以规模化，但是在 Marketing 作为 GTM 的主流的时代，当 MQL 产生之后还需要销售代表进行跟进才能转化为客户，也就是 MQL -> Customer 这个过程是不可能规模化的。而 PLG 则注重让用户 self-serve，用户自助购买不需要人工介入，因此整个流程从 Acquistion 到 Activation 再到 Retention 都可以规模化。

OpenView 在这篇中提出了 PLG 的 11 个原则，我认为没有必要这么多，因为 Growth 是一个系统，这些原则实际上都是可以通过 1 个主要的原则推导出来，这个原则就是「为用户设计而非客户」，这个是从用户的角度来理解，而从商业的角度来理解就是「等价交换」。

为用户而设计

原则 #1：Build for the end user
原则 #9: Monetize after you deliver value

实际上所有的原则的核心都是「Build for the end user」，如今一些 2B 软件的购买者实际上是用这个产品的用户，而决定购买因素主要是产品是否能够解决用户遇到的问题。当用户了解产品可以解决自己的问题时，也就感受到了产品所能提供的价值，在此之后再鼓励用户付费，用户也更容易转化。

我把原则 9 提前的另外一个原因是即便是一个全新的产品，从第一天开始就要考虑商业化，虽然说用户价值优先，但不代表着不可以在这个阶段去获取商业价值。事实上产品的早起就思考商业价值也可以进一步验证 Product-Market Fit（PMF），如果产品真的帮助用户解决他们的痛点，用户一定会选择付费。

原则 #2：Build to be discovered
‌原则 #7: Deliver instant product value

原则 1 和 9 对于验证 PMF 很重要，当产品有了 PMF 之后我们才去讨论如何让更多的人了解产品。PLG 的一个关键特征是 touch less，即用户发现和购买的流程尽可能的减少人为干预，让用户可以更加容易的自助的完成发现和购买。用户自助发现产品的一个关键渠道就是搜索引擎。

我把原则 7 提前是因为它和 discovered 密切相关，当用户发现产品之后，产品要尽可能的在更短的时间内让用户感受到产品的价值（Time-to-Value, TTV），时间越短越好，而「Instant」这个词并不夸张。我之前有个诉求是想要根据网站访客的 IP 来识别这个访客是来自哪个公司的，通过 Google 我找到了 Clearbit，然后在 Clearbit 的 Landing page 上我直接看到了我们公司的官网，显然 Clearbit 通过这个工具直接让我看到它可以通过我的 IP 识别到我是来自哪个公司的¹，在这一瞬间我就感受到了 Clearbit 的产品价值。

原则 #8: Deliver instant customer experience

Touch less 鼓励尽可能的减少人为干预，并不代表着完全不与客户接触，有些产品过于复杂，用户在使用的过程中难免会遇到问题，这些问题越快解决用户也就越容易的感知到产品价值。

原则 #3：Build to meet your users where they work

企业用户有一个共同点就是用户不可能只使用一个软件来完成所有的工作。所有企业用户都会使用聊天工具，可能是 Slack 也可能是 Teams；同样他们也一定在用文档工具，可能是 Notion，也可能是 Office 365 或者 Google docs。不存在一个软件可以满足企业用户的所有需求，因此「为用户而设计」就要考虑用户所有可能的使用场景。例如当你在 Slack 里面粘贴一个 Google docs 的链接的时候，你无需再附上文档的名称，Slack 会自动获取文档的名称；在或者你在 Notion 里面修改了某个重要文档，你个改动是可以通知到 Slack 中让其他关注该文档的人知晓这次改动。

原则 #4: ‌Build for openness

为了尽可能满足各种不同客户的使用场景，产品就需要有更多的 integration，如果要把用户使用的所有第三方产品都集成进来显然是不可能的。Openness 的意思是说，产品要保持开放（开放 API），让第三方可以帮助产品做各种 Integration，类似于 Zapier 这样的产品就可以帮助产品快速 Integration 成千上万个第三方应用。

原则 #5: ‌Build for flexibility

Openness 是指产品对外要保持开放，而产品内部同样也需要开放（灵活），原因同样是企业用户不仅仅是用的上下游工具千差万别，他们的工作模式和流程也是千差万别，以 Jira 为例，虽然大多数软件开发公司都在使用 Agile，但每家公司的 Agile 的实施过程都各不相同，这就导致使用 Jira 的过程中用户角色和 ticket 流转过程也不相同，Flexibility 的意思就是用户可以根据自己的诉求在配置不同的 ticket 流转过程，来适应自己的工作流程。

原则 #6: Build community as a competitive advantage

Flexibility 与 Complex 总是同时出现，一个灵活性非常高的产品复杂度也会更高，而当产品变得复杂的时候教育用户就成了比较棘手的问题。你当然可以通过完善的帮助文档来用户学习如何使用产品，但用户通常不会按部就班的学习如何使用产品，他们会自己探索，只有当遇到具体的问题的时候才会去寻找帮助，而这些问题在灵活的产品中几乎无法穷尽，通过社区，用户可以相互交流自己的使用场景和遇到的问题，这些记录都可以让有相同的问题的用户来参考。显然社区不是给新用户准备的，它跟 Deliver instant product value 相违背，社区更多的面向是用户向更高级的转变。

等价交换原则

以上几条的核心都是「为用户设计」，都是关于如何创造用户价值，但做产品不可能只考虑用户价值，用户使用产品实际上是一种「交易」，即通过商业价值来换取用户价值，这其中我觉得最重要的理念就是「等价交换」。所谓等价交换是指产品能够为用户带来多大的价值，就可以收取相应的费用。SaaS 软件商业化通常采用订阅制，用户每个月都需要支付一定的费用才能使用产品。以下几个原则都是跟商业价值有关，不过这几个原则我认为跟 PLG 并无关系，只要是 SaaS 产品都适用。

原则 #10: Monetize based on usage

以 Apple Music 为例，每个月支付 $10.99 就可以听其中的所有音乐，但无论你每天只听 1 首歌还是 100 首歌，Apple Music 带给你的价值并不会有多大的差异；而 Shopify 则不同，商家通过 Shopify 开店，每个月能够获得 GMV 越多，价值也就越大，那么 Shopify 就可以根据商家的 GMV 抽佣，因为它提供了更多的价值，这就是 usage based pricing，这里的 usage 不是随便什么用量都可以，而是一定跟用户的价值相关联的，usage 的变化是可以反映出用户价值的变化的。

原则 ‌#11: Monetize beyond software

最后一个原则其实所有的软件都适用，用户购买软件的目的不是使用软件，而是解决一些特定的问题，软件只是解决这个问题的工具，除了软件本身以外，软件使用的最佳实践（best practice）作为一种服务也可以收费。OpenView 给出的例子是 Shopify Payments，我觉得并不合适，Shopify Payments 类似于 Amazon 把自己服务器基础设施做成一个平台类似，将软件中的一个模块做成了一个 PaaS（Platform-as-a-Service），是通过现有产品延伸出来的新产品，作为第二增长曲线的新产品。

PLG 显然并不适合所有的产品，尤其是极度复杂，用户难以在短时间内上手并理解其价值的产品，他们需要销售代表向用户演示产品如何运作，例如 Workday²。抛开 PLG，为用户而设计的产品永远都不会过时，这里的「为用户而设计」已经不仅仅是产品的 UX 所代表的用户体验，而是整个用户生命周期中的体验，从发现产品到试用，再到付费，续费和升级。Hila Qu（Former Director of Growth）也提到 B2B 可以从 B2C 领域学习很多增长模式³，而其中的一个关键点就是 B2C 鼓励用户自助服务。归根结底，无论是面向企业还是面向消费者，产品最终面向的都是人，好的产品是那些真正能够解决用户痛点的产品。