产品经理成为原型人的七大迹象，看看你中招了没！

发现很多初创互联网公司都是Feature Factory（功能工厂），很多产品经理都是Axure People（原型人），需求方任意提“需求”，产品经理负责“需求”的实现，胡乱堆砌功能。

最典型的特点是“上线即完成”的心态（PS：一个版本上线了，交由需求方确定后，就什么都不管了。紧接着开始新的版本开发）。

就像只是坐在工厂里，做出新功能，在流水线上传递下去。

John列出了7种“功能工厂”团队的迹象（或者说产品经理作为原型人的迹象），读友可以看看，你中枪了么？

一、没有业务规划会议

有些产品经理从来没有参与业务OKR规划和拆分会议，这其实是非常有隐患的。

因为产品需求的来源大部分来源于业务需求，而业务需求绝不是业务同事拍脑袋产生的，而是基于整体的业务规划。

产品经理需要非常清晰接下来业务OKR，基于业务的方向制定有效的产品迭代计划。

能达成OKR，整个团队一片祥和，一旦偏差较大，团队凝聚力指数下降。

所以制定版本迭代计划绝不是产品经理拍脑袋的，每一步都必须做好追溯。

John在历史文章也写过《致产品经理，去了解下业务吧！》

再絮叨下OKR制定的步骤：（建议定季度OKR，做月度拆分）

• 季度最后一个月的月初（比如6月初），需要和业务负责人沟通下一个季度的业务OKR，在月中进行业务OKR述职；
• 会议中敲定下一季度OKR，并在会后做好邮件确定；
• 产品组依托于业务OKR做产品版本计划形成产品路线图并内部宣讲确定；
• 并在月底之前同参与确认存档。

在公众号私信回复：OKR。可下载John给团队培训OKR的PPT。

二、以“上线交付”来衡量版本完成

产品版本上线是一个非常重要的节点，标志着该版本在内部是可用状态。

是否被用户接收？能否达到预期效果？尤其对于主版本号①调整是非常重要的问题。需要注意两个方面：

一方面是在普测时，邀请核心用户来测试体验（尤其是B端产品，一定要让客户试用），如果有条件的话，做下可用性测试②，遇到问题点可以作为接下来优化的版本；

另一方面在上线后前三天做好数据整理和分析，看看是否有异常状况，持续在种子群/客户群做好吐槽点收集。

持续1周反馈看效果，看后续优化动作。

C端产品做好用户“可用”后，后续通过优化做到“易用”和使其产生“传播点”。

B端产品做好客户“可用”后，后续通过优化达到真正为B端“降低操作难度”和“提高工作效率”。

这才是产品经理需要持续去做的，也是产品经理通过项目能快速成长的。

（PS：如果是外包呢？如果外包交付后，建议可以后续跟进下效果，并提供下你认为比较好的运营策略和迭代方案）

①版本号划分，John给了一张图说明：

②可用性测试。公众号私信回复“可用性测试”，即可领取PDF案例文档。

三、团队未做过项目复盘

项目复盘的目的是产品上线一段时间后或者某个活动结束后，项目部都需要有针对性的对项目复盘。

看看项目执行过程中的得分点和失分点，来实现向过去学习，达到能力的提升。

复盘分为两个方向——针对产品迭代过程中团队协作的复盘、针对产品上线后产生的效果复盘。

再来把这两个点赘述下：

• 团队协作——在协作过程中遇到了哪些问题？哪些可以形成沟通流程并固定下来……（长时间用下来就形成了产品开发流程方案）；
• 线上效果——通过数据看线上的效果怎么样？用户对产品的使用怎么样？其中反馈在模版的活跃度、使用人数和对核心流程的影响。

其他项目复盘的内容，John在历史文章写过《项目复盘，看这篇就够了！》。相信John，每一次复盘，你会得到很多“反馈”，也会收获很多。

四、只注意细节，未深挖底层

不知道大家有没有遇到这种情况——“哼哧哼哧的把功能清单、流程和原型梳理出来，反馈给业务方，发现业务流程并非如此？”

