互聯網公司中，產品部門的需求主要來自於兩方：一是來自於產品內部自己的idea；二是來自業務部門，至於說到業務部門具體指哪些，可能是產品運營人員和公司高層，也可能是來自於市場或者商務等，這由公司的性質和業務決定。
不同的需求，對產品經理也會有不同的影響。前者的優點在於可以充分發揮產品經理自己的想法；而後者的優點在於需求比較明確，產品人員只需給出解決方案即可。缺點在於溝通成本會比較高，對產品經理自身想法的發揮也會有侷限性。相比較而言前者產品的風險性會更高，之所以這麼說是因為後者的需求很多時候滿足的都是公司內部，例如CRM系統滿足編輯使用，這類產品雖然用戶量不大，至少有其用處。面向用戶的產品，如果用戶每需求那產品最終就會被關閉，產品經理就要看到自己的努力付諸東流了。
來自業務部門的需求，大致可以劃分為兩類：
第一類是明確的提出一些新功能需求
需求的背後通常都是同事自己在工作中遇到了困難，希望通過開發產品來節省自己的時間和力氣、提高工作效率。例如說想在管理後臺增加定時上線功能；在向產品人員提需求的過程中，運營方會說明自己在工作中遇到的問題，但是具體的解決方案就要靠產品經理自己了。
我曾經做過一個EDM系統，其中有一個細節給我的印象很深：運營人員把他們的一個需求描述的很複雜，還跟我描述了他們做郵件營銷的整個工作流程，拿他們的工作文檔給我看，其實終歸他們只是需要看一下自己的營銷郵件發送時間與別的產品是否有撞期的情況。想要的東西其實很簡單，但卻費了很多唾沫。
因公司內部需求而做的產品，很大程度上也是供公司內部人員使用的。在產品設計中，我們有一條原則是先有後優，本身也是後臺，更注重實用性，所以本著優先上線、縮短開發成本的原則，對於產品的交互和美觀性方面的要求相對也都會低一些。
第二類是反饋用戶的需求
畢竟運營人員是直接跟用戶打交道的，他們會把一些用戶的反饋轉述給產品經理。如果是轉述用戶的需求，就需要尋找滿足需求的方法。這也分兩種情況：如果是用戶提出的新功能就要衡量是否有必要開發新產品滿足；如果是對現有產品的改善建議，那就要尋找現有產品的缺陷，繼而優化改善。
至於怎麼優化，要綜合三個方面進行考量：
- 同一個問題用戶反饋的數據量針對用戶的反饋做一些相關的數據分析，看問題的用戶覆蓋範圍考慮與產品未來的發展方向是否一致，有時候如果用戶反饋的意見與產品未來的發展不一致，即便是呼聲很高，產品經理也要繼續堅持。
我個人在產品經理與需求方溝通過程中總結了一個原則，就是：聽他的，但不跟他走。
聽他的——要聽運營方的需求，畢竟產品的最終目的是要滿足他們的需求。不跟他走——雖是滿足運營方的需求，但是產品經理不應被牽著鼻子走，不能他說什麼就是什麼。而且產品經理與需求人員在合作的過程中各司其職，需求人員負責的是功能和內容能否滿足，而產品經理則需要決定界面的排版和詳細的功能。
實際情況中，如果產品經理一味聽從需求方而沒有自己判斷的話，會發生一種情況就是把需求的滿足方式設計的特別複雜，結果給開發人員帶來了很大工作量。但是當產品經理的設計與需求方的設想有出入的時候，多半還是要產品方作出讓步。
有兩點需要產品經理注意：
一是由於需求方因為不懂技術，所以提需求的時候不會去考慮能否實現（雖然很少會碰到無法實現的情況）。如果有這種情況，需要產品經理的腦子靈活一點，找一種折中的方式解決。
也有需求方由於擔心技術實現難度，所以在提需求的時候會提的比較簡單，有些工作寧可自己做。這時候就需要產品經理髮揮自己的能力，給需求方提供一些更好用的工具。
二是在溝通的過程中很多事情需求方也未必能想得到，如果產品經理幫他們想到了或是根據他們的需求給出了更好的方案，這樣肯定會達到更好的效果，也會提高需求方對於自己的信任度。
我曾經做過一個獎品管理系統，需求方提出了他們想看到的數據，我當時規劃的後臺已經能夠滿足他們，後來我給他們添加了一個統計功能，便於他們查看某個活動獎品的發放情況以及花費的費用等，因為當時覺得這些會是他們非常關注的信息，他們看到後就感覺很欣喜，覺得很有用。
跟需求方打交道，有時候也看產品經理的運氣，合作的愉快程度跟需求方的職能和工作經驗有關。如果需求方的工作經驗很豐富的話，他們會幫產品經理想到很多點。
如果是做產品運營的，因為他們的互聯網思維意識比較強，所以無論對於概念的理解還是功能的使用上都會更熟悉，在需求的溝通過程中也會更順暢一些。相對而言，跟市場、客服部門的同事溝通起來就會差一些，因為這些部門的人有很多都屬於小白用戶。
如果需求方的經驗不多或是小白用戶，在溝通的過程中，產品經理會非常被動。特別是當由產品部去發起做一個供公司內部人員使用的產品時，就需要不斷的去了解產品使用者的工作流程，去問他們在這中間遇到的問題，這不僅需要產品經理積極的推動能力，還需要有很大的耐心，如果對方屬於比較強勢的那一種的話，恐怕還需要產品經理受一點委屈。
理想的情況，如果業務部門跟產品經理合作的過程中，雙方都能夠積極的配合，會使得產品上線的過程更加順利。反之，則需要產品人員的主動意識和責任心更強一些。
互聯網公司中，產品部門的需求主要來自於兩方：一是來自於產品內部自己的idea；二是來自業務部門，至於說到業務部門具體指哪些，可能是產品運營人員和公司高層，也可能是來自於市場或者商務等，這由公司的性質和業務決定。
不同的需求，對產品經理也會有不同的影響。前者的優點在於可以充分發揮產品經理自己的想法；而後者的優點在於需求比較明確，產品人員只需給出解決方案即可。缺點在於溝通成本會比較高，對產品經理自身想法的發揮也會有侷限性。相比較而言前者產品的風險性會更高，之所以這麼說是因為後者的需求很多時候滿足的都是公司內部，例如CRM系統滿足編輯使用，這類產品雖然用戶量不大，至少有其用處。面向用戶的產品，如果用戶每需求那產品最終就會被關閉，產品經理就要看到自己的努力付諸東流了。
來自業務部門的需求，大致可以劃分為兩類：
第一類是明確的提出一些新功能需求
需求的背後通常都是同事自己在工作中遇到了困難，希望通過開發產品來節省自己的時間和力氣、提高工作效率。例如說想在管理後臺增加定時上線功能；在向產品人員提需求的過程中，運營方會說明自己在工作中遇到的問題，但是具體的解決方案就要靠產品經理自己了。
我曾經做過一個EDM系統，其中有一個細節給我的印象很深：運營人員把他們的一個需求描述的很複雜，還跟我描述了他們做郵件營銷的整個工作流程，拿他們的工作文檔給我看，其實終歸他們只是需要看一下自己的營銷郵件發送時間與別的產品是否有撞期的情況。想要的東西其實很簡單，但卻費了很多唾沫。
因公司內部需求而做的產品，很大程度上也是供公司內部人員使用的。在產品設計中，我們有一條原則是先有後優，本身也是後臺，更注重實用性，所以本著優先上線、縮短開發成本的原則，對於產品的交互和美觀性方面的要求相對也都會低一些。
第二類是反饋用戶的需求
畢竟運營人員是直接跟用戶打交道的，他們會把一些用戶的反饋轉述給產品經理。如果是轉述用戶的需求，就需要尋找滿足需求的方法。這也分兩種情況：如果是用戶提出的新功能就要衡量是否有必要開發新產品滿足；如果是對現有產品的改善建議，那就要尋找現有產品的缺陷，繼而優化改善。
至於怎麼優化，要綜合三個方面進行考量：
- 同一個問題用戶反饋的數據量針對用戶的反饋做一些相關的數據分析，看問題的用戶覆蓋範圍考慮與產品未來的發展方向是否一致，有時候如果用戶反饋的意見與產品未來的發展不一致，即便是呼聲很高，產品經理也要繼續堅持。
我個人在產品經理與需求方溝通過程中總結了一個原則，就是：聽他的，但不跟他走。
聽他的——要聽運營方的需求，畢竟產品的最終目的是要滿足他們的需求。不跟他走——雖是滿足運營方的需求，但是產品經理不應被牽著鼻子走，不能他說什麼就是什麼。而且產品經理與需求人員在合作的過程中各司其職，需求人員負責的是功能和內容能否滿足，而產品經理則需要決定界面的排版和詳細的功能。
實際情況中，如果產品經理一味聽從需求方而沒有自己判斷的話，會發生一種情況就是把需求的滿足方式設計的特別複雜，結果給開發人員帶來了很大工作量。但是當產品經理的設計與需求方的設想有出入的時候，多半還是要產品方作出讓步。
有兩點需要產品經理注意：
一是由於需求方因為不懂技術，所以提需求的時候不會去考慮能否實現（雖然很少會碰到無法實現的情況）。如果有這種情況，需要產品經理的腦子靈活一點，找一種折中的方式解決。
也有需求方由於擔心技術實現難度，所以在提需求的時候會提的比較簡單，有些工作寧可自己做。這時候就需要產品經理髮揮自己的能力，給需求方提供一些更好用的工具。
二是在溝通的過程中很多事情需求方也未必能想得到，如果產品經理幫他們想到了或是根據他們的需求給出了更好的方案，這樣肯定會達到更好的效果，也會提高需求方對於自己的信任度。
我曾經做過一個獎品管理系統，需求方提出了他們想看到的數據，我當時規劃的後臺已經能夠滿足他們，後來我給他們添加了一個統計功能，便於他們查看某個活動獎品的發放情況以及花費的費用等，因為當時覺得這些會是他們非常關注的信息，他們看到後就感覺很欣喜，覺得很有用。
跟需求方打交道，有時候也看產品經理的運氣，合作的愉快程度跟需求方的職能和工作經驗有關。如果需求方的工作經驗很豐富的話，他們會幫產品經理想到很多點。
如果是做產品運營的，因為他們的互聯網思維意識比較強，所以無論對於概念的理解還是功能的使用上都會更熟悉，在需求的溝通過程中也會更順暢一些。相對而言，跟市場、客服部門的同事溝通起來就會差一些，因為這些部門的人有很多都屬於小白用戶。
如果需求方的經驗不多或是小白用戶，在溝通的過程中，產品經理會非常被動。特別是當由產品部去發起做一個供公司內部人員使用的產品時，就需要不斷的去了解產品使用者的工作流程，去問他們在這中間遇到的問題，這不僅需要產品經理積極的推動能力，還需要有很大的耐心，如果對方屬於比較強勢的那一種的話，恐怕還需要產品經理受一點委屈。