聊聊敏捷的产品经理

这是鼎叔的第九十三篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

这篇聊聊我对产品经理这个岗位的看法，以及产品经理如何拥抱敏捷，产品和技术如何形成高效协作的团队。

部分内容参考了《敏捷产品-不确定性的思维革命》一书。

产品经理的专业修炼

我一直认为，产品经理的岗位很特殊，好的产品经理是一个创业者，或者微型的CEO。这个岗位在大学里很难匹配到合适的专业，因为学校无法提供给产品经理刻意练习的环境，不像软件工程师有很多刻意练习的项目 参考聊聊刻意练习-天才并不存在。更不用说，产品经理需要修炼的跨专业内容很多。

产品经理的专业培养也缺乏定论，博大但不规范，没有大学的学科储备。行业充斥着一战成名的传说，但是否战战必胜？

在互联网业务过去突飞猛进的二十年，产品经理的校园招聘岗位，成为了一个大批量群面筛选的岗位。大公司招入的产品经理往往是帅哥美女，因为候选人的背景、逻辑和表达都很不错，最后脱颖而出的往往是颜值高的…（开个玩笑哈）。

产品过程有很多具体的选择取舍，由于蝴蝶效应，细微的选择会导致最终上市的成果产生极大的差异。互联网业务的风口导致了资本投入盲目的快，如果一定时间没有成功就撤换团队。

但这并不符合敏捷组织的观念，快速失败指的是“项目”而不是“团队”。

这种撤换还会导致团队不能安心试错和成长，造成公司培养资源的浪费，也导致盲目的年轻化（年龄歧视）。

在某个大型集团的年轻化变革中，我能感受到负面的变化是：随着资深员工的流失，有深度的思考碰撞在减少。被快速提拔起来的年轻人，往往没有经历过足够多的硬仗，且人品素质也没有经过充分的检验。

产品的敏捷原则

和敏捷测试的原则一样，敏捷原则同样适用于产品设计，最重要的就是：动态规划，小步快跑；拥有长期愿景，但聚焦眼前交付。具体展开：

健康频繁的个体交互，最重要的是尊重每个人的价值，数据和行为透明，诚实交流，彼此信任，投身于共同目标。

有建设性的冲突对团队有益，鼓励过程改进的吐槽和有益于思考碰撞的异议。

建设轻量级产品文档，尽可能和代码保持一致，包括：原型图，用户旅程，用例场景思维导图等。

客户协作胜于合同谈判，客户分为外部和内部，对内就是和研发经理的上下游矛盾，做多和做少的矛盾。

拥抱变化，因为客户永远要变化。寻求变化和计划的动态平衡，平衡就是产品经理的艺术所在。所以，产品经理是一个艺术大于科学的岗位，需要掌握正反辩证态度。

敏捷产品设计和敏捷研发是一个融合闭环，最终目标是建立能自我管理的敏捷团队。

敏捷不承诺找到产品的成功战略方向，因为产品失败是大概率事件，敏捷更强调团队建立长期的执行纪律，从失败中学习，把“潜规则”变成“明规则”。

相反，伪敏捷的表现就是产品过早细化，过早具象。产品应该是需求的组织者，需求要简约可协商，避免文档浪费，落实真人交流。

和技术侧一样，敏捷产品的可视化有利于用研和高层更早介入，早提修改意见。

用户思维

互联网时代的用户体验评价更加重要，因为用户迁移成本几乎为零，产品的死亡率极高。

产品经理要有用户思维，应该怎么做？

大的方面，是有差异的产品定位（聊聊定位-如何占领用户心智）（战略），小的方面，有制度来激励和用户互动的员工，建立容忍失败和从产品失败中学习的文化，有各种打动用户的设计细节，再把好细节的方法论变成组织规范。

产品经理要有产品价值观，价值观是做什么不做什么的过滤器。产品经理还要有专业激情，尽量争取到团队共识，而不仅仅是上传下达的角色。

所有需求的精益求精都在成本约束下才有意义，新需求务必要增加用户的价值才应该做，这个价值也包括这个时代流行的情绪价值。‍‍‍‍‍

需求可以改变，但带来的用户价值要大于相关产研投入，大于做其他需求的机会成本。

穷尽路径思考，是通往精益求精的唯一之路，从各种思考路径中再聚焦成本可控的最佳路径。

拿产品需求直接进行开发，没有验证容易产生浪费，和开发给测试验证是一个道理。用户研究和可用性测试就是给需求做验证的方法，但它们首先是研究痛点，而不是给出需求。这个验证效益更高，能够减少浪费但不是创造价值。

敏捷产品的验证鼓励全员参与。定性比定量好 ，被训练过的产品经理是最好的调研者，他更熟悉业务逻辑。最好的验证是在用户使用产品的现场。

我们之前介绍的用户画像，其目的是提醒产品经理不要把自己的需求当做真实用户的需求。

我们可以从不同用户群体调研中绘制关系图，一张图是看不同用户群大小和潜在价值，另一张图是看用户问题发生的概率和痛点价值。痛点大小应该和解决方案匹配。

