起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理實戰篇-面對復雜的需求，如何高效落地？
不少剛入門的產品經理在面對復雜的需求時很難推動項目的高效落地，畢竟很多項目是要通過實驗需求才能看清效果的。面對這種情況，產品經理可以做什么？本文作者解答了在推動產品落地過程中的常見問題，一起來看看吧。
在我們日常的產品工作工作中，有兩個模塊非常核心：
- 設計/產出需求文檔
- 上線后拿到效果
客觀來說，完整地執行好這兩部分，需要很多的精力和經驗才能不踩坑。
很多高階產品經理，在面對一個項目(多個需求的集合)時，依然不能高效落地，原因就在于沒有一套方法論，或者沒有很好地復盤之前踩的坑。
今天，我們主要來說一下，作為一個想要晉升/已經高階的產品經理，如何做到高效、高質量的落地。
首先，很多需求/項目是需要做AB實驗、分析埋點、或者用戶調研來看清效果的，簡稱為“實驗”需求（即這個需求不是100%有正向收益，需要實驗后才能明確）。
其次，實驗是一套新的方法論，相較于做一些普通功能來說，有以下特點/難點：流程長、復雜度高、易遇突發問題、考量因素多。我們做的重點需求/項目，基本都是實驗需求。
一、以例子開頭
有個需求是「給體驗不好的用戶發券，降流失」，遇到了幾個問題：
- 上線后出現bug：需求文檔上寫明了——只適用于新用戶，但后續環節出現問題、導致老用戶也收到了券。不僅實驗進度受了影響，而且花出去的錢浪費了。
- 改了老bug，來了新bug：基于1的問題，技術改了，沒想到又引發新問題。實驗暫停。
- 取不到數，無法進行分析：由于底層數據的問題，出現了意料外的情況，實驗進度受了影響。
- 實驗效果有負向，怎么辦：是不是需要優化實驗方案？還是放棄這個實驗方向？還是數據分析有問題？
以上問題易發，產品經理只能被動解決。雖然不完全是產品的鍋，但作為owner，會受到各種質疑和責問，長此以往將失去老板、協作方的信任。
二、掌握主動權，產品經理可以做什么？
實驗=做不明確的事，要快、準、狠地找到解法/結論。
首先要準（方向），找準方向，事半功倍。（經驗/數據/用研的指導）
其次要快（效率），天下武功、唯快不破。（落地不delay）
再次要狠（成本），學會決策，不斷迭代。（實驗不成功，及時轉變方向/調整方案）
以上為實驗的指導方針，那么具體怎么做到呢？
首先，定義實驗中的關鍵流程和約束條件。
- 關鍵流程：我總結為四要素，好設計→控時間→保品質→拿結果。
- 約束條件：時間(要求最晚上線時間)，人力資源(需要開發、運營、數據分析師、客服等協同)，不能有PR/法務風險，ROI投入產出比必須≥1.5，等等。
其次，規避“關鍵流程”里的“約束條件”下的坑。
在前面列舉的約束條件下，會踩很多坑，不如：
- 求快，那么開發周期就要縮短，質量和功能完整度就會打折扣。
- ROI約束，那么發券的范圍、優惠額度會收窄，導致驗證不出實驗效果。
那么，如何找到最優解、盡量避坑呢？
1. 好設計：磨刀不誤砍柴工
追求短時間的快，可能帶來長時間的慢。
a. 功能設計：實驗一般都先做一個MVP極簡版本，需要明確定義核心要素——保留對實驗結果影響較大/有指導意義的要素。
比如要做用戶任務、完成任務給予獎勵，需要同時保留后端邏輯和前端感知（均對任務完成率有較大影響），任務配置后臺就不用做。
b. 實驗設計： 并聯效率≥串聯，分多個實驗組，驗證多個猜測、更好地指導迭代。比如：
- 給用戶發券，想了解哪種券ROI最高，可以分幾個實驗組發不同金額的券。
- 評估實驗效果，數據分析師寫sql跑數 or 實驗后臺能直接看到數據，當然后者更方便且錯誤率低。
c. 定義實驗指標： 指標直接關系著效果評估、實驗成敗，放在后面環節來說。
d. 技術方案設計： 缺失該環節，可能導致取不到數/取數不準/迭代困難。 在需求評審or開發階段，需要和數據分析師、技術一起明確技術方案（關注要點即可，不必面面俱到）。
比如底層表里沒有某項數據，大家均自信認為有，結果到了評估階段，技術發現問題、數據分析師發現取不到數。
2. 控時間：定好排期后、減少delay
Q：如何防范delay風險？
A：排除掉外部因素，基本就是人的因素，所以我們要針對人。以下主要說核心參與人員的避坑。
- 針對能力尚缺的人（評估失誤），復雜的實驗需要技術評審且技術leader要在，double確認排期、并確認開發難點（憑經驗）有無問題；
- 針對沒有承諾意識的人（不去彌補、認為提前告知風險就沒有責任），和技術leader一起溝通、復盤問題；
- 同時，PM需要強調“排期準確性的重要程度=實驗質量”，排期即為ddl（最晚上線時間）。
舉個例子，實驗A邏輯比較復雜，需要多部門協同，技術變更了兩次排期。
- 第一次變更：技術開發了一半，發現開發時間要拉長。
- 第二次變更：技術反饋開發復雜度高、測試需要更嚴謹、又拉長了測試周期。
在做復盤時，大家對問題產生的原因描述如下（不討論各人能力問題）：
- 技術：產品急著要排期，所以對時間評估不充分。
- 產品：很委屈，早前和技術確認、給了幾天完整的時間用于評估，且技術從未反饋時間不夠。
- 產品：第二次時間變更，未提前告知我，是測試介入時間拉長、才發現的。
Q：怎么約束人的行為？
A：在實際情況中，我們能做的有限。
這類人在工作中遇到的并不多，以后的需求留個心眼，做一個僅對ta催命的PMO。
另外，遇到此類情況，需要及時復盤，減少以后出現的概率。
3. 保品質：bug降發生、及時發現
- bug的出現：源于測試case的不完整，特別是邊界case、不好構造的場景、測試不知道的改動點。（不是說測試人員有問題，而是整體協作的問題）
- bug的發現：反饋渠道有限，比如進線、自己遇到、達到閾值報警，也有可能直到實驗全量都不會發現。
Q：如何保障實驗質量？
A：最擔心的兩個問題：
-實驗沒法看效果（沒生效或出了bug或數據紊亂）；
-實驗影響了別人（造成事故）。
所以，站好owner的崗，必須做好以下4件事：
1. 定義最小驗收成本：定義能保證實驗正常運轉的產品驗收case；推動測試case評審。
2. 定義最大適用范圍：需求文檔里專列一個模塊，標注適用和不適用的情況，和RD、QA強調一定要測試到。
3. 監控：基于實驗風險程度和重要性去評估要不要做。有兩大作用：控制風險——超出閾值代表著「量級超出預期、可能存在bug」，比如大范圍發券，一定要有閾值控制。保證質量——低于閾值代表著「量級太小，不滿足評估條件、或者實驗未生效」，用于及時發現問題。
4. 改動必回歸：每一次的改動，都要及時回歸，可以找測試幫忙。比如改了bug后、又影響了其他地方，如果沒有監控、且未回歸，就容易留坑。
4. 拿結果：≠拿收益，只是驗證對錯
我們需要正視的是，實驗結果不一定是好的，甚至有可能負向。此時，我們應該有兩種思路：
實驗結果是準確的嗎？——嘗試去驗證/發現問題。
實驗結果是可改變的嗎？——嘗試去迭代/優化。
如果以上均告失敗，那么，該轉變實驗方向了。
Q：沒提升「某一核心指標」的實驗=失??？
A：不是。 拿轉化率來說，它可能是一級/核心指標，但不是衡量成功失敗的唯一指標。如果一個實驗沒能提升用戶的轉化率、但提升了用戶留存率，從長期來看也是成功的。
- 每個實驗指標不是唯一的，可以有很多輔助指標（用戶頻次、活躍、留存、功能埋點等），幫助分析問題、review實驗價值。
- 轉化率的特性在于當時的刺激（比如優惠券刺激轉化）等，如果要看實驗的長期潛價值，可能需要其他指標的輔助（比如用戶留存）。
Q：如何定義輔助指標？
A：需要基于公司大目標、實驗內容來靈活調整。比如公司大目標是訂單量增長，那么：
核心指標應該是訂單量。
二級指標，比較通用的是用戶量、人均下單頻次、轉化率這些。
三級指標，需要基于單個實驗內容，比如曝光、點擊、停留時長等。
Q：效果不達預期怎么辦？
A：有三種情況。
一是環節問題，太多地方能出問題了——方案設計不合理、存在bug、取數口徑…
二是評估問題，可以精細化拆解，通用方式是城市差異、新老用戶差異等。
三是方向問題，沒有bug、沒有錯誤，只是因為實驗方向不對、對未來預判錯誤，不過這個點比較難被接受。
以上，希望能幫到你。歡迎補充和提問~
本文由 @小喬 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
- 目前還沒評論，等你發揮！
