这篇文章是看极客专栏邱岳的产品手记 写出来的总结文章。不敢妄自菲薄的跟二爷比文采，本着把二爷的精神传递出去的想法写下了这篇。
顺便还写了一个app测评的设计总结产品设计Tips.

需求变更的前世今生

需求不会变更，变更的是实现方式
用户的需求大体来说是不会变的，只是产品经理对需求的理解。比如本来说训练一匹快马，后来说要变成造汽车。这里用户的真实需求是“更快的到达目的地”。

挖掘需求背后的需求
五问法，连续问五个为什么。比如上面说的造汽车，为什么需要更快的马？ 最后尽量去贴近用户的真实需求。而不是简单的根据用户所说的需求。

给需求流出时间
需求文档后给两天冷静发酵期----很多时间需求文档不够受重视，给的时间过少，或者情况紧急需求需要尽快落地，会导致需求思考不全面不彻底从而导致需求后期需要变更才能达到预期目标。

别忘了需求评审
需求思考之后叫上开发测试相关人员一起做需求评审，尽量多挑需求的毛病，此时挑出来总比以后踩坑的好。

具体比抽象更重要
需求评审时用具象的demo总是更能吸引人的注意力。提升需求评审各方的参与性。

变更时机的选择
开发前里面变更，开发过程中与开发沟通协调，上线前，不动原则通过运维处理。

让团队消化需求变更
让团队习惯敏捷开发，快速迭代。有计划的变更需求。

关于产品抄袭

被抄袭了怎么办？

摆正心态，泰然处之。抄走的都是表现，抄不走“气质”。不要把产品的护城河建在脸上。做有积累效应的支持。有条不紊，不要情绪化处理。

被抄袭了一定是因为产品有些某些亮点，或者方向是对的。而且抄袭者永远是跟随者，保持自己的节奏更新就不虚。要清楚自己产品的定位，特性是基于什么样的考虑。产品是为了用户服务的，思考自己可以解决用户的什么痛点，交互页面都是表象。内在才是核心。有效积累指的产品设计考虑数据的积累和用户的卷入。类似微信早期，因为朋友的加入更加无法脱离微信。对于抄袭，早日注册专利，通过相关法律手段对待恶劣者，但注意不要花大精力去对付抄袭者。我们要做的，只是做好产品，抢占市场。

如何借鉴灵感

不要像素级抄袭。脑子里带着自己的问题。追本溯源，知其所以然。跨领域跨行业借鉴。致敬与付费。

不要照搬别人的设计，界面或者文案等等。要带着自己的问题去看别人的设计，借鉴别人好的地方。最好的能做到去想为什么别人这里是这样设计的，背后的思考是怎么样的。有时候我们也需要跳脱出来去看其他行业或者其他的地方寻找灵感。有能力有机会的话要给借鉴着创造价值或者致敬，可以的话去付费。任何好的设计都不能被辜负。

关于产品规划

无用却必要

自上而下还是自下而上？产品规划不等于功能发布计划。好的产品规划从宏观和判断入手，尽量避免过多关注项目和特性列表。

自上而下，更利于公司资源的战略安排和协调，也方便战略安排在组织内部的沟通。而自下而上能够给团队成员更多的发挥空间，能够激发主观能动性。要根据不同的场景选择不同的策略。

产品规划做成功能发布计划很容易让员工失去参与感，也少了主观能动性。产品规划应该是做到上传下达。把握公司的战略规划，然后下发到各团队，在让团队内部做具体的调整。

留白与节奏

产品规划的留白。定期回顾和更新产品规划。产品规划到项目交付的节奏感。

产品规划要在时间和空间上尽可能的留白，时间上是为了产品经理的可信任度。空间上是让一线开发有更深的思考与参与。 产品规划也是需要定期回顾和更新的，根据当前完成进度和市场做对应调整。

形成稳定的节奏 tick-tock。定有固定的节奏，让开发更好的知道什么时候做什么事情。

产品经理的价值

在内部产品中找到产品经理的价值

内部产品就是说公司内部使用的产品，用户会离你很近，同时也会带来用户随时提需求，并且待着解决方案，很容易变成功能经理。

资源显性化，项目流程化，用户研究的最佳试炼场。
针对用户离得近带来的争吵或丧失信任问题，将所有的资料显性展示出来，对于用户提的需求放置到项目流程中。由于不配备专门的交互设计师，这时候反而是产品经理最接近交互设计的时刻。

