產品需求文件簡稱PRD（Product-Requirement-Document)，是產品經理最核心的交付物，沒有之一（產品算是業務、產品、運營共同的交付成果），反正就是非常、非常得要。

一般情況PRD的產生過程，會因為發起方不同，過程略有差異，如下：

產品端發起：可行性研究-》業務調研-》原型設計-》業務評審-》PRD編寫-》技術評審-》研發、測試、上線等。

業務端發起：接收需求-》業務調研-》原型設計-》需求確認-》PRD編寫-》技術評審-》研發、測試、上線等。

而一個PRD要想寫的好，就要把前邊的每一步都做好，並且滿足技術評審的需要，這樣PRD就算是及格了。

一這個需求是否名正言順，究竟是做？還是不做？。考驗的是PM的業務判斷力，做這個事究竟有沒有價值？是不是值得投入？此過程無法投機取巧，如果實在判斷不出來，兩個方法：

尋求外界幫助

在做的過程中，再進行不斷論證，及時糾錯

兩個關鍵點要特別注意：

當調研物件表達觀點時，不能原樣照搬，要有自己的分析。PM圈的話叫：“別聽調研物件說什麼？要聽調研物件因為什麼這麼說”。

調研過程要全面，對於特殊流程務必做好記錄工作，這將是PRD產出的素材，多多益善。

不同的PM有不同的習慣，有些PM隨便在Axure裡隨便畫畫，就敢拉業務評審，再趕上不負責任的業務，很容易透過，卻給後續留下了無盡的隱患。

所以我的習慣是做Axure原型圖、然後把PPT做出來（理順思路）、再然後把PRD初稿做完（把細節考慮完整，再進行下一步），保證業務評審前的準備充分。

兩個關鍵點要特別注意：

B端產品服務於業務，對於有些業務細節，PM就是沒法瞭解充分，需要業務人員補位。，所以要善於引導業務，CHECK主流程的同時，也要CHECK業務細節。

對外的業務評審/需求確認，務必要簽字；對內的業務評審/需求確認，務必要有會議紀要，防止他們事後不認賬；這個非常重要、重要、重要。

也有兩個關鍵點要特別注意：

不要偷懶，嚴格參照部門的格式模板。模板是一個非常好的，幫你理思路的工具，有些PM工作習慣不太好，常常因為模板麻煩，而把PRD寫得很簡單，結果開發或上線後，因為有些事沒考慮到，而產生很多問題。但其中有些問題，是可以透過使用PRD模板避免的。

PRD主要是RD人員來使用，為的使他們能看的懂，不妨多舉一些例子。

業務、產品、技術，大家立場不同、背景不同。同樣一件事，同樣一句話，大家可能理解都不一樣。我個人常用的方法是，“我說、你說”就是這個需求，我說一遍，你再用你的話說一遍，確保理解沒有出現分歧。如有變化或關鍵點，需及時更新到PRD上。

對於題目中說的寫好寫好PRD，做好上邊幾點，就差不多了。但很多細節是沉在基本功裡，不是一篇回答可以寫盡。