几年前，在我学驾照的过程中，我开始是很痛苦的，因为教练根本不告诉我为什么这么做，只是告诉我，先开出去，看后视镜，当后窗的x点与车库的x点对齐了，右打满往前开，然后，balabalabala的

我为什么痛苦呢，因为他没告诉我为什么这么做（WhyToDo），他只告诉我要这么做（HowToDo）。虽然，从实用性的角度看，直接按照他教的那么机械的做是最高效直接，不会出错的。

学完车之后，关于倒车的那些技法我还是记不住，每次停车都挺难的，所以我上网继续搜索教程，但是，我发现，网上的教程也都是直接告诉你要怎么做，很少说为什么这么做的。就这样，我对着教程慢慢琢磨慢慢练，也算把停车技术弄的还说的过去了。

于是，有个问题就一直在我的脑海里盘旋，为什么他们总是只说怎么做，不说为什么这么做呢？后来开始自己带团队，开始不断的教别人怎么做事情，我觉得我有点理解这个道理了。

从基本意义上看，授之以鱼不如授之以渔，把为什么这样做说清楚是对的。但是，这个理论忽略了一个重要的基础因素，每个个体的接受程度是不一样的，简单讲就是领悟力不同，当你不断给他讲道理的时候，他往往领悟不到，更有甚者则理解偏颇了，出的麻烦更大。同时，这样不断的一遍一遍的讲，效率也是很低下的。

所以，看上去，在实际行动中领悟，不断自我纠偏自我理解则是更为有效的方式，就是中国传统文化中的言传身教。总结成人话就是，先有样学样，然后在失败中总结。会总结的人自然就能举一反三，不会总结的人就自然的被降级为螺丝钉。

你比如做产品这件事，它有没有技法呢？是有的。技法是什么样的呢？在我看来就特别简单，搭架子、定流程、抠细节。这属于理论，属于我自己的方法论，我要给你展开来讲这个方法论，至少可以讲一整体不带歇脚的。我给你讲完了，你会做吗？你肯定不会，而且你往往还会被我带的偏颇了。

问题出在哪里呢？之前有一张比较有意思的图应该可以直观的解释这个问题。

如何解决不同思维模式带来的差异问题呢，最好就是先把大家都调到一个频道上来。怎么把大家调到一个频道上来呢，先做把事情变成「形式化」的，然后所有人「行事化」的执行，之后沉淀成了「习惯化」的。这个时候，决定你是成为一代宗师还是普通武师的时候到了。

如果你能做到自我领悟，你就能成为宗师，有自己的内功心法与招式，甚至开宗立派，比如张三丰；如果你不能自我领悟，你就一辈子只能消耗师傅的招数，甚至因为资质的问题有些招数还演绎不出来。

这里就可以顺带再次回答被无数入门的产品经理们问了无数遍的问题，我想做一个优秀的产品经理，我该怎么入手呢？

1、别管什么狗屁的产品理论，永远不要在刚入行的时候去学习什么狗屁的产品理论，记住，碰都不要碰！

2、去实际使用每一个产品，然后做自我总结，把某一个共性的模块全部归纳出来。比如，把你用过的所有产品的注册、登录流程全部记录下来，整理出来做归纳，得出一般的规律

3、基本的产品模块的设计思路你应该都要做到了然于胸了。当你要设计某一个模块或者流程的时候，把你脑子里存储的那些案例全部调出来，挑拣一遍，选出一个最好的，加点自己的个性进去

4、重复第3点，去尝试新的产品设计。

5、悟到自己的产品理论。

6、你现在可以回去再看看那些产品理论，好像，也不过如此，而且还有些说的非常偏颇

以上这个过程，就是一个从HowToDo到WhyToDo的过程。也是一个相对科学与效率的进入一个新的领域的方式。先不要管任何的理论，直接有样学样照猫画虎，学样的过程中不断感受不断总结，多次的总结与沉淀之后，如果你适合做就会自成一派渐入佳境，如果你不适合做就认命或者换行吧。

这里再次回答被无数入门产品经理问了无数遍的另外一个问题，我想做一个优秀的产品经理，我最重要要具备什么素质？

勤奋，没有之一了。

类似的产品，做了同样的一个功能，但是，我们还是可以很明显的感受到不同，这种不同我们常常把他叫做「用户体验」。

但是这种差异究竟是怎样的，我们似乎很难描述，那好吧，我换个方式来聊聊，我们在使用类似产品的同样功能的时候的感受。

来看看3组类似产品相似功能的设计：

在很早的时候就存在一个需求，听歌识曲。于是早期有很多类似的APP，比如音乐雷达、shazam等。

后来，微信也做一个摇一摇识别歌曲的功能。

最早的音乐雷达只完成一件事，帮你找到这首歌的名字，这属于及格的产品；微信的摇一摇能做到帮你找到这首歌的名字，还能帮你定位到当前播放的位置，并继续自动滚动歌词，这属于优秀的产品。

在很早的时候，支付宝做了手机端的支付流程，我们需要记住很复杂的支付密码。

后来，微信也做了手机端的支付，微信说密码应该延续实体卡片的6位数字，不需要那么复杂；微信说支付这个环节为什么需要确认呢？

支付宝的手机端支付流程，属于一个及格的产品；而微信的手机端支付流程，属于一个优秀的产品。

另外，大家注意对比这2个页面，从设计角度讲，支付宝的这个页面设计实在烂透了！

1、浮层标题栏的提示，微信更简单明了；

支付宝的标题栏，又是icon又是文字，怎一个乱字了得！这个页面是在支付宝APP中调起来的，这个时候还突出你的logo，想要表达什么呢？完全没必要啊

2、主信息展示区域，付多少钱，用什么方式支付，微信在信息的区分展示上处理的更好，而支付宝的这个设计，我经常会分不清楚那个364.00元指的是我的余额还是我要付的钱。

付多少钱与用什么形式付款，是2个不同的层级的信息，但是，支付宝的UI处理上，放在了一个层级上，给用户在信息的识别上增加了更多不必要的负担。

3、为什么要有确认按钮，为什么要有确认按钮，为什么要有确认按钮？

— 重要的事情说3遍！

支付宝迫于微信的鸭梨，把密码修改为支持6位，但是，在设计上，还是没敢放开自己，一个需要确认按钮，一个不需要确认按钮，产品设计功底，高低立现，差的真心不是一丁半点。

ps：我们很多的产品经理，我们很多的设计师，在设计上非常的「传统」。比如，切换城市了不是在后台就自动完成，非要提示一下用户，还要用户确认一下。

产品经理对设计的认知变化，远远赶不上用户越来越懒越来越追求快的心智模型变化！

这是一个导流页面的对比，我们主要看文案的提示。

场景是用户叫出租车叫不到，推荐用户去用专车。快的打车的做法属于及格产品，而滴滴打车的做法属于相对优秀产品。（个人觉得优化空间还较大）

分析一下这个场景，用户叫不到车了，这是现实，用户的需求是用车，但是专车明显比出租车贵。

所以，这个文案提示有2个方面要讲，一方面是没车了，你可以换个别的试试，一方面是别的车大概多少钱，你能省多少，你算算是不是符合你的预期。

