立项验证：不写代码先确认有没有人需要
验证的意思是：在写代码之前，确认有没有人愿意为这个想法花时间、花钱或留联系方式。三种低成本方法：着陆页与等候名单、人工代办、访谈。验证通过的信号是具体的行动，不是客套的肯定。
为什么先验证
做出来没人用，是个人项目最常见的结局。验证的成本是一页说明加几次对话；不验证的成本是几周甚至几个月的开发时间。验证不是保证成功，是把“没人需要”这个结局提前发现。
三种低成本验证方法
着陆页与等候名单
一页说明：解决什么问题、给谁用、怎么用，留一个邮箱输入框。把链接发到目标用户出没的地方，看有没有人留邮箱。留邮箱的人数与来源，是第一批用户的线索。
人工代办
不用先写产品，手动替用户完成服务：用户提需求，人在后台手工处理。手动跑几单，就能知道需求是不是真实存在、流程里哪些步骤最费时间。手动跑不动的量，才值得写代码自动化。
访谈：问过去的行为
问对方过去是怎么解决这个问题的：上次遇到这个问题是什么时候、当时怎么处理的、花了多少钱或多少时间。过去的行为比未来的表态可靠。
判断信号
- 愿意留联系方式：留了邮箱或加了联系方式，等产品出来愿意试用。
- 愿意付定金或预付：愿意先付一部分钱，是最强的信号。
- 反复追问：主动问什么时候能用、支不支持某种情况。
- 已经在用替代方案：对方已经在为类似方案花钱或花时间，说明问题真实存在。
反信号同样要认：只说“不错”“有需要”却没有任何行动；问“多少钱”之后再无下文；点赞和转发很多，留邮箱的很少。
常见误区
- 问“会不会用”：对方出于客气会说会用，回答没有参考价值。改问过去的行为。
- 做完整产品再验证：功能越多，验证越晚。先验证需求，再决定做多少功能。
- 把点赞当需求：点赞的成本是零，留邮箱、付定金的成本是真的。
- 只问身边的人：朋友的肯定最不可靠，目标用户本人的行动才算数。
验证之后
验证通过后，定下最小可用的第一版范围：一个核心功能，解决验证中确认的那个问题。其他功能等第一批用户用起来再加。进入开发的环节见工作流总览，代码托管见代码托管列表，部署方式见部署与托管列表。