产品经理成为原型人的七大迹象.docVIP

产品经理成为原型人的七大迹象 / 发现很多初创互联网公司都是Feature Factory（功能工厂），很多产品经理都是Axure People（原型人），需求方任意提“需求”，产品经理负责“需求”的实现，胡乱堆砌功能。 最典型的特点是“上线即完成”的心态（PS：一个版本上线了，交由需求方确定后，就什么都不管了，紧接着开始新的版本开发）。就像只是坐在工厂里，做出新功能，在流水线上传递下去。 John列出了7种“功能工厂”团队的迹象（或者说产品经理作为原型人的迹象），读友可以看看，你中枪了么？ 一、没有业务规划会议 有些产品经理从来没有参与业务OKR规划和拆分会议，这其实是非常有隐患的。 因为产品需求的来源大部分来源于业务需求，而业务需求绝不是业务同事拍脑袋产生的，而是基于整体的业务规划。产品经理需要非常清晰接下来业务OKR，基于业务的方向制定有效的产品迭代计划。 能达成OKR，整个团队一片祥和，一旦偏差较大，团队凝聚力指数下降。所以制定版本迭代计划绝不是产品经理拍脑袋的，每一步都必须做好追溯。 再絮叨下OKR制定的步骤（建议定季度OKR，做月度拆分）： 季度最后一个月的月初（比如6月初），需要和业务负责人沟通下一个季度的业务OKR，在月中进行业务OKR述职； 会议中敲定下一季度OKR，并在会后做好邮件确定； 产品组依托于业务OKR做产品版本计划形成产品路线图并内部宣讲确定； 并在月底之前同参与确认存档。 二、以“上线交付”来衡量版本完成 产品版本上线是一个非常重要的节点，标志着该版本在内部是可用状态，是否被用户接收？能否达到预期效果？尤其对于主版本号①调整是非常重要的问题。 需要注意两个方面： 一方面是在普测时，邀请核心用户来测试体验（尤其是B端产品，一定要让客户试用），如果有条件的话，做下可用性测试②，遇到问题点可以作为接下来优化的版本； 另一方面在上线后前三天做好数据整理和分析，看看是否有异常状况，持续在种子群/客户群做好吐槽点收集。持续1周反馈看效果，看后续优化动作。 C端产品做好用户“可用”后，后续通过优化做到“易用”和使其产生“传播点”。B端产品做好客户“可用”后，后续通过优化达到真正为B端“降低操作难度”和“提高工作效率”。 这才是产品经理需要持续去做的，也是产品经理通过项目能快速成长的（PS：如果是外包呢？如果外包交付后，建议可以后续跟进下效果，并提供下你认为比较好的运营策略和迭代方案）。 ①版本号划分，John给了一张图说明： 三、团队未做过项目复盘 项目复盘的目的是产品上线一段时间后或者某个活动结束后，项目部都需要有针对性的对项目复盘。看看项目执行过程中的得分点和失分点，来实现向过去学习，达到能力的提升。 复盘分为两个方向，针对产品迭代过程中团队协作的复盘、针对产品上线后产生的效果复盘。 再来把这两个点赘述下： 团队协作：在协作过程中遇到了哪些问题？哪些可以形成沟通流程并固定下来……（长时间用下来就形成了产品开发流程方案）； 线上效果：通过数据看线上的效果怎么样？用户对产品的使用怎么样？其中反馈在模版的活跃度、使用人数和对核心流程的影响。 四、只注意细节，未深挖底层 不知道大家有没有遇到这种情况——“哼哧哼哧的把功能清单、流程和原型梳理出来，反馈给业务方，发现业务流程并非如此？” 这个问题80%在于产品经理，主要是这几个原因： 1. 业务确认环节：深挖业务方提出的需求 业务方实际的目标是什么？（通过目标看看方案是否切实可行，证明不是拍脑袋出来的） 业务方实际的流程是怎样的？（按照实际操作场景一一说明，能够形成实际流程的闭环，看看是否有简化流程的可能） 竞品是如何做的？（看看竞品的解决方案是怎样的？效果如何？是否有优化的空间？） 这儿John想再次重申的一点是：抄袭竞品不丢人，上线没有效果才丢人，所以多去拆解下竞品。 2. 业务反馈环节：提出初步产品解决方案 通过业务流程图模拟路径，和业务方确认业务流程图（二次澄清非常有必要）；通过竞品解决方案梳理初步的用户操作路径并指出和其他模块关联的点。 至此，起码很清晰的了解业务方为什么这么做？背后的原因有哪些？产品经理应该如何有效的做解决方案。有了业务的确认和自己的专业理解，起码产品的方向不会有太多的偏差。 John之前和团队小伙伴聊过：执行永远只占49.765%（不到一半），所以前期的梳理和思考很重要，建议多去挖掘下核心。 五、极少正视“失败”的结果 主动背锅是极需要勇气的，当产品多方位尝试始终未产生明显效果时，还在不停的叠加功能，而未回头看原因是什么？ 在John团队中一直遵循这几个原则： 当投入50%的开发资源来做这个事情时，一定会去想好后手，万一没有产生效果，应该如何做补救方案，产品负责人和运营负责人同时背锅。C端产品当使用该模块用户少，且不牵涉核心业务，该砍掉