編輯導語：作為一名產品經理，從需求到PRD，中間還有多少糾結？，這中間到底經歷了什么？作者先以熟悉又尷尬的語境對話開始，結合自身經歷，傾訴了從需求到PRD，產品經理經歷了什么，在想什么？

需求討論會已進入尾聲，各方終于達成了共識，與會人員紛紛露出了疲憊又滿意的微笑。這時，領導對產品經理小M說道：

“小M，需求咱們已經討論清楚了，你看，明天能給PRD嗎？”

“??？”，小M一臉詫異地看著領導。

“？”，領導一臉詫異地看著一臉詫異的小M。

工作中，我經常會碰到“今天提需求、明天要PRD”，甚至“上午提需求，下午要PRD”的情況。很多時候，并不是因為項目有多么緊急。而是，相關干系人對“制作PRD”沒有概念，不知道具體是在做什么，要花多少時間。

其實，不僅是其他崗位的朋友不了解。很多對產品感興趣的朋友，因為沒有實際項目經驗，往往也很難有比較深入的了解。制作PRD，并不是簡單的文檔作業，不是把討論好的需求直接整理成文檔就好了。從需求到PRD，產品經理需要梳理、填充、完善很多內容，有很多兩難的情況需要糾結、決策。

這個思考糾結的過程，非常重要，往往也非?；〞r間。有時候，具體把東西寫出來，大概也就1個小時。但是，前面我可能得呆坐在電腦前思考一整個上午。

從需求到PRD的過程中，產品經理都在考慮些什么，糾結些什么？今天我們就來聊聊這個話題。

在進入話題之前，我們先來解讀一個概念，“討論好的需求”。

可能你也注意到了，上文有這么個“邏輯漏洞”：既然需求都討論清楚了，產品經理還需要糾結什么？或者說，既然還存在問題需要糾結，產品經理為什么不在需求討論會上提出來討論？

這個嘛，大概只能說是理論和實操的差異吧。能溝通的盡量溝通清楚，這是一個無需贅言的大前提。但是，在實際工作中，不可能把所有的問題、所有的細節都討論清楚。

大多數情況下，能把核心流程討論清楚，并對幾個重要的問題點達成共識，就已經算是非常不錯了。甚至，有的時候，因為條件限制，根本沒法進行深入的溝通。

比如說，不幸碰到了一個“不愿多說，讓你自己去意會”的干系人。比如說，跨公司合作，或者異地團隊合作，溝通只能靠電話和微信，非常受限。

所以，當我們說“需求討論清楚”，其實可以理解為，就是確定了個大綱而已。

拿到“需求大綱”之后，產品經理還需要考慮些什么呢？

當然，還是那句話。不同產品崗位、不同項目，情況大不相同。這里，我結合自己的經驗，分享幾個比較有共性的點。

一、根據需求大綱，把整個交互鏈條梳理并完善

舉個例子，假設我們要做一個抽獎活動。抽獎資格、獎品設置、抽獎概率、獎品發放等核心內容，需求討論會上肯定會討論清楚。

但是，這些只涉及到整個交互鏈條中的一小部分，還有很多空白要補充。產品經理需要從用戶觸達那一刻開始，通盤考慮，梳理完善。

比如說登錄態判斷，未登錄訪問怎么辦？

如果是僅限特定會員參加的活動，且不宜外漏，那么訪問時就需要強制跳轉到登錄頁。否則，這個H5專題，就還需要補充一個“未登錄”狀態，并且得有登錄指引和登錄模塊。

比如說用戶類型判斷，沒有抽獎資格的用戶類型訪問，要怎么辦？是引導用戶進行指定操作，使之變成有抽獎資格的用戶類型呢？還是直接告知沒有抽獎資格呢？那是否需要向用戶說明理由，或者留個聯系客服入口？

比如說，抽獎成功/失敗后的引導、抽獎結果查詢、獎品發放與扣回等等。

從用戶觸達到所有流程走到終點，產品經理要根據需求大綱的要求，梳理完善全部的交互鏈條。

整個交互鏈條都補充完整了，這個方案才能算是“可用”。

二、結合公司產品情況，考慮需求的涉及范圍