这样一分析，高低立现。

所以还是那句话，产品经理们，你们该多读点书的！

及格的产品，能把流程想完整，把该有的元素都放上去；

优秀的产品，流程是极简完整的，元素都是无法再剔除的；

及格的产品，有耐心的用户一步一步坚持，可以完成任务；

优秀的产品，不管是什么用户，很简单就能完成任务；

及格的产品，在思考产品方案的时候，会考虑的是完成任务；

优秀的产品，在思考产品方案的时候，会考虑的是如何愉悦的完成任务；

最后，为了让你们更简单直观的理解及格的产品和优秀的产品，放一张生活中常见的图吧。

 

关于什么是需求评审，不在这里做解释与定义了，直接进入主题。

关于需求评审的几个原则：

1、需求评审不是谁要说服谁，而是我们要就某一个具体问题寻找到最优的解决方案。

我们有很多PM总是会抱着「我要说服研发」的态度来做需求评审，所以整个需求评审的基本氛围是辩论，是相互的寻找极端情况支撑自己的观点，试图让对方让步，这是非常错误的开局。

2、所有问题的讨论，都必须要先建立基本共识，然后基于这个共识再细化。

什么是基本共识呢？就是我们首先要把双方调整到一个频道上来。不要在不同的频道上相互努力，那没意义。比如，我们先要定义清楚什么是激活用户、什么是注册用户；比如我用到的这个名词指代的是什么这样的基础的小问题。

3、先不要在僵持不下的观点上浪费时间，先求同，后攻异。

在已经形成基本共识的基础上，如果一个小问题有分歧，且一时半会讨论不清楚，那就先放下，继续讨论其他的，等其他的解决了，再回来解决这个差异点上的问题。

关于需求评审的推进步骤：

1、先说我们这次需求的目标与目的。

简单说就是先讲明白我们要做什么，我们为什么要做这个。

就像是演讲的时候，先讲一个能够引起观众兴趣的故事或者观点，然后再提出一个在这个美好的故事中需要解决的难题。

这个问题是经常会产品经理忽略的，但也恰恰是需求评审中最最重要的，它的重要性甚至超过了后面所有的步骤！

我看过太多的产品经理在需求评审的时候，上来就打开画好的原型图，开始讲功能，讲流程。这是完全错误的。一定要花时间先讲为什么要做这个，要达到什么目标，并且一定要在这个目标上达成一致意见。

就像我之前说的，「设计师，别急着打开设计软件」，产品经理在需求评审之前，请别着急讲功能点与流程，这非常重要。

2、在目标与目的达成一致的基础上，再说你准备怎么做

在谈怎么做的时候，我们是默认为什么做大家达成了一致的。这个时候，不要再返回去讨论第一个问题了，聚焦在怎么做上。

在我们讨论问题的时候，在我们评审一个需求的时候，很多人会很着急，当你说要做这个的时候，他的思路会跑的很快，立刻就先跑到了想要是这么干，我们目前的架构会有什么问题，会存在什么潜在风险，已经跑到细节上了。

这样很不科学，也很不高效，很容易把问题混到一起去了，然后就会陷入到细节的争吵与辩论，然后就走偏了。这样的讨论也是低效的。

谈第一个层次问题的时候，就不要想第二个层次的事情，谈第二个层次的事情的时候，就不要再回去质疑第一个层次的结论了。

讲述你准备怎么做的过程，实际上就是要描述你的解答对解决问题而言的好处。

关于「准备怎么做」的讨论，会有2个结果：

2.1、你认同或者大部分认同我的方案

那么，就按照这个方案来执行，其中有一些不太认同的，我们坐下来讨论，看是否有更好的方案来做。

2.2、你不认同我的方案

那么，我们先回到第一个问题「关于我们要做这个事情的目标与目的」是否认同。如果认同目标了，那就是实现方案的问题了，我们可以坐下来研究。如果不认同这个目标，那这评审也就没得玩了，这个状态一般极少出现。

好，现在问题出在不认同方案上了，又有2个结果：

2.2.1、这个方案可以做基本的修正吗？

可以，那我们探讨如何修正

2.2.2、你是否有更好的解决方案呢，这个方案是否可以勉强执行？

可以，那好，先按照这个方案干。如果你有更好的方案，我们按照你的方案干。

2.2.3、我没有更好的方案，我也不认同你的方案

靠，你这完全不是一个团队合作的状态，赶紧换人。

3、方案达成一致了，开始做排期与风险及收益预估

为什么做这个事情，都清楚了，也认同了；

是不是可以这么干，也基本达成一致了；

剩下的就是排期，安排人员，具体去执行了，这是一个新的话题，不展开了。

总结一下，其实就是一个不断拆解的过程，

1. 先说我们的目标与目的，在为什么要做这个事情上达成一致；
2. 再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；
3. 按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。

讨论问题与需求评审一样，是一个解决问题的过程，解决问题的最合理方式就是不断拆解问题，拆解到不能再拆解了，然后分别的寻找解决方式。

另外，相比情商，智商反而有时候显得不是最重要的。

我是个宅男。

宅男，可以做的事情很多，比如，玩游戏、打飞机、看小说、看电影。

我不爱玩游戏，因为我定力不够，容易沉迷；我也不爱打飞机，还是因为我定力不够，容易上瘾。所以，当我宅的时候，我大部分时间在看电影或者看书。

我喜欢看电影，大部分时间是被这个导演所营造的氛围还有故事结构所吸引。一个好的电影导演，他首先是一个很会讲故事的人，其次他是一个能借助道具，透过细节，表达内心的人。

我从电影里悟到更多的是，为什么要设置这个细节，这个人此刻的行为将会对整部电影的影响如何，如何去表现一个人物的内心的感受，用什么方式去承接2个不同的画面。

所以，当我看到汉武大帝里所用的道具，基本都是博物馆里真实的物件一比一仿制还原的时候，我觉得胡玫是一个了不起的导演；当我看到李仁港先生的所有古装片里，不分朝代，所有的服装几乎都一样的时候，我觉得丫太特么的不负责任了！

当然，如果我不宅，我也会选择去看话剧，演员们在台上的走位，就是产品设计中的流程设计、交互设计。

相比电影，我更喜欢看书，当我领悟到，产品之要，首在场景感。没有错误的设计，只有放在错误的场景下的设计的时候。

电影是一种几乎完整的呈现，导演能做的就是通过细节去刻画人物的细节，通过故事安排去吸引观众，制造悬念，因为观众通过声音、影像已经让可以想象的空间太少了。

而书则完全不一样，文字的表述，给读者留下了几乎全部的想象空间。这对于我们培养自己的想象力，培养我们的场景感，更加有帮助。

当金庸描写小龙女肌肤吹弹可破的时候，你发现，根本没有一个真实中的演员能完美的与你的想象所契合；当刘慈欣描述那浩瀚宇宙中的三体人的时候，你发现，根本不可能有一个导演能用镜头承载你的想象；当孙皓晖描述老秦人吼出那句赳赳老秦共赴国难的时候，你发现，没有一个演员能有你想象中那么到位的表达；当叶曙明在大变局中描述孙先生为了革命，无耐加入青帮的时候，似乎也很难去表达此刻孙先生的内心所想。

