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

　　此处产品运营为侠义产品运营，单指产品运营师，不是产品运营大序列。本篇文章写给刚刚入职产品运营职位，或者期望入职产品运营的人员，如有不足请随时指出。
　　产品运营推进需求按照时间顺序简为：了解需求、沟通需求、确认方案、产品跟踪。
　　了解需求
　　了解需求可以分为：接收需求、需求现状、需求期望、需求涉及、需求收益。
　　关于接收需求，必须自己认同
　　接收需求方式，每个公司有每个公司的方式流程，甚至同一个公司内的不同产品运营团队也有所不同，本文就不班门弄斧，只是想说，接需求要量力而为，接属于自己的正确需求。如果不是自己职责内的需求不要去触碰（除非你对其极为有兴趣，特别想了解此部分），不是自己职责内的需求很难理解需求，还容易遭到PM的投诉，甚至最后沦为背锅着；如果需求为不合理需求（包括不能说服你自己的需求）一定不要接，因为很明显接下来要被PM狂喷，然后
　　关于需求现状的了解，判断需求真伪
　　为什么出现这个需求？
　　现在产品是什么样子的？（相信没有几个产品运营对自己负责的产品100了解，这是个坑）
　　现在情况下需求方在怎么处理？
　　需求方提这个需求到底因为什么？为了什么？
　　但是此处要求产品运营要对业务有所了解，作为一名产品运营一定要对业务有所了解，甚至说比业务更加了解业务。如果不了解业务会导致你不能快速理解需求，不能快速GET到业务关键点，沟通浪费时间，还会让业务质疑你的专业性。
　　关于需求期望，初期产品模型
　　其实，很多的时候需求方并不知道自己想要的是什么（或者给出的期望是不能解决他们的问题的），他们只是感觉不爽，希望可以改进。这个时候一定要谨慎，一定要了解业务，了解需求方提出这个需求究竟是为什么，然后判断需求是否和需求方所说一致。
　　如果与需求方所说不一致，那么你就需要去实地了解、使用、甚至调研，获取最真实的需求。获取真实需求后要与需求方沟通（切记沟通，否则容易遭到投诉），沟通后确定最真实需求。
　　确认需求之后，可以与需求方讨论出初期产品期望模型以及确定业务放期望排期，是初期不是最终，所以不要跟需求方把话说死。
　　关于需求涉及，关系背锅问题
　　在于业务方沟通之时，一定要全局考虑需求，尽量将需求考虑好，考虑复杂，注重需求将会涉及的部门及人员，一定要考虑完全，可以按照如下方向梳理：
　　此产品需求涉及哪些产品端变动
　　此产品需求是否涉及策略问题，需要leader同意
　　是否有其他部门也拥有同样的需求
　　是否有相关相似需求，可以同时改进
　　如果产品上线涉及哪些部门使用
　　如果产品更改是否会影响其他部门使用
　　关于需求收益，评定需求优先级
　　很多产品运营在于PM沟通产品需求的时候经常被PM问：多少人有这个需求，需求上线能给公司来到多少收益。然后需求更多的是被拍回，等待你收集好数据卷土重来，或者直接搁置放弃。
　　其实，每一个产品需求，作为一名产品运营师都应该了解清楚，不能盲目的去推进，毕竟我们要了解产品上线会有多少人受益，会有多少收益。的确有些产品功能是没有办法评估收益的，那么你要根据重要紧急度给出一个评定，根据重要紧急度与需求收益结合，你可以很好的将待实现的产品需求进行评定，分级，紧急需求先推进，重要需求勤推进，相信这样PM也没有办法驳回需求。
　　沟通需求
　　此处需求沟通主要是与PM沟通，同时也会涉及与需求方沟通
　　沟通需求阶段是这些阶段中最煎药的阶段，也是决定你的需求在PM心中的评定，所以一定要注重。
　　需求一定要了解清楚
　　一定要比产品了解业务使用情况
　　一定要对需求有初步方案（即时是一个大概也好，要知道你要做什么）
　　对产品上线后推广有预期
　　沟通中切记不要做传话筒，要自己有所了解，让PM与需求方认为你是不可或缺的，当然，你不是万能的，如果必要的情况下可以将需求方及PM放在一起沟通。
　　在PM部门之间跨部门沟通时（负责不同方向不同产品的PM），尽力将双方放在一起沟通，防止出现确认之后变更的事情出现。
　　沟通过程中一定要有会议纪要，以为这个是你们确定的凭证，各端人员都必须承认。
　　确认方案
　　确认方案应该是整个跟进过程中最爽的时候，也是撕逼比较多的时候，这个时候你不光要搞定PM搞定需求方，还要帮PM搞定RDFEDA
　　与PM确认方案，本环节是你与PM接触时间最长，相亲相爱的一个阶段，此处建议可以在沟通前自己思考一份产品初步方案，根据产品初步方案与PM共同沟通新的产品方案。
　　产品方案沟通中，这个时候你们相互需要，PM将会提供一份你较为满意的PRD（MRD），同时方案确认的过程中，PM也需要你从中沟通，确认很多产品方案的细节，这个时候你一定要在，帮产品确认好，因为这个关系到产品功能是否真的切合实际。
　　需求评审一定要跟PM说叫上你，需求方评审（业务方评审）一定要叫上你，这个时候如果需要改动一定要尽快变更，不要推延到技术评审或者交互评审。技术评审的时候也要跟PM处好关系准时参加，因为你不在研发大大们可以肆无忌惮砍需求，你需要站在需求方的角度，用你的理由保护你的需求不被砍掉。
　　评审排期了，不要放松，因为可能随时有紧急需求、老板需求插入，这个时候你一定要了解好是什么需求插入，根据紧急重要程度决定是否让步。如果有所让步一定要了解清楚为什么delay，同时需要PM帮忙一起出一份delay邮件给需求方说明。
　　产品跟踪
　　产品正常上线了，我们没事了？no，no，我们还有很重要的产品推广工作，还有产品效果跟踪，产品可能还有二期。
　　产品上线同步培训，这个是一个很难的问题，一般是系统内更新通知邮件群发通知工作群通知，邮件和系统通知最好附有操作手册，如果是大型项目，可能还需要线上线下的培训（此阶段要求你一定要了解产品，建议要到PRD）。
　　效果跟踪环节，你要在上线后创建好独立的反馈工作群，或者独有的反馈渠道，建议要单独渠道，不要与其他项目混用。此处要记得上线前跟PMDA沟通做好数据埋点，要设定反馈周期，定时关注数据，适时产出产品效果分析报告，准备项目二期。
　　本文仅为Lycom一年产品运营工作经验，不代表任何理论以及公司，如果其中存有分歧，欢迎随时沟通。