产品经理必备思维方式——工程思维

本月有一个印象深刻的对话，刚好也学习到了一种“新思维”是用于工作中避免该对话中出现的问题；因此记录并复盘，刻意练习。

对话：

我：这个功能在后台能查看到吗？

同事：可以的，是在后台管理的xxx里面。

我：但是我看到这些反馈的问题没有人处理呀？或者说现在是谁负责这块呢？

同事：我也不是很清楚这个功能现在是谁用，还有没有人用。

基于这段对话，问题的关键在于我们团队付出了时间和经理设计一款功能，并没有产生价值。似乎有一种“为了做而做”的感觉。要解决这个问题，产品经理该有点“工程思维”。

本月记录对“工程思维”的认识(why/how)和运用(what)（遵循“黄金圈法则”），但是由于还在不断学习中，因此还未完全吃透。在此推荐乔梁先生书籍《持续交付2.0》，比起产出需求，更重要是明白需求对业务的价值是什么。

图1：《持续交付2.0 业务引领的DevOps精要》 乔梁/著

一、工程思维之“why”

“why”部分解决两个问题：

1. 为什么要有工程思维；
2. 什么是工程思维。

1. 为什么要有工程思维？

互联网产品，追求质量和速度的平衡是很难的，甚至在我看来，质量和速度根本不存在平衡，仿佛”慢工出细活“这种工匠精神是对平衡质量和速度的挑战。

虽然不同的产品阶段对产品质量有不同的要求和标准，至少在同一产品阶段，质量的标准几乎是稳定的。因此在满足几乎稳定的质量前提下，追求快速交付产品价值意味着效率。在互联网行业，效率代表未来，代表金钱。

快速交付产品价值必然是需要成本的，例如产品开发成本、测试成本、金钱成本，如何降低迭代中的固定成本、提升产品迭代效率，就是工程思维中体现的了。工程思维解决的是“交付”、“价值”和“效率”的问题。相较起“科学思维”的无限期探索和发现，“工程思维”就是要脚踏实地。

脚踏实地，才能更好地仰望星空呀！

2. 什么是工程思维？

工程思维有两大特点：

1. “把事情做成”，也就是要交付“可靠、可用的成果”；
2. 要有“计划性”，在具体的时间周期内交付成果。

像上述本月对话，就是没有交付可靠可用的成果，原因在于没有明确什么样的成果才是可靠可用的。如何明确，围绕用户做起。

对于初级产品经理来说，前期准备工作是很有必要的，因为我们不像有五年十年工作经历的PM可以把产品原则、用户心智吃的透透的，方案上来就有，因而前期对于用户场景、需求分析、产品目标拆解等工作就尤为关键。

这也是我从入职到现在，一直在每个需求中都会做的事。

但是也不要理想化，想着自己把前期工作准备好了，就能交付可靠可用的成果了，因为工程思维并不是按照每一步过程走完，就能够得到最终想要的结果。毕竟产品经理所处只是”软件工程“的其中一环，工程失败也有多方的原因。

对于第二个特点，或许现在每个产品迭代版本，都可看做是一个”具体的时间周期“，但是这里面问题的关键在于如何做到。那么就是回归到第一个特点”交付可靠可用的成果“。所有成果是以“解决问题”为出发点，如何让成果变得明确，重要前提是“能够正确定义问题，并达成共识”。

图2

“达成共识”针对不同的沟通对象有不同的方法。当沟通对象是业务方时，达成共识就是要明确现实背景和需求背景。现实背景是当前现状是什么，现状带来什么问题；需求背景是哪些问题是需要紧急被解决的，解决的标准（目标）是什么，而不是业务方上来就和产品经理谈方案，这样只会变成“为了做而做”（在和业务方沟通时推荐使用5why分析法）。

因此在了解背景后，双方就问题和目标达成共识，这时产品经理或许能够提供MVP的方案来更好解决业务方的问题。

当沟通对象是研发人员时，达成共识就是不断将他人话转述成自己的理解，当自己理解和他人理解是相同时，才能达成共识。