所以，现在你能理解，黄色小说其实比黄色电影更毒害人了。
黄色电影，也可以拍成像X-Art那样的唯美，就连X-Art的Logo都设计的那么优雅，但是，一部黄色小说，越是成功，就越能让读者打开更大的脑洞……

电影，在一个层次上可以让场景感具象化，文字，则在一个释放了更多的束缚，让想象力扩散更大，我们俗称的脑补。

某种意义上说，脑补能力高的人，更适合做产品。

有次跟一个朋友聊天，我们聊到，读书到底有什么用？

我说，我不读书，那我干什么呢。时间反正都会消失，干点什么总比干等着好。我们读过很多书，其实，我们根本记不住书里具体写的是什么，那些具体的内容我们都会慢慢遗忘，但是，很多东西很自然的渗透到了我们内心，这些东西在我们内心积累、发酵，最后这些东西渗透到我们的思想、行为中，这就是读书最后所剩下的东西。

而这个东西是什么，其实，我也不知道。但是，我可以肯定，这个东西，是很好的。

1.

如果我们把「做产品」或者叫「做功能」吧，比喻成是打造一把剑。我们也可以同样的把运营/销售/推广这个产品，比喻成要去上阵杀人。

很显然，这里存在相互依存的关系。那么，同样的，问题也来了。

你必须要拥有一把锋利的剑，一把像样的剑，一把剑才能上阵迎敌吗？

在很多人的意识里，这个问题的答案是肯定的。产品必须要做好了，我们才能去运营与销售。在产品没有做好之前，我只能等待。我都没有剑啊，你总不能让我赤膊上阵吧！

这个意识是有待商榷的。把金子卖出金子的价钱，是一般的运营与销售；把银子卖出金子的价钱，是相对出色的运营与销售；把一坨屎卖出金子的价钱，是天才的运营与销售。

有条件要上，没有条件创造条件也要上。

2.

面试一个做策略的产品经理。我问了一个问题，你觉得微信拼手气红包，分钱的策略是什么，是纯随机的吗？如果你来设计这个策略，你会怎么做？

对方回答，我觉得不应该是随机的。我应该考虑如何让这个「功能」可以玩的起来，我需要同时照顾发红包的人和抢红包的人的利益。比如，发的越多的人，可以抢的越多。

我问，在发红包这个场景里面，发红包的人一般会是什么样的人，抢红包的一般又会是什么样的人？他们分别是什么心理呢？你的老板应该是发红包很多的人，相对的，你可能是发红包很少的人，你的老板会抢很多红包吗？

对方回答，可能不会吧。

我问，那你有怎么去实现这个平衡呢？

对方就着这个问题继续分散了很多，想了更多的策略去弥补我所设想的分支场景。然后，策略叠加策略，很多策略交织在一起了。

然后我说，好，我们现在停一下，回到问题的原点，你重新来设计这个策略，你会设计成纯随机的吗？

对方怯怯的回答说，会。

你看，这就是我们作为一个「设计者」最爱犯的毛病，我们什么都想去「设计」一下，仿佛不设计就不能显示我们的本领来。我们始终不愿意去走那条看似最平常的路，我们就这样被自己设计的设计所设计着，平常总是蕴含着无穷的力量，而我们常常忽略她。

（微信红包的策略具体是不是随机的，我不知道，这个问题我只是从我的思维出发，做的答案，大家没必要较真）

3.

我们经常受惠与机器，所以我们变的特别依赖与机器，依赖与技术。相应的，我们希望并且试图把所有东西都技术功能化来完成。于是，我们会提出很多的需求，要做很多的功能。

如果没有用技术去实现一个功能，我们好像都不能再去推进什么事情了。所以，我经常开玩笑的说，整个互联网已经快变成了劳动密集型产业了，稍微上规模的互联网公司，都有超级多的工程师。这些工程师还经常需要加班。

核算成本是一个看似跟产品设计、跟体验设计、跟技术开发没什么关系的事情。所以，很多工程师写了很多代码，这些代码很少发挥价值，这是个很悲哀的现象。

4.

我们偏爱铸剑，但是很少磨剑。同样的，我们偏爱开发功能，设计功能，但是，很少持续运营功能。

一个产品在推进的过程中，很少去合算成本。反正做功能是一个很简单的事情，有想法了，有方案了，就可以去开发了，再激进一点，需要很快这个功能就可以出来，所见即所得最好。

一个功能做出来了，发现之前想的不太对，不愿意去运营，也不想迭代。那就继续再去做功能，反正做功能是一个简单的事情，有想法了，有方案了，就可以去开发了。

产品重要，但是，持续运营要比产品更重要一百倍。不要随意的满足一个用户提出的要求，因为，每一个用户的要求，都可能会是一个包袱。

5.

要转载我的文章，请带上作者名称，原文地址的超链接，不允许修改我的标题，不允许删减修改我的内容，包括错别字的修改！如果你无法全部满足上面3个要求，请不要转载，欢迎大家举报。

2011年11月左右，FB发布了新的ios和android客户端，其中一个重要的变化就是导航模式的变化，推出了新的抽屉式的导航，同时强化了对Timeline的展示。

FB推出这种新的导航模式不久，Gmail的ios版本同样采用了这种导航模式，再之后path 2.0版本也采用了这种抽屉式导航并将其演变到极致。至此，这种抽屉式的导航模式迅速窜红与ios产品设计中。

我在2012年7月曾经对抽屉式导航做了总结，在「说说抽屉式导航」中我认为，大部分APP会使用抽屉式导航，核心原因是为了突出核心功能，将其他的功能隐藏掉。

现在来看，这个说法并不完全对。2011年到2012年，是中小屏幕移动设备占绝对主导的时代，中小屏幕，单手完全可以操作，不存在太多的操作盲区。同时，中心屏幕使得可以展示的内容有限，所以，抽屉式导航是最合适的做法。将导航收缩到一个入口，放在左上角最显眼的位置，用户操作也没有困难，其他核心的内容直接显示出来。

2012年之后，大屏幕成为移动设备的一个新趋势。一方面手机从一个单一的工具，逐渐演变成人们生活的一部分，不可或缺的一部分，用户在手机上处理的事务越多，使用的时间越长；另一方面，屏幕尺寸和内容消费效率及阅读舒适度极为相关。所以慢慢的，手持舒适度和携带便利在整个产品设计众多决策里面的重要排序便没有那么高。

所以，我们看到4寸屏、5寸屏越来越成为主流，尤其是iPhone6和iPhone6 plus的推出，大屏幕手机时代就这么不可阻挡的来了。有一篇老外的分析，点击这里查看。

手机屏幕越来越大，带来了哪些问题呢？

最简单直接的就是，内容显示变多了，但是，单手操作变难了。曾经有报告显示，49%的用户是单手操作手机的，现在，是改变单手操作的设计的时候了。

这张图，非常直观明了的告诉了我们，为什么抽屉式导航衰退了。因为，一个需要被经常操作的入口，现在，处在了操作盲区。

那么，伴随着抽屉式导航的衰退，在大屏幕时代，该如何去设计呢？这是每个产品设计师面临的一个新的思考。我有几点感受，可以分享出来

