产品经理打架引发的问题：如何识别需求及其价值
[作者按：平安產品經理與研發工程師打架的小視頻在IT圈刷屏了，筆者不能免俗，參與討論了，自以為討論中有不少干貨]
趁著產品經理最新的段子，來聊聊產品經理如何識別需求并恰當表達？
一、背景假設-線上產品及其特征
背景假設是已經在線上運行的產品或者產品群，有一定的訪問量。
無論是主動調研還是被動響應，需求的來源必然是多方的。
有如下特征：
- 1，碎片化
- 2，涌現式，不可預知
- 3，易變
- 4，時效敏感
變色這個需求對比整個產品或者應用，應當就是個碎片需求，或者叫需求碎片。
跟原有的需求，也許有聯系，也許沒聯系，就算有聯系也不會那么明確和緊密。
平安這次提出的隨手機殼變背景顏色的這個需求，也是一個典型的涌現式需求。
猜不到誰在什么時候會提出來？ 它在今年炎熱的夏天突然就冒出來了。
需求易變是顯然的。出了這么一檔子事，平安產品經理側不知道還會不會堅持這個需求？
說不定如視頻當中搞笑的要做成隨內褲顏色變，
這個太不靠譜了，那也許是可以隨外衣顏色變。
根據手機殼變主題顏色，類似這樣的在手機應用上需求，如果要搞五個月搞出來，那就是生意還不夠好，不僅僅不夠好，簡直就快死掉了。
因此需求時效性是值得追求的，互聯網活動季節比如618，雙11等等，都是強時效。
經典的故事地圖方法，看起來很美，可以組織計劃多個迭代，
其實是不能夠應對以上特征的需求流。
或者說如果能夠應對，那說明生意還不足夠好；足夠好的生意，大量涌現的各方訴求可以把故事地圖沖擊得歪七歪八。
二、需求流模式
在處理具體到單個需求，目前在需求條件方面，仍然是SMART用得多。
但是SMART并不是一步到位的。
從模糊創意到符合SMART的需求，有一個過程。最新有些理論流派給出了“持續探索”的說法，比如SAFe。
也有product discovery和product development，雙軌Scrum的說法
我在最近幾年的實踐中，更加喜歡把它稱之為需求流模式。
所謂需求流模式，需求如同小船一樣放到泉水里面流淌。
對于單個需求而言，以上的過程跟經典的瀑布式生命周期模型幾乎一樣。
不同的地方在于，同時并行許多需求。
就像泉水里面有很多船，有的在前，有的在后，有的在加速，有的拋錨了。
三、從創意到需求
回到平安那個事情，貌似那根據機殼改變主題色調的需求來自于一個拍腦袋創意，
那憑什么這樣的一個拍腦袋的創意能夠傳遞到開發人員？
拍腦袋的創意要做到什么份上，可以往下流轉，可以避免打架？[呲牙][呲牙]
先來為回顧一下經典的做法-BRD, MRD，PRD（引自 https://www.jianshu.com/p/607c3ac65887 ）
PRD
一、PRD的含義 英文簡稱，PRD（Product Requirement Document），PRD文檔中文意思是：產品需求文檔。 PRD文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD中的內容進行指標化和技術化”，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。
MRD
二、MRD的含義MRD，英文全稱Market Requirement Document，中文意思是：市場需求文檔。 該文檔在產品項目中是一個“承上啟下”的作用，“向上”是對不斷積累的市場數據的一種整合和記錄，“向下”是對后續工作的方向說明和工作指導。 作用是：產品項目由“準備”階段進入到“實施”階段的第一文檔，其作用就是“對年度產品中規劃的某個產品進行市場層面的說明”，這個文檔的質量好壞直接影響到產品項目的開展，并直接影響到公司產品戰略意圖的實現。
BRD
三、BRD的含義 BRD，英文全稱為：Business Requirement Document；中文意思是：商業需求描述。 基于商業目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用于產品在投入研發之前，由企業高層作為決策評估的重要依據。BRD是產品生命周期中最早的文檔，再早就應該是腦中的構思了，其內容涉及市場分析，銷售策略，盈利預測等，通常是供決策層們討論的演示文檔，一般比較短小精煉，沒有產品細節。
PRD、MRD、BRD之間的關系
1、PRD要把MRD中的“產品需求”的內容獨立出來加以詳細的說明，而產品需求本身是在MRD中有所體現的。
2、MRD側重的是對產品所在市場、客戶（client）、購買者（buyer）、用戶（user）以及市場需求進行定義，并通過原型的形式加以形象化。
3、如果說PRD的好壞，直接決定了項目的質量水平；那么BRD的作用，就是決定了你的項目的商業價值。 BRD、MRD和PRD一起被認為是從市場到產品需要建立的文檔規范。
當前如何處理需求載體？
在當今快速變化的市場環境下，如果還要三份文檔的話，恐怕早就被競爭對手遠遠甩在身后了
寫三份文檔會太慢，
不寫文檔，直接去找it，恐怕要打架。
這如何是好，如何平衡？
從業界的情況而言，首先減少的是MRD
現在已經有很多公司不再寫MRD，最大的原因，因為它是一份夾在中間的文檔，無論是BRD向后延伸，還是PRD向前覆蓋， 都比較容易把它給替代掉。
因此當前在需求識別時，常用二級信息識別，先識別創意，然后到具體需求。
常見創意的載體是BRD或者簡化BRD，或者直接就叫創意，或者原始需求，或者意向。
具體需求的載體常見沿用PRD的說法，也有沿用需求說明書的說法。
如何判斷創意？
創意的產生一般是不受限制的，鼓勵產品經理們打開腦洞，但顯然的，從創意到具體需求是要講究的，否則可能出現打架。
創意有多大市場價值？
首先考慮是這個創意有多大市場價值？
從一個拍腦袋創意，要轉換到一個需求，首先回答的就是多大市場價值？
自動根據機殼色彩改變主題色彩，顯然有一個替代方案，是手動。
那么手動變化主題色彩的功能是不是已經有了？
如果有了的話，有沒有數據監控運行了多少次？
比例如何？什么樣的客戶群體在用？
如果沒有的話，那是不是先上一個手動改變主題色調的功能？
從方法論上，首先尋找最小可行產品，根據實際數據反饋，再來決定下一步。
簡單而言，如果手動改變色調，這樣的功能上去了之后，都沒幾個人用。
那也許沒必要搞自動改變。
難以判斷的市場價值
雖然說是首先應該想到市場價值，但在目前這樣的一個快速發展的市場上，不少需求，不少創意，其實是很難評價市場價值的。
所謂無心插柳柳成蔭，有意栽花花不發。
這樣的例子比比皆是。
這也就是烏卡時代的一個特色。 簡單而言，充滿了不確定性。在不確定性的大背景下來，考慮當前的需求處理，就值得引入概率思維。也就說不假設做某個需求，絕對能夠獲得巨大的成功；而試圖提高每個需求的成功概率，積少成多，從量變來引發質變。
回到BRD的撰寫上面來說，在激烈競爭的市場環境下，花10天寫一份BRD，會比花30分鐘寫的BRD更加精準嗎？
答案真的是不一定。
拜訪現場客戶走斷腿，
購買各類市場研究分析報告，花很多錢，
自己收集采集數據，花很多時間做研究分析
所以現在有一個性價比更高的方法得到了大量的應用，
那就是基于自己產品運行的數據采集。
有些公司做到了實時監控，有些公司做到了隔天出報表。所以現在產品經理的一個工作情景是這樣的：
看著前一陣子的數據表現，包括昨天的情況，
拍自己的腦門，還有什么招？可以提升關鍵的各項指標？
蠻拼的產品經理
根據手機殼搞個自動換色，是不是能夠吸引那些對主題敏感的潮人？ 那些新新人類喜歡什么呢？這個需求實現了也許可以提升百分之一的訪問量[疑問]
拜求幸運女神眷顧我
為了這百分之一，我不惜跟開發干一架[奮斗][奮斗]
作為產品經理也是很拼的呀[可憐]
小結
以上整理了微信群里面的發言，回望上文發現還是蠻有條理的。
烏卡時代，為奮戰在一線的產品經理喝彩！ 指數式增長的基礎來自于每個1%的努力！
總結
以上是生活随笔為你收集整理的产品经理打架引发的问题：如何识别需求及其价值的全部內容，希望文章能夠幫你解決所遇到的問題。