有个例子是我就一个问题和开发咨询，但是我的这位开发总喜欢和产品讲“技术”，但是自知技术功底不深厚但又需要和开发理解达到一个层面，所以可以将开发的话转为自己的理解——

“开发大佬，你看我这样理解对不对啊，你说的这个问题是xxxx，影响到了xxxx业务，所以我觉得可以这样解决blablabla”

将自己不懂的技术知识用自己懂的业务知识转化表达，再去询问对方自己理解是否正确，这样就能达成共识，进行接下来的沟通了。

二、工程思维之“how”

“how”部分解决两个问题：

1. 如何创造价值；
2. 如何“共创”与“精炼”。

1. 如何创造价值？

上述提到工程思维的两大特点，目的都是为了在保证质量的前提下，快速交付产品价值。如何培养工程思维的核心点就落到了如何创造价值上。

乔梁先生在《持续交付2.0》书中讲述了如何创造价值，即不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案（MVP）。通过快速实现解决方案并收集反馈和数据，以验证业务问题是否得以解决（或是否达成目标）。

产品设计过程会分为“0到1”和“1到N”。对于“0到1”，需要先快速迭代，确认需求有用户；对于“1到N”，需要针对具体需求具体分析。因此如何创造价值，需要同时满足以下3个假设—-

• 假设一：有用户；
• 假设二：用户有需求；
• 假设三：产品经理有最小可行解决方案（MVP）满足用户的需求。

如何同时满足3个假设，作者提出了“价值探索环”的4个可持续循环步骤，分别是提问、锚定、共创和精炼。

图3

由此可见，在前面提及的“前期准备工作”（用户场景、需求分析、产品目标拆解等）是至关重要的。保证产品经理和业务方对现状问题的理解和制定的目标达成共识，才开始进行产品设计、研发测试。

有很多时候，业务方有这样那样的想法，但是现状没有功能支持，但是他们觉得用户就是需要的，因此对于“用户是否真的有这样需求”，是首要明确的，也就是假设一。关于用户需求和需要，在8月复盘中也有提及（用户需要不等于产品需求）。

最近在做用户增长，这种场景和体会也就更深了：

前两周教研同事提出需要了解用户对什么样的直播课主题感兴趣，希望我能够开发一个列表进行对AB-test，以明确用户喜欢什么主题。在明确背景和目标后，发现可以使用“装饰窗”的方法来收集用户信息，即仅开发一个入口，不实现真的功能，来快速得到业务方想要的效果。

于是结合现有的功能，我给教研提了一种MVP：利用学员ID尾号的不同，投放不同的课程主题banner，用户点击进入后看到是一个“假页面”，但可以通过测算用户在这个“假页面”的滑动占比，满足需求目标。

图4：工作场景实践”装饰窗“方法

最终测试效果得出用户最喜欢课程banner4，并且点击进入查看的滑动占比达75%以上。因此在产研团队不需要花资源和时间就能帮助业务方获得用户的反馈，也是非常值得的。

2. 如何“共创”与“精炼”？

通过提问和锚定，明确问题和量化目标后，产品经理要投入精力去提出不同的解决方案。团队中各位产品碰撞，会得出多个解决方案，它们都是基于一定的假设条件猜想得出的，试图解决的是这个大问题中的某个具体问题。

（1）共创

共创得到的是基于某些数据、反馈等有实质参考内容得出的，满足上述3个假设的方案。“量化式影响地图”和“用户旅行地图”是其中常用的两种方法。

量化式影响地图是从业务问题触发，按“角色—影响—方案—量化”的顺序，去量化指标，从而尽可能挖掘可行性解决方案。用户旅行地图，就是我们熟知的用户与产品或服务之间的互动的流程阶段。

图5-6：摘自《持续交付2.0 业务引领的DevOps精要》

在我看来，这两种方法也可以是相辅相成的，本月思考如何串联现有产品功能去做用户增长也是尝试组合了这两种方法。

总目标是提升入库例子数，达成该目标涉及的角色有游客、体验课用户、正式课用户；可以通过一键登录和赠送新手礼包降低注册门槛，提升游客的注册数；可以通过引导正式课用户多分享，影响ta的朋友看到报名内容的曝光度….

