技术活是我们能力之下的保障，我们通过技术去获得可能性，而最终走到哪里，是看我们定的方向和能力。
产品经理的6个必备能力
一个产品经理，至少要有6个能力：
- 评估：评估需求做不做的能力，评估合理性。
- 排序：需求什么时候做的能力，MVP原则和优先级。
- 取舍：取舍的能力，方案和需求的妥协权衡。
- 创新：打破流程颠覆场景的创新思考。
- 洞察：洞察产品背后的产业和利益链条。
- 理性：用事实逻辑选择方向，而不是个人喜好和经验。
下面我想通过三个常见的问题案例，来跟大家谈谈这几个能力的场景和逻辑。
3个问题案例
问题1：你这样做工作量太大了，建议砍掉这个需求，节约工作量
日常会听到开发发出这样的声音，其实仔细想想，这个表述可能表达了两个意图：
- 我觉得这个需求不合理，我不想做；
- 我觉得这个需求合理，但是性价比很低，我觉得应该先做别的。
即暗藏了两个问题：
- 这个需求做不做？
- 这个需求什么时候做？
但是往往我们开会沟通的时候，会把这个问题纠结地去考虑，造成彼此的困扰。在这里我建议将这个问题分两步考虑，下面是我的一些经验：
首先，我们应该评估这个需求的合理性，即做不做的问题。做不做的问题完全取决于产品定义和产品形态，这个时候要放开时间的界限，把可能性都囊括进来。比如，在讨论语音搜索功能是否要做音量检测反馈的时候，我们的答案是肯定的，所以我们把这个需求记到需求列表里面。而常见的问题是，出现一个不和谐的声音“这个需求太边缘了，先不做了，赶不上要求的上线日期了”，这个时候往往就容易把这个需求打压掉，或者针对做不做的问题来纠结。其实仔细想，在讨论做不做的阶段，有些人往往在表达什么时候做的相关信息，这样就造成了信息沟通问题，造成了不必要的浪费。
第二步，我们要评估什么时候做的问题，这个问题即优先级的问题。讨论优先级的情况下，主要是看方案，而不要去怀疑这个需求的合理性。这个阶段的原则主要是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端用户会比较容易讲出这种话，当你听到这句话，其实依旧暗含了几个方面的意思：
- 移动端是比PC更新的计算平台，所以我们做新不做旧；
- 移动端的移动性是PC不具备的，所以我们要做在这个更方便的平台上。
所以他想要的其实有两个方面：
- 我要的是便捷性；
- 我要的不是功能的迁移，而是创新。
对于便捷性很好说，这个时候要聊场景，即需求是否有这个便捷性场景或要求？便捷性对于这个功能是否有显著的提高？比如远程签到打卡功能。但是便捷性意味着展示信息的一些损失，就像大型游戏依然是在PC端和主机端一样，手机屏幕的6寸大小对于报表、复杂表单的展示依旧是捉襟见肘的。所以在场景的基础上，评估出是否值得用完整性来换取便捷性，是这个需求评估的关键问题。
对于创新，我们要讲一个很深刻的问题。其实大部分产品经理做的事情都是效率的提升，而不是创新。比如对于物流行业的验证码、二维码扫描功能，其实是对输入单号的一种优化，属于既定流程的效率提升。而区块链仓库，则是对于流程和原理的颠覆，是一种创新。
所以对于产品经理来说，提升效率是我们安身立命的最低要求，创新才是不能放弃的追求。如果放弃了创新这个念头，就会越做越无聊，看不到希望，很多事情都会固化懒惰地去思考，而不是先高瞻远瞩看看有没有能跳出流程之外的创新做法。
总而言之，创新是优秀产品诞生的基因，所以我们要感谢那些创新的产品经理，我们才能有机会用上微信语音，而不是更小巧的物联网对讲机。
效率提升是最低要求，创新是追求的理想成就。
问题3：这个产品不盈利，就不是好产品
这一点其实很难理解，这个时候需要产品经理跳出产品本身的概念，去思考清楚整体的利益链条。
比如当一个产品经理看到某播的劣质内容，思考增加一个鉴黄功能时，却忽略了劣质内容背后一整套的利益链条。所以功能是为需求和目的去服务的，而不是为了喜好和干净。
一个看似不起眼的产品，很可能养活了背后千千万万个利益相关者，某些利益链条是产品存在的根本，有了这些根本，才有存在和创新的可能。
所以，当你想创新或优化的时候，不妨先看看背后的利益逻辑，你的优化点是否触碰了这些？当你推进不顺的时候，是否挡在了一些不可移动的困难前面？
作为产品经理，要靠对利益链条的洞察来为自己划出边界，而不是靠感性去改变世界。
作为产品经理，不是要去做对的事，而是要去做存在可能性的事情里，最对的那件。
产品经理的术
对于原型、功能构建来说，只是指导思想确定之后的技术活。而技术活是我们能力之下的保障，我们通过技术去获得可能性，而最终走到哪里，是看我们定的方向和能力。
所以，深挖世界背后的含义，走向更深的产品境界。
