[摘要]
從項目制到產品制，說來只有6個本質不同，但實施起來並非易事。所有產品都需要每兩週發佈一次嗎？不管什麼類型的產品，都需要投入大量精力做用戶研究嗎？是否每個產品都應有一致的增長和運營策略？哪些產品做“虛擬”端到端團隊就夠了、哪些產品必須有“實體”的端到端團隊？怎樣才算夠“產品化”了？
“什麼是數字產品我大概瞭解了，Top 10的戰略產品我們也薅出來了，然後呢，下一步該怎麼辦呢？”
“有些是技術平臺型的產品，也需要兩週發佈一次嗎？”
“我們已經盡力讓業務、運營、開發和測試都坐一起了，這樣是不是就夠了？”
“從項目制到產品制，中間有很多過渡態我能理解。那到底要多‘產品化’才算夠了呢？我們做了用戶研究、制定了成效價值指標，是否就已經足夠‘產品化’了呢？”
“......”
作為組織中產品制轉型的推動者， 在“確定正確的產品邊界”以後，可能很快就會想到這幾個問題。從項目制到產品制，說來只有6個方面的不同，但要實施起來，卻沒有可以一二三按部就班的套路。上面這些問題的背後，本質上是源於：
- 如何認知當前產品化運作的狀態？產品化運作包括哪些實踐？哪些實踐夠了，哪些實踐還不夠？
- 各種不同類型的產品，產品實踐的側重點會有不同嗎？
- 如果想要提升產品化運作的成熟度，如何設置適宜、合理的目標狀態？
- 轉型的路線是如何的，哪些產品實踐是應該儘快去實施的，哪些實踐可以緩緩？
本篇就來談談這些問題。
1. 如何認知當前產品化運作的狀態？
前文談到，產品制的本質之一，是要如何應對“不確定性”，構建快速響應外部變化的能力；
而從另外一面看，我們看到了數字產品的容器——大型組織作為一個超級複雜系統，所具有的“複雜性”，與天生具有產品基因的中小型互聯網企業相比，這是轉型組織所遇到的完全不同的一面。
在應對外部不確定性上，有四個值得考量的維度：
- 用戶中心（User-centered）：項目制裡面基本上是忽略用戶的，只是按計劃去執行；產品思維最核心之一，就是要以用戶（注：這裡泛指產品的購買者及使用者，下同）為中心，深入洞察用戶，挖掘用戶真正需要的，解決用戶真正的問題，要求團隊有足夠深入的用戶研究和洞察實踐，真正同理到用戶、洞察不同細分用戶群體的需求、主動探索與用戶一起共創方案等。
- 價值驅動（Value-driven）：以產品為中心，要求管理的核心要素從項目的範圍、時間和成本轉向給用戶帶來的實際價值和質量。產品願景是否清晰？願景目標是否完全對齊？是否有基於用戶實際價值的成功度量？是否綜合考慮了用戶、客戶（購買者）等多方干係人、短期和長期的綜合價值？是否提前就需求設想的價值進行了驗證？是否總是基於價值進行優先級排序？
- 快速響應（Rapid Response）：對於不斷變化的環境和用戶問題，是否總能小步前進、快速上線驗證、滾動規劃頻繁發佈？有明確跟蹤從想法到上線產生效果的週期、並努力縮短這個週期嗎？
- 持續增長（Continuous Growth）：從0到1後，是否能端到端地對產品的整個生命週期負責，持續關注產品的增長？有明確的獲客策略和留存策略及渠道嗎？是否進行持續的成效指標數據跟蹤、並根據數據來調整策略？
在應對組織內部複雜性上，有兩個不可忽略的維度：
- 溝通協作（Communication & Collaboration）：團隊是否對產品有強烈的Owner意識？產品團隊契約的關鍵儀式是否總能按時開展？是否都主動溝通、通過有效地會議進行決策？跨部門跨團隊地協作是否順暢？有沒有持續積累產品、業務、技術、實踐等一切相關的知識庫、並形成持續分享的學習文化?
- 治理管控（Steering & Governance）：團隊產品相關的願景、目標、決策信息是否充分透明可視？組織是否能容忍失敗、不斷培育實驗文化？是否構建了充分的跨職能團隊、團隊是否能夠充分自組織？是否支持滾動預算？是否形成持續改進的習慣和文化？
如果把這內外部的六個考量維度放在一起，就會形成如下的一個框架（Digital Product Management Framework, 以下簡稱DPMF)。以這個框架為一個基點，通過考量在這些維度上的實踐情況，可以對組織當前產品化運作的狀態建立一個初步、系統的認知。
圖1 認知數字產品管理的成熟度 - DPMF
圖2 認知數字產品管理的成熟度 - 不同維度下的產品實踐
比如價值驅動維度：
- 產品願景定位（Product Vision Clarity）：產品願景、價值定位、願景陳述（電梯演講）等；
- 願景目標對齊（Visions & Goals Alignment）：戰略目標上下對齊（精益價值樹）、產品路線圖、可視化規劃路線等；
- 成功度量（Measures of Success）：成效指標體系、目標度量、機會點度量、舉措度量、特性度量等；
- 系統性價值分析（Holistic Value Analysis）：價值決策因子矩陣（涵蓋所有干係人、短中遠期)；
- 早期價值驗證（Value Validation）：原型測試、MVP等；
- 持續按價值優先級排序（Continuous Value-based Prioritization）：價值決策矩陣、週期性優先級決策會。
2. 各種不同類型的產品，產品實踐的側重點有什麼不同嗎？
“數字產品在組織中的核心定位”，即數字產品所提供的核心能力，如果粗略地來講，有三種傾向性：
種傾向性：
圖3 以一個大型金融企業為例，數字產品的核心能力
- 業務流程/邏輯導向型（Business-oriented）：數字產品的核心價值在於對於核心業務流程、業務邏輯自動化和封裝，比如金融企業中的支付結算系統、卡管理系統、統一支付平臺，業務中臺服務如統一賬戶服務，以及內部作業系統如移動辦公應用、採購系統等；
- 用戶體驗導向型（Experience-oriented ）： 數字產品的核心價值在於為用戶提供在各個觸點上都非常好的互動體驗，比如手機銀行、線上理財、在線投融資、金融教育視頻內容等；
- 技術能力導向型（Technology-oriented or Data-oriented）：數字產品的核心價值在於提供不可或缺的技術或數據能力，比如DevOps平臺、基於大數據分析的用戶畫像中臺服務、通用技術能力AI算法服務等；
圖4 企業中的數字產品型 B.E.T
這三種不同模式的產品，在產品管理實踐的側重點要求是不同的：
- 模式B - 重點投資的業務邏輯導向型數字產品：此模式的產品，在價值驅動、溝通協作和治理管控維度上需要更高的成熟度；
- 模式E - 重點投資的用戶體驗導向型數字產品：此模式的產品，在用戶中心、價值驅動、快速響應、持續增長等方面需要更高的成熟度；
- 模式T - 重點投資的技術能力導向型數字產品：此模式的產品，則在價值驅動、 溝通協作、治理管控上需要更高的成熟度。
3. 提升產品化運作的成熟度，如何設置適宜、合理的目標狀態？
圖5 ThoughtWorks數字產品管理成熟度模型 - 實踐成熟度等級
為了提供指引，在DPMF中，提供了從-1到3五個級別的成熟度等級。以成功度量實踐為例，這五個級別的含義分別為：
圖6 ThoughtWorks數字產品管理成熟度模型 - 實踐成熟度等級示例
所有產品都需要每兩週發佈一次嗎？不管什麼類型的產品，都需要把用戶研究做到極致嗎？是否每個產品都應有“一致”的增長和運營策略？哪些產品做“虛擬”端到端團隊就夠了、哪些產品必須有“實體”的端到端團隊？答案肯定是不同的，甚至整個組織本身的狀態也會影響到成熟度目標的設定，好比變速檔要適合坡的高度，否則適得其反——“流暢”就好，而不是“等級越高越好”。
例如，在一個“數字化轉型”有著廣泛認知、“敏捷性”深入人心、科技為核心、IT基礎平臺和創新基礎設施已到位的組織裡，產品制相對來說有一個較好的土壤，在產品管理成熟度目標可以設置相對得高一些，如模式B的價值驅動、溝通協作、治理管控維度都設置到了最高；模式E則在用戶中心、價值驅動、快速響應和持續增長都設置到了最高；模式T則在價值驅動和治理管控上接近最高。
圖7 不同數字產品型的成熟度目標要求不同
4. 如何構建一個有效的轉型路線？
如果應用模型，想要對組織內產品運作的成熟度進行評估，建議步驟如下：
- 參考上面的數字產品型定義B.E.T，在組織中識別出需要評估的重點產品；
- 設定組織中B類型、E類型、T類型的在各個維度上的目標；
- 深入瞭解和熟悉每個產品的背景、特點，以及確認是模式B、E還是T；
- 對每個產品，通過團隊成員訪談、實踐活動觀察、輸出產物查驗等方式，依次針對6個維度，對照每個分類實踐的等級定義，識別每個分類實踐當前的狀態；
- 參照組織中對應產品型的目標狀態，設置該產品在3-6個月左右想要達到的目標狀態，建議選取1-2個重點維度進行提升；
- 識別在這1-2個重點維度上應提升的實踐能力（含團隊級別的實踐和組織級別的實踐）
- 制定出3-6個月內的實踐能
下圖展示了，一個組織中3個產品團隊的成熟度評估結果，可以看出，每個產品團隊提升的側重點實踐會是不同的。
圖8 不同數字產品型成熟度目標要求不同
藉由成熟度評估的結果，對比組織中對相應產品型的成熟度目標，那就可以制定出相應的實踐實施路線圖：
- 按照產品目標相關性及緊急性兩個維度，把與目標有差距的實踐放在這個矩陣上；
- 第一優先級為近期聚焦實踐；第二優先級為中期聚焦實踐；第三優先級為遠期聚焦實踐。
如圖所示，這是上圖中的統一支付平臺產品團隊的實踐實施路線圖：
圖9 產品團隊實踐實施路線圖-示例
值得注意的是，在進行實踐能力提升時，一些是團隊內部自己可以提升的，比如成效度量、用戶研究；一些卻是在組織層面支撐需要提升的，比如滾動預算、跨職能團隊。
5. 該如何有效使用DPMF？
圖10 應該如何理解並使用DPMF
- 這僅可用作一個參考框架，而不能作為一個通用的固定模型。如同《成熟度模型：罪與罰》中提到的，“只有結合組織和業務上下文的成熟度模型才可能產生正向的成效”，並不存在一個“普適的”、“標準的”產品成熟度模型。每個組織都要基於自己的外部環境和業務上下文，來去選擇其中的維度，或者補充其他的維度，或者是把某個維度細化、拆解，基於自己組織的情況來定製或裁剪。
- 即便是定製好的產品成熟度管理模型，目的也只是為了得到更全局的系統性認知、站在組織視角去審視產品制轉型的聚焦點，而不是為了評估和解決數字產品本身的問題。例如，當發現組織產品創新性不足的時候，不是簡單地去讓各個團隊在規定時間內提交若干“創新的idea“，而是系統性地看看，主要問題出現在哪方面：是因為沒有足夠的用戶調研能力？沒有為市場調研和用戶研究提供投入？還是戰略目標不清晰、行動舉措忽左忽右？還是組織缺乏“實驗文化”，團隊因為害怕“失敗的創新嘗試”影響績效而不敢有所行動？
- 各個維度上的衡量結果，不反映不同組織進行橫向對比的優劣，也不能反映出不同團隊的績效差異，不能用作對團隊績效的衡量。
- 實踐成熟度要達成的目標，應追求“流暢”——即與組織上下文匹配，而不是越高越好；不用去攀比，非要達成一個看起來“很高”的等級，走形式化會適得其反。
- 即便是定會好的評估模型，僅僅是為了有一個認知基點，需要不斷演進和迭代，而不是提供一套行為規範、強制所有團隊一成不變地照此執行。
下一步？
瞭解了當前組織中產品化運作的成熟度，如何有效提升團隊的產品實踐能力？團隊級實踐怎麼辦？組織級實踐怎麼辦？如何能實現更輕量級的規劃？數字產品的成效和進展如何度量？且等後續分解。
文/ThoughtWorks 亢江妹 王汝佳
更多精彩商業洞見，請關注微信公眾號：ThoughtWorks商業洞見