这个问题80%在于产品经理，主要是这几个原因：

业务确认环节：深挖业务方提出的需求

    ——业务方实际的目标是什么？（通过目标看看方案是否切实可行，证明不是拍脑袋出来的。如果通过，接下来再确认：）

    ——业务方实际的流程是怎样的？（按照实际操作场景一一说明，能够形成实际流程的闭环。看看是否有简化流程的可能。如果通过，再接下来确认：）

    ——竞品是如何做的？（看看竞品的解决方案是怎样的？效果如何？是否有优化的空间？）

这儿John想再次重申的一点是：抄袭竞品不丢人，上线没有效果才丢人。所以多去拆解下竞品。

请看历史文章：《“抄袭”产品很重要（内附案例）》。

业务反馈环节：提出初步产品解决方案

    ——通过业务流程图模拟路径，和业务方确认业务流程图。（二次澄清非常有必要。）

    ——通过竞品解决方案梳理初步的用户操作路径并指出和其他模块关联的点。

至此，起码很清晰的了解业务方为什么这么做？背后的原因有哪些？

产品经理应该如何有效的做解决方案。有了业务的确认和自己的专业理解。起码产品的方向不会有太多的偏差。

John之前和团队小伙伴聊过：执行永远只占49.765%（不到一半），所以前期的梳理和思考很重要。建议多去挖掘下核心。

五、极少正视“失败”的结果

主动背锅是极需要勇气的。

当产品多方位尝试始终未产生明显效果时，还在不停的叠加功能，而未回头看原因是什么？

在John团队中一直遵循这几个原则：

当投入50%的开发资源来做这个事情时，一定会去想好后手，万一没有产生效果，应该如何做补救方案，产品负责人和运营负责人同时背锅。

C端产品当使用该模块用户少，且不牵涉核心业务，该砍掉就砍掉；

B端产品只要有1个人用，就需要想好迭代方案并优化。

当投入少于30%的开发资源来做这个事情时，产品经理应该对这个事情付全部责任。

虽不及项目流产这么重大的失败，但是取决于效果反馈，产品经理背锅不仅仅是流程逻辑等产品工作流没清晰，更多的是知道做哪些模块更有意义。

正视“失败”的产品产生的数据，防止更大的失败。

再一个学会给产品做聚焦和减法——短时间内专注让重点业务长板更长。当重点业务增长后，再围绕重点业务建立壁垒。

六、执着于排优先级

我们对优先级其实有一个误区——优先级应该决定当前做最重要的事情，而不是用来安排可以做的事情。

优先级也应该是实时需要调整的。

比如在源需求池中，已经规划了部分优先级的功能清单，产品经理去捞需求做版本计划时，应该重点根据业务方制定的业务需求来重新整理产品规划侧需求和优化需求。

紧急重要程度只是针对于当前阶段需求排期来制定的。

尽管业务同事做了紧急重要程度，但是后续的二次确认和澄清是非常有必要的。

同样再说一个点：除了胡乱的提需求外，其实需求是没有真伪的。

只有当前阶段是否需要做和紧急程度。所以建议产品经理还是制定源需求池。

七、一次性迭代计划

做产品模块切记别制定一次性方案。

至少要做两次迭代计划，便于开发提前做技术预研和给后续迭代方案留坑。

否则等业务发展到一定阶段，就需要做重构和换技术债的工作了。

再一个想说的是防止做重复性工作，相同属性的模块进行有效整合，统一管理。

比如拼团和免费领统一收纳至营销管理中。

以上7个方面只是John觉得和产品经理关系很大的点，以上都是需要产品经理去驱动的。

尤其是互联网团队，产品经理应该扮演最重要的角色，摆正自己的位置，做起工作会得心应手。

#作者介绍#

John,公众号：产品狗聚集地（ID：Johntalking）,栀枝翰林院专栏作家，专注互联网思维 ；专注互联网产品 ；为产品经理授业解惑

本文系作者授权发布，未经允许，不得转载。

题图来自网络，如对文章、图片、字体等版权有疑问，请联系类类小助手（微信：leileixzs)