不要变成功能经理。跳过方案寻求背后的动机和诉求。统一战线，成本收益一致。发挥强项，让技术帮助业务。
五问法要牢记。产品为业务服务。产品经理要去深入理解业务。

产品经理的影响力

建立信任是长期的过程。如何试错。要重视承诺，不要找借口。不要在不重视承诺的环境工作。
如何建立信任：被动完成任务，主动承诺，超额完成。
产品就是一个试错的过程，但是如何降低错误的影响：提前沟通把目的、逻辑、数据、可能的风险和不确定性因素都提前交代清楚。
错了就要认，不去找客观借口，找到真实原因，并且不要被错误打垮。
在一个失信不会受惩罚，完成任务不会被表扬的环境。趁早离开。

如何不被开发仇恨

打破思维的边界

加强沟通，互通有无。专程交代业务规划和产品价值。掌握技术概念和技术语言。
仇恨来源：产品经理注重为什么和做什么。开发想的则是怎么做和做什么。当沟通不到位产生分歧时。两方不能相互理解。作为产品经理要尽早跟开发沟通，提前公布信息。不要突然袭击。专程在闲暇时间多交代业务规则和产品价值，长此以往，让开发产生同理心。也需要掌握相关技术概念和技术语言，不要觉得什么都很简单，尤其要多了解非功能需求。

合作与共赢

全流程参与。多听工程师的意见。不要强迫工程师做评估。背黑锅和利益争取。互背KPI，同仇敌忾。建立良好的个人关系。
工程师尽早参与讨论设计，产品经理尽量晚的抽离项目。遇到项目问题尽可能的帮忙解决。兼听则明偏信则暗，鼓励工程师多提意见，并且公共的看待提出的问题，也可以碰撞出不一样的火花。不要强迫工程师做具体点的评估，尽可能模糊的给一个deadline。出问题时产品经理要积极的背锅，对于其他工程师的贡献要心怀感谢多帮其争取利益。产品经理要理解工程师的KPI在讨论的时候，也能多理解工程师的选择。多跟工程师交朋友，当你把工程师当成朋友，交流起来也会更加顺畅。

图文基本功

产品文档

BRD/MRD/PRD/U/FSD/产品原型/交互稿/Others
BRD是指商业需求文档，一般只在公司层大型变动时才需要。主要针对一直新的商业模式或其他。

MRD市场需求文档，交代市场机会，竞争情况，产品和运营策略和计划等等。

PRD产品需求文档，用得最多的一个文档。它一般是写具体的功能逻辑和细节。也可以吧MRD补充在PRD中。比如重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。

UC用户用例通常是以用户角度的完整功能单位为粒度，描述用户跟系统的交互过程以及系统的输出逻辑。最核心的部分是流程，通常会把主流程和分支流程分开描述，再复杂的业务，主流程一般都简明扼要，，所有的复杂度最好都放到分支流程里面去，分支流程里面的一些限制和规则。

FSD 是功能详细说明（Function Specifications Document)有时候我们也称作 FRD，我们经常说“写 Spec”，其实就是指它。这时的文档就偏向实现了，交代具体的数据字典，概念模型结构，业务接口规范等等.一般与PRD合并。

产品原型一是记得把事情做到刚刚好就够了（这种完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值的思考的逃避）。除非面对面讲解，否则产品原型需要一个明确的阅读线索。
交互稿要描述元素布局和交互流程。

其他还有需求收集文档、需求进度文档、需求评审报告、发布通知有时要做验收测试，还有验收测试的文档等等。在任何需要文档来规范思考、引导书面沟通、存档留底的场景中，都可以建立相应的文档机制。

总之，只要有明确的目的，而且在保证沟通效率的前提下，文档不是一个坏东西。但千万不要为了文档而文档，，变成形式化的东西，禁锢了流程和创造力，就糟糕了。所以我一直提倡要会写文档，同时提倡不强制要求文档，在你认为合适、需要的时候，能写出恰如其分的文档就好。

产品图例

概念模型图/流程图/泳道图/时序图/状态图/用例图
概念模型的目的是要将产品中的业务概念分门别类的整理出来，并在同时确定概念之间的关系。在复杂业务的系统中，这一工具非常重要，它是一切业务流程的基础。概念模型的梳理最大的作用是来回答系统的根本性问题，从而可以帮助工程师设计数据结构，也帮助业务找到设计出发点。（二爷这里讲的非常好，只能浅显的搬运一些东西过来了。但是概念模型真的特别重要，是一个产品的骨架了。）

