- 问题：目标客户经常遇到这个痛点，而且后果不容忽视。
- 受众：你能识别并触达那些有同样问题和触发场景的人。
- 方案：当前的工作流比他们现有的变通办法更能帮助他们取得进展。
- 交换：他们愿意为这个结果付出时间、访问权限、行为改变或金钱。
使用场景中文
资格边界
把创始人经常混为一谈的四类假设分开。
一个产品可能通过了某一个假设，却在另一个假设上失败。在选择测试之前，先诊断当前的风险。
- 把一次性的 AI 想法评分当作需求证明。
- 一个宽泛的市场规模统计数据，却没有证据表明你能触达的客户会采取行动。
- 来自无法使用或不愿使用该产品的人的夸奖。
- 又一轮功能冲刺，却没有明确的假设或验收测试。
最小完整工作流程
从产品成果走到一个可证伪的测试。
验证是一连串的决策，而不是一张证书。每一轮都应该让下一笔投入更容易被证明合理，或者更容易被叫停。
- 01
审视当前的产品成果
描述产品现在做什么、面向谁、承诺带来什么进展、第一个价值事件是什么，以及要求访客采取什么行动。
- 02
把假设写成可检验的陈述
写下问题、受众、方案和交换四类假设，让每一条都可能被可观察的证据推翻。
- 03
选出风险最大的假设
选择那个既不确定、又可能让下一轮构建白费的假设，并说明它为什么比其他假设更重要。
- 04
调研决策背景
用附带来源链接的调研，找出当前的替代方案、客户用语、社区、触发场景和相反证据。把它当作背景，而不是需求证明。
- 05
设计最小的真实测试
请合格的人采取一个行动：试用工作流、分享数据、约定后续沟通、再次回访、推荐他人或付费。事先定义阈值和停止条件。
- 06
审批并执行这个有边界的行动
审阅确切的目标、内容、渠道、成本和验收标准。公开发帖、私信、邮件、代码改动和部署都要走各自真实的审批路径。
- 07
决定继续、调整还是停止
当行为支持假设时继续；当受众或工作流接近但不对时调整；当核心问题、触达途径或交换意愿不存在时停止。
可检查的控制
审批卡片示例：风险最大假设的测试
这是一张示意性的任务卡片，不代表已声称的客户结果或已完成的实验。
- 目标
- 检验当前落地页的承诺，是否对应已经上线产品的独立 SaaS 创始人反复遇到的问题。
- 行动
- 对十条当前公开的问题陈述进行经审批的调研，然后准备一批五人的访谈名单，另行审阅。
- 对象
- 说英语、拥有上线网址、且近期有证据表明面临上线后需求问题的独立 SaaS 创始人。
- 验收标准
- 返回来源网址、原始的问题表述、相反证据、五个合格目标和一个拟定的测试。不要把调研中的出现频率当作愿意使用或付费的证明。
- 停止条件
- 如果符合既定受众和触发场景的来源少于三个，或者证据指向的问题与落地页承诺的不同，则停止。
修改拒绝按确切范围审批
验证交接模板
让「产品成果 → 决策」这条链路可以被审阅。
用来自实际产品和测试的观察证据填写这份交接材料。空白或相互矛盾的字段是有用的；编造出来的确定性则不是。
- 输入的产品成果
- 链接到所审阅的确切网址、代码仓库快照、路演材料、演示或落地页版本。
- 风险最大的假设
- 陈述一个可证伪的问题、受众、方案或交换假设。
- 为什么是这个风险
- 说明如果这个假设是错的，为什么会让下一轮构建失效或需要改变方向。
- 经审批的测试
- 记录目标、行动、内容、渠道、成本、验收阈值和停止条件。
- 返回的证据
- 把观察到的行为、直接表述、无回应、失败、相反证据和仍然未知的部分分开记录。
- 决策
- 选择继续、调整或停止；写明支撑该选择的证据，以及下一个被允许的行动。
决策记分卡
使用验证阶梯，而不是一个混合分数。
客户付出的时间、访问权限、习惯、声誉或金钱越多，证据就越强。
背景
可信的来源确立了品类、替代方案和用语。
问题证据
合格的人描述了问题的频率、后果和当前的变通办法。
投入
他们给出时间、数据、访问权限、推荐，或同意下一步。
首次价值
他们完成了目标工作流，并体验到预期的进展。
回访
在第一次有人协助的尝试之后，他们重复了这一行为。
付费
他们付费以继续获得这一价值。
当前产品边界
按今天实际能运行的功能来规划。
任何调研报告或自动化评估工具都无法单独验证需求。验证结论始终只适用于测试中的受众、产品状态、报价、渠道和所收集的证据。
调研
已上线经审批的调研可以研究市场、竞品、公开抱怨和潜在客户，并输出附带来源链接的结果。
X / Twitter
已上线（需 OAuth）经审批的 X/Twitter 工作可以通过已连接的账号发帖并收集回复。
冷邮件
Beta · 需要 Gmail邮件执行依赖 Gmail 以及任务上显示的审批模式。
使用调研和可审阅的草稿，公开发帖仍由创始人亲自完成。
广告
仅规划可以规划广告假设，但 Soloop 目前不购买或管理广告投放。
编码
审批后上线Coding Agent 可以在沙箱中实现并测试经审批的产品改动。
继续这个循环
当决策发生变化时，使用下一个资源。
常见问题
进行下一步之前的问题。
可以在动手构建之前验证 SaaS 想法吗？
可以在构建之前测试问题、受众、用语和投入意愿。这个工作流聚焦于已有真实产品成果的创始人，因为人们可以针对具体的承诺或工作流做出反应，而不是针对抽象的描述。
等候名单能证明想法已经得到验证吗？
不能。等候名单可以体现关注度，并提供可以联系的人，但合格用户的使用、回访和付费是更强的信号。请分别追踪。
Soloop 会给出 SaaS 验证评分吗？
不会。Soloop 的定位不是神奇的想法评分器。它帮助你组织经审批的调研和执行，让创始人可以基于可审阅的证据做出决策。
带上你已有的产品
带上你需要检验的假设。
复制简报并替换方括号，点击「从一个项目开始」后，将其粘贴到 Soloop 首页。此链接不会自动传递简报。先讨论测试；调研及其他行动需要各自的审批流程。
这是我已经做出的产品：[网址、演示或代码仓库]。我认为 [具体受众] 需要它，因为 [证据]。我最不确定的假设是 [假设]。请帮我选择一个小规模的行为测试，说明什么结果会让我改变判断，以及何时停止。区分公开调研与必须向真人了解的内容。任何执行都先提出方案供我审阅。从一个项目开始