《产品经理方法论》 乔克·布苏蒂尔 第二章读书笔记
情境
前一段时间的有个轰动的新闻是深圳某公司产品经理与程序员为了一个需求打了起来，双双辞职而收场，之后沸沸扬扬的都在说产品经理提了一个非常傻的需求，不切实际，最后说是和老板一起拍板的需求。产品经理成了被diss的对象，重复用户的每一句话，感觉就像一个传声筒一样。其实并不是的，“用户读心者”才是更加贴切的表达，但是即使是这个词，也有一些油腻的感觉：产品经理从老板那里了解了某一市场可能存在空缺，再去冰冷的开几次谈话会了解需求，所以也不是最正确。但是这是我目前知道的最好的词语了。
菜单
产品经理的价值到底在哪里呢？
一个产品诞一般诞生于老板的灵光闪现，所谓膝跳反应或者拍脑袋的结果，它或许伟大但还只是想法而已，老板认为某个市场有空缺，所以产品经理最开始需要识别产品是否真的被需要，必须测试我们的假设来减小风险，并且确定老板所发现的市场空缺中我们的产品真的能给人带来益处，以及如何评估产品应包含哪些特性。这些工作的重点，还是用户，对于目标用户的剖析。
所以，产品经理要做到比用户自己还了解他们。
三道菜
one
首先，我们要知道一件事情老板发现的空缺市场里真的有用户吗？产品经理最好能在一开始就质疑一个新产品的基本观点，无论这个观点看起来多么棒，也无论这个观点是不是由公司最权威的领导提出的，要知道不论大公司还是小公司，产品经理最大的用处还是让产品获得更多的成功机会，不要随意让有限的资金打水漂。市场中存在某一产品的空缺，和一个渴望你填补空缺的用户市场，绝对不是一回事，一些产品出现空缺是由一定理由的。你要如同大侦探柯南一般，额，不是如同大侦探福尔摩斯一般，让开始分析这个市场是否有用户，用户数量多不多，这个数量的程度有没有可能让产品盈利。换而言之，就是这个产品真的对用户有用吗？让我们来问几个问题：
具体是哪些人会有这样的难题，会影响很多人吗？
要开始找到老板或者产品观点提出者所说的市场里的真实用户，比如平衡车的用户到底是什么？不会骑车的人？想要接触新技术的硅谷技术人员？短距离方便行驶，到底有多少人需要？当然有时候，不需要影响很多人，一些特定的行业里，比如制造量子对撞机的某个原件，可能只要有一个客户就能满足企业盈利了
人们是否希望马上解决这一难题，还是等等看？
还是平衡车的例子，平衡车是解决“最后一公里”的新兴产物，短距离行驶方便，但是共享单车也同样解决这一需求，而大多数人，像我一样，并不认为“最后一公里”公交或地铁站到家的距离给我造成很大困扰，我愿意多走走。所以在提出一个产品想法的时候，考虑一下用户的紧迫性，客户能在当下就明白你所提供产品或服务的价值价值，并愿意为此买单吗？
人们能自行解决难题，还是需要别人出面解决？
像之前我们有想过给无法遛狗的白领们搞个APP，你有时间我交给你，由一个空闲的人溜多只够，像个交友平台一样。但是真的需要搞个APP来解决么？可以交给邻居或者宠物商店。当用户可以自行想到办法解决，并不需要第三方时，这个难题是否真的是难题？是否能成为产品的需求的是需要考量的。
这个难题到底有多令人头疼，他们愿意花钱解决吗？
还是拿平衡车举例，目前对于生活在城市里大多数人来说，“最后一公里”并不是真的令人难以忍受，况且行驶平衡车是否符合国家道路交通法规还是个问题，还需要在后面拎着并不怎么轻便的平衡车上楼，还是一件挺麻烦的事情。多少人能够花钱解决？当然有的产品本身就是作为辅助，并不需要付费，但是要有盈利的产品需要让难题够难，解决的点能够让大家戳到痛处，才能让用户花钱。
解决这个问题的成本是否会高过这个问题本身的价值？
在之前做ERP产品的时候，遇到过消息传递的问题，当时消息中心是下一期的优化项目，在优化项目开始前，遇到了用户想要即时提醒订单状态变更，可以马上开发一个单独针对订单状态变更的功能，也可以让业务双方通过列表查询或者电话QQ等线下沟通的方式解决消息传递。因为消息中心已经规划进了优化项目，单独开发无异于浪费人力物力，在新消息中心上线时，可能还需要移除。所以解决问题的成本是否高于问题本身价值也是需要考虑的。
客户什么时候最想要付费？如果在办公室里，你和你的团队说，你手里有半杯水，问他要不要买，他肯定以为你神经病，不会去买的。但是如果场景换到沙漠就不一样了，如果是他刚刚长途跋涉徒步沙哈拉沙漠，烈日下她汗流浃背，嘴唇干裂，他的水好几个小时前就已经喝完，他的嗓子都要冒烟了。这时你把那半杯水给他，这个场景里这杯水已经变成了他的救命之水。他现在会为它掏多少钱？如果能在用户最能认识到产品价值的时候提出支付要求，他们会更乐意花掉他们辛苦赚来的钱。
当产品真的被需要，真的对于用户是有用的，才有人愿意掏腰包来购买它。
two
其次，我们要弄清楚一件事，需求往往是被隐藏的，人们往往弄不清自己要什么，一般来说都是事后诸葛亮，比如罐头发明了48年后才有了开罐头的起子，比如一场大雨才知道带伞很重要，数据丢失了才知道原来数据备份很重要。在询问潜在客户，你要什么的时候，他们往往还没有意识到自己需要什么。比如在移动支付未出现前，我从来没有想过我要移动支付，只觉得银行或者柜员机很麻烦；比如在微信出现以前，我并没觉得飞信是一款难用的产品，也没想过语音聊天，那为啥不打电话呢？
还有欲望不等同于需求，当我想要喝第二杯奶茶，我日渐变小的衣服都在说明我并不需要它，但我们容易将欲望和需求等同，所以有时候很难从潜在用户表达的欲望里找到背后的实际需求。我不知道大家有没有过这样的体验，当认为我们想要的东西就是我们所需要的，直到被要求付款了，就突然不想要它们了。因此产品经理的一项重要技能就是学会深刻理解人们到底先要解决什么问题，并且直到为什么，而不是过于抢到用户可能说它们想要什么。毕竟，如果人们都能“认识你自己”，那产品经理的工作就真的变得只是“传声筒”而已了。
当你对产品有了任何想法，或者应该说是假设，去核实它。在团队里形成一个头脑风暴，对于每一个假设都问一句，“你怎么知道X会有这样的反应？”如果你或者你的团队无法拿出有力的证据，那就去寻找证据。这样就记录下一个很长的清单，需要质疑是否每一项都能放心的假设。之后当然要做好优先级，因为最大优先级的必然会对整个产品甚至整个项目带来最高风险的影响。就像美国曾经被吹捧很久的赛格威，它亮相后因为在道路上行驶这种代步机器是不合法的，这其实最高风险的假设之一了吧。
有很多的方法来测试你的假设。最快最便捷成本最小的应该就是创建一个最小可行产品，它可不是一个只有一半功能的半吊子，是能最小解决某一市场的难题了。最简可行产品的概念源于埃里克.莱斯的书《精益创业》。莱斯提倡一种循环的方法，创建——评估——学习，有点像敏捷开发，快速投放市场可用的最简产品，通过市场反馈来确定是否该想法解决了或者缓解了该市场的难题。如果反馈不错，可用继续投入成本。
需要注意的是，并不是在创建这一环节就开始写代码，如果能在纸上，画出高保真的原型图，和少数几个核心成员确认一下，未尝不是个好方法。你们猜猜谷歌眼镜的原型从提出到开始研发花了多久？当谷歌实验室的汤姆.齐开始测试眼镜项目是否有效是，他仅仅用了几分钟就用模型的电线和几团用来增重的橡皮泥创建了最初的原型。通过快速测试，他得知装置不会伤到耳朵的最大重量以及鼻梁的承受能力比耳朵好一些，这就是谷歌眼镜在鼻梁处稍稍重一些的原因。在一行代码都没有动手之前，就创造一个合适测试的产品版本，这就是一个非常经济划算的方法。
而投入最简可行性产品测试市场的最广为流传的例子就是苹果公司。苹果公司在2001年发布了第一版的iTunes,可以将CD音频转换成压缩的音频文件的软件。当时人们要把CD里的音乐翻录，是需要一定的技术的，苹果公司用这样一个极简的产品检验了人们是否真的有使用数码音乐的想法，数码音乐是否会有广阔的市场。答案是肯定的，所以苹果在当年10月，发布了iPod。它用最小的成本来检测一个新兴的市场，而且最开始的Itunes也是收购的一家小公司的软件，苹果公司并未真正的开发软件。苹果公司挖掘了一个尚未被满足的需求，并且被用户很好的接受了。
three
最后，既然说到苹果公司IiPod，就要来说说他的广告词了——“将一千首歌装进口袋里”，为什么比其他随身设备的，拥有5G内存来的让用户动心呢？因为特性无法让用户产生共鸣，能产生共鸣的是益处。同需求和欲望一样，特性和益处也总是被混淆。“一千首歌”是产品对于真实世界真实用户的益处，而产品有5G内存只是产品的一个特性。益处的表达能够让产品脱颖而出，被潜在用户共鸣。比如，推销房子的时候，价格低真的是你所推销的房子的益处吗？不是啊。问问“那又如何？”如今是这样宣传的，因为离公司离家近可以省去通勤时间，有更多时间可以陪孩子入眠，可以陪伴爱人。
益处更多的是感观体验，益处常常也是产品的期待因素，比如产品存储空间大，可以把更多的歌放进口袋里，这就是用户会对产品产生期待，期待满足度越高，用户对产品就会越满意的。而对产品的期待往往也会演变成产品的基本因素，产品的基本因素就是指产品解决用户需求的基本点，比如酒店房间总得有张床吧，有床不会提高用户对酒店的评价，但是没有用户可能会投诉。而产品的期待因素随着时间演变会变成产品的基本因素，比如苹果公司推出了iphone触屏手机后，手机是否触屏成了行业标杆，苹果手机每一代推出总也没有更多的亮点了。
饮料
好了，现在我们已经知道老板或者创始人发现的空缺市场里是否有真正的用户以及判断这个空缺市场到底能否让用户掏钱，然后我们还辨别了用户说出的到底是欲望还是真实的需求，最后我们还辨别了产品的益处和特性。我们对用户已经有了特别特别多的研究，产品经理在分析需求上面花的时间和精力一定是最多的，我们不可能仅仅作为上传下达的“传声筒”，还有一系列的分析，在需求管理上，就可以洋洋洒洒说上面这么多的东西，还有很多我没有讲述到的，产品经理在产品成功是有很大的决定性因素的。
彩蛋
我们对用户的了解程度之深，大于对我们的爱人，甚至大于他们自己，比用户自己还了解自己才是合格的产品经理。那么我们要知道用户是活生生的人，是会恐惧、会愤怒、会开心的用户，我们创建用户画像的时候，可以使用生动的个人，要知道一个生动的故事更能让团队理解产品定义。
比如用实际的头像来代替卡通图片，体现出用户在什么时间使用软件等
产品经理是出色的听众，是优秀的沟通者、调解者和教育者，产品经理的工作任重而道远，有时候也不被理解，在其他人都失去冷静并归咎于产品经理的情况下也被保持镇定。产品经理需要倾听，不仅仅是用户的读心者还是团队其他成员和老板的读心者。
