人人都是產品經理是中國最大最活躍的產品經理學習、交流、分享社區。集媒體、社區、招聘 、教育、社群活動為一體，全方位服務產品經理。本文由人人都是產品經理社區 作者：艾老思，前騰訊首席敏捷管理教練，“極速產品研發”方法論創立者；原創發布。轉載請聯系人人都是產品經理。
請注意2B產品經理不是罵人啊！而是指做企業產品的2B產品經理。（怎么感覺還是有點怪，干這行真吃虧）
艾老思認為2B產品經理是宇宙里最苦逼的產品經理！他們有三大苦難（排名不分先后）：
1、自己做的產品，自己永遠也用不上
正如金蝶李帆老師講到的：“做了十幾年2B軟件產品，難以成為最終用戶。但是即便2B，也必須要有用戶的思維和最接近用戶的方法，否則做的產品只是紙上談兵。所以，靠自己單打獨斗是不行的，必須借助外腦。”
2、客戶和用戶分離，到底該聽誰的？反正自己說話不管用
艾老思也在后援團里說過：
“2B表面上是服務客戶，但再往前挖一層，可能會有兩種情況。如果2B產品是給自己企業用的，例如OA，真正的用戶是客戶企業的實際使用用戶。如果2B產品是給自己的客戶用的，例如訂貨系統，真正的用戶是客戶的客戶，甚至是客戶的客戶的用戶。”
3、客戶要求極高，容錯度極低
相比2C用戶，2B客戶那要求可是相當高。每一個細節都會反復確認。更重要的是不！能！出！錯！誰都擔不起這個風險。很多時候我們要花費了80%的時間在20%的細節上反復調試修改。
難怪無數2B產品經理會去羨慕2C產品經理作上帝的感覺……
艾老思后援團里的岳三峰老師對二者的總結非常精彩：
“2C的是用戶，和2B的是客戶，區別還是非常大的。一個是要讓用戶爽，一個是要讓客戶贏；一個是瞬間體驗決策，一個是集體決策；引發內部的組織方式也不同，一個是小團隊獨立作戰就可以搞的定，一個是必須多團隊協同。”
很多年前，我被關在江蘇泰州的一個小黑屋里，和3個同學在老師的帶領下，一起開發一款偉大的產品——某藥廠ERP系統！
相比最牛叉的ERP——SAP，我們的競爭優勢是“定制化”。上線前我們完全根據客戶的業務特征進行定制，每一個字段都可以定制。上線后客戶說要什么報表，我們就能迅速開發一個。在這個過程中，我們既是碼農，又是產品經理，我們需要不斷的收集需求、溝通需求、設計產品、培訓使用……
絕對的以客戶為中心。但是以客戶為中心，并不代表客戶滿意。我們遇到過至少以下N種情況：
接口人A告訴你，他可以全權代理所有內部需求，不必去和部門溝通。
業務部門員工B告訴你，他非常忙，沒時間跟你溝通需求。
員工C告訴你，我需要請示我們領導，時間過了一周。
員工D熱情的告訴你他的需求，但是他的需求只是“他的需求”
員工E堅定的告訴你，我們要的就是這個，但是做出來說不對
你問員工F需要什么，他告訴你，一切都挺好啊
你問員工G我們可以幫你簡化現在工作，他告訴你，省省吧，別來折騰我們了
……
難吧？這些難題逼退了很多人對真相的追求。傳統的需求調研、需求分析，重點都放在客戶代表身上，間接獲取用戶。真正面對用戶的時候一般是比較粗略的。一個重要的原因是驗收項目的是客戶代表。但每天要用一百遍的是內部用戶，他們才決定了我們的產品是否能夠用好，帶來好口碑。但他們的需求如上所述，實在難以洞察。
第一步：要搞清楚的是用戶有哪些？
財務軟件的用戶可不只是財務人員，至少還會涉及領導查看報表、業務部門提交單據、IT部門負責數據安全和權限。
一定要搞清楚除了核心角色以外所有關聯角色，哪怕是不使用產品的人，如果與該核心角色有利益關系，那么他們也是我們的間接用戶。因為他們的需求很可能會左右核心角色工作業績。
第二步：他們的滿意度來源是什么？
識別出所有不同類型用戶的滿意度來源，例如他們的KPI、經濟收益、工作負荷等。如果不是顯性的滿意因素，那么就需要通過分析他們的核心工作場景來獲得他們工作中的痛點，解決他們的痛點將會獲得他們的滿意。
第三步：用戶類別優先級是什么？
如果你識別出的用戶少于3類，那么你應該還沒識別全，通常我們能夠識別出超過8類以上的用戶類別。我們全面識別是為了找到最重要的用戶。所以我們要對用戶類別進行強制排序，然后選出最重要的1~3類用戶，作為我們的核心用戶。
第四步：找到他們的利益共同點
找到3類核心用戶的利益共同點，作為他們之間的連通紐帶，這個將是我們的工作核心，一旦滿足，我們將同時收獲三類用戶的滿意度。
第五步：識別關鍵產品特性
需求與特性區別是，需求是原本的訴求，而特性是滿足需求的實現方式或者解決方案，所以當我們識別出核心用戶的需求之后，就需要想辦法解決他們的需求，制定出關鍵的產品特性。
第六步：繪制特性地圖
對特性進行優先級排序是比較常規的做法，但是特性之間是有依賴關系的，我們需要結合這兩個參數，繪制出特性地圖。
第七步：強制拆分成三期規劃
對特性地圖中的幾十個特性，進行強制分期，找到邏輯間隙，劃分開來，然后把焦點放在第一期上。
第八步：第一期強制拆分周粒度版本
再對第一期的特性進行細化和再拆分——特性裂解。把粒度降到最低可驗證規模。
然后以周為單位進行開發。
第九步：與核心用戶每周驗證中間成果
周迭代的核心目的是要求強制加速反饋驗證的速度，保證至少每周一次對結果的驗證，加速我們用戶體驗產品的速度。
第十步：迅速調整后續特性與規劃
基于用戶的反饋，對好的特性保留，錯的特性刪除，差的特性改進，用最快速度進行調整，并體現在下一周的迭代里。對于重大調整還需要調整產品整體規劃。
為什么做不到？
以上方法也許你知道，或者自己也能想到，但是為什么做不到呢？
這一部分才是重點。
大多數企業的產品經理是將前四步合并為“需求分析”一步，而且由大量主觀、片面、離散信息組成，更未經過嚴謹論證，僅僅是通過簡單的群體決策或上級決策，得出結論。
第五步則由“撰寫產品規格說明書”代替，這可能是花費時間最多，評審次數最多的步驟，但實際并沒有什么價值，因為文檔中通常存在大量bug，甚至是邏輯缺陷。更悲催的是在后續開發過程中，沒有幾個人領會說明書的每個設計初衷。
后五步，則通常省略，直接用幾個月甚至一兩年時間一次性做完，推給市場，用市場檢驗，用數據說話。然而檢驗的結果通常是打臉。返工、調整、撕逼、扯皮……噩夢開始。
沒有什么可以化身用戶的辦法，你就是你，是顏色不一樣的煙火。承認自己是常人，就按常人的辦法——科學理性的方法一步一步老老實實的做，一定能成，這個事并沒那么難。
