My Secret Rainbow

三个问题看懂PM必备能力

产品经理的6个必备能力

一个产品经理，至少要有6个能力：

1. 评估：评估需求做不做的能力，评估合理性。
2. 排序：需求什么时候做的能力，MVP原则和优先级。
3. 取舍：取舍的能力，方案和需求的妥协权衡。
4. 创新：打破流程颠覆场景的创新思考。
5. 洞察：洞察产品背后的产业和利益链条。
6. 理性：用事实逻辑选择方向，而不是个人喜好和经验。

下面我想通过三个常见的问题案例，来跟大家谈谈这几个能力的场景和逻辑。

3个问题案例

问题1：你这样做工作量太大了，建议砍掉这个需求，节约工作量

日常会听到开发发出这样的声音，其实仔细想想，这个表述可能表达了两个意图：

1. 我觉得这个需求不合理，我不想做；
2. 我觉得这个需求合理，但是性价比很低，我觉得应该先做别的。

即暗藏了两个问题：

1. 这个需求做不做？
2. 这个需求什么时候做？

但是往往我们开会沟通的时候，会把这个问题纠结地去考虑，造成彼此的困扰。在这里我建议将这个问题分两步考虑，下面是我的一些经验：

首先，我们应该评估这个需求的合理性，即做不做的问题。做不做的问题完全取决于产品定义和产品形态，这个时候要放开时间的界限，把可能性都囊括进来。比如，在讨论语音搜索功能是否要做音量检测反馈的时候，我们的答案是肯定的，所以我们把这个需求记到需求列表里面。而常见的问题是，出现一个不和谐的声音“这个需求太边缘了，先不做了，赶不上要求的上线日期了”，这个时候往往就容易把这个需求打压掉，或者针对做不做的问题来纠结。其实仔细想，在讨论做不做的阶段，有些人往往在表达什么时候做的相关信息，这样就造成了信息沟通问题，造成了不必要的浪费。

第二步，我们要评估什么时候做的问题，这个问题即优先级的问题。讨论优先级的情况下，主要是看方案，而不要去怀疑这个需求的合理性。这个阶段的原则主要是MVP思想，把最核心的功能到最外围的梳理清楚，再去取舍。比如说领导预期上线的计划时间是2月底，我们在上一个环节合理性确认清楚的原则上，根据MVP的优先级原则，对需求进行分期、排期。这个阶段主要是由项目经理和产品经理对方案进行评估，能在最简洁、最合理的方案下，达到最合适的需求效果。

MVP（minimum viable product，最小化可行产品）概念最早由埃里克·莱斯提出，刊载于哈弗商业评论，并有出版物《精益创业》

和常规产品不同，MVP更侧重于对未知市场的勘测，用最小的代价来验证你的商业可行性。举个例子，如果你希望做一个图片分享网站，那么作为产品原型，MVP仅仅包含最基础的功能，形态或许就是一个提交图片的按钮以及图片的展示。借助MVP，经过一系列实践，产品的设计思路将被一次次整改，最终完成正式版的开发。

MVP的目的——更快的接触客户

按照常规的开发方式，从调研、到设计、到开发再到推向市场，会是一个漫长的过程，而且很难有人会保证成功率。但当换一种方式，以MVP进行小样调研，快速进入市场、接触客户并得到反馈。透过反馈不断修改原型，并进行不断地的迭代开发，极大减少了试错成本。

两种MVP——Validating MVP 和 Invalidating MVP

MVP的模型分为两种，Validating MVP 和 Invalidating MVP。

第一种是Validating MVP（可行的MVP，无对应中文，斗胆翻译），也是是较为常用的MVP：接近你的目标客户，把现有未完成的产品低价出售。如果他们乐意接受，则产品验证成功；反之，失败，但这并不影响项目的进程。

举个例子：

小明做了一款社交付费APP，目前做好了文字沟通功能，语音通话尚未解决。此时的小明希望知道这个方案是否靠得住，于是走访了多家企业出售他的半成品APP，市场反馈良好。于是小明拿到了第一笔钱，继续研发。

第二种是Invalidating MVP（昂贵的MVP，亦无对应中文，斗胆翻译），讲究的是高大全：将所有部分开发好，接近客户并尝试以高价推销出去，期间通过不停地修改产品的功能和定价，最终实现产品验证。

