独立开发者如何筛选需求：市场、竞争与可行性

找到问题之后，不应马上决定开发。需求线索只是候选项，还需要回答一个更现实的问题：这个问题是否值得投入接下来的时间？

问题可能真实，但用户太少；也可能用户很多，却已经被成熟产品覆盖；还有些问题看起来有价值，却找不到第一批用户。早期不必追求最大的市场，而是先找一个能触达、能验证、也能交付的切口。

先判断问题强不强#

应先把注意力放在问题，而不是市场规模。对每个候选需求，可以记录四件事：

问题多久出现一次？
不解决会造成什么具体损失？
用户现在用什么替代方案？
用户已经为替代方案付出了什么？

“希望效率更高”太宽泛，因为没说清楚到底哪里慢。“每周把同一批数据复制到三个系统，出错后还要人工核对”就具体得多，也更值得继续验证。

应优先选择已经存在替代方案的问题。用户正在用表格、脚本、人工服务、多个工具拼接，说明他们已经在为这个问题付出代价。需要判断的是，项目能不能提供更好的解决方式。

再判断市场是否可触达#

市场规模很大，不代表一定能触达用户。早期先找到一小群明确的人，再考虑更大的市场，不必急着估算一个漂亮的总数字。

可以用下面的问题检查触达难度：

能说出这类用户在哪里交流吗？
能用一句话描述他们的工作或身份吗？
能找到十个真实用户，而不是只找到行业报告吗？
他们是否已经在公开讨论这个问题？
是否有机会在一周内让其中几个人试用？

如果这些问题都答不上来，不应因为“市场很大”就继续投入。早期项目需要的是可触达的窄市场，之后才有机会扩展到更大的市场。

先把竞品当成证据#

看到竞品时，可以先把它当成一条线索：已经有人尝试解决这个问题，可以继续观察用户怎么使用、哪里不满意。

可以从四个角度看竞品：

观察项	需要确认什么
用户	它服务的是谁，是否和目标用户相同
核心任务	它真正帮用户完成了哪一个动作
价格	用户为哪一部分价值付费
差评和流失	用户为什么不满意，为什么离开

尤其要关注低分评价和“替代品”讨论。用户抱怨不是自动出现的机会，但它能帮助发现现有产品的边界：太贵、太复杂、缺少某个平台、学习成本高、结果不稳定，或者根本不适合某类小用户。

不应把“竞品功能列表”当成产品计划。复制十个功能，只会让项目进入一个更大的竞争范围。更有价值的问题是：能不能只解决竞品没有照顾好的一个场景？

判断是否适合独立开发#

可以把开发可行性拆成三个层次：

核心动作能否独立交付#

第一版必须完成一个完整动作，不能只完成流程的一半。例如，用户上传资料后，是否能得到可使用的结果；用户输入需求后，是否能得到可以执行的输出。

是否依赖复杂基础设施#

需要大量实时数据、复杂合规、重运营、线下履约或高额算力的项目，不一定不能做，但不适合拿来做第一次验证。独立开发应该先选择可控的核心环节。

是否能在短周期内得到反馈#

如果做完第一版要几个月，才知道用户是否需要，风险就太高。更适合选择可以在几天内做出手工版本或可点击原型的需求。

需求评分表#

可以给每个候选需求从 1 到 5 分，分数只用于比较，不代表精确预测：

维度	1 分	3 分	5 分
问题频率	偶发	每月	每周或每天
问题损失	几乎没有	有时间损失	有明确金钱或机会损失
付费迹象	没有	有替代性支出	已有稳定付费
用户触达	找不到人	有零散渠道	有清晰社区或名单
竞争空隙	没有空隙	有小缺口	有明确未满足场景
MVP 难度	数月以上	数周	数天可完成
后续使用	一次性	偶尔使用	高频重复使用

不必把所有分数简单相加。付费迹象和用户触达是两道门槛；这两项都低时，技术再可行也不该马上开发。

90 分钟筛选流程#

当存在多个候选需求时，可以用 90 分钟做一次快速筛选：

前 20 分钟：写清问题。 每个候选项只用一句话描述用户、场景、任务和当前替代方案。

接着 25 分钟：找现有方案。 记录三个竞品或替代方案，重点看定价、差评和用户抱怨。

再用 20 分钟：确认触达方式。 写出可能的社区、搜索词、平台或第一批用户名单。

最后 25 分钟：评估 MVP。 写出一个用户动作和一个可交付结果，估计能否在几天内完成手工版或原型。

可以把剩下的时间用来写下一步验证动作，而不是继续搜集更多资料。筛选的结果应该是一个可验证假设，而不是一份几十页的市场报告。

常见的错误判断#

只看市场规模#

市场报告可以说明行业存在，但不能说明一定能找到用户。早期应优先判断触达和交付。

只看竞品数量#

没有竞品可能是机会，也可能是没人需要。竞品很多可能竞争激烈，也可能说明付费需求稳定。数量本身不能替代用户证据。

把技术难度当成护城河#

难做不等于有价值。用户不愿意使用的复杂技术，不能形成产品优势。

一开始就追求完整市场#

不必一开始服务所有人。一个足够窄、足够明确的用户场景，反而更容易验证和传播。

最终输出：一张决策卡#

筛选结束后，可以把候选需求整理成一张决策卡：

1
目标用户：
2
具体场景：
3
核心问题：
4
当前替代方案：
5
已有证据：
6
竞品空隙：
7
第一批用户在哪里：
8
MVP 的一个核心动作：
9
48 小时内要验证的假设：
10
继续的条件：
11
停止的条件：

如果最后三项写不出来，说明问题还没有想清楚。下一步应回到用户和场景，重新收集证据。

筛选后的决定#

筛选需求时可以按这个顺序检查：

问题强度 → 用户触达 → 现有替代方案 → 竞争空隙 → MVP 可行性 → 后续使用。

独立开发不必一开始就选出“绝对正确”的方向。先用低成本排除明显不值得做的选项，把时间留给最容易拿到真实反馈的候选项。

下一篇会讨论如何验证用户是否愿意付费，而不是只得到一句“这个想法不错”。