流程图是面向过程的描述性流程图，用来描述简单流程。

泳道图就是在传统的流程图上加入角色，因为每个角色之间是平行的。通过这些泳道去标识每个动作是由哪个角色（或子系统）做出的。这种图形一般用于比较宏观的流程描述中，比如划分各业务角色之间大的流程步骤，或描述子系统之间的边界和职能。

时序图也是 UML 标准里面的一种图示，也是面向对象设计的一种工具。时序图整体看起来像很多根竹签，每根竹签代表用户、业务对象、子系统甚至“时间”，凡是可以向其他竹签发出请求的都可以表示为一根竹签，，而有些过程是需要定时执行的。

状态图每个节点是一个状态，每两个状态之间是一个行为，描述的是出发状态转变的可能。这样可以尽可能的避免冗余状态和状态合并的情况。

用例图是 UML 的标准图示，看起来特别简单，一个火柴人和一些椭圆。每个椭圆是一个用例描述，然后把椭圆和人连起来。以卖点作为粒度。

产品设计的暗黑模式：操纵的诱惑

这样通过网页或 App 的界面或流程的有意精心设计，诱导用户做出本不打算做出的举动，比如购买、注册、点击广告、发送垃圾邮件等等，被统一定义为“暗黑模式”（Dark Patterns）Dark Patterns的网站 https://darkpatterns.org/types-of-dark-pattern

操纵来自于基因/尊重和磊落的用户感知价值低/不成熟期的劣币逐良币

对这些根植在人性中的特点进行操纵总是有效的，它诉诸于本能，可有效的设计一旦用到暗黑模式中，就像落到魔鬼手里的权杖，让人心生厌恶和绝望。

对于不尊重用户的行为，只能引起部分人的反抗。在绝对的利益面前，尊重目前没有太大的价值，大家不愿意为了尊重付费。

这样的克制和磊落却势必会导致服务提供方的利益受损，在同样的功能特性面前，一个尊重客户的，具有美德的产品，却处在了竞争劣势之中。只希望发展成熟以后，尊重会越来越重要。

至少当他们开启暗黑模式时，我们应当表达愤怒和抗拒，而不是当做某种惯例，悄无声息地任它发生。没错，我指的不光是产品设计。

写好产品文档的诀窍

明确受众、目的和形式。
要明确的知道文档是给谁看的，根据受众，想达到的目的的不同，来准备不同的形式，比如BRD目的一般是要获得支持和授权，获取一定的资源。一般以PPT的形式。记得同时准备两种类型的ppt。演讲型（提纲和图文）用来演示，阅读型（逻辑关系）则用于邮件。PRD则是面向工程师，一般写成文档，pdf或者wiki的形式。不推荐使用word（word的不兼容会导致不同机器产生变形）。

知其所以然，然后知其然
要在PRD文档中交代背景和原因，让工程师真正参与进来，没准会给你一个更好的建议呢。

打造良好的阅读体验--金字塔原则，逻辑和格式
有个著名的方法论叫金字塔原理，就是从一个论点出发，通常是文档的目的），找到支持它的三到五个方面，每个方面再向下拆分，形成一个逻辑上的金字塔。每一层的拆分都要尽可能保证观点是相互独立，同时又完全覆盖的。另外商业规则在流程体现的同时，建议单独在最后列出来，方便开发查看和测试写测试用例。

先写厚，在写薄。
写文档的过程也是一个思考的过程，开始尽可能的全，写完文档后再反复修订，让文档发酵后，尽量精简表达。

产品分析的套路

谁是利益相关者

利益相关者，不止用户
我们最直接重要的的利益相关者当然是用户，但是除了用户以后，我们还需要根据业务考虑上下游的利益，还需要平衡投资者的利益。产品经理要有共情能力，要站在各种利益相关者的方面去考虑问题。

ToC和ToB模式不同的决策
对于 To B 类用户，做出购买决定的人、影响决定的人和使用最终产品的人、甚至是掏钱的人可能都是不同的，他们在购买决策链上的角色和作用，以及发生作用的时机也是不同的。

To C 类产品通常是一人一票，只要打动一个用户，就会投一票，一票就是一个实打实的 deal。

所以针对不同的模式类型需要考虑的问题就会完全不一样，toB对注重系统指标（安全，性能等）而toC更偏重交互上。

上下游特点与平台价值
平台怎么为上下游创造价值？这里举了一个桔子交易平台的实例，留作思考。有兴趣的可以看专栏，这里就不照搬了。

