从「我觉得」到「有证据」：如何成为真正的证据导向型产品团队

嘉宾：Itamar Gal ｜前Google产品经理、产品教练、作家｜领域：AI产品与产品方法论

背景与引子

2011年的硅谷，一场豪赌正在进行。

Facebook正如日中天，用户每天花数小时刷动态，这让Google寝食难安。Google的对策是什么？答案是：打造自己的社交网络——Google+。

这家公司调动了整整一千人的团队，在园区专门成立了堪比Android规模的独立部门，所有资源向这个项目倾斜。Gmail、YouTube、搜索……所有核心产品都被要求与Google+整合。

最终，这个投入了数百万工时的项目在2018年被彻底关闭。

这听起来像是一个关于竞争失败的教训。但如果我们深入思考，它揭示的其实是更深层的问题：为什么聪明人会做出如此糟糕的决策？为什么最优秀的公司也会犯这种错误？

答案在于决策方式本身。

我最近采访了一位亲历Google+项目的Google老兵Itamar Gal，他现在是一位产品教练，刚刚出版了新书《Evidence-Guided》。他提出了一个振聋发聩的观点：大多数公司自认为在做数据驱动决策，但本质上仍然是「Opinion-Based Development」——opinion-based，靠拍脑袋做产品。

这正是他想要改变的事情。

一、嘉宾是谁

Itamar Gal曾在Google任职超过十年，是一位真正的产品老兵。他亲历了Gmail、Identity和YouTube等多个核心产品的研发，更重要的是，他经历了Google+从立项到失败的完整周期，以及Gmail Tabbed Inbox（分类邮件）从被质疑到成功的逆袭过程。

这些经历塑造了他对产品开发的独特思考：什么是真正的证据导向？为什么Google的两面性（既做出了Google+，又做出了Tabbed Inbox）揭示了公司成长的秘密？

离开Google后，Itamar成为了一名产品教练和作家，服务于全球各大科技公司。他在实践中最核心的工作，就是帮助产品团队从「我觉得」「领导说」「竞争对手在做」这种Opinion-Based的决策方式，转向真正的Evidence-Guided（证据导向）方法论。

他出版的新书《Evidence-Guided: Creating High-Impact Products in the Face of Uncertainty》是这一领域难得的实战指南，包含了大量可以直接落地的框架和工具。

二、核心观点 TOP10

Opinion-Based Development是大多数产品失败的根源——我们想出一个主意，相信它有价值，然后就all-in去实现它，直到碰壁。
证据的力量在于赋能普通人挑战权威——当你想反驳创始人的想法时，最好的武器不是你的职位，而是你收集的数据和证据。
Google+是一个战略级别的Opinion-Based案例——投入一千人的团队，最终零产出，同时还错过了WhatsApp这样的机会。
Tabbed Inbox的成功源于证据，而非信念——这是一个没人看好的小想法，但团队通过层层验证（包括手动伪造的「Wizard of Oz测试」）最终确认了它的价值。
85%-88%的用户真正热爱分类邮件功能——这完全出乎那些「专业用户」的预料，因为专业人士根本不需要这个功能。
证据导向的方法论反而更快、更省资源——Opinion-Based看似快速，实际上在错误方向上浪费了更多时间和人力。
即使像乔布斯这样的人，看到证据后也会改变想法——iPhone的诞生实际上是多次试错的结果，并非天才的一锤定音。
证据本身可以分层级——从「我的直觉」到「经过实验验证」，不同层级的证据对应不同的置信度。
学习可以在极低成本下发生——你不需要先做出完整产品才能验证想法，有很多低成本的测试方法。
GIST模型让证据导向成为系统性的工作方式——通过Goals、Ideas、Steps、Tasks四个层次的结构化，让团队自然地走上证据导向的道路。

三、关键洞察

1. Google的DNA里就有证据导向，但它也会背叛自己

Google在第一个十年里是典型的证据导向公司——快速试错、发布beta版本、用数据说话、敢于砍掉不work的项目。但Google+项目却采用了「Plan and Execute」的方式，完美地规避了这些成功经验。讽刺的是，Gmail团队在Google+项目失败后，用了完全不同的方法论打造了Tabbed Inbox——这恰好证明了证据导向的生命力。

洞察：成熟的方法论不会自动传承，需要刻意保持。每一次成功的反面都可能是下一次失败的伏笔。

2. 置信度可以被结构化地评估

大多数人在评估想法时只有模糊的「我觉得靠谱」或「不太确定」。Itamar引入了「Confidence Meter」这个框架，把置信度从0到10分成不同层级，每个层级对应不同类型的证据：最低是纯粹的个人意见和PPT演讲稿，最高是通过A/B测试等实验方法获得的验证。这个框架让人能够客观地讨论「我们对这件事到底有多确定」，而不是陷入无休止的「我 vs 你」的辩论。

