CB Insights 每年都会发布一份创业公司失败原因的分析。多年来，排名第一的原因始终没变：“没有市场需求”。不是执行不力，不是资金耗尽，也不是团队不行。而是产品根本没有解决一个足以让人们改变习惯的问题。
想想打造产品需要投入多少精力，这个数据就更令人震惊了。团队花上几个月，有时甚至几年，设计系统、编写代码、争论架构、打磨流程。而最常见的失败原因，却是从来没有人问过这一切是否在解决一个真实的问题。
打造用户真正想要的产品并不是一种天赋，而是一门需要严格自律的功夫。它有方法，而这种方法是可以学会的。
最常见的产品错误，就是在深入理解问题之前，就爱上了某个解决方案。这在首次创业的人当中几乎是通病，在经验丰富的创业者身上也出人意料地常见。套路总是一样的：有人冒出一个想法，觉得它很有吸引力，就开始动手做。客户成了事后才想起的角色——是需要被说服的对象，而不是需要被理解的人。
解药并不复杂，但需要自律：在考虑任何解决方案之前，把比你认为必要的更多时间花在问题上。去和有这个问题的人交流，观察他们工作，了解他们今天用的变通办法，以及这些办法为什么不够完美。只有这样，你才有足够的背景信息，设计出真正契合需求的东西。
好的产品开发不是一条直线，而是一个循环。循环中的每一轮迭代，都是用证据取代假设的机会。能做出用户想要的产品的团队，都是那些完成这个循环又快又勤的团队。
这个循环不是走过场。每个阶段都有明确的产出，并成为下一阶段的输入。跳过其中的阶段——最常见的是直接从“问题”跳到“构建”——就会做出偏离目标的产品。
并非所有问题都值得解决。一个好的产品问题有三个特征：高频（经常影响人，而不是偶尔），强烈（人们的痛感足以让他们想要缓解），以及现有的解决方案确实不够好（而不只是和你要做的略有不同）。
常见的错误是只盯着第一个特征，却忽略了后两个。“人们在会议上浪费时间”很高频。但如果痛感很弱——如果人们已经找到了凑合够用的变通办法——这个问题在商业上可能就不值得解决。而如果市面上已经有十二个工具在做你想做的事，你就需要一个非常具体的理由，说明为什么用户会选你。
研究在产品圈里名声不佳——人们会把它和拖沓的咨询公司、厚厚的报告、没人看的结论联系在一起。但这是执行的失败，而不是研究方法本身的问题。好的产品研究快速、具体，并且会改变你要做的东西。
研究的目标不是为了确认问题是真的。在你大量投入研究之前，就应该已经相信这一点了。研究的目标是把问题理解得足够深，从而知道一个好的解决方案应该是什么样子：具体是谁有这个问题，在什么情境下，他们已经尝试过什么，他们用什么词来描述它，以及在他们眼里“解决了”意味着什么。
假设是一个具体的、可证伪的预测，说明你认为什么是真的。它迫使你把想法讲清楚。如果你写不出一个清晰的假设，说明你对问题的理解还不足以去构建解决方案。
一个有用的产品假设包含三个部分：
信号是最重要的部分，也是最常被遗漏的部分。没有事先约定好的信号，每个实验都“算是有点效果”。团队总会想办法把模棱两可的数据解读得对自己有利。没有证伪条件的假设，只是一厢情愿。
构建阶段是大多数团队花时间过多的地方。目标不是做出产品，而是做出能为你的假设提供信号的最小东西。这是两个不同的目标，产出也截然不同。
对大多数早期阶段的假设来说，所需的最小投入比团队想象的要少得多。你能不能为十个人手动完成软件要做的事，来检验他们是否看重这个结果？你能不能在构建新的基础设施之前，先拼凑现有工具来测试这个工作流？你能不能先画出原型，在写任何代码之前，带五个用户走一遍？
这里的自律，是在构建任何东西之前先问：“我想弄清楚什么？”以及“要弄清楚它，最小需要做什么？”答案几乎总是比团队想做的要小。
发布之后——无论是原型、手动试点，还是已上线的功能——衡量阶段是团队最容易自欺欺人的地方。他们问用户喜不喜欢，用户说喜欢，团队就把实验标记为“已验证”。
态度不是信号。唯一可靠的信号是行为：用户有没有真的去做？有没有再回来？有没有付费？有没有推荐给别人？
做定量衡量时，要在上线之前就做好数据埋点，明确你要追踪哪些具体行为。提前设定一个阈值——“如果X%的用户在Z天内完成Y，我们就认为这一点得到了验证。”做定性衡量时，要进行结构化的跟进访谈，而不是开放式的满意度调查。
学习阶段的重点是更新你对用户和问题的认知模型，而不只是决定下一步做什么。跳过这一步的团队只是在收集数据，并没有积累理解。他们执行得很快，但判断力不会随着时间推移而提升。
一次好的复盘会这样提问：我们当初预测了什么？实际发生了什么？这个差距说明我们的假设有什么问题？现在我们最重要的未知是什么？
学习阶段的产出，是更清晰的问题定义、修正后的假设，或者——如果实验明显失败——彻底转向另一个方向的决定。这些结果都有价值。最糟糕的结果是含糊不清：“我们学到了一些东西，但不确定下一步该做什么。”这说明实验设计得不够具体。
产品开发永远不会进入可以停止这个循环的阶段。问题会变——早期你在验证问题是否真实；后期你在验证某个具体的方案要素是否有效——但结构始终不变：观察、提出假设、测试、学习。
能做出用户想要的产品的团队，并不是那些一开始洞察最聪明的团队，而是那些完成循环最快、也最诚实的团队。学习的速度，而不是上线的速度，才是竞争优势。