明确下个迭代版本的量化目标后，再根据体验地图分析问题痛点机会点等，就进入产品策划了。

图7：工作场景实践“量化式影响地图”寻找明确量化目标

（2）精炼

精炼就是对共创环节中得出的众多方案进行评估，并筛选出产品团队内认为的MVP进行敏捷迭代。评估因素有很多，例如各方案的实施成本、时间人力、验证结果的反馈周期、该方案对目标的影响程度等。

很多时候业务方都希望一次性有一个“大而全”的解决方案，但是做产品经理的工程思维恰恰是相反的：清楚知道达成这个目标的规划，每次小步快跑、快速迭代验证结果，会比策划出一个大而全、看起来“成就感满满”的方案，然后因为各种因素砍功能砍需求，最终只做核心功能方案来得高效。

三、工程思维之“what”

“what”部分分为：

1. 我如何刻意练习工程思维；
2. 生活中的工程思维。

1. 产品经理的工程思维 之 “寻找MVP”

基于本月的刻意练习，看看在寻找MVP途中，自己的提升空间。

本月在思考如何利用虚拟化场景串联产品功能，以达到提升用户粘性，促进分享频次提升的目的。但是在思维发散的过程中，很容易将0到1的产品功能思考的很庞大，不仅导致自己“陷进去”，而且这么庞大的功能迭代起来也比较麻烦。后来和团队leader讨论后，本着“快速迭代，利用最小成本检验虚拟场景的可行性”，决定化广度为深度，先做“分享”这种场景，做好做透后再迭代拓展其他场景，简单既达到目的。

从这个需求来看，自己的不足在于：

1. 思维发散后容易往庞大和复杂上靠，没有收回来落到MVP上去；
2. 很容易陷进功能逻辑里面去，忽略了场景化（教育产品的裂变场景很重要）。

针对上述两点，也总结了3点改进措施：

1. 思维发散利于脑暴，但是落地一定要落到实处，考虑性价比（特别针对0到1的功能设计）；
2. 进去时时刻提醒自己目的！目的！目的！不要着急一下子做完整需求，时刻谨记3个假设是否都满足了（有用户、用户有需求、有MVP）；
3. 把大需求拆分成一个一个子需求，量化管理，确保每个需求都能被get到，有人开发，有人测试。

2. 生活中的工程思维

做了产品之后，发现自己的心态有了很明显的变化，变得没有那么急躁了。之前总是很关注目标，比如刚工作时给自己定的半年做72个需求，但是后来发现，过程对我也非常重要，需要在确保周期内交付结果的同时，关注过程（逻辑的合理性，用户的体验感，路径的流畅性等）。

如果只是为了交付结果，为了“做而做”，这样的需求根本不会产生任何价值。

工程思维不仅是对工作，对人也是一种磨练。把“事情做成”，交付“可靠、可用的成果”，何尝不是一个靠谱的人该有的品质呢。按时交付高质量的需求，按阶段给自己生活一个高质量的交代，这种踏实的自信，正是源于一次又一次的“有计划和可靠”啊。

很多时候我们总是想要这个想要那个，就好像在写雅思作文一样，光想没用，落笔才能理清逻辑。只有落地，我们才知道怎么一步一步触碰到自己想要的那个东西。

如我，我希望成为一个经验丰富的产品经理，那我现在每周记录、每月总结、每季规划，都是为了给自己一个周期性的复盘和计划，希望自己能够在一段时间内成为什么样的产品经理，自己达到70分、80分、90分、100分需要什么能力，这些都可以看作是自己给自己这段时间交付的有价值的成果。

产品经理的工程思维是务实的、落地的，在每次和业务方的沟通、“battle”中，了解背后的真实原因，尽可能给出可量化目标，找到最高性价比的方案。持续快速交付产品价值，不断提升自己乃至团队的整体战斗力！

参考文章：

《持续交付2.0 业务引领的DevOps精要》 乔梁/著

人人都该有点工程思维： https://zhuanlan.zhihu.com/p/83706091

聪明人的10个工程思维：https://www.huxiu.com/article/328953.html

本文作者 @莫琳

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！