洞察：把置信度显性化、量化，是让团队真正接受证据的起点。模糊的不确定感是Opinion-Based决策的最大帮凶。

3. 测试可以极低成本，也可以高成本——选择取决于置信度

Itamar展示了一个从低到高的测试光谱：Assessment（对齐度检查、商业建模）→ Finding（用户访谈、数据分析）→ Fake it（Wizard of Oz测试、烟雾测试）→ Mid-level test（原型、Alpha版本、Fishfood测试）→ Experiments（A/B测试）→ Release（灰度发布）。关键原则是：根据当前置信度选择最低成本的验证方式，不需要一开始就构建完整产品。 Gmail团队最早测试分类功能时，连一行代码都没写，只是用HTML伪造了一个界面，然后手动把邮件拖到正确位置——这给了他们足够的证据来决定是否值得投入开发。

洞察：越早开始验证，浪费越少。但验证不等于做出来，它可以是任何形式——只要能回答你的核心假设。

4. 结果导向的OKR和Roadmap是证据导向的敌人

当你在Roadmap里写着「Q3必须上线这个功能」时，你实际上是在低置信度状态下做出了高承诺。这锁死了团队的学习空间，让他们不得不为了「完成计划」而构建，而不是为了「解决问题」而构建。真正的做法是使用「Outcome Roadmaps」——描述你想要的结果（比如「Q4将印度市场使用率提升30%」），而不是具体的交付物。这为团队留出了探索和验证的空间。

洞察：承诺交付物 vs 承诺结果，是区分Opinion-Based和Evidence-Guided的试金石。

5. 最强大的「不」来自置信度框架

当一个想法来自创始人或高管时，说「不」是困难的。但如果你用Confidence Meter评估它，发现它只有0.3的置信度（纯Opinion），然后展示给当事人看——这创造了一种客观的对话语境，而不是对权威的挑战。Itamar说，许多团队发现这个框架是「委婉说不」的最佳工具，因为它把争论从「我vs你」变成了「我们的置信度在这里，应该先做什么测试？」

洞察：好的工具不是用来证明对方错了，而是让所有人站在同一个评估标准面前。

四、精彩金句

“Behind every terrible idea that was ever created, someone thought it was great.” 「每一个最终被证明很糟糕的想法背后，都有人当时觉得它超级棒。」

——这句话直击Opinion-Based的本质：我们对自己的想法都有过度自信的倾向，这不是性格缺陷，而是认知偏见。认识到这一点，才能真正转向证据导向。

“The metric is not how fast we get the bits into production. It’s about getting the right bits into production.” 「衡量指标不是我们多快把代码发布上线，而是我们发布了正确的代码。」

——这是对敏捷开发最深刻的重新诠释。速度只有在正确方向上才有意义，否则越快越浪费。

“Strive not to be a success, but to be of value.” 「不要追求成功，而是追求创造价值。」

——Itamar分享的爱因斯坦名言，也是Evidence-Guided方法论的核心哲学。当你真正关注为用户创造价值时，证据自然会指向正确的方向。

“The iPhone was a story of discovery, trial and error, multiple projects. Most of them failed.” 「iPhone的故事是探索、试错、多项目并行的故事。大多数项目都失败了。」

——关于乔布斯的神话需要被打破。iPhone并非天才的一锤定音，而是多次验证、多次失败后的结晶。

五、实战案例

Gmail分类邮件的「Wizard of Oz测试」

在Google+项目结束后，Gmail团队接到了一个新的挑战：帮助用户处理日益混乱的收件箱。大多数人不再主动管理邮件，收件箱变成了一个无序的信息垃圾场。

Itamar当时提出了一个想法——把社交通知和促销邮件自动分类到不同的标签页。他确信这是一个好主意，想要「Plan and Execute」。

但他的同事们泼了一盆冷水：「我们之前做过类似的功能，用户根本不用。」

这促使团队走上了真正的验证之路：

第一步：手动伪造测试 他们没有写一行代码。团队成员用HTML做了一个假的Gmail界面，然后手动把邮件拖到「正确」的位置——完全模拟AI分类的效果。研究员邀请用户来体验，让他们在假界面里测试前50封邮件的分类效果。用户的反应是：「哇，这太酷了！」

第二步：扩大样本 基于这个手动测试的反馈，团队开始招募更多用户进行测试，包括外部用户、不同背景的用户。

第三步：构建数据能力 团队还专门建立了数据挖掘和机器学习团队，来优化真正的分类算法。

第四步：逐步发布 功能最终上线后，团队持续监控数据，准备好了随时回滚。

