3分鐘寫好產品調研「產品需求調研報告怎麼寫」

許多產品經理在需求調研都會犯一個相同的錯誤。

“下載一款新產品，就提出產品的問題，說出產品哪裡不好用、哪個功能好用”

判斷出什麼好，什麼壞就結束需求調研了

但實際上，產品經理僅靠發現什麼好用、哪個功能創新是無法提升自己產品設計能力、完善自己工作產品的。

產品經理做需求調研要詳細依靠：

功能描述、交互設計、商業模式、用戶定位、優化&建議5個維度去做。只有這樣才可以轉化為可以用的產品。

但如此多的產品經理都只站在一個普通用戶視角去做需求調研，為什麼會這樣呢？

原因很簡單，站在用戶角度才是最簡單、不費腦子的體驗產品，只有經過重複不斷的操作、各類極端情況體驗、和推演歸納才能區分出上面5個維度的需求調研。

所以要想一個產品經理對每一款產品，都走4步驟。除了工作的硬性要求，生活中這點是不可能的。

2.產品經理去理解產品-使用產品-優化產品

不是工作需求，我們平時的體驗都僅提留在“使用產品上”，真正要轉化為忠實用戶、付費用戶，要麼是自己生活需要，要麼就是綁定性服務，比如我買了小米的智能家居則需要下載小米家APP才能完成智能硬件操作。

所以產品經理在日常中，很少以需求調研的習慣去使用一款產品。這也導致很多人把需求調研歸功於溝通能力、文檔能力。

其實需求調研是一個單獨的考核能力。

產品經理的需求調研主要做什麼？

有人人都可做產品經理的概念吹捧，導致好像只要有一顆發現問題、並解決問題的心，就可以算產品經理的需求調研。沒有具體的規範，很多企業在招聘上都不引起對需求調研能力的重視。

但實際上真正的產品經理職位上，需求調研其實是有標準的。

無論是那種類型的產品經理、還是老鳥新人，都適用。

1. 功能性需求界定

比如曾經我在做客服系統時候，客服部門隨着日常客服諮詢量增加，客服人員的效率極度下降，急需要提供一套語料會話機制，智能問答、快速回答，幫助提升服務效率。

這類場景，是比較典型的功能性需求。無論是業務方還是產品經理在調研後都可知道要增加什麼功能，具體怎麼做改造，目前互聯網公司最主要的調研方式就是這類功能性需求調研

▲ 客服系統的功能設計

也就是說缺什麼功能，就補充什麼功能。產品經理的核心能力表現在能不能把功能做到體驗好、又能效率高。

還有比如面向C端的產品上，功能性需要還有邏輯不合理、功能使用下有明顯bug、不穩定情況，也屬於這類需求。

2.既定業務流程與規範

比如曾經我在做醫療管理系統時候，醫生需要一套管理病人數據的問診系統。但由於病人在實際服務中有檢測數據、儀器設備數據等多端來源，以醫生為代表業務方並沒有規定到要怎麼展示、要什麼數據。

所以需求調研搞清楚整個全業務流程和每個業務節點的數據使用情況，比如有的單機設備（皮膚檢測儀）數據是拿不到，則需要人工導入或以“外掛”形式採集。

同時告知醫生們部分數據不能採集，但可以通過第三方設備展示，在醫生服務中增加用戶查詢第三方平台的操作流程

這部分工作是搞清楚邊界與規範。甚至是協助優化業務方的規則。

3.通過數據、問卷調研規律

這一部分需求調研其實是站在數據挖掘、和新功能的優化上的。比如在PMTalk產品經理社區裡面，你會發現周一到周五用戶的閱讀、訪問量是最高的，反而在周六周日是最低。

同時一到國慶等假期，數據也是最差的。

最後我們得出了一個結論：產品經理這群學習者是懶惰的，只有在工作日才會想起來學習。

由此我們在調研中給出在周一到周五的保證有廣告展示投放，和增加工作日簽到功能幫助提升用戶在高轉化周期的停留。

▲ 電腦管家增加簽到，增加用戶日常留存

4.推薦合適的產品給自己，將抽象變具體。

在需求調研中，由於互聯網所包含的業務越來越廣。產品經理不可能做到行行精通。比如監獄系統、政府環境管理系統，市面上都不可能有成熟的競品給到產品經理。

由此通過推薦一些同行的標準化產品，其實也是幫助產品經理更好具象化需求。畢竟最後需求調研是要落地到研發上線，必須要可以執行、可評估、可以統籌計劃、可以運營的。

無論什麼系統，都離不開用戶使用場景。用戶無非也是依靠查詢、增刪等操作來完成自己的使用。

5.確定能做與不能做的邊界

需求調研還有重要的部分，是確定什麼需要研發、什麼不需要。比如PMTalk在做小程序的時候，通過競品、和用戶畫像發現小程序讀文章的體驗差、還有內容展示存在與公眾號矛盾，給出結論在小程序里做文章閱讀是沒必要的。

但由於小程序滿足投放在社群的跳轉和數據獲取，用戶點擊小程序報名、利用小程序拼團門票是有意義的，因此我們在活動報名系統上選擇小程序。

同樣的場景還有閱讀第三方開放平台的開放文檔。通過閱讀平台開放文檔，確實有什麼能力和缺乏的能力。

閱讀API文檔，也是需求調研的重要一部分。熟悉平台能力有什麼，才能知道可以做什麼。

產品經理的需求調研，不是評價“好與壞”

綜上一個產品經理的需求調研，並不是站在用戶視角覺得：“產品好不好用”

反而是輸出業務、技術實現、資源整合、規則邊界的綜合性能力。在互聯網早期，需要調研還有專門的需求分析師職位。這類同學會最終輸出產品的問題、優化建議等，和產品經理的區別是不會給出原型、或產品方案。

同時需求調研依靠產品經理背後強大的方法履歷工作經驗。你做過多少同類產品就清楚同樣產品的普遍實現方案，說白了就是找到問題、和問題解決方法是核心產品經理的知識沉澱。

由此，經驗和從業時間也十分影響一位產品經理的需求調研能力。最主要是的要養成超過“普通用戶”視角以產品經理角度觀察產品的習慣。