PM为什么它对企业服务公司重要

PMF 本质上是回答了“你解决了什么人的什么问题”，然后就是“Good Market”——你的好的市场是什么。PMF 既是定义产品的过程，也是寻找目标客户的过程。较早提出者 Marc Andreesen 给 PMF 的定义是：在一个好的市场，有一个满足市场需求的产品。

PMF和产研体系都是比较大的话题，但随着SaaS公司的业务从初级阶段走向规模化增长阶段，这也是必然被产品团队/创始团队关注的问题。

希望通过这次发布会，分享我们 PingCode 团队在 PMF 上的认知，以及如何构建以客户为中心的研发工作流，来实现在 PMF 的进化，进而找到 PMF 的过程。

本文整理自PingCode CEO 企服发布会演讲

之所以在 PMF 上会有深刻的体会，是因为公司成立十多年我们自己在这上面踩了非常多的坑。

比如下图“纷纭”这个产品，它定位非常像现在的 Slack。因为产研团队的能力非常强，所以我们认为自己所有的事情都能做，这也是非常多的创业公司在初期都会犯的“毛病”——别人能做的东西，凭我们自己的技术实力应该能以更快的速度迭代出一个原型，并推向市场。

所以用了9个月的时间把产品做出来，但在推广两个月之后，我们决定把这个产品关了。因为复盘“纷纭”在国内商业机会之后，我们发现：

来自美国的经验和需求，可能在中国是完全不同的：一方面，在国内基于团队之间的沟通，微信已经成为一个沟通的基础平台，留给其他IM的机会非常少。

另一方面，Slack 在美国是想解决不同工具/服务之间的连接问题，构建统一的消息聚合平台。而国内的 SaaS 还没有发展到成熟期，所以用户根本不需要这样一个工具。

所以这件事，对我们在打造 Worktile、PingCode 时候有一个重要的启示就是——销售和增长不给力，通常情况下，大部分原因是没有找到 PMF。这也是我和很多企服公司 CEO 聊到的非常有共鸣的一件事。

国内外SaaS公司在PMF这件事的现状如何？

如果跳出我们自己再去看中国以及国外公司的情况：

• 75%+的公司创始人，无法清晰的回答：谁是你的客户，你解决了客户什么问题？
• 80%的公司从来没有找到过 PMF，没有造出过真正有人需要的产品（数据来源：Y Combinator）
• 在定义清楚 PMF 之前，98%的公司都把时间用错了地方（数据来源：Marc Andreessen）
• 70%公司失败的名列前茅大原因是：产品不被市场需要
• 在硅谷，能完成PMF的创业公司不到10%，所以 PMF 是一件很难的事

世界上只有两种公司，有PMF的，和没有PMF的——PMF创始人Marc Andreesen

什么是PMF？以及PMF对SaaS公司的意义

其实很多人对 PMF 都有自己的理解，所以这里主要分享我们视角下的 PMF 究竟是什么，它为什么对企业服务公司的意义可能是最重要的。

较早提出者 Marc Andreesen 给 PMF 的定义是：在一个好的市场，有一个满足市场需求的产品。

他认为产品和市场的中间会有一个匹配问题，而在 PMF 中，我们习惯性关注的东西可能是产品，但是在 Marc Andreesen 视角下，更重要的其实是“Market”部分——在一个好的市场，有一个满足市场需求的产品。

所以我们公司现在做决策的底层逻辑之一就是“首先要做正确的事，然后才是把事情做正确”。

因为，商业化的公司做正确的事的源头，就是你是否提供了别人需要的东西，这是后续销售、市场、服务等所有事情能够展开的起点。如果方向错了，你就有可能是越努力越费力。

在产研管理群体，关心的重点问题通常是：如何提升产研的效能、什么样的组织形态更能激活团队能更好更快的发布产品。

但我认为首先应该关注你现在做的需求/产品是不是对的，如果这件事做好了，后面的效能提升是事半功倍的。

因为：PMF 做好了，本质上就是为公司构建了以客户为中心的产品和商业模型设计。

通常，CEO 在公司的运营中需要找到“牵引点”，在找这个“点”的时候我们通常会说：以客户为中心去构建一家公司的商业以及服务。

那什么是以客户为中心呢？很大程度上它的源头就是 PMF。

PMF 本质上是回答了“你解决了什么人的什么问题”，然后就是“Good Market”——你的好的市场是什么。PMF 既是定义产品的过程，也是寻找目标客户的过程。只有产品匹配了市场，才能开始规模化扩张。找到 PMF 之前和之后，对公司而言，是完全不同的运营战略选择：

• 找到PMF之前

你通过 PPT、一个产品原型 demo 就能去进行很多的工作，比如：验证这件事有没有人需要，为什么需要。

所以我们完全可以用 MVP 模式去验证PMF，用少量的钱和少量的规模化去试错和调整。如果我们在有明确的找到 PMF 信号之前，进行了规模化，这种规模化投入越大，对后面的影响可能就越大。

通常在企服公司，在某个阶段一定会面临一个思考：营收为什么会趋缓，销售、营收的体系是不是有问题？

如果是在找到 PMF 之前，它会加大你去判断是产品有问题、市场问题、还是销售体系有问题的难度。

• 找到PMF之后

除了规模化之外，在找到 PMF 之后，还有个非常重要的事情——PMF 持续迭代。

它并不是一个新产品从 idea 变成了一个可交付的产品之后，PMF 这件事就停止了，而是应该随着整个产品、客户产生变化的时候而去持续迭代。

我们在做 PingCode 的时候就有个典型的案例：

PingCode 在正式商业化运行之后我们发现，原来对于研发管理的认知是有偏差的——在海外有75%以上的开发模型都是敏捷开发模型，但是国内几乎50%的研发团队是以瀑布开发为代表的传统模型。

