以“工厂”视角来浅谈产品经理的工作推进
如果系统性地梳理产品经理的工作,我们可以得到怎样的一个流程?这篇文章里,作者就以产品“工厂”为比喻,谈了谈产品经理的工作推进,一起来看一下吧。
如果把产品经理的工作比作一个产品工厂的话,本篇内容就是想粗浅的讲讲这个“工厂”的流水线设计,希望能用这粗浅的假设来抛砖引玉。
一、需求来源
作为产品工厂,需求是起点,有了需求“工厂”才有开动的理由。产品需求来源可以分为两个大类:承接的需求和挖掘的需求;划分方式很多,这里仅以来源方区分。
1. 承接的需求
这一部分算是被动接单,会分成单个功能和专项;其中单个功能比较独立且单一,主要包括一些体验反馈提炼出的需求,例如内部打卡和用户反馈所产出的需求。
专项则不同,通过单个独立功能无法实现某个目标,则需要通过专项产出或优化一系列功能来实现目标;这种需求更多由上而下来源于整体规划调整和目标导向。
2. 挖掘的需求
顾名思义,这类需求是完全内驱,也都是基于要实现某类目标挖掘出的需求,关键在目标拆解方式。
以实现订单增长目标的需求挖掘举例,可以按订单来源渠道和用户下单路径来挖掘需求;针对订单来源渠道,可以根据不同渠道转化率的差异,来设定不同的提升方式,例如,高流量低转化渠道,主要提升转化率,相反,则提升高转化渠道的流量;针对用户下单路径的漏斗分析或场景分析,同样能挖掘出实现目标的需求,这里不再细分列举。
二、需求决策
作为工厂,在一定条件下,产能是固定的;在这种限制下,不是所有需求都能立项,也不是所有需求都能立马进项。这里就需要说到需求决策:立项决策、排期决策。
1. 立项决策
需求是否成立,是否能被纳入需求池,都需要决策;决策的维度和方式有很多,这里简单列举一些:
- 需求提炼:接收到的或者挖掘出的需求,是方式需求,还是目的需求;如果能提炼出目的需求,那就一定要找到基于目前条件能实现的最优方式需求。
- 用户优先:需求与目前产品的用户画像是否相符,当然也有那种为了拓展用户类型而专门为其他类型用户设置的需求,来获取这批用户。
- 产品阶段:一款产品在不同阶段能附加的能力和使命是不一样的,有时候,需求本身没有问题,但是他可能不适合放到现阶段这个产品里。
- 对齐战略:这个好理解,公司战略定位圈选了哪些能做,哪些不能做。
2. 排期决策
当需求完成立项之后,就需要根据排期来进项,排期决策用于梳理需求池需求优先级;决策依据有很多方法论,比如用kano模型,或者简单粗暴的使用重要+紧急公式,也有按ROI来决策的。
三、需求输出
对于“工厂”流水线来说,也可以是先有需求输出,再做需求决策;针对需求输出每位产品都有自己的心得,也都有自己的见解,这里不多说,笔者认为的两个重点是:用户优先&可拓展性。
四、需求推进
在需求进项之后,最重要的事情就是保证产品能够按时保质上线;虽然很多公司有专职PMO来做项目管理推进,但是作为PM——产品的第一责任人,还是很有必要全程参与需求推进。在此过程中有以下几点可以保证项目顺利推进。
1. 把控关键节点
人的精力是有限的,对于一个项目能够把控其关键节点,基本上就能很好的掌控项目;项目的关键节点的定义需要结合项目而定,以一个普通后端项目举例,关键节点,可以包括以下几个:
- 需求评审,这个阶段重点确保研发和测试能够完整理解需求。
- 接口文档输出,这个阶段在开发进项初期,这算是开发依据对需求的理解输出的接口方案,产品需要自己验收,其次可以让前端(接口使用方)验收,确保协议一致没有遗漏,接口文档确认无误,最终结果会有保证。
- 测试用例评审,这个阶段在提测前,是测试基于自己理解把测试case全部列出,供相关方来确认。
- 上线验收,只要前面几个关键节点没有问题,基本上验收能够顺利通过。
2. 及时沟通
这个不只是说预见问题及时沟通,大的项目可能需要定期沟通知悉进度;这个好理解不多说。
3. 管控预期
预期有几个方面,包括:进度预期、风险预期、收益预期等,产品预先对项目的进度安排,风险预估,项目收益有一个清楚了解,并且在项目推进过程中让项目成员对于各类情况的心理预期一致,减少消极情绪产生,让项目推进更容易。
本期内容就到这了,对于产品“工厂”的流水线粗浅想法,纯属抛砖引玉~
作者:知晓,公众号:未知未晓
本文由 @知晓 原创发布于人人都是产品经理。未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
- 目前还没评论,等你发挥!