很多一人公司不是因为没有能力而失败，而是先把能力投入成一个完整产品，再去寻找愿意购买的人。等你发现需求不清、用户不急、交付范围不断扩大时，开发成本和心理成本通常已经发生了。更稳妥的做法，是把“做不做产品”拆成连续的低成本决策：先确认问题是否真实，再确认目标用户是否愿意投入时间，接着验证付费或试用行为，最后才设计可重复的最小交付。

两周验证的目标不是做出稳定收入，也不是证明产品一定成功，而是获得足够证据，决定下一步是继续投入、调整方向，还是及时停止。

先定义验证对象：不是验证想法，而是验证行为

在开始前，你需要把“这个产品可能有人需要”改写成几个可以观察的问题：

• 哪一类人正在经历这个问题？
• 这个问题是否足够频繁、具体，已经影响时间、收入或工作质量？
• 他们现在用什么方式解决？
• 他们是否愿意为更好的解决方式投入时间、预算或资料？
• 你能否在不扩充团队的情况下，交付一个明确结果？

点赞、转发、口头称赞和“以后有需要我会买”，都可以作为线索，但不能作为继续开发的主要依据。对一人公司来说，更有价值的信号是用户愿意接受访谈、提供真实材料、预约演示、支付定金、提交订单，或者投入时间完成试用。

你可以用下面这条简单标准筛选问题：

真实问题 = 有明确对象 + 最近发生过 + 已经产生代价 + 用户正在采取行动。

如果只能描述“很多人应该会需要”，却说不出具体对象和最近一次发生的场景，先不要开发。

第一阶段：问题筛选，确定值得验证的一个场景

你要做什么

从自己的专业能力、过往客户经历或熟悉行业中，列出三到五个可能的问题。每个问题只写一页纸，内容包括：

1. 用户是谁，最好具体到职位、业务阶段或工作场景；
2. 问题在什么时刻发生；
3. 用户现在如何处理；
4. 处理不当会造成什么损失；
5. 你可以提供什么结果，而不是罗列哪些功能。

例如，你有内容运营经验，不要一开始就写“做一个内容管理工具”。可以先写成：“服务型个体经营者每周需要把客户咨询整理成可发布内容，但没有稳定的整理流程，导致重复沟通和持续拖延。”

你要收集什么证据

优先寻找已有行为证据：

• 用户是否已经购买过类似服务或工具；
• 是否使用表格、人工外包、临时脚本等替代方案；
• 是否反复在社群、评论区或咨询中提到同一困难；
• 是否因为这个问题延迟交付、错过销售机会或增加人工工作。

继续还是停止

满足以下条件，可以进入访谈：

• 问题对象足够明确；
• 你能找到至少一批可接触的目标用户；
• 你大致知道自己能在短期内交付什么结果；
• 用户当前已经在付出某种成本解决问题。

如果问题只能依靠大规模流量才能成立，或者必须先开发复杂系统才能让用户使用，就不适合作为首个低风险产品。你可以保留这个方向，但不要把它作为两周验证项目。

第二阶段：目标用户访谈，确认问题是否具体且紧迫

用户访谈不是向熟人介绍你的想法，也不是让对方替你设计功能。它的任务是还原过去发生的事情，判断问题的频率、代价和现有解决方式。

访谈问题应该围绕过去行为

可以这样提问：

• 最近一次遇到这个问题是什么时候？
• 当时具体发生了什么？
• 你是怎么处理的？
• 花了多少时间、预算或人工？
• 哪个环节最麻烦？
• 以前尝试过哪些解决办法，为什么没有继续？
• 如果这个问题下个月仍然存在，会有什么影响？

尽量少问“你觉得这个产品怎么样”“你会不会购买”。这类问题容易得到礼貌性的肯定，却不能说明购买意愿。

在两周计划中，你可以先联系一小批高度相关的人，完成若干次有效访谈。数量不是唯一标准，关键是访谈对象是否属于同一类用户，回答是否开始出现重复模式。不要为了凑数量，把完全不同的人群混在一起统计。

访谈记录至少包括四项

继续还是停止

可以继续验证的信号包括：

• 多位相似用户描述了相近场景；
• 用户主动谈到当前方案的成本或限制；
• 用户愿意让你进一步了解资料和流程；
• 用户接受一个明确的下一步，而不是只表示感兴趣。

应该停止或换题的信号包括：

• 用户只是认可问题存在，却没有亲身经历；
• 问题发生频率很低，且没有明显损失；
• 用户已经有满意且稳定的解决方案；
• 你需要教育用户很久，才能让对方理解为什么现在要处理。

第三阶段：预售或试用，验证真实投入

访谈只能证明问题可能存在，不能证明用户愿意接受你的解决方案。下一步要设计一个足够具体的行动邀请：预售、付费诊断、限量试用、预约服务都可以。

选择哪种方式，取决于你能否在交付前清楚说明结果。

适合预售的情况

如果你已经能明确描述交付结果，例如一份诊断报告、一套定制流程、一次实施服务或一个小型工具，可以直接提出预售：

• 面向谁；
• 解决什么具体问题；
• 交付什么结果；
• 什么时候交付；
• 用户需要投入多少钱和多少时间；
• 哪些内容不包含在内。

