企业要如何建立适合自己的PMF？

本篇文章将围绕以下问题展开：1、PMF（产品和市场的匹配度）是什么？2、为什么它对企业服务公司如此重要？3、企服行业要如何找到自己的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步走」策略，以矩阵化产品和咨询服务为实现路径，帮助企服公司打通客户、业务和产研的协同，抢占市场，提升续约率。

PingCode 企服行业「以客户为中心的研发工作流」解决方案（整体框架）

PingCode 企服行业「以客户为中心的研发工作流」解决方案（业务流程及矩阵产品）

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

需求全生命周期管理阶段

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