图 1：本文封面，漏斗就是独立开发的真实形状：想法很多，能活着到底的很少。
很多工程师做第一个独立产品的轨迹惊人地相似：某天灵光一闪想到个点子，兴奋地写了两三个月代码，打磨到自以为完美，上线，然后——没人来。复盘时大家习惯归咎于「不会推广」，但更常见的原因是顺序错了：先写代码，后验证需求，把最贵的投入押在了最没被验证的假设上。
核心结论一句话
第一个产品要按漏斗走五步：需求发现 → 关键词验证 → MVP 范围裁剪 → 技术选型 → 上线收反馈。每一步右侧都有一个「淘汰出口」：验证不过就换题，不带着沉没成本硬撑。这套流程的核心纪律是每一步都在为下一步省钱——最早的验证，成本最低。
第一步：需求发现，从身边找题。
好题目有两个可靠来源：一是自己的痛点——你天天遇到、忍了很久、愿意为解决方案付费或付出的麻烦；二是社区里的抱怨——论坛、问答区、同类产品的差评区，抱怨就是没被满足的需求清单。判断标准一句话：我自己愿意天天用吗？连你自己都不会天天用的工具，指望陌生人天天用不现实。看社区抱怨时多一步甄别：同样的问题有没有不同的人反复提起，零星的吐槽是个案，成片的抱怨才是机会。
第二步：关键词验证，先证明有人在找。
点子有了，别急着写代码，先问一个问题：遇到这个麻烦的人，会去搜什么词？把这几个词丢进搜索趋势工具看看热度走向——以 Google Trends 为例，它基于真实搜索的匿名样本，但给出的是按比例缩放到 0 到 100 的相对热度，不是绝对搜索量，所以看趋势走向和词与词的相对高低可以，别拿它当精确人数。再直接搜一遍这些词：已经有竞品存在不是坏事，恰恰证明有人愿意为这个需求花时间花钱；一个词完全没人搜、一个竞品都不存在，反而要警惕是不是需求本身不成立。
第三步：MVP 范围裁剪，只留主链路。
最小可用产品的标准是：用户能走完一条核心链路并拿到价值，仅此而已。裁剪时反复问「砍掉这个功能，核心价值还在吗」——注册登录能不能先用最简单的方案，后台能不能先用人工，报表能不能先不做。能手工的先不自动化，能借现成服务的先不自建。每个砍掉的 feature 都是在给「快点见到真实用户」让路。
第四步：技术选型，用最熟的栈。
第一个产品的目标是验证需求，不是技术展示。用你最熟的语言、框架和部署方式，哪怕它不够时髦——熟悉意味着遇到坑能立刻爬出来，新栈意味着把「学框架的时间」从「验证需求的时间」里扣。速度优先于优雅，能跑优先于能扩展；真有十万用户那天，重构是幸福的烦恼。
图 2：五步漏斗与每步的淘汰出口。
第五步：上线收反馈，让小范围用户教你。
上线不是终点，是验证的开始。先小范围发布——发给目标用户聚集的社区、发给身边符合画像的朋友，观察他们是否真的用、卡在哪一步、抱怨什么。真实使用留下的痕迹，比任何上线前的自我推演都值钱；然后按反馈迭代，而不是按自己的想象加功能。
三个常见误区
误区一：先写代码后验证。代码是最贵的验证手段，关键词搜索和竞品调研一个下午就能做完，而写完才发现没人要，代价是几个月。误区二：把 MVP 做成完整产品。范围每扩大一分，见到真实用户就晚一天，「最小」两个字是纪律不是妥协。误区三：借第一个产品学新技术栈。学习目标和验证目标抢同一段时间，第一个产品请让验证赢。
给你的行动建议
今天就做一轮低成本演练：列出三个你自己天天遇到的小麻烦，给每个麻烦拟出用户会搜的两三个关键词，查一遍趋势走向和竞品存在性，淘汰到只剩一个，然后为它写一句话价值主张——「帮什么人，在什么场景，省掉什么麻烦」。写不出这句话的题目，不进开发阶段。
你做第一个 side project 时，卡在了哪一步？欢迎聊聊。