举个例子：

小明做了一款社交付费APP，不仅完成了通话功能，还做出了打赏功能。此时的小明希望知道这个方案是否靠得住，于是走访了多家企业出售他的半成品APP。很多企业很满意，但觉得价格过于高昂，于是小明将部分功能删减，APP折价继续推入市场。

满足客户需求——何为好的MVP

一个好的MVP一定要做到满足客户的必要需求。尽管许多人客户的意见各异，调和其中需求是不可能的。但事实往往相反，通过多次市场测试，得到更多的市场意见，我们可以获得越来越直观、高效的MVP。而这种MVP，又将会将会成为面向市场的第一款产品。

资料来源：

《精益创业》by 埃里克·莱斯

《哈弗商业评论》

《构建强大MVP的商业技巧》by Jonathan Gilligan

这样探讨之后，我们发现目标更加清晰了。有些时候沟通的瓶颈在于，我们一次性想说太多东西，考虑了太多方向。从数学或是物理的角度来讲，分散角度，会让力量减弱。所以，分步骤是一个好的思想，不管是在沟通、评审，还是交互设计，都很受用。

好的沟通不仅仅在于表达，而是建立在明确的逻辑梳理之上。

问题2：我们要把web端功能搬到移动端，因为以后都用移动端了

往往业务方或者B端用户会比较容易讲出这种话，当你听到这句话，其实依旧暗含了几个方面的意思：

1. 移动端是比PC更新的计算平台，所以我们做新不做旧；
2. 移动端的移动性是PC不具备的，所以我们要做在这个更方便的平台上。

所以他想要的其实有两个方面：

1. 我要的是便捷性；
2. 我要的不是功能的迁移，而是创新。

对于便捷性很好说，这个时候要聊场景，即需求是否有这个便捷性场景或要求？便捷性对于这个功能是否有显著的提高？比如远程签到打卡功能。但是便捷性意味着展示信息的一些损失，就像大型游戏依然是在PC端和主机端一样，手机屏幕的6寸大小对于报表、复杂表单的展示依旧是捉襟见肘的。所以在场景的基础上，评估出是否值得用完整性来换取便捷性，是这个需求评估的关键问题。

对于创新，我们要讲一个很深刻的问题。其实大部分产品经理做的事情都是效率的提升，而不是创新。比如对于物流行业的验证码、二维码扫描功能，其实是对输入单号的一种优化，属于既定流程的效率提升。而区块链仓库，则是对于流程和原理的颠覆，是一种创新。

所以对于产品经理来说，提升效率是我们安身立命的最低要求，创新才是不能放弃的追求。如果放弃了创新这个念头，就会越做越无聊，看不到希望，很多事情都会固化懒惰地去思考，而不是先高瞻远瞩看看有没有能跳出流程之外的创新做法。

总而言之，创新是优秀产品诞生的基因，所以我们要感谢那些创新的产品经理，我们才能有机会用上微信语音，而不是更小巧的物联网对讲机。

效率提升是最低要求，创新是追求的理想成就。

问题3：这个产品不盈利，就不是好产品

这一点其实很难理解，这个时候需要产品经理跳出产品本身的概念，去思考清楚整体的利益链条。

比如当一个产品经理看到某播的劣质内容，思考增加一个鉴黄功能时，却忽略了劣质内容背后一整套的利益链条。所以功能是为需求和目的去服务的，而不是为了喜好和干净。

一个看似不起眼的产品，很可能养活了背后千千万万个利益相关者，某些利益链条是产品存在的根本，有了这些根本，才有存在和创新的可能。

所以，当你想创新或优化的时候，不妨先看看背后的利益逻辑，你的优化点是否触碰了这些？当你推进不顺的时候，是否挡在了一些不可移动的困难前面？

作为产品经理，要靠对利益链条的洞察来为自己划出边界，而不是靠感性去改变世界。

作为产品经理，不是要去做对的事，而是要去做存在可能性的事情里，最对的那件。

产品经理的术

对于原型、功能构建来说，只是指导思想确定之后的技术活。而技术活是我们能力之下的保障，我们通过技术去获得可能性，而最终走到哪里，是看我们定的方向和能力。

所以，深挖世界背后的含义，走向更深的产品境界。