1、手势操作将会变的更加重要。

Android上有单独的back键，而iOS的返回一直依靠左上角的导航。大屏幕下，iOS的左上角点击返回将非常低效，在屏幕边缘右滑返回是最高效的模式。另外，针对信息流类产品，点击顶部迅速返回到最开始的信息的模式，也是一种高效的交互。阅读类产品可以考虑使用双击关闭这类的手势交互。

相应的，一个产品统一使用上滑、下滑来进行导航的产品将会更多。

2、底部Tab模式导航重新受追捧

实际上，底部Tab模式导航在iOS和Android上一直是「最安全」的一种导航模式，他不怎么出彩，但是绝对不会犯错。在大屏幕时代，底部Tab模式的导航更能适应，也更好设计。

3、浮动导航入口有可能出彩

在path的3.0版本，那个浮动在左下角的「+」号曾经一度流行。在大屏幕时代，这种浮动的入口很有可能出现优秀的设计。

4、将提交类操作按钮，放在弹出的键盘的顶部

这个模式，在Android中较为常见，但是同样存在不同屏幕的适配问题，需要仔细考虑。

5、语音交互，谨慎看好

语音交互，始终感觉没有一个好的使用场景。

「专注、极致、口碑、快」，这是小米神话中传播最广的一则口诀。

人人都喜欢极致，因为极致代表着完美，代表着用心，没有人不喜欢完美，所以人人都喜欢极致。

不过，在夜深人静的时候，我也会反思一下，我们是不是中了「极致」的毒。世事无绝对，产品设计尤其如此，对极致的狂热追求，在很多时候，会掩盖一些更本质重要的东西。

今天这篇文章是一位工程师写的，很难得的看到从工程师的视角，有人能反思一下目前互联网圈子对极致的过渡崇拜。

在乔布斯的时代，其实，乔布斯说的对多的观点应该是，「It just works」。我认为，这才是我们应该推崇的产品理念，是一个更环保的产品理念！

从一个产品架构开始，到一个产品功能，到实现功能所需要的代码，都应该考虑是否环保。环保的产品是恰如其分的可以工作，环保的代码是在当前的那个情境能达到运行状态。

在移动互联网时代，摩尔定律已经失效，这意味着更快的发展，更快的变化，更多的不确定性在等待我们，所以，不要制定遥远漫长的工作计划，如果做不到高瞻远瞩，那就尽可能把最重要的功能实现，保证系统可运行。

说白了，这个世界上，存在某种“极致”的产品吗？我认为不存在极致的产品，甚至不存在有着极致倾向的产品。

“代码是为产品服务，产品是为用户服务的。”这是一个非常简单直接的道理，但是这个道理在纷繁复杂的当今社会，竟然被各种花花绿绿五光十色的词汇所裹挟与扭曲，忽视用户，忽视产品生命周期，追求虚无缥缈的所谓“极致”与“完美”，出现这样的苗头其实是非常令人诧异和心痛的。

其实，“极致”从来都不是产品需要具备的品质，甚至从来都不是成为产品的开发倾向。产品的天性，只是迎合消费者的需要，体现技术的价值而已，无他。

— 点击这里可以查看原文，略长。

 

每年都要有一次总结，这事儿坚持了好几年。每年都是到最后一刻才想起来，今年没忘记，正好写完一篇跟团队小伙伴的分享，索性直接贴出来，当做总结吧。

—

hi，亲爱的小伙伴们

本来想着赶在12点之前写完这封邮件的，但是到家就12点了，所以，硬生生的把标题又改了。

作为产品部的一员，我特别的希望能跟大家每一个人做最充分的沟通，特别的希望这个部门里的每一个人都能快速的成长，有所收获，快乐的工作。

但是，时间太有限了，所以我没能实现跟每个人都1on1一次，至今，我还没有跟UED的同学们1on1过，在接下来的日子里，我努力跟大家一对一的交流。

我觉得我们都应该感到很幸运。我们所处的这个行业，站在了风口上，我们的订单和用户每天都在快速增长。在一个激烈的战场中，顶着前方的炮火前进，这是最快速的成长方式，这也是最刺激的职业生涯，这是我选择加入易到的最核心的原因。

同时，我们也应该有足够的危机感。刺刀见红，这个行业的玩家们都在肉搏，这是最坏的年代，也是最好的年代。在战场上，只有顽强的人才能活着，只有学习能力足够强的人才能最终胜利。

思考了很久，最终决定写下这封邮件，有些话，想跟大家说说：

我很早的时候就意识到，我下一份工作的薪水与待遇，是由我上一份工作决定的。所以，我把每一分工作都当成是自己的一次修炼，我在思考的事情是，我能在这份工作里让自己成长多少，让自己的段位提升多少。我希望所有的小伙伴们都能有这个意识，你是在为自己的下一份工作拼命的增加筹码。互联网是一个相对公平的行业，产品与设计更是一个用成绩说话的职业，这一点我们必须意识到。

这就要求我们必须有策略的成长，我有几点建议：

1、我们必须足够努力才能让自己看起来毫不费力

设计师也好，产品经理也好，基本上不用拼天份，拼努力就已经足够可以笑傲江湖了。我以前觉得自己挺努力的，后来发现一位我敬重的前辈居然可以做到每天工作17个小时，我只有默默的继续努力了。世界真特么的可怕啊！

2、我们必须有很强的学习能力

每一次功能设计，每一次界面设计，都是一次锻炼，在每个锻炼之后，我们都应该有所总结，这次哪里做的好，哪里做的不好，为什么做的不好，我该如何让下次做的更好。只有不断的自我总结，自我反思，才能形成属于自己的方法论。
只拼努力是不科学的，有效的努力才是王道。

3、独立思考，做正确的事情

在百度PM文化中，有一句非常经典的话，叫做「跟多数人商量，听少数人意见，自己做决定」。
我们必须要先判断哪些事情是对的，必须对一个需求，一个设计先有自己的判断，有自己深刻的理解。然后才去做设计，做产品，而不是拿到了一个需求就开始做，做了一半被人PK回来了。
「不唯上」应该是我们产品部门最核心的价值观，另一个核心的价值观是，我们只做对用户有价值的事情。
我们应该用我们对用户需求最精准的把握，对用户需求最深刻的理解去跟需求方探讨，去跟老板PK。我们之所以背动，核心就在于我们没有深刻的去理解，去思考。

4、优化流程，正确的做事

我们应该针对每个case去做总结，通过流程的优化，规避多次犯同样的错误。我们也应该根据自身的特点，建立适合自己的工作流，不断提升效率。
傅红雪是个瘸子，但是他依旧是个绝世高手，因为丫通过苦练找到适合自己的刀法。

5、我们必须学会合作

这是一个需要合作的互联网，这不是一个逞个人之勇的年代，合作才能创造更多的价值，合作、学习才能让自己成长的更快。
我们一再的墙掉，我们内部一定要做到足够的信息互通，一定要建立充分分享的意识，只有这样，我们才能更加强大

6、不要等，要快

