上周交互同學問我：怎麼排產品路線圖

背景閑聊（趕時間請跳過）：

最近我負責的產品線要將基礎能力的迭代需求及對應的路線圖規劃交給我的交互設計師負責了，這位同學有些疑問和擔心，不知道怎麼來排路線圖。

回憶了下，我當時也是這樣吧，剛開始負責一個產品模塊（雖然是自己設計的，但當時真的是菜鳥，嘲笑.jpg）覺得 1.0 版本（當時我真的有這個概念嗎？笑）完成度挺高的，除了在需求評審會上被壓後的幾個需求外，不知道要怎麼再去迭代。

雖然之後總監教導+自己梳理、調研後，挺順利地就排出路線圖並推進起來了，不過這種心情我還是很感同身受啦。

嘛，正好也是個契機，整理下自己的需求梳理邏輯吧，算是個基礎方法論，可供原交互現產品同學參考。

先來 Kano 好了，開局穩一點。

來自日本的狩野紀昭教授(Noriaki Kano)，將需求分為：基礎型、期望型、魅力型（其實還有無關和反向，不展開，都是不去做的需求）。可以用來做基礎的定性分析。

網上的介紹很多了，我不再贅述，簡單介紹下。

可以通過詢問用戶來確認，針對同一個需求（當然可能你得轉化成產品方案再去問），做和不做對用戶的感覺，分別打分（5分制）。在產生的矩陣里，划出需求類型。

當然，實際的情況下，產品可能會預先判斷一次（竟然使用經驗判斷，皮）。嘛，確實也是挺常見的情況啦，不過儘可能還是要去問的！尤其是心裡沒底時，務必多問一下。這個點上砸點成本是最不虧的。

通過 Kano，我們基本知道了這個需求的定位，可以算是定性地評估了一下。

接下來就是定量地分析了（所謂的定量也就那樣啦，要保證嚴謹性成本很高的，但你不做的話不就沒有依據來排優先順序了嘛！如果你說是老闆提的，優先，那我無話可說）。

按照幾個核心維度對需求進行劃分，第一點是「用戶價值」，可以通過：

• 覆蓋用戶比例，直接觸及的用戶率是否足夠高。
• 對單個用戶的價值，需求做出來後，對單個用戶產生的價值有多高（多層次時，分別乘以對應的用戶比例加權）。

這兩項相乘，可以得到需求「用戶價值」的指標。不夠的話，就進一步考慮：

• 是否針對核心用戶

特指付費客戶、B 端產品的核心決策人或使用者等，手游的盯緊重氪用戶，toB SaaS 瞄準老闆/核心決策人，少做無用功哈，不然有的悔了。

• 另外，還要考慮價值兌現難度，包括啟用和維護的成本。

比如 toB SaaS 中，特別容易出現價值大，但啟用難度也巨大的特性，提供好對應的「梯子」是一回事，同時也不應對價值兌現過於樂觀。

視產品的複雜度，用上以上的其中幾項，基本就夠了。如此，可以獲得對「用戶價值」評估值。

第二點，就是需求的商業價值，即對公司產生的價值。

• 能帶來營銷優勢的（即使兌現不到用戶身上）
• 帶來的數據效益的（如簽到有助於提高你的產品 DAU，這個要謹慎，不要給用戶帶來負價值）
• 能有助於產品快速上手的（Onboarding bonus 是好東西）
• 能用於產品甚至公司破局的調整（即使對用戶而言看不到收益的）這個比較少見，但對創業公司的產品經理來說還是完全可能碰到的。
• 其他各種給到公司的收益。

這邊需要一定的商業基礎知識和判斷能力，大多數產品應該都能達到。根據當前產品線和公司對對應收益的渴求程度，加權算一算，就差不多了。

第三點，研發成本。這個，其實是一個溝通能力的活兒，如果對應的研發 Leader 和你的溝通還算愉快地話，你就能在產品方案早期得到一個基本的研發成本判斷了，這個不用特別細（畢竟早期），1天左右、半周、一周、一周半、2周、3周、一個月、一個半月？基本這樣去切就夠了。需要提醒的是，預期周期越長，延期風險和變動度也越大。時間預估這事兒，可以後面和我熟絡的研發 Leader 一起詳(tu)細說(tu)說(cao)。

第四點，時效性，這個主要是定緊急程度的，輔助你排路線圖。如果某個時效性很強，但是短期蠻難做完的需求，掂量下成本就改明白是否要捨棄掉了。當然，如果你資源多就可以去搶，好好寫方案去爭來資源吧（doge.jpg）。

好了，到這裡為止，不可能還排不出順序了。

不過這只是讓所有需求真正進入你的掌中，這樣其實還是不夠的（那你說這麼多！）。畢竟，只是給簡單定個順序的話，會把迭代節奏拖壞了。

下一期（真的有嗎？），再來說版本構成吧。

（後悔了，感覺還是寫那些年我做悔了的特性更喜聞樂見嘛，捂臉.jpg）