解决什么问题

重视解决的问题而不是解决的方案
很多产品经理更注重解决方案，根据需求就拆分出方案，而忽视需求背后真正的问题。正确的做法应该是：把类似的所谓需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。

把自己放进场景，“吃自己的狗粮”
我们常说场景是需求的灵魂。也就是我们在考虑需求时，不应该只是孤立地考虑功能逻辑，而应该把这些功能和流程放到具体的用户使用上下文里面去。场景这个词来源于戏剧和电影，包含了时间、空间、角色等等许多因素。把自己放进场景里才能更多的去体会用户的所思所想，成为自己产品的重度用户。

转益多师，加深对场景的理解
关于场景的理解，我还推荐大家可以去看一些编剧相关的书，看看编剧是如何构建和表述一个场景的。甚至是一些漫画书，我曾经在公众号中介绍过一本叫做《以图代言》的书。多站在不同人的角度去思考问题。甚至在使用产品的过程中当一个挑刺的“混蛋”。则更容易发现问题。

如何出解决方案

这个应该不予多说，只提一下怎么提升出解决方案的能力。

首先要见多识广，多把玩和分析不同类型的产品，另外要能够跳出功能开发来考虑解决方案，以及从游戏设计领域借鉴经验，最后说到了首因效应和简化版的可用性测试方法。

产品经理设计的方案既包括流程上的、逻辑上的，也包括交互和体验上的。提高出方案能力的最好方法就是大量把玩各种各样的互联网产品和服务。但要注意一点，这个把玩的过程不应该是随便用一下、体验一下就完了。产品经理需要通过看到特性就能理解背后的问题、用户，尽可能地去抽象考虑同样的问题还有哪些不同的方案。其实产品经理还要学会通过改变业务规则、流程，甚至利用财务手段去解决问题。关于产品方案设计还有一个非常值得学习和借鉴的领域就是游戏设计。

分享两个有意思的经验。一个是我们需要特别拿出精力来设计“第一印象”，另一个是破除知识的诅咒，所谓知识的诅咒是指由于你掌握了某种知识，所以无法假装自己不知道这些东西，并重新回到无知的状态，就像被诅咒一样。

简化版可用性测试，就是去找一个不相干的同事，最好比较细腻，而且比较外向，创造一个比较放松的条件，让他来体验整个流程。

排定需求优先级的方法

从受众规模、需求频率和强度出发

避免毫无价值的正确
比如页面优化交互优化，背后没有业务的思考的优化等等。我们要把时间跟精力投入到更重要的优先的事情中。首先我们去将所有的利益相关者以及他们的问题列出来，逐条分析受众的规模，以及问题的频率和强度。最简单的逻辑是：受益者越多、问题的频率越高、强度越大，则解决这样问题的价值就越大，优先级也越高。

规模频率与强度
判断规模，有一个概念叫做 TAM（Total Addressable Market）这是指潜在市场范围，每项服务都有受众天花板。

需求的频率和强度比较容易理解，跟规模一样，频率和强度也会随着时代、基础设施以及环境的变化而变化。在规模、频率和强度之外还有一个考虑因素，叫主观的可达性。

排定优先级
根据规模频率和强度来做优先级考量。描述规模、频率和强度的时候，得到结论固然重要，但更重要的是去探求结论的过程，它背后是产品经理对自己产品定位的深入理解。还有对用户的理解、对场景的理解、以及对市场和竞争环境的理解。有时候还会包含产品经理的一些价值取向和判断，比如有人相信薄利多销，有人则愿意高价高质。这并没有对错，只是选择不同而已。

价值曲线分析

我们如果去看传统的价值曲线分析（或称价值曲线评价），会发现它主要是用于分析用户感知和服务质量的工具；但正如我们之前的分享所提到的，产品经理不能仅关注用户，而是要关注所有跟产品相关的受众。我们要从产品涉及的所有利益相关者的角度出发，利用价值曲线分析的方法去理解他们的感知，然后再去评价我们产品提供的服务质量。

罗列利益相关者和他们的感知价值
这里二爷举了一个“X县小吃”的连锁饭店的例子。列举了相关利益者和感知价值。顾客：他可以感知到的价值可能是菜品的种类、口味、价格和卫生等等。加盟店店长:他们最关注的可能是收入、成本、利润、翻台率等等指标.