我最反感的就是你们跟我说，「等明天再看看」，为什么要等到明天？明天世界会有很大的变化吗？为什么不是现在呢！
一旦我们决定了，我们就应该迅速的展开。做产品，怎么做都是错的，唯一不同的是，谁做的更快，谁能更快的从错误的坑里爬出来。不要等，等待是loser才会用的词儿！

7、一定，一定要好好锻炼身体

身体，始终是我们最值钱最珍贵的。多锻炼身体，让自己强壮起来，这样，你才能更好的享受你的成功。

就写到这里吧，记住，我亲爱的小伙伴们，「对贡献充满激情，对回报充满信心」。

– kentzhu，2014.12.30 0：50

从事产品设计行业有些年头了，发现还是会不断遇到新的问题，不断强迫自己去思考，去总结，这是这个行业最吸引我的地方。并且，我也时常翻看自己之前的总结，发现，总是能从过去的总结中重新寻找很多灵感。也许正是这样的感觉不断的推动着自己在往前走吧。

产品设计3件事，搭架子、定流程、抠细节。

搭架子

产品设计工作，首先是一个创造的过程。依据设计者对市场的理解，对用户的理解，对战略布局的理解，去搭建一个生态系统，或者换个角度看，就是一个虚拟的王国。产品架构是最底层的设计，这会直接影响到后续产品的不断发展路径。

我比较喜欢用一个词叫做「产品的边界」，任何事情都有边界，产品也一样。产品边界的一个直观外在体现就是产品的架构。

比如，在12年的时候，我在做快捷酒店管家的产品。快捷酒店管家的起源是一张便签纸，连长在上面画了一个原型，地图上面插几个小牌子，牌子展示的是酒店的名称，这就是快捷酒店管家最早的产品框架。

我对这个产品框架做了完善，增加了个人中心的入口，增加了展示列表的入口。但是，架子没有做改动，就是以地图为核心，展示附近的酒店。

现在回头再看这个框架，是有明显的边界，其根本的限制就在于地图的使用。地图占据了用户界面的绝大部分内容，这些内容看上去很直观，但是实际上展示信息有限。所以，如果快捷酒店管家要做更广阔的探索，必须要改变这个架构。

同样的，uber作为一个用车应用，也使用了地图作为其基本的产品框架，而国内的打车软件滴滴和快的也都使用了这个架构。这个框架对uber而言，有更多的限制性，可以预见的，在不久的将来，这个架构将成为限制其产品扩展的一个巨大问题。

uber用地图做为主要界面展示，揣测一下，是试图达到这样几个目的，将车辆的位置实时在地图上展示，可以突出很多车，且车就在附近的感觉，建立用户的信任感。当只有一个业务的时候，这个框架非常适合，但是，扩展性就差了很多，我们可以看到，uber目前主要在页面的下方，与地图并列的部分展示不同的车型，不同的服务的，在某些地区，服务特别多的时候，uber都开始采用双行选择的展示方式了，很臃肿。可以预见的，国内学习uber的滴滴和快的，肯定会多品类的扩充，肯定会遇到一样的尴尬。

另外一点，车辆在APP的地图里表现为一个图标的时候，因为颜色的限制以及形状的限制，如果密集展示的话，会导致地图非常的难看，密集恐惧症啊。

 

相对而言，易到用车目前的产品框架在扩展性上则强了很多。易到用车抛弃了地图模式的产品框架，在一开始的时候就使用了服务细分，并且下面的模块也可以延伸更多的细分服务类型。在非地图的产品架构下，甚至扩展类目压力都不是很大。

所以，搭架子是一个很基础的产品工作。一个好的产品框架需要同时具备易用性、稳定性、扩展性。

搭架子是一个如此重要的产品工作，以至于很多产品直接放弃了这个工作，搞起了拿来主义。所以，我们看到在中国，所有的电商产品、在线旅游产品基本上都是同一个产品框架。如果不是用色和logo的区分，你几乎分不出来哪个产品是哪个…..

搭架子的外在表现是产品的界面结构，这是一个比较容易被看出来的架子，而另外一个更重要的架子则是业务架构，业务如何通过技术作用产品。

比如说，你不能让业务之间有太多的耦合与相互嵌套，共用一套流程看似很快，坏处也显而易见，未来你想改动任何一个流程，都会影响到所有的业务；你也不能把同一个业务体系里的功能，分散到各个业务流程里去，应该建立一个统一的系统，通过调用的方式去支撑不同的流程，比如风控、个人信用体系等。

业务层面的架构与产品层面、技术层面的架构需要相互作用，最终确定产品的边界。

定流程

框架一旦确认下来，接下来一个很重要的工作就是确定流程。这里的流程表现在产品上就是产品流程，而背后驱动的则是业务流程。

在做快捷酒店管家的时候，我们没有依照现有的流程，完全从移动出发，从需求出发思考了一个新的流程。包括，不需要用户登录，直接用手机号作为帐号，密码就是每次的短信验证，最大限度的提高流程效率。默认就是用户自己给自己预订，预订就是一间房，尽量弱化分枝流程等等。这背后都是一个核心的业务逻辑在支撑，马上订，立即住。

uber的业务模式下，追求了极致的快，所以，uber使用系统发单的模式，用户点击使用，系统按照规则给用户派发一辆车来。而易到用车的模式则相反，用户点击使用，系统会给出一些司机，用户自己来选择司机。

一个系统决策，用户没有决定权，一个系统推荐，用户有完全的决策权。这2个流程下，2个产品的不同价值观与调性就出现了。用车这件事，并不是一个特别标准化的事情，因为用车背后的意义其实是服务，服务无法标准化，或者说，标准化的服务的边界很显而易见。再一点，用车这件事，核心并不是快，而是有车，其次是这个车符合我的要求。因为专车不像是出租车那么标准化与深入人心的信任感，所以，在使用这个服务之前，需要给用户建立信任感，建立信任感的方式就是让用户自己去选择。

这个选择，虽然是用户去点击了一次，但是并没有拖延用户太多的使用时间，在效率上损耗不大。

同样的，为什么uber那么强调信用卡付款，甚至在注册的时候必须要求绑定信用卡，而国内大多数的专车应用则把这个步骤放在了后面？2个完全不一样的业务思路，高门槛控制新用户，进入之后第二次使用流程超级顺畅，下单，来车，下车直接走人。

产品的流程必须追随着业务的流程走，然后通过交互方式的优化来提高用户的使用效率，这是产品的第二步。

抠细节

我们看到太多平庸的产品，根源就在于细节不到位。我最痛恨的就是PM对我说，我觉得这个也可以吧。一个也可以吧，心中的那口气就完全散了，再也做不出惊艳的产品。

不注重细节的产品可以生出来，但是肯定活不下来，不注重细节的产品经理也永远都只会是个功能经理。

 

先看看日常生活里的例子：

小卖部挂着一个牌子说：本店有新鲜羊肉出售，10块钱3斤。其实，只需要说，「新鲜羊肉，10块钱3斤」就足够了。

饭店门口经常出现的招聘信息：本店诚聘业务人员，男女不限，吃苦耐劳优先，有意者请联系，电话：13800138000。这里的’有意者请联系’是不需要的。

卖水果的叫卖到，「新鲜苹果，又大又甜 ，不甜不要钱」，通俗易懂、卖点明确。

