互联网企业中的产品需求主要来自两个方面：一是内部产品团队构思；二是业务部门提出。业务部门包括产品运营人员、高层管理者、市场或商务部门，具体由公司的性质和业务决定。
不同的需求类型对产品经理的影响有所不同。内部想法的好处是产品经理可以充分发挥自己的创意；而基于业务需求的好处是需求明确，产品经理只需提供解决方案。不足之处是沟通成本较高，对产品经理的想法发挥有一定限制。相比之下，第一种需求的风险更高，因为这种需求往往是为了满足内部使用，例如 CRM 系统满足编辑使用，此类产品虽然用户数量不大，但至少有其用处。而面向用户的产品，如果无法满足用户需求，最终会被关闭，导致产品经理的努力付诸东流。
业务部门的需求大致可分为两类：
此类需求通常是由于同事在工作中遇到了困难，希望通过开发产品来节省时间和精力、提高工作效率。例如，要求在管理后台增加定时上线功能。在提出需求时，运营方会阐述他们在工作中遇到的问题，而具体的解决方案需要产品经理自己制定。
我曾经开发过一个 EDM 系统，其中一个细节给我留下了深刻的印象：运营人员将他们的需求描述得非常复杂，还向我详细讲述了他们的电子邮件营销工作流程并向我展示了他们的工作文档，但他们的实际需求只是查看自己的营销邮件发送时间是否与其他产品冲突。他们想要的其实很简单，但浪费了很多时间和精力。
基于公司内部需求开发的产品主要供公司内部人员使用。在产品设计中，我们遵循的原则是先有后优，本身是后台，更注重实用性，基于优先上线和缩短开发成本的原则，对产品的交互和美观性等方面的要求也会相对较低。
运营人员直接与用户打交道，他们会将一些用户反馈转达给产品经理。如果是转述用户的需求，则需要寻找满足需求的方法。这有两种情况：如果是用户提出的新功能，则需要考虑是否有必要开发新产品来满足需求；如果是对现有产品的改进建议，则需要找到现有产品的缺陷，进而加以优化改进。
至于如何优化，需要综合以下三个方面进行考量：
- 相同问题用户反馈的数据量
- 根据用户的反馈做一些相关的数据分析，了解问题的用户覆盖范围
- 考虑与产品未来的发展方向是否一致，有时候如果用户反馈的意见与产品未来的发展不一致，即便呼声很高，产品经理也要坚持自己的立场。
我在与需求方沟通的实践中总结了一个原则：听他的，但不跟他走。
听他的——要倾听运营方的需求，毕竟产品的最终目的是满足他们的需求。不跟他走——虽然要满足运营方的需求，但产品经理不应该盲目接受，不能对方说什么就是什么。在产品经理与需求人员的合作过程中，各司其职，需求人员负责评估功能和内容是否满足要求，而产品经理则需要决定界面的布局和详细的功能。
在实际情况下，如果产品经理一味听从需求方而没有自己判断，就会出现一种情况，即需求的满足方式设计得过于复杂，给开发人员带来很大的工作量。当产品经理的设计与需求方的设想不一致时，通常是产品方做出让步。
原因之一是，由于需求方不了解技术，因此在提出需求时不会考虑能否实现（虽然很少会遇到无法实现的情况）。如果出现这种情况，需要产品经理灵活变通，找到折中的解决办法。
也有需求方担心技术实现难度，因此在提出需求时会比较简单，有些工作宁愿自己做。这时候就需要产品经理发挥自己的能力，为需求方提供更易用的工具。
原因之二是，在沟通的过程中，很多事情需求方未必能想到，如果产品经理帮他们想到了或根据他们的需求给出了更好的方案，肯定会达到更好的效果，也会提高需求方对自己工作的信任度。
我曾经开发过一个奖品管理系统，需求方提出了他们想看到的数据，我当时规划的后台已经能够满足他们的需求，后来我给他们添加了一个统计功能，便于他们查看某个活动奖品的发放情况以及花费的费用等，因为我当时觉得这些会是他们非常关注的信息，他们看到后立即感到很高兴，觉得很有用。
与需求方打交道，有时候也取决于产品经理的运气，合作的愉快程度与需求方的职能和工作经验有关。如果需求方的工作经验很丰富，他们会帮助产品经理考虑很多细节。
如果是做产品运营的，因为他们的互联网思维意识比较强，所以无论对于概念的理解还是功能的使用上都会更熟悉，在需求的沟通过程中也会更顺畅一些。相对而言，与市场和客服部门的同事沟通起来就会差一些，因为这些部门的人员中有许多属于小白用户。
如果需求方的经验不足或属于小白用户，在沟通的过程中，产品经理会非常被动。特别是当产品部发起开发一个供公司内部人员使用的产品时，就需要不断地了解产品使用者的工作流程，询问他们在工作中遇到的问题，这不仅需要产品经理积极的推动能力，还需要有很大的耐心，如果对方属于比较强势的那一种，恐怕还需要产品经理受一点委屈。
理想的情况是，如果业务部门和产品经理在合作的过程中，双方都能积极配合，会使得产品上线的过程更加顺利。相反，则需要产品人员主动意识和责任心更强一些。