本篇文章将圍繞以下問題展開：1、PMF（産品和市場的匹配度）是什麼？2、為什麼它對企業服務公司如此重要？3、企服行業要如何找到自己的PMF

PMF和産研體系都是比較大的話題，但随着SaaS公司的業務從初級階段走向規模化增長階段，這也是必然被産品團隊/創始團隊關注的問題。

希望通過這次發布會，分享我們 PingCode 團隊在 PMF 上的認知，以及如何構建以客戶為中心的研發工作流，來實現在 PMF 的進化，進而找到 PMF 的過程。

本文整理自PingCode CEO 企服發布會演講

之所以在 PMF 上會有深刻的體會，是因為公司成立十多年我們自己在這上面踩了非常多的坑。

比如下圖“紛纭”這個産品，它定位非常像現在的 Slack。因為産研團隊的能力非常強，所以我們認為自己所有的事情都能做，這也是非常多的創業公司在初期都會犯的“毛病”——别人能做的東西，憑我們自己的技術實力應該能以更快的速度疊代出一個原型，并推向市場。

所以用了9個月的時間把産品做出來，但在推廣兩個月之後，我們決定把這個産品關了。因為複盤“紛纭”在國内商業機會之後，我們發現：

來自美國的經驗和需求，可能在中國是完全不同的：一方面，在國内基于團隊之間的溝通，微信已經成為一個溝通的基礎平台，留給其他IM的機會非常少。

另一方面，Slack 在美國是想解決不同工具/服務之間的連接問題，構建統一的消息聚合平台。而國内的 SaaS 還沒有發展到成熟期，所以用戶根本不需要這樣一個工具。

所以這件事，對我們在打造 Worktile、PingCode 時候有一個重要的啟示就是——銷售和增長不給力，通常情況下，大部分原因是沒有找到 PMF。這也是我和很多企服公司 CEO 聊到的非常有共鳴的一件事。

如果跳出我們自己再去看中國以及國外公司的情況：

• 75% 的公司創始人，無法清晰的回答：誰是你的客戶，你解決了客戶什麼問題？
• 80%的公司從來沒有找到過 PMF，沒有造出過真正有人需要的産品（數據來源：Y Combinator）
• 在定義清楚 PMF 之前，98%的公司都把時間用錯了地方（數據來源：Marc Andreessen）
• 70%公司失敗的第一大原因是：産品不被市場需要
• 在矽谷，能完成PMF的創業公司不到10%，所以 PMF 是一件很難的事

世界上隻有兩種公司，有PMF的，和沒有PMF的——PMF創始人Marc Andreesen

其實很多人對 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端公司找到核心客戶的核心需求是非常重要的洞察。

除此以外，因為客戶和客戶的需求是多變的，但如果你能确定你的核心客戶及需求，就能去做産研資源投入的優先級評估，從而一定程度解決産研資源這個難以平衡的矛盾。

原則：

• PMF 是 CEO 和管理團隊的頭等大事，不僅是産品經理；
• 拉長 PMF 的時間，通常新場景和新産品的周期在12-24個月，廣積糧、高築牆；
• 設定清晰的 PMF 目标，例如目标客戶畫像、活躍用戶數、付費客戶數、NPS、嚴重缺陷率、沒有定制化需要、銷售輕松、切換競品的能力；
• 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步走」策略，打造「以客戶為中心的研發工作流」，以及國内一些頭部企服公司的實踐，我們将在《企業服務研發解決方案》中詳細介紹，大家可通過點擊下載完整版方案。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!