我的朋友keith说，「一个写不好文案的产品经理，就像一个瘸了腿的武士」。

现实中看，能写好文案的产品经理确实是少之又少。文案的几个层次，把事情说清楚、不啰嗦、传递情感。大多数产品经理倒在把事情说清楚这里了。

把事情说清楚，第一看用户所处的场景，其次看语境。

互联网产品里随处可见的「确定」按钮是产品经理最偷懒的表现之一，这些按钮的名字完全可以根据不同的场景进行扩展的。我写完一篇文章，那个提交的按钮如果是「发布」或者「预览」会不会更清楚些？我修改了我的个人资料，那个确定按钮如果是「更新资料」会不会更清晰一点？

另一个表现就是随意造词或者搬词到产品里来做表述，在我的wordpress后台，「仪表盘」这个汉化的翻译我一直很困惑，这到底是个啥？

当然，近年来，有另外一个趋势是用图标代替文案提示了，比如用手机的图标告诉用户这里是写手机号的。这算是一种进步了，图标可以传达出这个要素的内容，也让页面更美观。但是，并不是所有的页面元素都可以同图标代替的。图标的表现方式只适用于大家都能理解的元素，并且图标并不利于扩展。

所有的文案都应该有特定的语境，结合特定的语境，有些文字是可以省略的。

比如上面的例子，你的门口挂的牌子，绝大多数的时候都应该是你的店里卖的东西，「本店有售」是一个不必要的累赘；而如果对方无意联系的话也不会没事儿拨打你的电话跟你扯淡。

啰嗦的文案很招人烦，同时也会让文案没有重点，浪费用户的时间。

如果一个人正在开车，你发了一段很长的文案出来，他哪里有时间看？在《汉武大帝》里，霍去病建议汉武帝给军士的诏书要越短越好，越通俗越好，士兵将士都是大老粗，哪里看得懂那些文绉绉的词汇。士兵们最在乎的是什么？皇帝奖赏我还是惩罚我，奖赏了我什么，惩罚了我什么，其他的修饰词汇他才懒的在乎。

同样的，在大多数产品，尤其是工具性产品里，用户在乎的就是你告诉他结果和该如何操作，其他的事情，不是他关注的对象啊。简单粗暴，直接明确才是最为重要的部分。

在移动产品上，如果要发布相对较长的文案内容，尽量用短句，一定要注意分行，先说结论，然后再做解释。

在短信通知上，尽量把突出的信息放在前面。比如一个短信验证码的内容，要保证验证码在系统消息栏直接展示出来，用户的操作场景是点击了「获取验证码」按钮之后，在那个界面等待输入呢，抬眼看到系统消息栏有内容了，记下来验证码，直接就在输入框输入了，这样的效率才是最高的。

用更少的元素直接告知用户结果，不需要用户自己去计算

不啰嗦的另一个表现就是，如果一个元素就可以让用户锚定一个信息的话，就不要用两个，两个信息，看似可以让用户更多的对比与了解，但实际上是增加了用户的认知成本，用户需要的是你直接告知他结果。

上周的时候，我跟同事探讨了一个设计。在产品上，我们需要通过一个元素来告知用户，给他服务的人什么时候可以到达。在产品上，使用了「距离」和「到达时间」2个元素。

我认为，2个元素太多了，不直接；我们应该用一个元素，给用户明确的预期就好了。所以，我选择只展示时间就好了。

同事反驳说，我们的时间计算的不准，所以我们用2个元素来同时让用户锚定。但是，再深入看，时间是根据距离计算出来的，距离并不是直线距离，是系统计算出来的路径距离。

那么，从结果上看，这2个元素是关联的，如果系统不准确，2个都不准确，放2个不准确的元素，更没有意义；同时，从用户的认知上看，时间是最直观的，其次是距离。如果时间的计算没有路径距离准确，我只能退而求其次的只显示距离了。（这个问题的根源在于技术的限制，产品做了妥协）

传递情感是一个更高层次的文案功底，一般出现在类似宣传页上，核心目的是引起用户的共鸣，下载或者使用或者传播你的产品。我曾经在内部做了个比喻，产品的页面分为几类、引诱用户下载的、引诱用户下单的、引诱用户传播的，不同的类型下，文案的方式不一样，但是背后的核心都是要找到引发用户共鸣的那个最直接突出的要素。

文案的练习是一个长期的过程，我的经验有这样几个：

• 坚持写作，写日记、写博客、写邮件；
• 公开演讲，向其他角色介绍你的产品方案、团队内部分享；
• 读书，读世界文明的法律文件、读调查报告

与一个同行闲扯，不知怎么地聊到了最近一个莫名其妙的问题叫做PM四件套。

在经过一顿调侃之后，我抽了颗烟，憋出来一句话，「产品经理应该少用甚至尽量不用PPT，善用多用Excel，常用纸跟笔，不断训练用口。」

1、少用甚至不用PPT

总感觉使用PPT的人都无法避免的陷入形式大于内容的怪圈。当然，工具本身没有错误，只是使用工具的人无法克制自己。

同时，我深信我是一个不太能控制好自己的人，所以，我选择少用甚至不用PPT。

（用keynote来做交互是另外一个高逼格高效率的玩法，另说）

2、善用多用Excel

说起这句，肯定会有人第一时间就联想到了数据的重要性什么什么的。并不是这样的，这不是我要表达的重点。

我之前大概的表达过一个观点，是在怎么写好需求文档的时候，我说，我们应该使用一个更好的方式，来同时兼顾阅读+操作。怎么个意思呢，就是说，研发的人可以一边对照你的需求文档，一边直接开发，而不是先翻到这里看半天，再翻到另一个地方，然后再来开发，这样效率会低下。

同样的，在需要从多个维度来描述一个事情的时候，Excel是最好的方式。

比如，甘特图是最好的表述计划的方式。同样的，需求列表等也可以用Excel来极好的表达。

当你需要从多个维度来描述一个事情，或者将一些事情划分成多个维度来进行展示的时候，试试Excel吧。

3、常用纸和笔

在产品经理这个行业里，永远都在讨论的一个话题就是，用什么来画原型。

年少不懂事的时候，尝试了无数个工具，最后，还是回归到了纸和笔。

将脑海中的想法输入到电脑的效率还是不够高，相比起来，直接通过纸跟笔的方式输出更为高效，而且局限性也更小。

一直梦想着会有一款只能硬件，在纸上直接书写，然后同步到电脑里，可以实现无缝的衔接，那就足够酷了。

4、不断训练用口

说服力，表达技巧是产品经理这个角色极为重要的外在表现。我观察发现，很多时候我们的沟通是非常低效的，根本原因就是表达的问题。

不知道怎么把一个事情按照一个好的方式表达出来，然后大家就讨论啊，讨论啊，讨论到很艰难的时候才发现也许大家讲了半天讲的不是一个事情。

表达就是讲故事，只可惜我们很多时候讲的故事太乏味了。

这里，再次推荐《金字塔原理》这本书。

 

对于一个产品来说，没有错误的功能，只有没应用到正确的场景的功能；

对于一个产品来说，从来就不是一个创造性的功能就能成功的事情。

