阿裡妹導讀：
之前參加了企業智能部門如何做産品化的讨論，大家對産品化的定義和過程都有各自不同的見解。我覺得這個話題其實可以擴充下，想站在一>個開發人員的視角嘗試探讨一下産品化。下面以自問自答的方式來展開。
1、當我們在談産品化時，我們想的是同一個概念嗎？
為了更好地了解這個問題，首先要解釋“系統、産品、商品”的定義。
我不太想用百科上的通用定義，如：商品是用于交換的勞動産品，這對我們今天的話題沒有指導意義，我嘗試用更貼近我們日常工作上下文的方式來給出定義。
- 系統的定義：各種離散功能組成的功能集合體。
- 産品的定義：有使用價值且封裝良好的可複用功能集合體。
- 商品的定義：以交易為目的的，有使用價值且封裝良好的可複用功能集合體。
舉個例子：我用各種零件制作了一個計時系統，具有計時的功能。給身邊的小夥伴使用沒問題，但拿到市場上去，就會被吐槽的體無完膚，“太醜了，感覺好複雜”。
是以我奮發圖強，給這個計時系統加上了好看的表盤和表帶，封裝成一個顔值高，易操作的産品。看上去專業多了，然後拿到市場上去，就會有人來詢盤，多少錢啊老闆？
于是我給這個産品定了個價格，就成了一個商品。
由此可見，系統可以轉化為産品，産品也可以轉化為商品。
系統轉化為産品的過程就是産品化。産品轉化為商品的過程就是商業化。從系統到産品再到商品，是複雜性逐漸降低，體驗逐漸提升的過程。
2、我們開發人員天天做的東西，是不是産品？
我覺得大部分内部系統開發團隊做的都是介于系統和産品之間的一種形态。很難将我們現在手頭上的幾個應用稱之為産品。
如果一個應用隻能在一個特定場景給一個特定客戶使用，這是一個系統，并不是一個産品。
産品應該是能快速複制給多個客戶使用的。比如：法務、采購、HRM、财務，等用于公司内部營運的應用。可以說是業務能力的集合體，一般滿足内部營運都沒什麼問題。但拿到外面的市場上去繞一圈，曬一曬，不一定有競争力。
更不必說這些系統耦合了很多公司内部的特殊邏輯，依賴了内部的元件，牽一發而動全身，很難直接複制出去給另一個公司使用。是以，公司内的很多系統，為了成為真正的“産品”，紛紛開始做産品化的改造。
比如，公司内部項目協作管理平台AONE是很好用的一個系統，但不能說是一個成熟可複制的産品，是以AONE經過産品化的改造，有了雲上版本“雲效”。
HSF是很好的技術中間件，在公司内部使用廣泛，但拿到雲上售賣還是得經過産品化封裝為EDAS産品。
3、什麼團隊需要做産品化？
如果你覺得你做了幾年的系統，積累了較多有價值的業務能力，在行業裡也有競争力，自信除了現有的使用者，還願意且有能力服務更多客戶的話。你就需要考慮下産品化的事情了。
例子：X産品本來是公司内部使用的辦公協作系統，如今産品化向市場開放。
4、開發團隊希望将維護的系統産品化，該怎麼做？
我手上維護的BUC、SSO、ACL、VDS，這些都是集團内使用廣泛的系統。
最近一直在做這些系統的産品化，封裝成一個産品叫做MOZI（墨子），兩年來，目前這個産品已經服務了集團經濟體生态20多個BU的200多個業務；同時作為基礎能力輸出到數字政府領域，已經在多個業務領域證明了産品價值。
我從我們自己産品化的經驗來講，如果手頭已經有個系統，在這個基礎上想做産品化的話，比較粗略的分，開發團隊做産品化具體可以分為以下幾個步驟：
1）産品能力的積累和建設；
2）低成本的可快速複制；
3）優化使用者體驗。
産品能力的積累和建設
比較容易了解，我們需要提升産品的使用價值，使用價值是客戶來衡量的。對标業界競品，有差距的補全差距，有優勢的鞏固優勢。這個過程是持續改進的。
低成本的可快速複制
産品要有能力快速服務不止一家客戶，這裡客戶使用方式分為saas方式和專有化傳遞方式，saas方式就必須要支援多租戶的能力，專有化傳遞方式的話，就需要盡可能的降低産品傳遞的成本，包括需要占用的伺服器數量，依賴的三方軟體等。
去掉不必要的功能，提供最小子產品功能集，最好可以讓客戶自定義功能集，僅對使用的功能付費。
優化使用者體驗
這個沒啥說的，現在這個時代，顔值就是正義，"dont make me think"。優化視覺，優化互動，優化體驗這三件事情要持續打磨。
5、産品化需要多少投入？
産品化是個持續改進，無限接近完美的過程，而不是一蹴而就，從0到1的變化。
技術部做了個A工單系統，給公司内部的客服人員使用。雖然界面很醜，bug一堆，但獨此一家，别無分店，客服隻能一邊嫌棄着一邊繼續用。
另一個技術部也做了個B工單系統，在産品品質和使用者體驗上深度打磨，推出以後，口碑越來越好，使用者越來越多，大量客服紛紛棄前者而來。
從使用者視角看，B工單系統的使用價值比A工單系統高。
換句話說，B工單系統的産品化程度比較高。B比A更像産品。如下圖所示，B比A的産品化成熟度更高。
但須知“文無第一，武無第二“，B也沒法知道自己的優勢能保留多久，也許馬上會有其他産品化程度更高的C産品出現。為了保持領先，不得不持續更新自己的産品功能和體驗。
6、産品化的建議路徑是什麼？
當然完整的産品化路徑并不僅僅是開發的事情，而是PD、UED、營運、開發、傳遞、商業一起參與的大工程。
我嘗試梳理了下從0到1做産品化的一般路徑，不一定對，以後可能還會補充和删減。
1）定義客戶和使用者，給出客戶畫像；
2）定義客戶需求痛點以及産品主要解決的問題；
3）定義産品核心功能和護城河；
4）明确價值和市場定位；
5）建設産品能力：面向客戶；
6）建設配置能力：面向傳遞；
7）建設開發工具：面向開發（插件生态，小程式生态）；
8）降低成本，快速可複制；
9）優化和打磨使用者體驗；
10）定義商業模式和盈利模式（可選）；
11）定義計費方案（可選）；
12）建設标杆應用（對于平台類産品适用，如宜搭）；
13）聯合行業領袖建立标準（頭部玩家适用，如office）。
7、終極問題：如何做一個優秀的網際網路産品？
既然是終極問題了，我沒法給出标準答案了，歡迎大家在留言區互動、探讨。