本篇文章將圍繞以下問題展開：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步走」策略，以矩陣化產品和諮詢服務爲實現路徑，幫助企服公司打通客戶、業務和產研的協同，搶佔市場，提升續約率。
從客戶開始的需求全生命週期管理流程分爲反饋收集、分析、規劃、執行、驗證五個階段。需求反饋收集、分析、規劃階段核心是深度客戶洞察，執行階段核心是提升研發效率，驗證階段核心是建立反饋響應閉環。
爲了避免篇幅過長，具體如何通過「3步走」策略，打造「以客戶爲中心的研發工作流」，以及國內一些頭部企服公司的實踐，我們將在《企業服務研發解決方案》中詳細介紹，大家可通過點擊下載完整版方案。