结果： 这个功能最终被85%-88%的Gmail用户采用（对于那些每天处理大量被动通知的普通用户来说尤为有用），成为Gmail历史上最具影响力的功能之一。而讽刺的是，当初那些最反对这个想法的「专业用户」——他们确实不需要这个功能。

关键教训： 最低成本的测试（手动伪造）给出了足够强的信号，让团队决定继续投入。这个测试没有花任何工程资源，但回答了最关键的问题：「用户会不会觉得这个有用？」

六、行动建议

建议1：从今天开始使用ICE框架评估你的想法清单

为什么要做：想法太多是每个产品团队的常态，但时间资源永远有限。如果没有结构化的评估方式，决策就会陷入Opinion-Based的泥潭——谁的title大、谁的嗓门大、谁先提的，谁赢。

如何开始：在你的想法列表里，为每个想法打分：Impact（影响，分数1-10）、Confidence（置信度1-10）、Ease（难易度1-10），计算公式：ICE = Impact × Confidence ÷ Ease。优先做高ICE分数的想法。

能得到什么结果：团队会看到优先级的来源不再是个人偏好，而是透明的评分标准。讨论会从「我觉得这个好」变成「我们看看ICE分数」。

建议2：用Confidence Meter重新审视你最大的在途项目

为什么要做：大多数团队在项目启动时是兴奋的状态，对成功率的估计往往过度乐观。但这种盲目自信正是Opinion-Based的最大症状。

如何开始：找一个正在开发的功能，用Confidence Meter（0-10分）评估你现在拥有的证据层级。0分是纯粹Opinion，10分是通过A/B测试验证。把评估结果分享给团队，看看你们的置信度是否支撑当前的投入。

能得到什么结果：如果你的置信度很低但投入已经很大，这是一个明确的信号：你需要先做更多验证，而不是继续往前冲。

建议3：下次有人提需求时，先问「你的置信度是多少？」

为什么要做：创始人和高管的直觉有时候是对的，有时候是错的，但你需要有能力质疑他们——不是质疑他们的人，而是质疑他们的假设。

如何开始：在会议上，当有人提出一个想法时，轻轻地问一句：「你觉得这个想法的置信度大概是多少？我们有什么证据吗？」这句话的力量在于，它创造了一种客观的对话氛围，而不是在挑战权威。

能得到什么结果：你会发现大多数想法的置信度都很低（0-2分区间），而这些想法本不应该立即进入开发阶段。

建议4：把下一个想法的手动测试版本做给用户看

为什么要做：在写代码之前先验证方向，这可能是节省资源最有效的方式。但很多团队不知道「测试」可以有多简单。

如何开始：选一个你想验证的功能想法（最好是比较独立的、体验层的功能），用一天时间做一个「Wizard of Oz」版本：可以是PPT、Figma原型、甚至是用Google Form伪造一个假的界面。邀请5-10个用户试用，观察他们的反应，记录他们的问题和建议。

能得到什么结果：即使只是手动伪造的测试，也能让你快速判断：这个功能是否值得投入开发？

建议5：把你的Roadmap改成Outcome描述

为什么要做：Release Roadmap（「Q3必须上线这个功能」）锁死了学习空间，把团队绑在了低置信度的承诺上。

如何开始：把现有的Roadmap里的每一条，从「我们将在Q3发布X功能」改成「我们希望在Q3达到Y结果」。例如：「我们将在Q3上线新的激活流程」→「我们希望在Q3把新用户首日激活率从25%提升到40%」。

能得到什么结果：团队会开始问「怎么做才能达到这个结果」，而不是「怎么完成这个功能」。这是从输出导向到结果导向的文化转变。

七、我的总结

这期访谈揭示了一个被大多数产品团队忽视的真相：我们以为自己在做数据驱动决策，但实际上我们仍然在被Opinion驱动。 Google+和Gmail Tabbed Inbox的故事，是同一批Google人做出的两种截然不同的选择——前者all-in一个缺乏验证的想法，后者则通过层层的低置信度测试找到正确的方向。

Itamar的GIST模型提供了一套系统性的方法论，让证据导向不再是一个口号，而是可以在日常工作中落地的工作方式：从Goals的明确定义，到Ideas的ICE评估，到Steps的渐进式验证，再到Tasks的执行管理。每一个层次都可以独立启动，不需要等待整个组织变革。

最核心的转变其实是一个心态上的转变：从「我知道该怎么做」到「我们先验证一下」。 这个转变越小，你浪费的资源就越少，你离正确答案就越近。

证据不会说谎，但opinion会。而你的工作，就是确保在产品开发的每一个关键节点上，是证据在说话，而不是opinion。

📺 播客信息

发布时间：2023-09-21
时长：1小时12分钟52秒
播放量：15232 次观看
原版视频：『YouTube』