還是用上面的例子，我們要搞個H5專題，用來做抽獎活動。那么，會議討論的核心，肯定是圍繞著“H5專題”進行的。但是，產品經理的思維不能被限制住。還得考慮，公司的PC端網站，是不是也應該搞一個PC端的抽獎專題放上去？

假設背景情況是，移動端已經是發展的趨勢，但是目前還有一半的流量在PC端。面對這樣的情況，你覺得，PC端的抽獎專題，是做，還是不做？

當然，這里面沒有標準答案，需要具體情況具體分析。但是，如果腦中只有“Yes”和“No”兩個選項，那就還是被限制住了思維。

這里面有n個選項，比如說：

• PC端完全沒有入口
• PC端放個廣告圖，附上移動端H5專題的二維碼
• PC端加個入口，點擊在新標簽頁打開移動端的H5專題
• PC端做個靜態專題，僅作介紹，并附上移動端H5專題的二維碼
• PC端做個和移動端一樣功能的抽獎專題

可選項其實非常多，這也就是為什么產品經理需要糾結，且需要糾結很久的原因?？紤]需求的涉及范圍，核心是要平衡“業務需求”和“開發成本”。就像上面的例子，換一個方案，開發成本可能就得翻倍。

三、根據項目的重要性，斟酌功能的精細程度

要實現一個功能，可簡單、可復雜。

具體要做到怎樣的程度？需求討論會一般不會討論到這么細?；镜每慨a品經理自己斟酌。比如說，引導關注微信公眾號。

如果只是附屬功能，比如在支付成功頁為公眾號引流，那放個二維碼就差不多了（雖然對非微信環境下的訪問不太友好）。如果是核心功能，或者是核心流程中必經的結點，那就得做得更加精細，優化體驗，以較少流失。

可能就得這么搞：

• 微信環境下，顯示二維碼，引導長按識別；
• 瀏覽器環境下，顯示二維碼圖片和操作指引，引導長按下載圖片，并有調起微信的功能；
• APP環境下，調起小程序，在小程序中打開指定的微信圖文鏈接，在圖文中引導用戶長按識別。

又比如說，查看詳細地址。我曾經做過一個招聘的專題，里面自然需要有公司的所在地址。干系人提出，用戶點擊地址時，需要調起地圖應用，定位并導航。

這體驗當然很好！

但是，開發成本可能比招聘專題本身還要大，肯定是不合適的。根據其重要程度，僅在頁面內顯示詳細地址的文本，就差不多了。如果還需再優化，再加個“點擊復制地址”的功能，也還算合理。

可以看出，本質上，我們是在權衡“用戶體驗”和“開發成本”的關系。以前大家愛講“追求極致”，但實際工作中，更需要“點到為止”。其中如何權衡，需要產品經理結合項目的重要程度去分析決策。

四、思考與舊模塊舊功能的關系，劃清需求邊界

對舊模塊舊功能進行調整，往往比新搞一個東西，要麻煩得多。有時候，在運行新機制時，還需要同時保持舊機制正常運轉，以保證某些老用戶的正常使用。同時還得有引導用戶從老機制切換到新機制的功能。

當然，這些大概率會在需求討論會上溝通清楚，不在我們今天的討論范疇內。但是，在制作PRD的時候，你還是會發現，有很多細碎繁瑣的東西要厘清。

比如說，我需要調整A類產品的價格顯示樣式?？雌饋砗芎唵?，把所有涉及到A類產品價格的地方，都調整一下，不就好了？

并非如此。

那個好多年前搞的老頁面，好久沒人維護了，也很少用戶訪問，要一起改嗎？某個地方有個價格顯示的bug，涉及包括A類產品在內的多種產品，這個bug要一起改嗎？

像這樣細碎的問題，需要產品經理一個個去排查、去權衡，非常繁瑣。如果偷懶，敷衍了事，后面進入開發測試階段，就得經常停下來協商討論，開發進度就會經?！翱ぁ?。

在制作PRD的時候，產品經理需要花很多時間精力，去梳理和斟酌許多細枝末節的問題。它并不像“需求分析”那么有“價值”，所以大家談論得比較少。

但是，這些細節，卻實實在在地關系著項目的最終效果。當然，也反映了產品經理的專業水平。

#專欄作家#

簡明產品論，微信公眾號：簡明產品論（ID：JianMingPM），人人都是產品經理專欄作家。在真實的世界里做產品。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議