开发前验证付费意愿，核心不是询问用户“想不想要”，而是观察其是否愿意为解决一个正在发生的问题投入时间、数据、流程迁移成本或金钱。用户认可某个产品方向，只能说明概念容易理解；只有当用户愿意试用、提供真实业务信息、安排测试，甚至支付早期费用时，需求才接近可购买状态。

验证应从具体问题开始，而不是从产品功能开始。先明确第一批用户是谁，他们最近一次遇到问题是什么时候，当前用什么方式解决，现有方案造成了怎样的时间、人力或协作损失。访谈中，“很需要”“如果有一定会用”这类形容词价值有限，更应追问已经发生的行为：是否尝试过替代方案，是否为此付出过成本，谁能够决定购买，谁实际负责付款。

竞争分析也必须服务于付费验证。不能只罗列功能，而要同时考察直接竞品、表格、文档、聊天工具以及人工流程等替代方案。用户为什么不继续使用现有方式？迁移数据和工作流程是否麻烦？新方案解决的是一个具体结果，还是仅仅重新组合了待办、标签和提醒？如果用户对现有工具没有明显不满，就不应急于开发，而应继续寻找高频、损失明确且尚未被满足的细分场景。

用小成本测试购买行为

较稳妥的顺序是先验证问题，再验证承诺，最后验证产品。可以用落地页、演示稿、低保真原型或人工服务交付一次结果，观察用户是否愿意留下真实联系方式、预约演示、提供数据或参与试用。最小版本也不应是功能缩减后的通用平台，而应只服务一类用户、一个核心流程和一种明确结果。

投入数月开发前，还应提前设定停止条件：如果连续访谈和测试都没有真实购买信号，是否继续开发，还是缩小范围或转向。老周投入 3 个月却没有付费用户的案例，不能证明任务管理工具没有市场，却说明一个关键顺序：技术可以验证“能不能做”，行为信号才能验证“有没有人愿意买”。