如何「做減法」—需求控制的方法與時機

03-27

引用一句我很喜歡的、拗口且裝逼的話作為開篇——

把簡單的事情變複雜是件簡單的事情；把複雜的事情變簡單是件複雜的事情。

前日和小夥伴們交流，談及此事，夥伴們各抒己見鏘鏘直言，思路逐漸通透，略作梳理以之共饗。

首先需要明確的是：「做減法」不是一個階段性任務，需求控制是從思路萌芽開始，直到上線運營，需要貫穿產品整個過程的任務。

結合產品工作的三大任務，表現如下：

a) BRD階段

BRD中最關鍵的問題是產品定位，定位決定了產品的核心價值，即根本特點和發展方向，因此，不符合定位的需求首先靠邊。此時用的是排除法，去掉錯誤答案。

b) MRD階段

MRD中需要解決的是產品規劃，包含功能規劃。我們在符合產品定位的前提下，採用畫像和場景的方法進行需求甄選。此時用的是篩選法，挑出必要的需求，排列優先順序和計劃。

甄選標準綜合參考3方面因素：

1. 需求的用戶價值。價值分三方面：用戶覆蓋、需求強度、需求頻率。通俗說：是否多數用戶的需求，是否剛性需求，是否經常用到。

2. 需求的商業價值。除了經濟價值外還有戰略意義。

3. 需求的技術難度。技術是否可行，開發成本多少。

c) PRD階段

PRD階段是具體產品實現的描述，涉及產品原型。是將MRD階段所制定計劃中的需求合理呈現到產品界面的過程。此時用的是排列組合歸納抽象等方法，最終落地標準可參考0123等設計法則（0說明書，1看就會，2秒等待，3步操作）。

本階段的任務有所不同的是：PRD階段不再進行「砍」需求，只是通過交互手段來突出或弱化，按計劃分階段呈現MRD中的所有需求。

因此，產品工作的全部過程其實就是需求不斷明確直至實現逐步清晰的過程，像是一尊毛胚由粗到精逐漸打磨的過程。所以很顯然，需求出現難以控制的局面，一定是工作環節出現問題，甚至很可能是缺失。此時需要做的，不是爭論，只是回溯檢討而已。

當然，在實際工作中，的確常常不是這麼進行的。可能只是負責某個模塊，若干個頁面，所以沒什麼MRD；客戶直接遞交需求，無法（無有效渠道）商量等等...這些苦衷我也都經歷過，表示理解。

但是

這只是借口！

別忘了——把複雜的事情變簡單，本來就是件複雜的事情。