一款产品，往往是从一个相对创造性的功能开始的，他可能前期依靠这个功能能成长起来，但是，如果不具备整合能力，他所创造的功能就会很快被整合走，最终，产品走向死亡。

微信的整个发展历程，就是一个整合的过程。

语音对讲，附近的人，摇一摇，朋友圈，基本上都是整合来的。

以上这些功能，之前都是某个产品相对单一的功能，单一的功能具备一定的打击力度，但是，不足以支撑其壮大。

经过微信很强力的整合之后，很优雅完美的协作发力，威力大增。

整合，让系统更强大，整合，也让产品更成为一个体系与生态。

我们再看2014年的WWDC，Apple走向更强的整合。

iPod的时候，苹果实现了软件更硬件的第一次整合；之后的Mac、iphone都是这个整合的思路。

而这一次，Apple开始实现跨设备的整合。这种整合让整个苹果的生态体系更完整，更完美。

然后，我们把再放开一点看。之前搜狗的王小川提出「三级火箭」的思路，后来金山的傅盛提出「矩阵」的思路，其实，都是一种整合。

产品内部，通过功能模块的「整合」让产品更强大；企业内部，通过不同产品的「整合」形成更高的壁垒。

整合，不是简单的功能堆砌，而是一种有机的组合。

坊间经常嘲笑说，大部分的产品经理是功能经理，其根本的原因就在于，功能与功能之间不能形成整合。

堆砌，会让产品看上去很臃肿，臃肿且不具备相互作用力，那就不牢固。整合，让产品看上去更协调，协调且相互呼应，坚不可摧。

注：这是一篇翻译的文章。经过翻译者授权，转载与该博客。

原文：How Spotify builds products

翻译：@Omnibingo

产品开发并不简单。事实上，大多数产品开发努力到最后都失败了，并且最常见的失败原因就是开发了错误的产品。

Spotify是一个瑞典的精益创业项目，它同时保持着一个很棒的产品交付记录。他们的产品广为用户和艺术家喜爱，并且像病毒一样传播开来：他们有超过2000万活跃用户，500万付费用户，并且用户数量增速迅猛。举一组数字说明问题，Spotify在美国这样一个已经充斥着不少音频传播软件提供商的海外市场，只用了1年时间，就把付费用户数从0上升至100万。

Spotify的愿景是在任何时候给你带来对的音乐。这意味着它将无限地接入全世界的音乐，并且在Spotify中分享音乐会十分容易；并且音乐被分享和播放得越多，那么音乐的创作艺术家们就可以获得越多的钱。几年前，Spotify以一个音乐播放器的身份诞生，如今，他们的产品演变成一个发现新音乐和在艺术家和粉丝间建立直连的广袤的平台。

这个产品的设计理念是简单、个性、有趣。甚至连Metallica（美国乐队名），这支长期以来被认为是音乐流服务的死对头的乐队，现在都称Spotify是“目前最好的流服务”并且“被它的方便所震精。”

但仍旧存在一个悖论：就是像Spotify这样成功的公司当然只希望产出人们喜爱的产品，但是只有在产品上线之后，他们才知道人们到底喜不喜欢这个产品。

那么他们是怎么做的呢？

这篇文章的目的就是给Spotify的产品开发方法做一个高度的概括总结。

概要

我们的核心理念是：

• 我们创造革命性的产品，同时通过早期低成本的原型设计来控制风险。
• 我们直到品质过关了才会发布产品，即便已经错过了发布日期。
• 我们通过产品发布后虐心地一次次tweak（可理解为“调整优化”）产品，来确保我们的产品从发布起就表现优异，并且到后来惊艳得令人称奇。

所有主要的产品计划都经历4个阶段–“Think It（思考）”，“Build It（构建）”，“Ship It（发布）”，“Tweak It（优化）”。下方为一个关于从产生灵感到形成产品的整个流，以及过程中的各个阶段会产出什么玩意儿的图示。

• Think It（思考） = 整明白我们在打造何种产品，为什么。
• Build It（构建） = 开发出最小可行性产品(MVP)
• Ship It（发布） = 将产品向全部用户逐步慢慢铺开，同时进行数据检测并不断改善。
• Tweak It（优化） = 持续不断地提升产品。这是产品的最终状态，产品不断优化直到生命周期终止或产品重构（= 回到Think It）。

Spotify 拥有超过30个 squads （可理解为“小分队”，下同）和许多不同的产品，为了让公司的其他人都了解公司正在发生什么，我们用一种产品状态图来表示每个产品分别处于哪个阶段。大致如下：

我们同时也面向一些squad试行预测机制，这些squad对产品何时将会到达下一个阶段有一个日期时间上的预期，并对提供的这个阶段晋级日期范围（日期X-日期Y）负责。

为什么是这4个阶段？

构建一个错误的产品是最具风险的事情–错误的产品无法取悦我们的用户，同时无法提升用户数以及用户留存等好的指标。我们称这个后果为“product risk（产品风险）”。

这个4阶模型帮助我们压低风险，并且快速做出产品。下面这个图表可以看出在每个阶段产品风险是如何被降低的，同时可以看到每个阶段是如何地成本密集。

我们可以看到，Think It这个阶段可以以很低的成本降低风险。同时我们也看到我们为什么要尽可能缩短Build It这个阶段（因为它消耗很高的运作成本却几乎无法带来风险的降低）。而在Tweak It阶段逐渐降低的运作成本表明，随着时间推移，产品并不需要进行尽可能多的更新，squad们可以开始继续去做其他事情。

每个阶段的周期变化多端，上面的这个比例只是一个例子而已。总的时间同样也是会变的；有些产品从孵化到产出也就是几个月的事情，而另一些产品可能要花去大半年甚至更多的时间。但是在每个阶段里，产出（即便只是内部的）都是在一个可持续性的基础上完成的。

好，现在我们仔细来研究一下每一个阶段。

Think It

产品灵感在任何时间，在公司的任何人身上都可能诞生出来。大部分灵感都是去提升现有的产品（也就是“tweaks”），这种情况squad们只需自己实施和发布即可。

这里说的“Think It”阶段指的是某人想出了一个全新的产品创意，或者说去重构一个现有产品。

如果管理者也认为这个想法是值得付诸实践的，那么一个小型的“Think It”squad随即成立。典型的“Think It”squad一般包括一个开发者，一个设计师和一个产品经理。他们的工作就是去完善产品描述，同时构建一个足够吸引人的产品原型。

• 产品描述通常是一个用来回答如下问题的一个简短的文档：
• 我们为什么要去构建他？谁会从中受益，如何受益？
• 我们期望这个产品去提升哪些关键指标？这些指标可能关于播放了多少流音乐，下载量有多少，注册量有多少等等。
• 我们的预期是怎样的？我们如何去判断这个产品是否成功？
• 产品会带来“阶段性的改变”（阶段性改变指的是，在预期中这个产品将带来至少双倍的既选指标上的提升）吗？如果在我们的期望中，这个产品只是较小地提高了指标，那么要去构建它，最好有更强有力的理由，比如一些战略方面的原因等。

产品描述不是必备的文档，也不是所谓的项目计划。它不包括特性清单、预算、资源计划等等。它更像是一个用数据说话（数据驱动）的意愿陈述。