对问题进行优先级排序
当我们列出每个角色的关注问题列表之后，我们要做的第一件事是为这些问题做个排序，这里的排序没有正确答案.但跟业务方向和目标用户群强相关。

将问题指标化并拆解
给问题排序之后，第二件事情是将所有的问题指标化。做产品和规划业务的时候，要多说数字，多说名词，多用白描。在指标化的过程中可能需要对部分指标做拆解，关于指标的粒度，并没有标准答案，不同的业务阶段和状态可能会有不同的关注点。指标以业务关注点作为原子点。

整体权衡并排序
指标化之后，我们需要基于这个模型进行整体排序，我们先要在业务上去做出一个判断，目前哪些人的哪些问题是当前的瓶颈，是我们需要集中解决的？抓住这个问题和背后的指标，基本就抓住业务重心和方向。找到了关键指标后，不要犹豫，要以指标为目的，甚至不惜牺牲其他利益相关者的利益。这里的权衡是产品的常态，要根据指标进行思考。

综合考虑解决方案
上面的步骤完成之后，还有非常重要的一部分是解决方案和成本分析。有时候排在第一位的问题需要耗费的成本巨大，我们承受不了，那在动手的时候，我们可以退而求其次。不要在单一指标上吊死。

如何做好需求评审

需求评审不止是一场会议

当我们在谈论需求评审时，我们在谈论什么？
也许我们会觉得需求评审只是一个环节，但是我们不能局限在一个流程切片的角度去理解和讨论它，需求评审串起了前期的需求收集和分析，不同利益相关方的博弈，以及后续项目落地实施的计划管理等各个方面，评审会议本事只是露出水面的一角，想要评审更有效，事前和事后工作不少。

需求评审的受众、目的
产品经理完成需求收集和分析，确定解决方案之后，面向两个角色，做四件事情。第一件事情是向需求方以及其他利益相关方详述自己对需求的理解和分析，明确我们的需求分析与他们的原始期望是一致的。第二件事情是想设计、研发和测试团队，讲清楚需求的背景和来龙去脉。第三件事情，是向需求方交代具体的产品解决方案，也就是告诉他们最后会得到什么东西。第四件事情向开发团队交代产品的解决方案，设计师、工程师要清楚产品的流程，特性。

哪些人参加评审，怎么安排议程
根据上述说的两种角色和四件事情来决定，随机组合就好。评审议程也应该结合目标来安排，一般是先讲业务，然后再讲方案，讲的过程中还是根据刚才说的四个目标来安排逻辑和内容，提高效率。

预则立，不预则废
大家一定要重视会前的沟通，提前做功课，要记住需求评审会应该是胜利的凯歌，而不是冲锋的号角。会前沟通一般是小范围的，针对一些细节点深入、频繁地与具体的相关人员交换信息，达成一致。另外很重要的一点是一定要提前发出需求评审的材料，让大家提前熟悉一下评审的内容。并且根据不同的人员让其熟悉具体的需要关注地方，能提升大家去看文档的积极性。

准备材料和议程。材料至少要包含需求文档。议程至少有讲业务，讲实现，评审讨论三个部分。会前发出的材料和议程，一定要专业严谨。一方面可以把事情交代清楚，另一方面也会产生潜意识上的影响，让大家重视起来。

在评审中控住全场

当心知识的诅咒
不要觉得大家都跟自己一样了解产品方案，所以在做宣讲或者需求评审时，要把自己放到听众的上下文中，把来龙去脉讲清楚，宁可啰嗦也要讲清楚。尽可能从所有人都知道的背景开始讲起，逐渐向外伸展，像讲故事一样。

不要强迫，要吸引
不要强迫大家来听，要靠吸引，怎么讲好故事？那就是具象。对于软件产品来说，就是用户场景和用例故事。我们从场景和故事出发。用具体的案例来跟听众沟通。先整体介绍业务，大的逻辑和背景，然后用一个实际的业务案例把相关的功能和流程串讲一遍，最后回到文档本身，过一遍需求文档。

用自己的态度感染他人
如果你做事严谨而自信。那别人来参与的时候会相信你靠谱。也会相信你所提出来的产品方案。

不要为了赢而争吵
在需求评审中，产品经理经常受到各种人员的挑战。为了维护自己的“孩子”难免会跳脚，防止将不同意见升级为争吵的一个办法是用陈述句复述并确认。这样可以稳定情绪，让事情尽快回到正轨，并挖掘出提出的真正需求。

