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

0 评论 12273 浏览 63 收藏 10 分钟

此处产品运营为侠义产品运营,单指产品运营师,不是产品&运营大序列。本篇文章写给刚刚入职产品运营职位,或者期望入职产品运营的人员,如有不足请随时指出。

产品运营推进需求按照时间顺序简为:了解需求、沟通需求、确认方案、产品跟踪。

了解需求

了解需求可以分为:接收需求、需求现状、需求期望、需求涉及、需求收益。

关于接收需求,必须自己认同

接收需求方式,每个公司有每个公司的方式流程,甚至同一个公司内的不同产品运营团队也有所不同,本文就不班门弄斧,只是想说,接需求要量力而为,接属于自己的正确需求。如果不是自己职责内的需求不要去触碰(除非你对其极为有兴趣,特别想了解此部分),不是自己职责内的需求很难理解需求,还容易遭到PM的投诉,甚至最后沦为背锅着;如果需求为不合理需求(包括不能说服你自己的需求)一定不要接,因为很明显接下来要被PM狂喷,然后。。。

关于需求现状的了解,判断需求真伪

  • 为什么出现这个需求?
  • 现在产品是什么样子的?(相信没有几个产品运营对自己负责的产品100%了解,这是个坑)
  • 现在情况下需求方在怎么处理?
  • 需求方提这个需求到底因为什么?为了什么?

但是此处要求产品运营要对业务有所了解,作为一名产品运营一定要对业务有所了解,甚至说比业务更加了解业务。如果不了解业务会导致你不能快速理解需求,不能快速GET到业务关键点,沟通浪费时间,还会让业务质疑你的专业性。

关于需求期望,初期产品模型

其实,很多的时候需求方并不知道自己想要的是什么(或者给出的期望是不能解决他们的问题的),他们只是感觉不爽,希望可以改进。这个时候一定要谨慎,一定要了解业务,了解需求方提出这个需求究竟是为什么,然后判断需求是否和需求方所说一致。

如果与需求方所说不一致,那么你就需要去实地了解、使用、甚至调研,获取最真实的需求。获取真实需求后要与需求方沟通(切记沟通,否则容易遭到投诉),沟通后确定最真实需求。

确认需求之后,可以与需求方讨论出初期产品期望模型以及确定业务放期望排期,是初期不是最终,所以不要跟需求方把话说死。

关于需求涉及,关系背锅问题

在于业务方沟通之时,一定要全局考虑需求,尽量将需求考虑好,考虑复杂,注重需求将会涉及的部门及人员,一定要考虑完全,可以按照如下方向梳理:

  1. 此产品需求涉及哪些产品端变动
  2. 此产品需求是否涉及策略问题,需要leader同意
  3. 是否有其他部门也拥有同样的需求
  4. 是否有相关相似需求,可以同时改进
  5. 如果产品上线涉及哪些部门使用
  6. 如果产品更改是否会影响其他部门使用

关于需求收益,评定需求优先级

很多产品运营在于PM沟通产品需求的时候经常被PM问:多少人有这个需求,需求上线能给公司来到多少收益。然后需求更多的是被拍回,等待你收集好数据卷土重来,或者直接搁置放弃。

其实,每一个产品需求,作为一名产品运营师都应该了解清楚,不能盲目的去推进,毕竟我们要了解产品上线会有多少人受益,会有多少收益。的确有些产品功能是没有办法评估收益的,那么你要根据重要紧急度给出一个评定,根据重要紧急度与需求收益结合,你可以很好的将待实现的产品需求进行评定,分级,紧急需求先推进,重要需求勤推进,相信这样PM也没有办法驳回需求。

沟通需求

此处需求沟通主要是与PM沟通,同时也会涉及与需求方沟通

沟通需求阶段是这些阶段中最煎药的阶段,也是决定你的需求在PM心中的评定,所以一定要注重。

  1. 需求一定要了解清楚
  2. 一定要比产品了解业务使用情况
  3. 一定要对需求有初步方案(即时是一个大概也好,要知道你要做什么)
  4. 对产品上线后推广有预期

沟通中切记不要做传话筒,要自己有所了解,让PM与需求方认为你是不可或缺的,当然,你不是万能的,如果必要的情况下可以将需求方及PM放在一起沟通。

在PM部门之间跨部门沟通时(负责不同方向不同产品的PM),尽力将双方放在一起沟通,防止出现确认之后变更的事情出现。

沟通过程中一定要有会议纪要,以为这个是你们确定的凭证,各端人员都必须承认。

确认方案

确认方案应该是整个跟进过程中最爽的时候,也是撕逼比较多的时候,这个时候你不光要搞定PM搞定需求方,还要帮PM搞定RD+FE+DA

与PM确认方案,本环节是你与PM接触时间最长,相亲相爱的一个阶段,此处建议可以在沟通前自己思考一份产品初步方案,根据产品初步方案与PM共同沟通新的产品方案。

产品方案沟通中,这个时候你们相互需要,PM将会提供一份你较为满意的PRD(MRD),同时方案确认的过程中,PM也需要你从中沟通,确认很多产品方案的细节,这个时候你一定要在,帮产品确认好,因为这个关系到产品功能是否真的切合实际。

需求评审一定要跟PM说叫上你,需求方评审(业务方评审)一定要叫上你,这个时候如果需要改动一定要尽快变更,不要推延到技术评审或者交互评审。技术评审的时候也要跟PM处好关系准时参加,因为你不在研发大大们可以“肆无忌惮”砍需求,你需要站在需求方的角度,用你的理由保护你的需求不被砍掉。

评审排期了,不要放松,因为可能随时有紧急需求、老板需求插入,这个时候你一定要了解好是什么需求插入,根据紧急重要程度决定是否让步。如果有所让步一定要了解清楚为什么delay,同时需要PM帮忙一起出一份delay邮件给需求方说明。

产品跟踪

产品正常上线了,我们没事了?no,no,我们还有很重要的产品推广工作,还有产品效果跟踪,产品可能还有二期。

产品上线同步培训,这个是一个很难的问题,一般是系统内更新通知+邮件群发通知+工作群通知,邮件和系统通知最好附有操作手册,如果是大型项目,可能还需要线上线下的培训(此阶段要求你一定要了解产品,建议要到PRD)。

效果跟踪环节,你要在上线后创建好独立的反馈工作群,或者独有的反馈渠道,建议要单独渠道,不要与其他项目混用。此处要记得上线前跟PM+DA沟通做好数据埋点,要设定反馈周期,定时关注数据,适时产出产品效果分析报告,准备项目二期。

本文仅为Lycom一年产品运营工作经验,不代表任何理论以及公司,如果其中存有分歧,欢迎随时沟通。

 

作者:Lycom(微信号公众号-追梦日记),百度外卖产品运营师。

本文由 @Lycom 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!