2017 年夏天，Superhuman 已经开发两年，团队有十四个人，Rahul Vohra 仍不觉得可以正式推出。大家继续写代码，却缺少一套能说明“还差什么”的共同语言。这是他在 2018 年回顾中描述的处境。[1]
他采用了一个调查办法：请已经体验过核心功能的用户，说明如果不能继续使用产品，会有多失望。第一轮只有 22% 选择最强烈的失望程度。团队继续按用户类型分析，把注意力放到更需要它的人群，统计比例变成了 33%。[1]
随后，他们一边强化用户喜欢的速度和键盘操作，一边处理妨碍使用的缺口，例如移动端和日历。Vohra 自报，经过三个季度的产品改进，这个比例达到 58%。这是他的公司回顾，没有独立对照实验，也不是今天的产品数据。[1]
故事里最容易被略过的一步，恰好值得停下来：22% 变成 33% 时，改变的首先是分析所关注的人群。
这可以帮助团队决定先服务谁，但不能直接解释成同一批人的体验已经改善。把不合适的对象从分析中拿开，和修好一个影响使用的问题，是两种不同的进展。混在一个不断变漂亮的数字里，团队就容易失去判断。
假设一个小团队做了面向“经常开会的人”的纪要工具。第一轮反馈很分散：有人希望自动写周报，有人要翻译，有人希望管理销售线索。十个人都说有用，但每个人想买的似乎是不同东西。这个场景是本文假设，与 Superhuman 的真实用户无关。
细看后，团队发现，一类需要频繁交接任务的项目负责人，对找回承诺、确认下一步格外在意。其他人主要把它当成偶尔尝鲜的转录工具。决定先服务项目负责人，是一个可以继续验证的选择。
我会为这个选择同时保留两份记录。第一份写清人群怎样定义、纳入了谁、排除了谁、有效反馈有多少；第二份记录这类人最近一次怎样完成真实任务，哪个环节仍然要回到旧工具。前一份防止统计范围悄悄变化，后一份检查产品是否真的接住了工作。
下一轮可以接触此前没有参与的同类用户。如果这些人也因为任务交接而持续使用，原来的判断就多了一层支持。如果只有最初几位热心支持者喜欢，也应保留这个结果。不能只邀请愿意夸奖产品的人，再把调查当作独立验证。
一个问卷答案还回答不了全部经营问题。用户表示舍不得离开，可能因为工作依赖，也可能因为暂时没有整理好自己的资料。需要接着了解他为什么需要、多久使用、愿不愿意承担实际价格，以及不使用时会怎样完成同一件事。这里的追问是本文建议，不是对 Superhuman 用户动机的断言。
筛选反馈还有另一条容易越过的边界。Sean Ellis 在 2012 年的《Chasing Problems?》中主张，围绕用户真正离不开的用途安排工作；他在补充说明里特意澄清，这不意味着对提出建议的客户不回应，更不意味着每条建议都要变成产品承诺。[2]
我会把这个区分放到实际处理里。一个暂时不在目标人群里的客户提出“请增加销售管理”，可以解释当前范围；同一个人报告“我的文件打不开”，仍然需要排查已经承诺的服务是否出了问题。用户是否属于目标市场，不能成为忽略现有故障的理由。
对很小的团队，调查最先带来的价值，可能是让讨论变得具体。原来大家争的是“这个功能有没有用”，后来可以讨论“哪类人正在用它完成什么工作，下一次我们要检查什么”。即使最后没有得到好看的比例，这些信息也能帮助决定继续、调整或停止某个方向。
Superhuman 留下的这段记录，展示了一个创始人怎样把模糊的焦虑变成可讨论的工作。借鉴时，我更愿意带走清楚的人群定义和可以复查的证据。数字负责报告发生了什么，后面的选择仍然需要团队自己承担。
资料与日期：
- [1] Rahul Vohra，How Superhuman Built an Engine to Find Product Market Fit，2018 年 11 月 12 日：创始人原文。团队情况、调查比例及改进过程均按作者当时自述转述；不把样本分组前后的比例当成严格可比的实验结果。
- [2] Sean Ellis，Chasing Problems?，2012 年 3 月 2 日：方法作者原文与补充说明。该文提供反馈取舍的背景，不是对 Superhuman 结果的独立验证。
- 两篇均于 2026 年 11 月 6 日阅读全文。纪要工具、人群记录及后续验证办法是本文分析与假设，没有声称真实访谈或测试效果。
