1樓：XCXC
想清楚九個問題，開發收到的產品需求基本就靠譜很多了。
問題1 ：目標客戶是誰？客戶規模如何？——定位客戶
①目標客戶的畫像要盡可能清晰明確，這決定後續運營方案、目標是否達成的評估。以電商領域商家來說，通常按成交規模、行業（如服飾/快消/家電等）等細分目標客戶 ② 而目標客戶規模是判斷產品是否值得做的重要依據。
2. 問題2：解決客戶什麼問題？——定位場景
以電商商家為例，商家為了經營店鋪，要做100件事。你聚焦解決的是那1件事情？
3. 問題3：客戶當前是如何做的？有什麼痛點/需求？——分析場景需求
① 完整、精細地還原客戶那1件事情的過程。「完整」要求一步步還原客戶所有操作流程，以流程化的一二三四步是最好的。」精細「要求每一步環節不是泛泛而談，而是能細緻到具體操作步驟。
② 分析每個環節的痛點和機會點。是不是操作成本太高？是不是操作過程中沒有資料指導？
是不是操作完沒有效果反饋？只要前面的場景還原足夠完整、精細，痛點和機會點分析就會相對容易了。
4. 問題4：客戶目前有用到哪些工具產品？——競品/關聯產品分析
5. 問題5：你的解決方案是什麼？——解決方案設計
在這裡，很多產品經理常犯的錯誤是，一開口就說：」我的產品是這樣設計的，提供1-2-3種功能「。此時， 我們一定要回到問題3，對照客戶場景的各個環節，將自己扮演成客戶：
」如果我是商家，當XX的時候，使用功能1來解決什麼問題，接著使用2來解決什麼問題「。這樣才能確保產品功能確實在實際中會被使用，而不是你YY出來的。
7. 問題7 : 需要和哪些產品聯動？產品協同邊界是什麼？
8. 問題8：成功衡量目標是什麼
9. 問題9：有哪些容易導致失敗的難點、風險點？你打算如何應對？
產品經理成長專欄
2樓：KrisSin
要注意以下五個方面：
「產品要幹什麼」，
「要實現什麼功能」，
交代清楚「互動的邏輯和跳轉的邏輯是什麼」
以及「每種情況下的托底邏輯」
3樓：黃偉
需求不清晰分為兩種情況：
1.沒有get到產品經理的真實想法。
2.產品經理給的需求是混亂的，需求本身有矛盾。
對於這兩個問題，我認為可以通過乙個方法解決，就是產品經理在給出需求文件的同時能夠給出相應的流程圖（業務流程，不是技術流程），直接使用流程圖去溝通，流程圖與開發人員溝通後沒有問題，基本上第一步就已經完成了。如果產品經理自己都無法完成流程圖閉環，那說明是第二類問題，需要產品經理再多思考下，形成最後的東西輸出給開發，基本上有這個打底，就算很多細節沒有考慮到，開發也會給你補的，開發還是本性善良的居多，不會硬推你進火坑的。
這個流程圖一定要很清晰的去包含涉及到的各個環節，每個環節中的細節可以大而化之，不用細節到顯示是字是「大」還是「超級大」，但環節一定不能少，不然後期雙方就容易產品互推的現象。
4樓：李堅
需求清晰分兩個方面：
1.產品方向、思路清晰；這個需要時間來和團隊共同明確，這個不是某乙個人拍腦袋就決定的，當團隊都明確我們要做的是個什麼東西、為什麼使用者服務、咱們這麼做有何意義時；他們自己便會進行思考。
2.輸出產物清晰；我認為這是PM的基本素質，其實很簡單；首先是換位思考，假設你是使用者、假設你是文件的閱讀者，看你的產出物時會是什麼感受；其次清晰這個功能、這條業務的流程；保持和團隊的溝通，你能很快學到很多東西。
ps：現在的很多PM都是糾結於這個功能技術如何實現、那個功能技術有什麼難題；這是個很大的誤區，做產品的，一旦完全陷入技術思維了，那到底你的產品是誰在用呢，為什麼要用呢？
5樓：
反對第一名的答案。
那種活已經不是乙個產品經理能決定了，什麼叫重點？誰能定義重點？
也許是行業不同，我的產品不是純軟體，而是乙個系統。身為pl+hw，如果沒有清晰明確的定義，在開發和驗證過程中，是非常容易導致延期的。我的硬體平台設計，有優先順序的考慮，有可靠性的需求，有有效性的保證，這些細節都是我和pm一點點談下來。
後續實現的時候，我還必須給me和sw的同事一點點的」翻譯」上述細節的思路和技術實現的大致方向，sw甚至要求我自己幹出部分功能的測試版本來。
所謂重點突出，那是一整代產品規劃時的需求，乙個pm恐怕沒資格。
6樓：
換位思考一下，如果你是開發怎樣表達會比較容易接受。
首先在正式提交需求之前先有乙個準備的階段。從產品利益和使用者價值兩個角度去分析需求，讓開發覺得他做這些是有實際意義的（誰都不想白忙活），可以直接體現在轉化率和收益方面，有資料或者競品分析的支撐會更容易溝通。同時聽取開發的意見完善需求。
總之在提需求之前要做好充分的準備，找出一切能證明你所提需求是正確的論據。
7樓：王小翼
個人一直不會提特別細的需求，如果太細，你就不能確保這些細需求都是正確或者適合的。一是個人精力有限，二是這些細需求大多會涉入別人地專業領域，你不夠專業。所以只需要把握住主體，讓後續環節都是在細化這個主幹，但絕不能推翻這個主幹。
8樓：張大魚
在給研發提需求前，自己要很清楚自己做的東西的目的，解決什麼問題，為什麼這麼設計，每乙個細節都是有原因的，拋開這些原因談需求，最終拋給研發的資訊再完善，都沒用，分分鐘就被研發問道啞口無言：為什麼是這樣而不是那樣？最後你也會覺得，哦，好像確實這樣也可以，那樣也可以，最後出來一堆爛東西
所以，最重要的不是這個需求有多完善，需求細節有多面面具到
而是你要讓研發了解你的整個設計核心思路，你的東西為什麼要這樣設計，你要做的事情是要解決什麼問題，為什麼要解決這些問題，你的需求想要達到什麼樣的目的，把你需求背後的這些東西傳達給研發，比你給他們乙個超級詳細的需求文件重要得多，比你費盡口舌乙個細節乙個細節的給研發講重要得多
研發真正理解為什麼要做這件事以及為什麼這件事要這樣做而不是那樣做以後，文件什麼的都是浮雲了（當然還是需要的，嗯嗯），在這樣的基礎上研發最終做出來的東西才會是你要的東西，而且研發還可能幫你想到更合理的實現方法
所以如果能在設計階段就讓ue ui 研發都參與進來是最好的，確保大家都真正理解要做什麼，最終的結果才是大家都希望看到的
9樓：安江澤
和你的直覺相反。我們開發真正希望的是產品經理在交代需求時，不要求全面細緻，但要重點突出。
其實工程師不僅僅要了解產品的方案的核心設計思路，還要知道工程上取捨的條件。這樣我們可以集中精力解決對公司對整個產品有巨大回報的問題，同時在那些次要的功能點上做變通。
而面對那些重點不突出的需求，越是交代得細緻，我們越是反感。因為不知道你真正想解決的問題是什麼，我們就不知道一處設定是你重點關注的還是隨便拍腦袋的，那我們肯定要到處挑刺啦。
此外，如果乙個名產品經理知道自己方案的核心要點，也是不會為一些次要的細節被挑刺而亂了陣腳的。只要底線沒被觸及，完全可以讓開發有些發揮的餘地，降低下整體的成本呀。相反，越是不知道底線在哪的 PM，面對開發的反饋越敏感，越怕自己的方案有一點的變化。
所謂一流產品講故事，二流產品列單子，三流產品哭鼻子，就是這個道理。
10樓：Kubar
如果PM自己都提不出完備且清晰的需求，那麼這樣的PM可以認為是完全不合格的
如果需求清晰，僅僅是各種臨界情況或極端場景沒有考慮完全，還可以慢慢用經驗來彌補
總而言之，產品經理拍腦袋提需求，會很快消耗掉RD對你的信任和自己的前途
11樓：楊邦豪
乙個需求要在大方向上被接受，就要結合需求所在的產品的定位做出說明，否則公說公有理婆說婆說婆有理。細節方面按照一般prd幾要素：需求描述，前置條件，後置條件，業務規則，使用流程，介面原型寫清楚，程式設計師根據這幾個要素就可以順利完成變成
12樓：
如果產品經理本身就沒有清晰的需求，那麼傳達到開發人員那裡肯定也是含含糊糊。
在提需求之前，產品經理先自己把需求梳理清楚，而且要進行可行性分析，並設定優先順序。在提需求之前，要避免溝通漏斗，就要盡量實現資訊的對稱性，把一些需求之外必要的東西講出來。同時至少要準備三份東西，一，流程圖，清晰的物件和流程，二，需求文件，表達準確，無歧義。
二，產品原型，約接近產品最終效果約不容易做偏，這是主要的參照物。
產品經理要從那幾個緯度向開發說明需求，先說啥 後說啥？
產品花姐 從實際工作中來回覆下，簡單粗暴，不囉嗦不拖泥帶水1.首先介紹需求背景，結合場景解說使開發人員更有帶入感2.明確要解決什麼問題，給他們明確目標任務3.提出解決方案，這個時候就講解自己設計的解決方案以及需求要求 吳金志 不扯大道理，直接說工作常見場景。作為產品經理在向研發講述需求的時候，是要有...
產品經理如何和喜歡思考各種需求 喜歡提非常細節的需求建議的程式設計師合作？
無缺草 而老闆決定做什麼。程式都這麼牛掰。又省了乙個員工，這個產品經理可以開除了，由程式來兼任。什麼，老子定了的還叨叨。那個產品走了沒，再叫回來，重找乙個程式。程式要按需求做，整天叨叨過度，不務正業，績效F。培訓軟體流程，改進不好淘汰。什麼？他叫張小龍？老張，對不起，我錯了。你看我不知道是你，哪個渾...
產品經理提出不合理的需求時 作為UI設計師該怎麼做？
日光傾城 產品素養過關的不會提出無腦的需求和智障的問題。往往提出這種想法的要不就是大牛級別實現了就可能現象級的產物要不就是技能不過關的 一般情況，設計師會思考解決方案的合理性和規範性。更好的情況，設計師會思考解決方案對問題本身解決的多與少。最理想的情況，設計師應該能結合產品的規劃與布局。其實很多時候...