如何验证一个 SaaS 创意：从“有人抱怨”走到“有人愿意改变”

一句“这太烦了”只能说明情绪，不能说明市场。记录问题发生在什么任务、多久一次、造成什么损失、谁负责处理、为什么现在变得更重要。高频小摩擦和低频重大风险都可能形成产品，但需要完全不同的价值和定价。

寻找至少三类证据：不同的人独立描述相似问题、他们已经投入时间或金钱解决、问题在某个触发事件后明显升级。只有抱怨而没有行动，往往意味着需求真实但优先级不足。

面对一个抽象设想，大多数人会礼貌支持。更有价值的问题围绕过去和现在：上次遇到是什么时候？你做了什么？花了多久？最终为什么停止？如果下周再次发生，你会怎么处理？真实行为比未来承诺更可靠。

当展示方案时，不要只问喜欢什么。让用户完成一个具体任务、比较现有做法、指出必须保留的步骤，并提出真实交换：预约下一次、提供数据、介绍同事、签署试点或支付小额费用。行动承诺才让验证向前。

竞争对手不只是同类软件。表格、人工助理、搜索书签、群聊、外包服务和“暂时不处理”都是替代方案。理解用户为什么继续忍受它们，才能知道新产品必须好到什么程度。

如果用户已经有满意方案，你需要明确差异；如果他们什么都不做，你需要理解不行动的成本是否真的足够高。没有直接竞品并不自动代表蓝海，也可能代表问题不值得购买。

验证不要求先做完整平台。你可以手动完成服务、用原型演示关键结果、提供一次付费研究，或建立等待名单后逐一确认场景。最小版本的目的不是显得先进，而是让用户做出接近真实购买的选择。

同时设定停止条件：连续多少次访谈没有出现重复问题、多少人愿意投入、什么价格无法成立、哪个用户群明显更有反应。预先写下标准，可以减少因为投入太多而不断解释失败。

最终需要连起来的不是“痛点很多”，而是特定人群在特定时刻出现问题，采取可观察的寻找行为，认可某种结果，并愿意付出足够成本。任何一环缺失，都需要继续学习，而不是急着扩大开发。

建立一页验证记录：已确认事实、仍待证明的假设、反例、付费或时间承诺、下一次测试。随着证据积累，团队应该更少使用“我觉得”，更多说出“哪类用户在什么情况下做了什么”。

验证也要覆盖“不适合的人”。明确谁不会购买、谁的场景无法支持、谁只需要一次性服务，会让目标市场更真实，也能避免上线后用错误用户的沉默惩罚一个本来可成立的产品。

如果证据互相冲突，不要急着用平均值消除差异。不同规模、地区或成熟度的用户可能需要不同方案；先分清人群，再决定是否聚焦其中一类，而不是做一个谁都能勉强使用的产品。