ToB產品從0到1：從項目中走出來

雖然說可復制的項目具備成為產品的基礎，產品交付的過程其實就是項目的體現，但是項目轉化產品并不容易，最重要的決定因素是什么？

我認為是人，只有人才是推動事情往哪個方向前進的核心驅動力。

領導項目的是項目經理，他更關注的是什么？交付！

他考慮更多的是進度、質量、成本和資源的平衡，而能否形成產品并不在其職責范圍內。驅動產品前進的是產品經理，但產品經理在項目中，首要的是根據項目經理的計劃完成需求分析和原型設計，其次才是產品通用性的抽象，正常交付是驅動項目的核心力量，滿足交付的基礎上才有可能去做產品的轉化，所以項目沉淀產品為何不容易，因為項目交付往往資源不足，進度延期，你懂得，這樣的環境還想完成產品轉化的目標那就天方夜譚。

雖然從項目沉淀產品不容易，但是對于ToB的產品來說，項目依然是產品誕生的重要渠道，甚至是首要渠道，為什么？

首先從產品經理這個角度來講，ToB的產品經理比ToC的產品經理更難做，ToC的產品經理往往自己就是用戶，對于用戶需求的把握、對用戶體驗的優化更有方向和感覺，而ToB的產品使用者是特定領域的用戶，而產品經理通常沒有該領域的經驗，即使做過這個行業，相比于用戶來說，經驗依然是欠缺的，如果不深入這個行業，不和特定的人群去親密接觸，就很難獲得真實的需求。

而項目恰恰是獲取真實需求的來源，客戶提供真實的需求，我們負責設計實現，這對我們研發產品也是有幫助的。

用下圖來簡單做個形象的說明，產品的成熟度=業務熟悉程度*研發時間，假設我們產品0-1的產品成熟度是確定的，業務越熟悉，需求越明確，我們研發的周期就越短，反之研發周期就越長。

所以當我們產品人員缺乏行業經驗時（完全依賴產品經理經驗部分為B），為了更快的讓產品成熟，借助項目中實際的客戶經驗來彌補（區域A），是一種重要的方式。

當然我也曾見過少數的ToB的創業者，他們可以不借助項目，在0-1的階段就是在家里“閉門造車”，最后推向市場也能成功，但是這種情況一般情況是創業者在這個行業里浸染很久，對行業的痛點，對行業的需求都有著超出大部分從業者的理解，如上圖虛線部分，那么對于他們來說可以不用過多的借助項目來孵化就能很快達到1的狀態。

其次，即使我們自己對于行業非常了解，對于用戶需求洞察非常到位，但是ToB的產品有一個非常大的特點：使用者并不是決策者，這也是和ToC產品在商業化方面本質的不同，所以許多做ToB的產品經理在經歷了產品研發之后，發現產品根本無法賣出，B端機構根本不采用，其中一個很重要的原因是，B端機構中那個重要的決策者不愿意使用。

從這個角度上來說，沒有賣出去的產品，就不能說完成了0-1的過程，因為對于決策者需求的滿足還沒有實現，可能這個功能就是我們非常鄙視的華而不實的功能。

所以借助項目，我們更容易和決策者交流，更容易get到他們的需求，從而完善我們對于需求的認知，從而更有助于做一個能被賣出去的產品。

最后，從產品研發的風險考慮。ToC的產品前期的研發風險是非常大的，因為它的回報周期太長，它需要一個量變到質變的過程，也就意味著質變之前可能是毫無收益的（ToC產品已經習慣了免費模式）。

但是ToC的產品是具備規模效應的，一旦爆發就會勢不可擋，實現幾倍幾十倍甚至幾百倍的增長，所以ToC的產品前期都是靠商業模式拿融資。

但對于ToB的產品的特點是它是線性增長的，很難大規模的爆發，所以前期不明朗的時候，是很難靠融資來發展，而項目既能為自己獲得收益，又能為自己獲取最真實的需求，那么創業的風險就會很低。所以很多ToB產品創業者大部分都是機緣巧合有了一些項目機會后，才走上自主研發產品的道路的。

并不是所有的項目都能轉化為產品，也不是所有的組織都具備轉化產品的能力，否則，每個軟件外包公司都會成為產品工廠。

做項目更多關注短期利益，快進快出是追求的狀態，但做產品是選擇長期的方向，追求的是未來的溢價。

不管是你一開始定位做產品還是半道決定轉產品，首先都要基于自身現狀選擇做什么樣的產品。沒有方向，所有的機會都是匆匆過客，只滿足一時的快感。

一個立志于做產品的公司，首先得成立類似產品委員會的決策組織，來選擇并定義我們的產品。在這一階段，我們需要討論明確產品的定位、目標客戶、市場預期以及上市計劃。產品的方向是我們選擇項目的重要指標，適合打造產品的項目，哪怕不掙錢都可能是有價值的。

我有朋友創業做軟件外包，老早就確定了產品方向，因為手里握有這個方向的幾個項目，但是幾年過去了，依然沒有形成產品。項目孵化產品，不僅僅只有方向就可以完成，你必須有轉化產品的路徑。

我們都知道０到１的過程非常關鍵，但我們往往忽視去定義１的狀態，導致產品轉化的過程遙遙無期。