这也就意味着 PingCode 在正式商业化之后，需要持续去根据新用户的需求和场景去迭代，并再次验证 PMF。

所以 PMF 并不是一锤子买卖，也不是一刀切的有和无，特别是对于企服公司来说，PMF 是随你的产品、市场、用户往前迭代持续验证的。

• 企业服务产品的PMF挑战

B端企业和C端企业在 PMF 这件事上并不太一样，比如在思考逻辑上，C端是长板逻辑，而B端是短板逻辑。

从客户视角看，C端是消费过程，而B端是投资过程，因为公司购买B端产品的时候需要去评估投入产出这样一件事。

这些差别就决定了B产品它的需求复杂度更高，难以用一些简单的模型或者维度去概括，因此在B端公司找到核心客户的核心需求是非常重要的洞察。

除此以外，因为客户和客户的需求是多变的，但如果你能确定你的核心客户及需求，就能去做产研资源投入的优先级评估，从而一定程度解决产研资源这个难以平衡的矛盾。



PingCode 在PMF上的原则和踩过的坑

原则：

• PMF 是 CEO 和管理团队的头等大事，不仅是产品经理；
• 拉长 PMF 的时间，通常新场景和新产品的周期在12-24个月，广积粮、高筑墙；
• 设定清晰的 PMF 目标，例如目标客户画像、活跃用户数、付费客户数、NPS、严重缺陷率、没有定制化需要、销售轻松、切换竞品的能力；
• PMF 是持续的，随着产品迭代而迭代；
• 同样的逻辑，做好一个聚焦行业客户的 PMF，再启动下一个行业客户的PMF；
• 尽量不做 PMF 以外的客户；

应该避免的弯路：

• 没有清晰的目标用户：你的产品并不能解决所有人的问题；
• 不要过多关注竞品，要关注用户：不同的目标用户，将导致不同的 PMF 逻辑；
• 定制化是 PMF 的对立面；
• 不要照抄海外：开发模型的差异、商业模式的差异、用户习惯的差异、产业形态的差异；

找到PMF，打造以客户为中心的研发工作流

既然 PMF 是构建以客户为中心企业的基石，那么对于公司的产研体系来说，打造以客户为中心的研发工作流其实是做 PMF 这件事的出发点。

如果你是想找对 PMF，并在未来一段时间去定义、迭代 PMF，那么你的产品和研发流程应该是从客户出发。

另外一个要转变的点是，PMF 还要求产研团队不仅关注开发、迭代和效率，更要考虑客户、业务和商业闭环，并体现在产研目标的定义上。因为只有定义在目标上，产研后续的工作流、体系、工具化等等才有可承载的基础。

那么一个以客户为中心的研发工作流应该长什么样？要如何建立？

要建立以客户为中心的研发工作流，在客户洞察、产品研发、反馈响应和用户体验等方面会面临如下挑战：

• 离客户太远，需求真伪难辨，难以洞察客户需求

业务充当客户与产研间二传手，同时通过 Excel 等线下需求传递方式效率低、无法持续积累，并且，需求的理解依赖业务人员和 PO 水平，产研没有可用的通道看到客户需求的原始记录，客户需求真伪难辨、核心需求被忽略。

或者是，有时为了拿下某个大订单，销售会承诺满足客户所有需求；或者客户已适应原来使用的产品，要求必须具备某些功能；或者销售为了应对竞争，提出友商有我们也要有。过分承诺和关注竞争带来了拼凑的、没有灵魂的产品。

PO/PM 往往面临不同客户海量且永无止境的需求，产品优先级“拍脑袋”决定， 如果不对客户统一管理且不区分客户级别，无法通过可度量的方式评估需求价值，就难以找出刚需和真实痛点，从而陷入需求漩涡和陷阱。

不同的客户提出相同的需求，被不同的业务来回反馈，此外，需求来源不仅是客户，还有公司战略目标、内部业务人员等，如此离散的需求，使得客户、业务、产研间信息相互割裂。

• 产品和项目交付时间长，过程和质量不可控

• 响应速度慢，用户体验反馈不好看不好用

PingCode 所提供的的 One Complete DevOps Platform 解决方案，就是阐述如何连接客户、业务、研发，并通过「3步走」策略，打造「以客户为中心的研发工作流」。

深度客户洞察，做正确的产品：有效连接客户、业务、产研，构建以客户为中心的需求深度洞察能力，从需求收集、分析、规划、评审到流转，确保做正确的产品，改善资源浪费。

提升研发效率，把产品做正确：打通需求到研发的无缝流转，构建规划、开发、构建、部署、测试、发布和上线的研发工作流，提升研发效率，缩短产品上线或项目交付速度。同时，通过效能的度量，帮助企服产研团队掌握偏差，持续改进。

反馈响应闭环，构建持续循环：搭建产研与客户的交流通道，产研将需求开发进度、产品路线图和功能更新日志等客户关注的问题实时反馈、同步给客户，实时响应客户，提升客户满意度。

《企服行业研发管理解决方案》以提升 NDR 和 NPS 为方向性指导，基于「3步走」策略，以矩阵化产品和咨询服务为实现路径，帮助企服公司打通客户、业务和产研的协同，抢占市场，提升续约率。

从客户开始的需求全生命周期管理流程分为反馈收集、分析、规划、执行、验证五个阶段。需求反馈收集、分析、规划阶段核心是深度客户洞察，执行阶段核心是提升研发效率，验证阶段核心是建立反馈响应闭环。

为了避免篇幅过长，具体如何通过「3步走」策略，打造「以客户为中心的研发工作流」，以及国内一些头部企服公司的实践，我们将在《企业服务研发解决方案》中详细介绍，大家可通过点击下载完整版方案。