小团队项目启动：别急着写需求，先列假设清单

先问一个问题：你凭什么认为这个项目能成？

很多小团队启动项目时，习惯性先写需求文档、画原型、排迭代。但如果你问一句“你凭什么认为用户会在这个场景下用你的产品？”，团队往往答不上来。或者答案是一个模糊的“我觉得应该可以”。

这种“我觉得”就是假设。而假设一旦出错，后面的所有努力都可能白费。

我见过太多项目，上线后才发现用户根本不关心那个核心功能，或者技术方案根本跑不通，或者市场时机已经过了。这些都不是执行问题，而是假设问题。

假设的分类：不止技术层面

假设不只是“技术可行吗”。对于一个项目，假设可以分成四类：

1. 用户假设：用户真的需要这个功能吗？他们愿意为此付费吗？使用场景存在吗？
2. 技术假设：依赖的库、API、算法能按预期工作吗？性能瓶颈在哪里？
3. 商业假设：成本结构合理吗？定价能被接受吗？渠道能触达目标用户吗？
4. 资源假设：关键人员能按时到位吗？外部依赖（如第三方服务）能按期交付吗？

每类假设都有不同的风险特征。用户假设的验证成本最低——一个访谈或一个原型就能测，但往往被忽略。技术假设的验证成本可能高——需要写demo或做POC。商业假设的验证时机要早，但很多团队等到上线才关心。

一个决策框架：假设优先级矩阵

我们不可能验证所有假设，只能选最关键的几个。怎么选？两个维度：不确定性和影响。

• 不确定性：这个假设成立的概率有多低？低于50%就算高不确定性。
• 影响：如果这个假设错了，项目会失败或需要重大返工？

把假设画在四象限中：

• 高不确定性 x 高影响：致命假设，必须优先验证。
• 高不确定性 x 低影响：可以快速验证，也可以先放一放。
• 低不确定性 x 高影响：如果错了影响很大，但概率低，可以准备备选方案，但不必投入大量验证。
• 低不确定性 x 低影响：忽略。

实际操作中，小团队一般只需要识别出3-5个致命假设，然后花1-2周去验证。验证不通过，项目就应该暂停或调整方向，而不是继续投入。

如何验证假设？最小验证设计

验证假设不是写论文，而是做实验。每个假设对应一个“验证问题”和“通过标准”。

示例：假设用户愿意每天打开App三次

• 验证问题：用户是否真的有每天多次查看的需求？
• 验证方法：做一个简单的Landing Page，描述核心功能，观察注册率或预注册数。或者做一次面对面访谈，用户描述使用场景。
• 通过标准：80%的受访者表示“每天会用”，或者Landing Page转化率超过5%。

注意：验证方法要匹配不确定性级别。高不确定性假设，用最轻量的方法（访谈、问卷、原型）。如果假设本身风险低，可以跳过验证直接进入开发。

一个假设清单模板

项目启动时，团队可以开一个30分钟的假设识别会议。每个人写出自己认为的假设，然后归类、排序。最终输出一个假设清单，包含：

这个清单应该成为项目的一部分，定期更新。

失败的可能性

但是，假设验证也有风险。

1. 过度验证：如果每个假设都做精密的实验，项目还没开始就耗尽了时间。所以必须只验证致命假设。
2. 验证偏差：团队可能只找正面的证据，忽略反面的信号。比如访谈时只找友好用户，或者只测对自己有利的样本。解决办法：在验证前就写下“什么情况下我们会认为假设不成立”，然后严格按标准判断。
3. 假设过时：项目进行中，外部环境或用户需求可能变化。所以假设清单不能一次写完就扔，而要定期回顾（比如每两周或里程碑结束时）。

什么时候该放弃？

如果假设验证失败，团队应该果断暂停或转向。但现实中，小团队往往因为沉没成本而继续投入。一个简单的规则：如果致命假设中有两个以上验证失败，项目就应当重新评估，而不是继续做。

总结

项目启动时，列假设清单不是形式主义，而是把风险提前暴露，让团队在投入之前就有机会问自己“我们凭什么认为能做成”。小团队资源有限，最怕的就是在错误的方向上狂奔。假设清单就是那个“先停下来想一想”的节点。

PaxLee