1 产品设计规则
一个产品的规则设计，本质上是在回答下面五个基本问题：
- 精神理念：什么最重要？（“嘴上怎么说”）
- 目标：产品要达成什么目标？（“嘴上怎么说”）
- 谁更重要：多方冲突时保护谁？（“实际怎么做”）
- 鼓励什么：什么事在产品中会受到认可和激励？（“嘴上怎么说”）
-
拒绝什么：什么事不能在产品中做？禁止和惩罚什么？（“实际怎么做”）
举个例子，如果我们把道路交通看作一个产品，它的设计规则可以表述为： - 精神理念：安全第一；
- 目标：保障道路畅通；
- 谁更重要：当行人和机动车冲突时，以保护行人优先；
- 鼓励什么：清晰的道路标识、有序的行进；
- 拒绝什么：禁止酒驾，对违规者要严惩。
思考问题：
（1）对于电商平台来说，优先保障的是买家的权益还是卖家的权益？
（2）对于即时通讯产品来说，消息接收者和消息发生者，到底谁更重要？
2 方案出错，90%是问题错了
产品在设计、开发过程中总是充斥着大大小小的问题。
比如，（1）领导可能会说：“咱们产品必须满足XX这种类型的需求，你安排实现以下吧。”“竞争对手最近推出了一个新功能，我们的产品跟进以下？”（2）运营同事可能会说“咱们最近刚推出的新版本，有很多用户反馈不好用，你看下个版本怎么改进一下？”（3）开发工程师可能会说：“上次那个设计方案引入了一些新问题。用户反馈群里也在说，你看怎么办？”（4）公司高层或合作伙伴可能说：“我在用你们产品的时候遇到一个问题，特别不爽。你们赶紧解决一下！”
产品人在日常工作中总是不断遭遇上述问题。如果我们没有一套处理问题的有效方法，就会在解决问题时出现类似下面的情况：
- 解决方案全靠灵感，随机且呈点状分布，没有说服力；
- 拆东墙补西墙，这边问题一解决，那么问题又冒出来；
- 无法正确处理领导或同事对产品提出的意见建议，陷入被动设计的局面，做出一个被需求的无用产品；
- 在与竞争对手对招的过程中，被对手的节奏带着走，无法有力回天、走出困境。
很多时候，我们无法拿出一个漂亮的解决方案，不是因为缺少灵感或是别的什么原因，而是方法不对。
对于这些棘手的问题，我们都可以用一个普遍适用的应对法则，这个应对法则可以在《决策的艺术》一书中的PrOACT法则（Problem、Objectives、Alternatives、Consequences、Tradeoffs）、麦肯锡的《金字塔原理》以及众多思考者的著作中找到这个法则的踪迹。在产品设计领域，我们可以把它定义为“问题-拆解-方案-结论”四个法则。其具体操作步骤是：
第1步：定义问题
通过弄清“问题背后的目标是什么”进而弄清“真正的问题是什么”；如果目标定义得不准确，就会使一个原本可以被回答的问题变得无法解答。（最重要的步骤）
第2步：拆解问题
将符合问题拆解成可以被回答的元问题；元问题的判断标准是能够直接导出相应的解决方案；拆解过程遵循MECE法则（Mutually Exclusive，Collectively Exhaustive）。
第3步：导出方案
根据元问题，一一导出解决方案。
第4步：评估得出结论
比较解决方案之间的优劣，做出取舍、得出最终结论。
上面四个重要步骤中，又数第一步最重要。可以说，90%的方案错误都是因为没找到真正的问题，或是在执行中遗忘、偏离了真正的问题。
领导说产品必须满足某种需求，竞争对手的新功能要不要跟进，用户或客服反馈产品有问题、不好用，所有问题都可以一步步追问下去，直到问出真正的问题。
例如，产品不好用的话，究竟是哪里不好用？具体在什么时候、地点，为了达到什么目标而使用？使用的时候遇到了什么情况？这种情况背后的真正问题是什么？这个问题是否已知？如果未知又可以归类到哪个模块去解决？只要用四步法则持续追问下去，答案就会自动浮现出来。
案例1：如何让用户更多地使用拼车功能？（俞军在PMCAFF社区抛出的关于滴滴拼车的问题）
第1步：先来定义问题
Q1：问题背后的目标是什么？
A1：从问题分析，追问“为什么滴滴想要让用户更多地使用拼车功能”，进而排除那些已经常用滴滴的用户，明确其目标在于为滴滴平台拓展用户群。
Q2：用户是谁？
A2：排除掉在时间允许时使用拼车的快车用户，主要目标用户群定位在那些使用公共交通的用户，不想坐公交地铁又想相对低成本出行的用户。
Q3：这些用户包含哪几类？滴滴想要争取的目标用户是谁？
A3：包含没体验过滴滴拼车的用户、体验过但已流失的用户、体验过且未流失的用户（流失用户可根据未使用时长定义）；滴滴想要争取的目标用户是前两类用户（统称为“目标用户”）。
Q4：争取到目标用户后，是否希望他们持续使用？
A4：是的，希望他们持续使用。
Q5：所以，真正的问题是什么？
A5：真正的问题是，通过什么产品方案可以让更多目标用户改用或重用滴滴拼车功能，并持续使用下去？
第2步：拆解问题
Q6：真正的问题包含了哪些子问题？
A6：子问题有：
Q6-1：如何让目标用户知道滴滴拼车现在具有很高的出行性价比？
Q6-2：如何改变目标用户选择公交出行的行为习惯，转而尝试体验（或再次体验）拼车？
Q6-3：如何让目标用户在体验拼车服务的全过程中获得满意体验，进而愿意下次继续使用？
//拆解Q6-3
Q6-3-1：拼车全过程包含哪些环节？
A6-3-1：行程前、行程中、行程后。
Q6-3-2：所有环节中存在哪些影响用户体验的因素？
A6-3-2：行程前——聚焦于预期，影响因素包括价格预期（不确定动态定价的浮动程度）和时间预期（不确定拼车会不会额外花费很多时间）；行程中——聚焦于实际体验，影响因素包括担心因拼车造成绕路引起的价格增加，感觉全程额外消耗时间的长短（等待同行人的时间），乘车的舒适度和社交意愿；行程后——聚焦于结果，影响因素包括实际花费的拼车价格和感觉中全程花费的总时长。
//拆解Q6-3-2
Q6-3-2-1：价格问题的本质是什么？
A6-3-2-1：本质是动态和增幅，即“下单前的预期问题”以及“担心因拼车造成绕路引起的价格增加”。
Q6-3-2-2：时间感受的本质是什么？
A6-3-2-2：人们对时间的感知永远是相对的。所以本质上是“拼车额外增加的时间”相对于“总行程时长”的比例决定了用户对拼车额外消耗时间的感知。
第3步：根据元问题，导出解决方案
（1）针对A6-3-2-1导出：
- “一口价”方案。
（2）针对A6-3-2-2导出： - 远距离拼车，即跨域拼车方案（拉长总行程时长）；
- 交通集散地拼车，即机场、火车站、汽车客运站拼车方案（缩短拼车额外增加的时间）。
第4步：评估方案得出结论
事实上，细心的读者一定可以发现，在导出方案的过程中，其实并没有针对行程中“舒适度”或“社交意愿”等因素导出方案，也没有考虑如何才能减少等待同行人的时间，因为这些因素非常依赖于司机和乘客的主观行动，相对不可控。另外，我们也没有针对价格因素提出烧钱降价的方案，因为那些简单粗暴，根本不需要产品设计和思考，不在我们的讨论范畴之内。
2.1 拆解问题的三种方法
2.1.1 将全流程拆解成各自独立的子环节
这是拆解问题最常用到的方法。
在案例1（拼车案例）中，我们用的就是这种拆解方法。想要用户使用某个软件的功能，必须打通用户从接触到了解、从动机形成再到付诸行动的全流程。
类似的，为了达到某个问题设定的目标，我们必须追根溯源，去看从“现状”到“目标”的这一路上，总共需要翻越多少个障碍，然后把这些障碍设定个成各自独立的子环节，一一攻克。
创新型公司（如谷歌）或咨询公司（如麦肯锡）发布的面试题中常常提到一些富有挑战性的题目，例如：
- 芝加哥有多少钢琴音乐师？
- 你所在的城市有多少家理发店？
- 一家冰淇淋店、一家面馆每月的净收入有多少？
事实上，这些问题考察的就是应试者拆解问题的能力。一个职业的从业者多少，和市场上需要多少这类型的劳动力有关，所以只要对人口数据、产品使用频率数据等提出假设，就可以估算出相应的结果。
2.1.2 将内部问题拆解到外部去
在商业领域中，这一拆解问题的思路常被应用到定价策略上，特别适用于那些由于生产成本过高，好产品得不到有效推广和普及的情境。
比如爱普生公司的喷墨打印机，由于高成本造成销售困难，爱普生采用了打印机低于成本价售卖的定价策略，依靠后期更换频度更高的墨盒来赚取利润。吉列公司也采用了同样的策略，把剃须刀刀架的价格定得极低，依靠刀片来赚取利润。类似案例更早还可以追溯到20世纪20年代的CTR（IBM的前身，制表记录公司）制表几，当时的制表机成本极高，经营困难，直到托马斯·沃森（Thomas Watson）制定出“不出售只租赁”的定价模式，才带领CTR走出了困境。
产品的生产成本原本是一个不可分割的整体，在传统思考模式中，以低于整体成本的定价去售卖商品是一件“不可能完成的任务”。可如果我们把这个整体拆解开来，让它们各自独立，承担不同的任务，最终反而能够更好地达到整体的目标。
类似的，在编程领域中，“依赖倒置原则”（Dependence Inversion Principle）本质上也基于同样的思路。它说的是程序要依赖于抽象接口，不要依赖于具体实现。在实际开发中，通过抽象接口的设置，高层次模块就能够不再依赖于低层次模块。耦合度降低，软件开发的危机也降低了。
2.1.3 将异常流程和主流程拆解开来
这个拆解方向其实是“将内部问题拆解到外部去”的一种比较特殊的情况。之所以把它单独拎出来，主要便于大家遇到类似症状可以对症下药。
今后凡是遇到需要异常处理的流程，不妨停下来想想：这个流程一定要和主流程同步处理么？可以把它和主流程拆解开来，分别处理吗？
以QQ同步助手2012年产品改版为例，当时我们的目标是让资料的同步和管理变得更便捷，因此需要变更产品逻辑，从单向“备份+恢复”逻辑改为“一键同步”逻辑。当时团队面对的最大困难有：
- 用户对“同步”逻辑认知不足，他们只知道同步意味着“保持一致”，却无法理解“和谁一致”的问题；
- 产品的核心用户群——换机用户有多种细分场景。用户在换机时既可能以云端为准进行同步，也可能以本地为准进行同步。通讯录资料安全非常重要，产品无法准确判断用户意愿；
- 除换机用户外，还存在一些异常情况导致用户执行同步后，预期与执行不符。
针对以上问题，团队分析后认为：解决同步认知困惑的核心是要建立一个一致性认知锚点，把不同步状态和同步状态拆分开。意思是从某个事件点开始，用户能明确认识到手机和云端已完全保持一致，这以后发生任意变更，两边都会自动保持一致。具体到产品设计上，我们引入了新设备接入的初始化流程。一旦用户使用新设备接入QQ同步助手必须先完成初始化，选择是否保留手机旧数据并进行首次同步。首次同步就是产品建立的一致性认知锚点，它将不同步的异常流程和同步流程完美切割开，较好地解决了产品的认知难题。
