⑴ 如何更好的与产品，需求方沟通
来自业务部门的需求，大致可以划分为两类：
第一类是明确的提出一些新功能需求，需求的背后通常都是同事自己在工作中遇到了困难，希望通过开发产品来节省自己的时间和力气、提高工作效率，例如说想在管理后台增加定时上线功能；在向产品人员提需求的过程中，运营方会说明自己在工作中遇到的问题，但是具体的解决方案就要靠产品经理自己了。我曾经做过一个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设计稿，确认设计稿。
第八步 ，协助研发开发，开始编辑测试用例和测试文档，并准备种子数据（如果有测试，就协助测试完成，如果没有，就自行完成）
第九步 ，测试，验收产品
第十步 ，上线，交付产品
以上流程中有的阶段可能会反复进行，最为重要的就是我们的沟通能力，下期我们继续讲解如何提高沟通协作能力，最后还是希望大家持续关注，微信公众号中搜索“小宝谈产品”，让我们一起在产品和运营的路上不断前行～