预售不等于用夸张承诺收钱。你应当说明这是早期版本，交付边界、退款方式和可能调整的部分都要写清楚。

适合试用的情况

如果用户需要先体验流程，或者你还无法准确估算价值，可以设计一个范围受控的试用：

• 只解决一个场景；
• 设置固定期限；
• 限制参与人数；
• 要求用户完成明确任务；
• 试用结束后安排反馈和转化判断。

免费试用也需要用户投入时间、资料或操作。完全无门槛的体验往往只能收集“还不错”的评价，难以判断实际价值。

你要观察的不是数量，而是投入程度

记录每位潜在用户处于哪一步：

1. 看过介绍；
2. 回复并提出问题；
3. 预约沟通；
4. 提供真实资料；
5. 完成试用任务；
6. 支付定金或全款；
7. 在交付后愿意继续使用或推荐。

可以把“口头认可”和“实际行动”分开统计。比如十个人说有兴趣，但只有一人愿意预约，这说明传播话术可能吸引人，却还没有形成足够强的行动动机。

继续还是停止

继续的条件，不是达到某个固定转化率，而是出现与目标用户一致的付费或高投入行为，并且你能解释这些行为为什么发生。

如果用户愿意试用，却不愿意提供必要资料，可能是价值不够明确，也可能是流程负担过重。如果用户愿意付费，但都提出完全不同的需求，说明方向尚未收敛，不宜立即扩展功能。

第四阶段：最小交付，只承诺一个可验收结果

最小可行产品不一定是功能最少的软件，也可以是由人工、模板、脚本和现成工具组成的服务。对一人公司而言，优先验证结果，通常比优先验证技术架构更低风险。

先写交付边界

交付说明至少写清楚：

• 输入是什么；
• 你会完成哪些步骤；
• 输出是什么；
• 用户如何判断完成；
• 交付几次、多久完成；
• 哪些请求属于额外工作。

例如，不要承诺“帮你搭建完整内容系统”，可以改为“在一次访谈和一份现有资料的基础上，交付一套未来两周可执行的选题与发布流程，包含模板、示例和一次修改”。

控制首个产品的复杂度

可以遵循三个限制：

• 只服务一种主要用户；
• 只解决一个高频场景；
• 只交付一个主要结果。

如果用户不断提出新需求，不要立即答应。先判断它是否直接影响核心结果。不能进入首个版本的需求，可以记录到候选清单，等完成复盘后再决定。

交付时收集三类证据

第一类是结果证据：用户是否真的完成了原本想完成的任务。

第二类是过程证据：哪些步骤最耗时，哪些说明不清楚，哪些工作必须由你亲自处理。

第三类是价值证据：用户是否认为结果值得支付的价格，是否愿意继续使用或购买后续服务。

如果每个客户都需要完全定制，你可能验证了咨询需求，却还没有验证一个可重复的产品。这个结论并不等于失败，但意味着下一步应当先标准化交付，而不是继续增加功能。

第五阶段：复盘，做出继续、调整或停止的决定

两周结束时，不要只看收入，也不要只看用户评价。把每个阶段的证据放在同一张表里：

可以继续投入的情况

• 目标用户相对集中；
• 问题和触发场景较稳定；
• 出现了真实付费或高投入行为；
• 你能在可接受的时间内交付；
• 用户反馈指向少数几个可执行改进，而不是完全不同的方向。

需要调整的情况

• 用户认可问题，但报价或交付形式不合适；
• 试用完成率低，可能是流程太复杂；
• 需求真实存在，但目标用户范围过宽；
• 交付结果有价值，却无法控制人工成本。

调整时一次只改一个关键变量，例如缩小用户范围、改变交付形式或重写结果承诺。不要同时改用户、价格、功能和渠道，否则下一轮仍然无法判断是什么因素产生了变化。

应该停止的情况

• 多轮接触后仍没有真实行动；
• 问题并不紧迫，用户没有理由现在解决；
• 交付成本持续高于用户愿意支付的价值；
• 每个用户都要求不同结果，无法形成清晰边界；
• 这个方向明显依赖你当前无法获得的资金、团队或渠道。

停止一个方向不是否定你的专业能力，而是停止继续为缺乏证据的假设投入。你可以把访谈记录、拒绝原因、交付难点和已验证的用户特征保留下来，作为下一次选题的资料。

把两周安排成连续决策，而不是连续开发

一个可执行的节奏可以是：

• 第1—2天：列出候选问题，选出一个具体场景，写出目标用户和交付结果；
• 第3—6天：进行访谈，记录过去行为，排除只有口头认可的问题；
• 第7—8天：设计预售或试用方案，明确价格、期限、范围和下一步行动；
• 第9—12天：完成少量最小交付，观察用户投入和实际使用；
• 第13—14天：整理证据，决定继续、调整或停止。

这个过程的核心不是把产品包装得更漂亮，而是让每一次投入都对应一个待验证的问题。你先确认有人正在处理问题，再确认对方愿意为解决方案投入，最后才决定是否值得把临时交付做成更稳定的产品。

对一人公司来说，首个产品最重要的成果往往不是功能清单，而是一组足以支持下一步经营决策的证据：谁愿意买、为什么买、你能否交付，以及怎样在不失控的情况下重复交付。