小公司的需求评审
小公司可能并不会组织大规模的需求评审，但是一定要有这个过程。多跟工程师和设计以及领导沟通。不能因为缺乏评审会，就把没有完全想清楚的需求交付给开发，浪费了时间，也影响了士气。

项目管理心得

影响力大于权利
不要利用权力威逼利诱，通过影响力大家团结一心才能做出更好的产品，提升产品的质量。

管人大于管事
士气是团队中看不见的那只手，项目经理需要对此有感性上的敏感，关注整个项目组的士气。士气低落会影响交互能力，并且会造成团队的不稳定。所有产品规划和设计要靠谱，要大家理解并看到希望。也要注意项目的里程碑和仪式感，达到目标是要表扬，做到功要赏过要罚。

交互大于计划
我们需要项目计划保持一定的严肃和刚性，但是计划只是手段，项目交互才是项目管理的目的。所以不能过分拘泥于计划，因为过程中的一些意外自乱阵脚。要能识别关键路劲，清楚任务依赖，并且建立尽可能多的观察点，在问题发生前预警，问题发生时快速调整。这要求我们在脑子里或者纸面上有一张完整的甘特图，即使出现问题，也能弄清楚可能的影响范围和应对措施。

当项目进展出现风险时，应对方案基本就是“加班，加人，砍需求”。不到万不得已不要延期，不要形成散漫的风气。交付就是承诺，只有保住交付才能保住饭碗。另外在项目计划中争取缓冲时间，在评估的结果上留有余量，应对可能出现的延期。

正确看待项目管理工具
全面了解项目管理工具和方法论，同时不拘泥于它们。通过研究工具的设计和构造，我们可以学习很多关于项目管理的洞察。根据实际情况选择合适的工具，择善而从才是正道。

稳住才能赢
作为项目经理心态一定要好，风格沉稳。要对整个项目通盘掌握，深刻的理解业务背景和项目目标，并以此把握好相关优先级，管理好项目边界，掌控好成本和质量，只有这样，才能在项目推进过程中尽早识别和应对风险的发生。

推荐一点好书
《人月神话》《构建之美》《团队之美》《网易一千零一夜》

“玩的启示”从游戏设计中学习产品设计

游戏设计的手段

持续实时的反馈
这种奖励会在神不知鬼不觉中激活我们的低级神经反应，达到一种生理上的上瘾。为什么我们可以持续性的玩游戏，却不能持续性的学习呢。因为游戏都是实时反馈，而学习这种是往往是延迟享受的反馈。 这里就应用到产品上就是我们要利用声音或者震动或其他设计产生沉浸式的实时反馈。

人性的开关
游戏的设计是最洞悉人性的欲望并加以利用的。成就感自豪感囤积欲望什么，把握好用户的心理更容易做出更人性化的产品。

与社群建立联系
人是社会动物，本能性的渴望与社会建立关系。在产品中加入社交元素可以产生爆炸式的影响。有一个提醒是：类似的产品特性在计算成本和投入的时候，一定要考虑到产品运维。（运维做不好，宁可不做社交）

构建意义
每个人都渴望成为超越个体的伟大事业的一部分，大部分游戏都会为自己的设计构建意义。在适当的时候提醒用户产品的意义，可以形成使命感或其他。或者我们可以通过构建意义的手段去润滑产品的体验，比如朋友圈的赞而不是阅。

游戏机制为核心的启发
那些精巧的、处心积虑的功能性设计，远不如关键性的机制设计来得重要有效。有时候要破除知识的诅咒，跳脱出来从本质上考虑问题，设置关键性机制。这里举了一个分享的例子，与其把分享做的易用好看交互特别好，不如分享提成。

尾声

外在快乐与内在快乐

如果是由于机缘巧合，偶尔与某些事物相关联。这些快乐都是外在的。而因为事物本身所获的成就感满足感则是内在的快乐。如果驱动力仅仅是外在奖励，比如晋升，加薪，奖金和地位。那么也就没有任何事情可以阻止我们为更高级的数据指标做出狡猾的设计。但是产品真切的改变着人们的生活这种内在快乐反而会让你更加的谨慎而认真。

关于初心和理想（Joshua Bell）

二爷举了梵高和Joshua Bell的故事，不管是梵高还是Joshua Bell都没有放弃自己对生活的热爱，对梦想本质的追求。也许看完这篇，我们还是会为了生计奔波，为了房贷车贷发愁，为了公司殚精竭虑，但是我还是希望你们偶尔回想起来这份初心，在选择的时候不要走错道理。