本人近10年都在從事企業數字化轉型相關事宜，尤其近4年重點在做2B數據中臺和數據應用產品。為了方便大家能更好得把“價值主張畫布”真正用起來，更好得助力“企業數字化賦能”，談談個人目前對此畫布的理解和建議。
1. 這張價值主張畫布, 邏輯上看著很清晰， 主要強調的是“解決方案”要和“客戶問題”相對應。
2. 但把“客戶問題”分為"Pains”和 “Gains”, 容易產生重復和混淆。
? 對於同壹個問題A， 從負面的角度來感受, 它就是 "Pain"（痛點），會出現在畫布右邊下方的“Pain區域”; 如果這個痛點問題解決了, 就會帶來"收益"，換成正面的描述方式，就可以出現在畫布右邊上方的“Gain區域”。（大多數人會把“Gains"理解成“收益”）
與此同時，畫布左邊的解決方案，分成了上下2個區域，"Pain Relievers"的方案對應解決的是右邊下方“Pain區域”的問題；“Gain Creators"的方案對應解決的是右邊"Gain區域的問題。但對於我們這個case, 實際上解決的是同 1個問題。
這麽分析下來，對於企業數字化建設而言，把右邊問題區域分成"Pains, Gains”, 容易造成重復和混淆，並不是壹個合理的分法。
3. 在企業數字化實踐過程中，有 2 類主要問題，若能解決好，都能貢獻業務價值 ：
壹類是“痛點”（業務用戶/外部客戶，已感受到痛苦，期待解決）；另壹類是“甜點”（往往是些創新點，用戶尚無感，但如果做出來的話，可以帶來明顯的增值或讓客戶興奮）。這2類問題，都需要解決；但都可以根據實際情況，選擇短期臨時解，或長期解決方案。
與此同時，老板們也越來越務實，不僅僅滿足於定性的描述（“能帶來這方面好處，那方面好處，......”），也需要有些定量的數字(比如: 新增收入, 新增利潤等指標) 來看相關IT投入帶來的業務價值產出，以便判斷ROI是否合理，是否值得投入。
綜合上述分析，我們在思考"企業數字化相關產品"的價值主張時， 個人建議采用優化後的 “ 價值主張畫布 ”， 如下 ：
大的來說， 把 “ 價值主張畫布 ” 分成 2 方面 ：壹方面，是給老板們講故事： 解決哪些痛點、哪些甜點，涉及哪個系統 / 功能，大概怎麽解決； 另壹方面，是向老板們立軍令狀（圓圈圖，右上角區域的 Outcome/Benefits）： 如果老板們給予支持，能在哪方面、產出多少業務價值，便於日後度量產品或項目是否成功。
這麽調整以後，價值主張畫布各模塊的邏輯會更加清晰。
1. 如果只需針對單個/ 單類別用戶角色擬制"價值主張畫布", ?可參考上方的改進模板，針對具體的某1類客戶角色，逐步列出痛點和甜點，並分別找出其短期臨時方案 和 長期解決方案，然後總結出對客戶的benefits, 這麽壹步壹步就畫出來了。(模板改進以後, 更符合MECE原則,不同模塊之間不易重復和混淆 - 某個"需求點" 或 某個“方案”到底應該歸入哪個模塊/象限，變得更加簡單清晰。）?
2. 如果某個事業部或業務單元，有多種 “ 客戶角色 ” 需要考慮 ，可以把主要角色分別畫出來（以便於，分別針對特定幹系人群體進行交流），最後需要進行梳理、合並，形成壹張包含量化指標的畫布。（不同企業可能要求不同，有的要求KPI, 有的要求OKR）
3. 如果某個 IT 產品 / 功能 , 有可能在集團裏的多個事業部進行復用 ，建議您針對每個事業部分別畫1張價值圖, （便於和不同事業部交流，另外給業務高層介紹時可著重突出該事業部與其它事業部的不同之處。）最後，梳理、合並成壹張集團層面的價值主張畫布。（考慮到不同事業部，準備就緒的程度可能不同，具體實施會有先後，往往需要附以Roadmap, 以便集團高層能看到覆蓋各事業部的整體落地計劃。）
補充說明 - 原模板中的 Gains（收益）, 已被改進版的 "Benefit/Outcome"所取代。對於Role級別的畫布, 只要能把"Benefit是什麽"說清楚基本就可以了, 對於"事業部"/"集團"級別的畫布, 在和事業部/集團高層匯報時, 需要提供 Outcome相關的KPI/OKR指標，以便於高層更直觀的判斷ROI、並進行決策。
希望這張優化後的價值主張畫布，有助於大家更輕松得把畫布用起來！更好地助力企業數字化賦能！