​

打造学习型的产品研发团队

培养多样化的学习型组织很重要，它对产品决策会带来更全面的真知灼见。我比较喜欢产品工作坊形式，几个月一次，这种深度研讨汇谈可以提高参与感和可视化。

产品人员自己的思辨非常关键，思辨要慢，行动要快。对研发团队能说清楚产品的功能目标和情感目标。要想说服工程师接受，需要提前准备量度和调研，以及解释隐喻手法。

注意：用户也在不断升级，之前习以为常的情感对策可能效果很差了。这是更需要引入跨职能团队来一起艺术创造。不过有时解决方案的难度超过团队能力太多，必然失败。

产品设计的方法论是对产品经理的高级要求，它重于个人的具体产品经验。方法论能对抗世界的随机性、概率性。产品结果虽然简单，但过程复杂。

产品过程管理有一个著名的五层模型，从下到上分别为：策略层，解决方案层，信息结构层，框架层和视觉层。不同岗位角色之所以发生协作问题，是因为在不同的层次上思考产品实现，缺失了重要的底层意图视角。

敏捷产品的创新

敏捷产品同样遵循三要素：优秀的交付品质，优秀的交付效率，优秀的人。优秀的人是对抗产品被友商抄袭的核创新武器。

产品的创新，颠覆性创新可遇不可求，更多我们见到的是微创新（除了功能复制外）。两者并非泾渭分明，很多时候大家津津乐道的颠覆性创新是在多个已有创新的肩膀上往前走了一步的结果。

微创新让产品不会大起大落，但是符合敏捷价值观：不可能一次就做对，根据反馈来渐进式改进。

产品经常被外部诟病抄袭，那借鉴和抄袭的区别是什么？

核心差别就是能否理解别人的解决手段是否适合自己团队，如何解决了自己用户的痛点，还有没有融合改进的空间。

这背后需要刻意主动学习，寻找灵感，耗费大量体力和精力。创新灵感可以被激发，但需要先休息，加班无助于创新。

创新失败的原因，往往是过于乐观，或者不得不乐观，团队成员会高估自己的掌控能力，低估项目实现的难度，对判断过于自信。另外一个原因是没有准备验证时间。只有尽早发布才能缓解这些风险。

越是不确定的市场，越要拥抱敏捷的产品观。

产品的数据运营

产品运营的数据驱动非常重要，但很多产品对指标值理解狭隘，比如留存用户的指标意义不等价于流失用户的指标。

很多情况下，低成本的统计抽样就能知道结论，不一定要花费昂贵代价的全量数据。

验证产品的指标如果没有指名方向，是不会有效果的。敏捷并不鼓励大量试错，而是聚焦降低试错成本。

MVP就是这类实践，其目标是低成本的快速验证和学习，只看是否满足基本功能，验证基本盘用户，不挂钩KPI。对于显著创新的MVP产品，客户能够容忍一些缺陷，只要满足了他一个关键需求。

做运营指标分析，可以深入参考系统思考理论聊聊学习型组织的五项修炼（上）。各种要素组件对结果产生了正向、逆向或延迟的效果，需要深入观察，相关性不等于因果，利用小系统的数据降低系统复杂度。通常，定性的指标比定量指标更有益处，成本更低，我们可以利用金字塔原理让拆解后的指标能穷尽和正交，逻辑有效。

数据工程师和产品通常不在一个部门，对彼目标互不理解，给出结果的时效也跟不上，这时需要一个独立负责人明确交付纪律。未来对于产品经理的数学能力也会有更高预期。

优秀的产品团队尽量多用户手段，反对滥用运营手段，这样会浪费可以纠错的机会。

互联网运营活动的本质和传统行业一样，不能依赖昙花一现的新奇玩法，这些所谓的小点子会带来低效的工作模式，让员工没有足够时间锤炼团队方法论。

补充一句，运营推广的态度应该是左右脑平衡的，左脑理性驱动，右脑感性驱动，光靠创造噱头不利于记住品牌本身。真正超出对手品质才能产生社会化营销。

产品自组织团队

敏捷组织希望在企业建立独立的细胞组织。细胞组织中的项目经理有用人权，有利于多样性培养，他需要被授权激励，按团队交付价值来区分绩效，自己承诺交付目标。细胞外部的管理者可以设立规则，但不强制干预。

自组织团队的人员相对成熟，而传统职能部门有利于以老带新的培养氛围。

一个产品自组织团队也同样要有共同的愿景认同，氛围是包容开放的。团队通过项目回顾会，聚焦要优先解决的问题（不超过三个）。

自组织团队通过迭代建立情感信任非常关键。不信任他人，通常是因为过低估计他人和自己公司，过高估计自己和对手公司。鼓励团队成员提出建议，但尊重对方专业性。异议是多样性团队的动力，把“多样化思维”和“统一性决策”融合在一起。

结语：

AI2.0时代，产品经理更容易在小而美的公司取得胜利，但是自身素养要求也会大幅提升，普通的产品经理技能，技术工程师能借助大模型就搞定了。