如何定義產品１的狀態？每個團隊可能定義的標準不同，我們是把第一個目標客戶正常使用（功能使用率70％以上）作為１的狀態。這里面核心的關鍵詞是“目標客戶”，這也是為什么產品定義階段要確定目標用戶，這是產品商業化的方向（你要知道產品賣給誰）。比如你做一個滿足基層醫療的信息化產品，但是你卻選擇了一個大型三甲醫院作為產品孵化的合作客戶，自然是不合時宜的。

找到合適的目標客戶，如果對方愿意陪你一起打造產品，那將是一件幸福的事情。只有能讓第一個目標客戶使用起來，基本上就覆蓋了產品七八成的需求，這為后面產品的標準化奠定了基礎。當狀態１達成以后，我們就開始著手標準化產品研發及市場推廣的活動。

在《沒有匹配的研發組織，如何實現高效的產品研發》中，我曾非常強調了組織架構在產品研發過程中的重要性，職責清晰是決定一個組織運轉是否順暢的基礎。同時也介紹了康威定律在IT架構層面不可忽視的影響。

在研發團隊承擔項目交付的一段時間里，我深刻的體會到職責錯位最終導致的是團隊間協作的不順暢以及過程中解釋的成本太高的各種問題。

我一直堅持認為，產品研發和項目交付是兩條不同的執行模式，一個側重產品管理，一個側重項目管理；一個產品經理驅動，一個項目經理驅動；一個關注長期價值，一個關注短期回報；一個自我迭代，一個客戶優先；一個需要團隊穩定，一個需要人員彈性。

所以用一個團隊承擔兩種職能，吃著碗里瞧著鍋里，事實證明啥都吃不好，產品上的要求會影響項目交付，一味的滿足項目交付讓你根本沒有精力按照產品思維執行。

如果公司要以產品研發為方向，就要設置穩定的產品研發團隊，以預算控制，保證人員穩定，盡量不要讓項目不停的搶占研發資源，才能保證產品輸出。

項目團隊可以基于市場需求動態增減，以利潤控制為主，項目開發人員在項目間歇可以適當支持產品研發。

總之，你想做產品，就要有意識的向產品研發傾斜資源，而不是讓產品研發天天去支持項目！

傳統的管理模式大家都習慣了部門層級的單線條管理方式，這也導致部門墻高筑，影響協同，而IT項目和研發又是高度協同的。高層以關注事情為核心，但基層以關注成長為核心，所以以事情為管理路線會導致技術資源分散，不利于技術能力的提升。

如果只考慮專業線的管理，以前端開發、后端開發等維度來管理，又讓產品線的人員變得不穩定，從而缺乏責任感。所以結合IPD的研發管理體系，產品線和專業線矩陣管理，組建產品開發團隊（簡稱PDT）。

PDT是一個依產品線的建立而動態組織起來的實體組織，成員在產品開發期間一起工作，由PDT經理全權負責。

參加PDT的人員需要接受雙重領導，這些人員本身的歸屬還是原來的職能部門或業務執行部門，只是被借調到PDT之中來工作，日常的工作接受PDT的指揮與考核，但如果該人員不能勝任PDT的工作，PDT有權將該人員退還給其原部門，并可要求該部門再重新派遣合適的人員參加PDT工作。

同時，對于相對穩定、團隊有一定規模的PDT，也可以團隊自治，獨立管理，實現高度的敏捷。即IPD和敏捷兩種模式的融合。

對于產品從0-1的階段，特別是以項目孵化為主的階段，建議以組建項目開發團隊按照項目交付方式為主執行，同時配備少量關鍵的產品研發崗位，負責推進產品孵化工作。

很多外包公司也想做產品，但往往毫無進展，大部分原因都是根本就沒重視設置產品研發的組織，靠項目團隊就能把產品孵化出來，簡直就沒有可能。

上文我們也分析了項目更關注短期利益和效果，成本控制，進度控制是非常嚴格的，所以我們在設計技術架構時一般會比較功利，這也間接的導致一個技術架構的問題就是代碼耦合在一起，功能擴展性不足。

而產品要滿足更多客戶的需求，對于系統的通用功能的抽象更強，要求的擴展性更高。所以從技術角度來說，單一項目架構≠產品架構。

擴展性的產品架構會帶來額外的項目成本和開發時間，但缺失擴展性設計的項目架構后期轉化產品所帶來的成本可能更高（特別是經過多個項目分化后），我見過很多做過多個項目后轉化做產品基本都要重新開發的案例，就是基于項目的架構無法支撐產品的發展。

為了平衡技術架構帶來的長期價值和當前成本，我們首先要本著以終為始的演化思維去推進產品發展，首要建立分層的架構體系：

①實現技術框架和項目工程的分離；

②實現平臺工程和項目工程的分離；

③實現平臺工程、產品工程和項目工程的分離。

根據不同的發展階段選擇合適的分層架構，上層依賴下層，上層的功能通過不斷抽象和擴展從而沉淀到下層，從而實現項目向產品，向平臺的轉化。

最后從企業發展階段這個角度來看產品發展，初創階段要孤注一擲，用一兩個項目孵化拳頭產品；發展階段可以節外生枝，拓展產品周邊的項目實現產品的完善；成熟階段要百花齊放，實現產品在更多場景的延展；衰退階段要推陳出新，拓展新項目，尋找新賽道，實現產品創新。