如何定义一周内可验证的一人公司MVP核心假设

一人公司创始人常把“我想做某个工具”误当成“我有一个待验证假设”。前者描述的是方案，后者描述的是可被现实否定的判断。一周内可验证的 MVP 核心假设，不是要证明方案能做成，而是要在极短时间、极小交付下，观察某类具体用户是否愿意用真实投入换取一个明确结果。定义这条假设，实际是在设定实验边界。

一个合格的周验证假设应满足四个条件：人群可主动触达、问题可从回忆中确认、交付结果可当场感知、承诺动作可被记录。人群不应是“所有自由职业者”，而应窄到可以列出联系名单，例如每月同时管理多个客户项目、容易遗漏交付节点的自由职业者。问题不应停留在“效率低”这类感受，而要能追问出上一次发生的场景、时间成本和替代处理方式。交付可以很轻，但必须完整：用户能看到一个文件、一个节点表或一次人工整理的方案，并能判断它是否解决了问题。最后，必须存在比点击和浏览更强的行动，例如预约一次访谈、提交一份真实任务或支付小额费用。

定义假设时，更可靠的做法是从证据倒推。先确定周末需要看到什么行为才足以继续，再决定本周的人群和交付范围。如果把“愿意付费”作为目标，就不能用访问量或注册数作为成功标准；更合适的信号是预约一次人工试用，因为它要求用户暴露真实需求并付出时间。假设句也应该写成可证伪形式：面向某类具体人群，在某问题发生时，通过某种最小交付获得某结果，并愿意用某种具体承诺表达需求。例如，与其说“为自由职业者做一个项目管理工具”，不如说“面向每月同时管理多个客户项目的自由职业者，提供自动整理交付节点的服务，减少交付遗漏，并愿意预约一次付费试用”。后一种写法直接划定了招募对象、问题场景和验证终点。

真正决定一周验证质量的，不是假设写得有多完整，而是它是否排除了无关路径。登录、权限、自动化后台、多端适配等若不影响客户感知结果，就不应进入本周范围。核心假设只需要承担一个任务：用最小可见结果，换来一次能够解释下一步选择的真实用户行为。若一周后只有礼貌反馈而没有承诺动作，结论应指向假设不成立或人群不准确，而不是立即增加功能。