本篇文章将盘绕以下问题展开：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这件事的现状如何？假如跳出我们自己再去看中国以及国外公司的状况：
世界上只需两种公司，有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 之前和之后，对公司而言，是完整不同的运营战略选择：
你经过 PPT、一个产品原型 demo 就能去中止很多的工作，好比：考证这件事有没有人需求，为什么需求。 所以我们完整能够用 MVP 方式去考证PMF，用少量的钱和少量的范围化去试错和调整。假如我们在有明白的找到 PMF 信号之前，中止了范围化，这种范围化投入越大，对后面的影响可能就越大。 通常在企服公司，在某个阶段一定会面临一个思索：营收为什么会趋缓，销售、营收的体系是不是有问题？ 假如是在找到 PMF 之前，它会加大你去判别是产品有问题、市场问题、还是销售体系有问题的难度。
除了范围化之外，在找到 PMF 之后，还有个十分重要的事情——PMF 持续迭代。 它并不是一个新产品从 idea 变成了一个可托付的产品之后，PMF 这件事就中止了，而是应该随着整个产品、客户产生变更的时分而去持续迭代。 我们在做 PingCode 的时分就有个典型的案例： PingCode 在正式商业化运转之后我们发现，原来关于研发管理的认知是有倾向的——在海外有75%以上的开发模型都是矫捷开发模型，但是国内简直50%的研发团队是以瀑布开发为代表的传统模型。 这也就意味着 PingCode 在正式商业化之后，需求持续去依据新用户的需求和场景去迭代，并再次考证 PMF。 所以 PMF 并不是一锤子买卖，也不是一刀切的有和无，特别是关于企服公司来说，PMF 是随你的产品、市场、用户往前迭代持续考证的。
B端企业和C端企业在 PMF 这件事上并不太一样，好比在思索逻辑上，C端是长板逻辑，而B端是短板逻辑。 从客户视角看，C端是消费过程，而B端是投资过程，由于公司置办B端产品的时分需求去评价投入产出这样一件事。 这些差别就决议了B产品它的需求复杂度更高，难以用一些简单的模型或者维度去概括，因而在B端公司找到中心客户的中心需求是十分重要的洞察。 除此以外，由于客户和客户的需求是多变的，但假如你能肯定你的中心客户及需求，就能去做产研资源投入的优先级评价，从而一定水平处置产研资源这个难以均衡的矛盾。 PingCode 在PMF上的准绳和踩过的坑准绳：
应该避免的弯路：
找到PMF，打造以客户为中心的研发工作流既然 PMF 是构建以客户为中心企业的基石，那么关于公司的产研体系来说，打造以客户为中心的研发工作流其实是做 PMF 这件事的动身点。 假如你是想找对 PMF，并在未来一段时间去定义、迭代 PMF，那么你的产品和研发流程应该是从客户动身。 另外一个要转变的点是，PMF 还请求产研团队不只关注开发、迭代和效率，更要思索客户、业务和商业闭环，并体往常产研目的的定义上。由于只需定义在目的上，产研后续的工作流、体系、工具化等等才有可承载的基础。 那么一个以客户为中心的研发工作流应该长什么样？要如何树立？ 要树立以客户为中心的研发工作流，在客户洞察、产品研发、反响响应和用户体验等方面会面临如下应战：
业务充任客户与产研间二传手，同时经过 Excel 等线下需求传送方式效率低、无法持续积聚，并且，需求的了解依赖业务人员和 PO 水平，产研没有可用的通道看到客户需求的原始记载，客户需求真伪难辨、中心需求被疏忽。 或者是，有时为了拿下某个大订单，销售会承诺满足客户一切需求；或者客户已顺应原来运用的产品，请求必须具备某些功用；或者销售为了应对竞争，提出友商有我们也要有。过火承诺和关注竞争带来了拼凑的、没有灵魂的产品。 PO/PM 常常面临不同客户海量且永无止境的需求，产品优先级“拍脑袋”决议， 假如错误客户统一管理且不分辨客户级别，无法经过可度量的方式评价需求价值，就难以找出刚需和真实痛点，从而堕入需求漩涡和圈套。 不同的客户提出相同的需求，被不同的业务来回反响，此外，需求来源不只是客户，还有公司战略目的、内部业务人员等，如此离散的需求，使得客户、业务、产研间信息相互割裂。
PingCode 所提供的的 One Complete DevOps Platform 处置计划，就是论述如何衔接客户、业务、研发，并经过「3步走」战略，打造「以客户为中心的研发工作流」。
深度客户洞察，做正确的产品：有效衔接客户、业务、产研，构建以客户为中心的需求深度洞察才干，从需求搜集、剖析、规划、评审到流转，确保做正确的产品，改善资源糜费。 提升研发效率，把产品做正确：打通需求到研发的无缝流转，构建规划、开发、构建、部署、测试、发布和上线的研发工作流，提升研发效率，缩短产品上线或项目托付速度。同时，经过效能的度量，辅佐企服产研团队控制倾向，持续改进。 反响响应闭环，构建持续循环：搭建产研与客户的交流通道，产研将需求开发进度、产品道路图和功用更新日志等客户关注的问题实时反响、同步给客户，实时响应客户，提升客户称心度。 《企服行业研发管理处置计划》以提升 NDR 和 NPS 为方向性指导，基于「3步走」战略，以矩阵化产品和咨询效劳为完成途径，辅佐企服公司打通客户、业务和产研的协同，抢占市场，提升续约率。
PingCode 企服行业「以客户为中心的研发工作流」处置计划（业务流程及矩阵产品） 从客户开端的需求全生命周期管理流程分为反响搜集、剖析、规划、执行、考证五个阶段。需求反响搜集、剖析、规划阶段中心是深度客户洞察，执行阶段中心是提升研发效率，考证阶段中心是树立反响响应闭环。
需求全生命周期管理阶段 为了避免篇幅过长，细致如何经过「3步走」战略，打造「以客户为中心的研发工作流」，以及国内一些头部企服公司的理论，我们将在《企业效劳研发处置计划》中细致引见，大家可经过点击下载完好版计划。 |
名表回收网手机版
