⑴ 如何更好的與產品，需求方溝通
來自業務部門的需求，大致可以劃分為兩類：
第一類是明確的提出一些新功能需求，需求的背後通常都是同事自己在工作中遇到了困難，希望通過開發產品來節省自己的時間和力氣、提高工作效率，例如說想在管理後台增加定時上線功能；在向產品人員提需求的過程中，運營方會說明自己在工作中遇到的問題，但是具體的解決方案就要靠產品經理自己了。我曾經做過一個EDM系統，其中有一個細節給我的印象很深，運營人員把他們的一個需求描述的很復雜，還跟我描述了他們做郵件營銷的整個工作流程，拿他們的工作文檔給我看，其實終歸他們只是需要看一下自己的營銷郵件發送時間與別的產品是否有撞期的情況。想要的東西其實很簡單，但卻費了很多唾沫。
因公司內部需求而做的產品，很大程度上也是供公司內部人員使用的。在產品設計中，我們有一條原則是先有後優，本身也是後台，更注重實用性，所以本著優先上線、縮短開發成本的原則，對於產品的交互和美觀性方面的要求相對也都會低一些。
第二類是反饋用戶的需求，畢竟運營人員是直接跟用戶打交道的，他們會把一些用戶的反饋轉述給產品經理。如果是轉述用戶的需求，就需要尋找滿足需求的方法，這也分兩種情況，如果是用戶提出的新功能就要衡量是否有必要開發新產品滿足，如果是對現有產品的改善建議，那就要尋找現有產品的缺陷，繼而優化改善。至於怎麼優化，要綜合三個方面進行考量，一個是同一個問題用戶反饋的數據量，二是針對用戶的反饋做一些相關的數據分析，看問題的用戶覆蓋范圍，三是考慮與產品未來的發展方向是否一致，有時候如果用戶反饋的意見與產品未來的發展不一致，即便是呼聲很高，產品經理也要繼續堅持。
我個人在產品經理與需求方溝通過程中總結了一個原則，就是：聽他的，但不跟他走。聽他的——要聽運營方的需求，畢竟產品的最終目的是要滿足他們的需求。不跟他走——雖是滿足運營方的需求，但是產品經理不應被牽著鼻子走，不能他說什麼就是什麼。而且產品經理與需求人員在合作的過程中各司其職，需求人員負責的是功能和內容能否滿足，而產品經理則需要決定界面的排版和詳細的功能。實際情況中，如果產品經理一味聽從需求方而沒有自己判斷的話，會發生一種情況就是把需求的滿足方式設計的特別復雜，結果給開發人員帶來了很大工作量。但是當產品經理的設計與需求方的設想有出入的時候，多半還是要產品方作出讓步。
有兩點需要產品經理注意：
一是由於需求方因為不懂技術，所以提需求的時候不會去考慮能否實現，但很少會碰到無法實現的情況，如果有這種情況，需要產品經理的腦子靈活一點，找一種折中的方式解決。也有需求方由於擔心技術實現難度，所以在提需求的時候會提的比較簡單，有些工作寧可自己做。這時候就需要產品經理發揮自己的能力，給需求方提供一些更好用的工具。
二是在溝通的過程中很多事情需求方也未必能想得到，如果產品經理幫他們想到了或是根據他們的需求給出了更好的方案，這樣肯定會達到更好的效果，也會提高需求方對於自己的信任度。我曾經做過一個獎品管理系統，需求方提出了他們想看到的數據，我當時規劃的後台已經能夠滿足他們，後來我給他們添加了一個統計功能，便於他們查看某個活動獎品的發放情況以及花費的費用等，因為當時覺得這些會是他們非常關注的信息，他們看到後就感覺很欣喜，覺得很有用。
跟需求方打交道，有時候也看產品經理的運氣，合作的愉快程度跟需求方的職能和工作經驗有關。如果需求方的工作經驗很豐富的話，他們會幫產品經理想到很多點。如果是做產品運營的，因為他們的互聯網思維意識比較強，所以無論對於概念的理解還是功能的使用上都會更熟悉，在需求的溝通過程中也會更順暢一些。相對而言，跟市場、客服部門的同事溝通起來就會差一些，因為這些部門的人有很多都屬於小白用戶。
如果需求方的經驗不多或是小白用戶，在溝通的過程中，產品經理會非常被動。特別是當由產品部去發起做一個供公司內部人員使用的產品時，就需要不斷的去了解產品使用者的工作流程，去問他們在這中間遇到的問題，這不僅需要產品經理積極的推動能力，還需要有很大的耐心，如果對方屬於比較強勢的那一種的話，恐怕還需要產品經理受一些委屈。
理想的情況，如果業務部門跟產品經理合作的過程中，雙方都能夠積極的配合，會使得產品上線的過程更加順利。反之，則需要產品人員的主動意識和責任心更強一些。
⑵ 產品經理，如何做需求分析
作為產品經理，每天要接觸到大大小小不同的需求，在面對需求時，需要進行有效的需求分析，才能更好地了解問題，從而制定相應的解決方案，就是通過用戶的問題，找到用戶需求的最本質，給予最合適的方案，滿足用戶需求。
需求分析是產品經理平常最基礎且重要的工作，確保需求的可行性，隨之進行後續的操作和跟進，需求分析也能發散出比較多的思考。
需求到底該如何分析？
需求的真偽判斷，在產品的生命周期里，我們需要對每一個需求進行判斷，不管是宏觀層次還是執行層次。而對於真偽需求的判斷總是模稜兩可的，我們需要根據產品生命周期、當前公司戰略、技術水平等很多情況進行斟酌。
用戶的需求也像一座冰山，有很大一部分隱藏在海平面以下，只有很少一部分需求暴露在海平面以上。
有時候我們收到用戶需求後，並且按他們的要求做了，但是在上線之後才發現所做的東西並不是他們想要的，這時候你應該怎麼辦？是怪自己還是怪用戶。可能他們提需求的時候都不清楚自己的真實需求，當然沒法告訴你了。
這就需要產品經理從自己專業的角度上出發，幫客戶找到那些隱藏的需求。我們經常所說的需求挖掘，主要就是找到隱藏在冰面下的需求。用戶的需求分成意識到的需求、無意識的需求、進一步的需求三種：
1、 意識到的需求 ：表面上的需求，就是一些直接體現的問題，這些大部分產品經理在調研的過程中可以直接獲取到；
2、 無意識的需求 ：這種問題需要產品經理對業務有一定的理解才能發現。只有對這類場景能做到「感同身受」的話，產品經理設計的過程中才能夠設計出更合理、更高效的方案；
3、 進一步的需求 ：這是項目的深層需求，用戶對於他們自己遇到的問題也沒有辦法提出關鍵的解決方案。因此需要產品經理對問題充分理解的前提下，選擇合適的實現方式以創造用戶未想到的功能。
⑶ 在提需求的時候，應該如何更加有效地與產品經理進行溝通#互聯網產品/運營管理#
咱們倆算是同行啊，其實不論是跟哪位同事溝通，重要的都是「需求整理」，主要是將雜亂的信息，用產品化的語言，表達得更加准確，可以將收集到的需求進行關鍵要素的提取，這些要素可以包括日期、反饋渠道、需求類型、關聯方、優先順序、備注等。梳理了以上這些信息後，這些信息可以通過一個表格的形式，清晰地展現出來。我覺得這樣做會更有效率。 來自職Q用戶：楊女士
1、理清需求的業務目的
2、理清目前整個業務操作流程及細節，如哪些是系統實現，哪些是人工支持
3、理清需求目標，如系統實現需要優化哪部分或人工支持部分是否需要新開發系統替換人工操作。
基於以上，產品經理能清晰的歸納整理出系統需要實現的需求
舉個實例：希望增加自動對賬功能
1、業務目的：實現自動化第三方對賬，節省時間、解放人力
2、目前操作流程及細節：1）操作流程：每天人工要求開發人員資料庫提取數據後與第三方郵件發來的數據進行人工核對；2）細節：a. 目前要求開發提取數據包含哪些內容；b.第三方數據包含哪些內容；c. 對賬成功標准；等等
3、需求目標：完全取消人工介入，或者減少人工介入
。如需完全取消人工介入，則依賴第三方是否支持介面對賬，如支持，要求第三方提供介面文檔及技術對接人。
以上，供參考 來自職Q用戶：匿名用戶
⑷ 產品經理日常：剛接到一個新需求，應該怎麼處理
作為產品經理，接收需求簡直是我們日常工作中再基本不過的事情了，只要和你有交集，都有可能產生需求，有可能是用戶直接反饋的需求，也有可能是公司運營、市場等部門同事給你反饋的需求，也有可能是老闆直接給你提的需求，當遇到這些需求的時候，我們應該怎麼去做呢？
我們首先需要去判斷下這個需求的真偽，接下來根據我們分析需求的優先順序進行排序，讓我們的產品圍繞核心目標朝著一個健康的方向不斷進行迭代。中間最關鍵一點就是要做好溝通反饋，不然給你反饋需求的人會認為你沒有重視起來，對於需求方來說會產生很多負面情緒，所以這一點一定要重視起來。
接下來，我們再來聊聊怎麼去分析需求，或者說怎麼去判斷需求的真偽，我們知道在設計某個功能的時候，就是為了解決用戶在某個場景下所發生的需求，從而解決這些問題，這個功能才會存在價值。那麼，如果用戶提的需求我們理解的不正確，設計的功能很可能無法真正解決問題，甚至僅僅是解決了用戶的表面需求，出現功能做了，用戶也不會去用，導致我們時間和精力都浪費了，最後的結果也不太令人滿意。
那麼，當我們遇到需求的時候，是否應該立即去處理呢？
我建議應該這樣去做：
1. 用戶為什麼會產生這個需求？
當需求方向你闡述完某個需求後，向他詢問：提這個需求的目的是什麼？即為什麼會產生這個需求？這個問題可以幫你完全理解需求，並辨別需求的真偽。
2. 用戶在什麼場景下會使用這個需求？
即搞清楚什麼人在什麼情況下會用到此功能。明白了這個，才知道如何更好地設計功能來滿足需求。
3. 是否有可能衍生出新的場景？
為了避免設計的功能因擴展性不足，後期推翻重來，在一開始，就應該做盡可能全面的考慮。通過需求方的場景，擴展思考，是否存在衍生的場景。思考的過程，也是幫助你抓住和理解需求本質的過程。
4. 技術層面如何看待這個需求？
接到需求，並充分理解了需求後，跟相關技術負責人花幾分鍾時間討論一下，聽聽他從技術上對需求的考慮。通過此過程，你們基本會對需求點及實現方式達成共識，在後期正式開發時，阻礙會小得多。
5.做了這個需求對用戶有什麼影響，以及用戶對這個需求的緊急和重要程度是怎麼樣的？
一定要問清楚，處理這個需求對用戶的有利影響和不利影響是什麼，從而判斷需求的類型，以及緊急重要程度，最後一定要多詢問一句，需求方對這個需求的緊急重要程度的認知，避免我們分析完需求的緊急重要程度和需求方理解的不一致，導致最後出現矛盾。
那麼，當需求方對需求不明確的時候，應該怎麼處理呢？
我建議這樣處理：
1.最直接的方式，誰提出的需求，找誰搞清楚需求，最好讓需求方把場景描述清楚，還原需求的真實使用場景，有助於幫助我們來更好的理解需求，有可能需求方調研清楚以後，該需求可能就不會存在了。
2.如果需求方也說不清楚自己想要的是啥，在你聽完他不清晰的描述後，利用你的專業技能，幫他梳理，並跟他確認，你的想法是否正確，是否就是他想要的
3.向對方提問題是搞清楚一件事情最好的方式，或許可以嘗試這么問需求提出者：什麼人在什麼情況下會做什麼事？你現在實際操作中覺得哪裡是最困難不方便的？你覺得最好的操作方式應該是什麼樣的？類似這類問題，既是幫你搞清楚問題，也是幫對方梳理思路。
當需求明確後，後續的工作流程就會清晰很多，我們做個復盤，來看下我的工作流程：
第一步 ，與需求方進行溝通，主要是復述你接收到的需求，確保需求接收正確沒有存在理解偏差。
第二步 ，我把它叫做清洗需求池，把接收到的需求進行清洗，分類出那些是已有替代功能完成了的，哪些是在之後的版本中有規劃的了，哪些是與公司戰略及產品目標不符合的需求，哪些是可以在這個版本加入的需求，同時評估需求的可行性、優先順序、難易度。
第三步 ，將上述第二步的結果形成文檔，並提交需求方，最好是自己親自講解，獲取需求方的同意。這一步至關重要。
第四步 ，需求的具體分析，梳理邏輯關系，業務流程。
第五步 ，進行原型設計，如果需要出PRD，再這個階段也一塊進行輸出。
第六步 ，開原型評審會（就是我們常說的kick-off會議），與UI、研發一同溝通需求及PRD，對會上的東西進行及時的補充和改進。
第七步 ，跟進UI設計稿，確認設計稿。
第八步 ，協助研發開發，開始編輯測試用例和測試文檔，並准備種子數據（如果有測試，就協助測試完成，如果沒有，就自行完成）
第九步 ，測試，驗收產品
第十步 ，上線，交付產品
以上流程中有的階段可能會反復進行，最為重要的就是我們的溝通能力，下期我們繼續講解如何提高溝通協作能力，最後還是希望大家持續關注，微信公眾號中搜索「小寶談產品」，讓我們一起在產品和運營的路上不斷前行～