初级产品运营，如何跟好需求？

《初级产品运营，如何跟好需求？》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、初级产品运营，如何跟好需求？此处产品运营为侠义产品运营，单指产品运营师，不是产品&运营大序列。本篇文章写给刚刚入职产品运营职位，或者期望入职产品运营的人员，如有不足请随时指出。产品运营推进需求按照时间顺序简为：了解需求、沟通需求、确认方案、产品跟踪。了解需求了解需求可以分为：接收需求、需求现状、需求期望、需求涉及、需求收益。关于接收需求，必须自己认同接收需求方式，每个公司有每个公司的方式流程，甚至同一个公司内的不同产品运营团队也有所不同，本文就不班门弄斧，只是想说，接需求要量力而为，接属于自己的正确需求。

2、如果不是自己职责内的需求不要去触碰（除非你对其极为有兴趣，特别想了解此部分），不是自己职责内的需求很难理解需求，还容易遭到PM的投诉，甚至最后沦为背锅着；如果需求为不合理需求（包括不能说服你自己的需求）一定不要接，因为很明显接下来要被PM狂喷，然后。。。关于需求现状的了解，判断需求真伪为什么出现这个需求？现在产品是什么样子的？（相信没有几个产品运营对自己负责的产品100%了解，这是个坑）现在情况下需求方在怎么处理？需求方提这个需求到底因为什么？为了什么？但是此处要求产品运营要对业务有所了解，作为一名产品运

3、营一定要对业务有所了解，甚至说比业务更加了解业务。如果不了解业务会导致你不能快速理解需求，不能快速GET到业务关键点，沟通浪费时间，还会让业务质疑你的专业性。关于需求期望，初期产品模型其实，很多的时候需求方并不知道自己想要的是什么（或者给出的期望是不能解决他们的问题的），他们只是感觉不爽，希望可以改进。这个时候一定要谨慎，一定要了解业务，了解需求方提出这个需求究竟是为什么，然后判断需求是否和需求方所说一致。如果与需求方所说不一致，那么你就需要去实地了解、使用、甚至调研，获取最真实的需求。获取真实需求后要与

4、需求方沟通（切记沟通，否则容易遭到投诉），沟通后确定最真实需求。确认需求之后，可以与需求方讨论出初期产品期望模型以及确定业务放期望排期，是初期不是最终，所以不要跟需求方把话说死。关于需求涉及，关系背锅问题在于业务方沟通之时，一定要全局考虑需求，尽量将需求考虑好，考虑复杂，注重需求将会涉及的部门及人员，一定要考虑完全，可以按照如下方向梳理：此产品需求涉及哪些产品端变动此产品需求是否涉及策略问题，需要leader同意是否有其他部门也拥有同样的需求是否有相关相似需求，可以同时改进如果产品上线涉及哪些部门使用如果

5、产品更改是否会影响其他部门使用关于需求收益，评定需求优先级很多产品运营在于PM沟通产品需求的时候经常被PM问：多少人有这个需求，需求上线能给公司来到多少收益。然后需求更多的是被拍回，等待你收集好数据卷土重来，或者直接搁置放弃。其实，每一个产品需求，作为一名产品运营师都应该了解清楚，不能盲目的去推进，毕竟我们要了解产品上线会有多少人受益，会有多少收益。的确有些产品功能是没有办法评估收益的，那么你要根据重要紧急度给出一个评定，根据重要紧急度与需求收益结合，你可以很好的将待实现的产品需求进行评定，分级，紧急需求

6、先推进，重要需求勤推进，相信这样PM也没有办法驳回需求。沟通需求此处需求沟通主要是与PM沟通，同时也会涉及与需求方沟通沟通需求阶段是这些阶段中最煎药的阶段，也是决定你的需求在PM心中的评定，所以一定要注重。需求一定要了解清楚一定要比产品了解业务使用情况一定要对需求有初步方案（即时是一个大概也好，要知道你要做什么）对产品上线后推广有预期沟通中切记不要做传话筒，要自己有所了解，让PM与需求方认为你是不可或缺的，当然，你不是万能的，如果必要的情况下可以将需求方及PM放在一起沟通。在PM部门之间跨部门沟通时（负责

7、不同方向不同产品的PM），尽力将双方放在一起沟通，防止出现确认之后变更的事情出现。沟通过程中一定要有会议纪要，以为这个是你们确定的凭证，各端人员都必须承认。确认方案确认方案应该是整个跟进过程中最爽的时候，也是撕逼比较多的时候，这个时候你不光要搞定PM搞定需求方，还要帮PM搞定RD+FE+DA与PM确认方案，本环节是你与PM接触时间最长，相亲相爱的一个阶段，此处建议可以在沟通前自己思考一份产品初步方案，根据产品初步方案与PM共同沟通新的产品方案。产品方案沟通中，这个时候你们相互需要，PM将会提供一份你较为满

8、意的PRD（MRD），同时方案确认的过程中，PM也需要你从中沟通，确认很多产品方案的细节，这个时候你一定要在，帮产品确认好，因为这个关系到产品功能是否真的切合实际。需求评审一定要跟PM说叫上你，需求方评审（业务方评审）一定要叫上你，这个时候如果需要改动一定要尽快变更，不要推延到技术评审或者交互评审。技术评审的时候也要跟PM处好关系准时参加，因为你不在研发大大们可以“肆无忌惮”砍需求，你需要站在需求方的角度，用你的理由保护你的需