产品描述中最重要的部分就是故事性描述。我们要向世界讲什么故事？新闻稿又是什么样的呢？

举个栗子，Spotify的“Discover（发现）”标签是最近的一个产品。介绍一种发现音乐的更好方式。看！你最喜爱的艺术家刚刚分享了一首歌给你。我们让艺术家们和粉丝们从未如此靠近过。喜欢一个艺术家？那就去follow（关注）他，并与朋友们分享你的新发现吧。

另一个例子是有“Radio you can save（你可以保存的电台）”说法的免费移动电台。这种情况下，我们会用谷歌的关键词广告去尝试几种不同的描述，看看哪种描述最吸引人。

关键在于，这个故事性描述在产品构建前就写好了！这样我们可以在产品构建前就确定这个产品足够吸引人。

另外，“Think It”squad会构建许多不同的原型来传递产品的感官上的体验–同时会有“低保真”的纸面原型和“高保真”的可运行的原型（上面跑伪数据源之类）。这时几个内部焦点小组会用来辨别哪一个原型最好地传达了它的产品精神（那个故事性描述），直到我们不断缩小范围，最后只剩下几个胜出的原型。

这是一个没有截止日期的迭代过程。只有当我们可以拿出一个足够吸引人的故事性描述和能够传达出它的可运行的原型，这个产品才是值得去构建的。我们无法决定这个产品前期会花去多少时间。

完成的定义：Think It阶段直到管理者和squad共同认同这个产品是值得构建的（或者这个产品永远都不值得构建，故应该被舍弃）则标志完成。

这是一个主观上的决定，它并没有硬数据作支撑。Ship It阶段才会产生硬数据，所以我们希望尽可能快地到达Ship It阶段。

Build It

在这时，Think It squad开始扩张，以组建一个更加长时间存在的squad（有时是好几个squad），这个squad具备开发、测试、发布一个真实产品的所有需要的能力，这个squad会长期负责这个产品，不仅仅是在Build It这个阶段。

Build It阶段的目标是构建一个MVP（Minimum Viable Product，最小可行产品，注释见上文），即一个对于发布给外部用户，传达某些产品理念来说已经足够好的最小可行产品。这个最小可行产品利用一些例如Scrum、Kanban以及eXtreme Programming的敏捷开发方法迭代构建。

一方面，我们不希望在发布产品前构建一个十分完备的产品，因为这个过程会延迟我们获取数据的时间。在我们把真实的软件发布给真实的用户之前，我们是无法确定我们是否处于正确道路的，所以我们需要尽可能快速到达Ship It阶段。另一方面，我们不希望产出无用的或令人沮丧的产品。人们总是期待Spotify产出优秀的软件，并以此来给我们打分，即便我们说目前软件仅仅是beta版本或alpha版本。

于是squad需要找到可以实现最基本的narrative（故事性产品描述，产品精神），并且可以取悦用户的他们可以做的“最小的可能的玩意儿”。或许形容它的一个更贴切的词是Minimum Loveable Product（最小可爱产品）。自行车对于没有更好的交通工具的人来说是可爱的有用的产品，但是距离它的升级版，摩托车的差距还很大。但我们的确需要实现基本的产品描述，产品精神。否则，我们的判断标准就会被误导：“嘿，我们做出了一个轮子，并且没有人去用它，所以说这个产品是失败的，我们不应该去打造自行车的剩余部分了！”

Think It和Build It阶段的关键不同在于，在Think It中，我们尽可能快，可以走遍各种捷径并且不用担心技术上实现的质量；而在Build It中，我们要写产品级的代码并且需要保障质量。

完成的定义：Build It阶段，直到管理者和squad共同认为目前这个产品已经实现了最基本的产品定义，并且对于开始发布给真实用户已经足够好的时候标志着结束。

面对Moment Of Truth（真理到来的时刻），我们已经准备好了！

Ship It

Ship It阶段的目标是逐渐将产品铺开给所有用户，同时进行数据检测，确保产品在自然环境下，也能够履行它的设计初衷。

Squad一开始只将产品发布给全部用户中的一小部分（一般1-5%），以便收集数据。
如何将这些用户的行为，相比于其他的95-99%呢？

还记得吗，我们在Think It阶段定义了一些关于这个产品的预期，现在我们可以最终测试一下这些预期是否依然保持正确，并且对产品进行一些必要的迭代提升。一开始我们应该不太容易一下就做对，在这个模型中花的力气也有不少是不必要的。

当管理者和squad共同认为产品正在小范围的用户群中发挥预期的效果，我们就可以逐渐地在更多的用户中铺开产品，同时仍旧需要做数据监测和产品提升。这可以给我们时间去处理一些业务方面的事物，例如硬盘容量，监测，脚本部署，扩展性等等。

完成的定义：当产品对所有用户都可用时，Ship It阶段完成。

注意一下，这时并不意味着产品已经“feature complete（特性、功能完全）”，完成了Ship It阶段只是意味着产品（最小可行产品+必要的改进）已经被100%铺开而已。其实并没有所谓“feature complete”的说法，因为产品即使在Ship It阶段之后还会持续进化。

Tweak It

这是最为关键的阶段，因为产品们在这里抵达重点（除非在路上他们被抛弃），并且产品在这里花掉它生命周期中的大部分时间。

产品现在已经产出成果，并且对所有用户可用。虽然在某种程度上它已经在Ship It阶段证明了自己，但总还是有很多提高的空间。Squad继续展开实验，在跟踪数据的同时，进行A/B测试以及改善产品，这可以包括重要的新特性也可以是较小的调整。

然而，未来的某一天，squad可能会到达一个产品的收益递减的点。这时产品已经很好，最重要的改进已经完成，并且改进新特性带来的收益率也将不再那么吸引人。转看监测数据，新特性和改进也不见得会带来很大程度的飞跃。

那么这就意味着产品已经趋近于一个“极大值”了。

在这个时候squad和管理者就会讨论：我们是不是甘于止步于这座山的山顶，或者去寻找一个更高的巅峰？在前一种情况下，squad可能会逐渐地转移到其他产品的工作上去。在后一种情况下，squad可能会回到“Think It”阶段去考虑重构这个产品或者让这个产品去开拓国际化道路（或者至少是一个更高的山峰…）。

这种情况的一个实例就是spotify.com这个网站。该网站在2012年夏天我们决定去重构它之前已经修修补补了4年。现在这个网站已经在以一种完全不同并且出奇高效地方式来传达Spotify的愿景。

总览图

最后的话

希望你能享受这篇文章！

如果模型中的某些部分让你觉得“我去，我已经早就造这些东西了，我们已经酱紫做几十年了好伐”，那么你八成是对的。这个模型所述并不是新玩意儿，屌玩意儿。它只是在讲述那些有用的东西–这玩意儿新老其实并不重要。我发现这种实例的结合还是非常振奋人心充满能量的，我也希望你可以在期中找到在你的环境中也有用的东东。

— 在Twitter上，有位哥们po了一张PPT的图，应该是这个主题的演讲，其中用一个更形象的图总结了什么叫「敏捷开发」，附录如下：