产品线怎么规划？我砍掉4个想法
立项那天我往文档里塞了 12 个选题，兴奋得睡不着。两周后再打开，我发现其中 4 个想法必须砍掉，否则一个都做不成。独立开发者产品线怎么规划？我的答案：先砍到只剩 1 条主线，砍不动的全砍。
砍掉那 4 个想法的时候心疼，现在回头看，那是整个立项期最值钱的一次操作。
最贵的一课：我以为想法多是优势
我曾经把"手里有 12 个选题"当成资产。
实际上那是负债。每多一个想法，就多一份注意力被分走，多一套要维护的说明文档，多一条要回复的咨询线。
一人公司的配置是 1 个真人加 5 个 AI 员工。AI 能放大产能，但放大的前提是方向只有一个。方向一多，AI 员工也在各干各的。
坑一：想在一条产品线上覆盖两类人
我最初的产品线想同时服务两类人——一类是自用型开发者，一类是接单型的服务商。
这两类人的需求节奏完全不同，自用的要便宜好用，接单的要能改能交付。 一套东西同时满足两边，最后两边都觉得不对味。
我现在的做法是先选一边。源码模板的三档定价（¥99 / ¥249 / ¥499）就是服务"想自己动手做产品的人"，不服务接单交付场景。
怎么避：写产品线时先写清楚"我不服务谁"，比写"我服务谁"更有效。
坑二：把技术栈当成产品线
我做 Cocos 3.8.x 那套涂色模板时，一度想按技术栈来铺产品线——Cocos 一条、Web 一条、Java 一条。
技术栈是能力，不是需求。 用户不会因为你会 Cocos 就买单，他买的是"能上架的小游戏"。
按技术栈铺线，结果就是每个方向都做了一点，没有一个能拿出来卖。而我做完那套模板只用 2 天、AI 批量生成 20 张线稿——快是因为目标单一，不是因为技术栈多。
怎么避：产品线按用户要完成的事来分，不按你会什么来分。
坑三：把"以后可以做"当成产品线的一部分
我那 4 个被砍掉的想法里，有 3 个被我写过"以后可以做"。
"以后可以做"是产品线最常见的伪装。 它让你觉得规划很完整，实际上让你在每个方向上都不敢投入。
我现在的判断很粗暴：三个月内不会动手的，从文档里删掉。 删掉不是放弃，是不让它占位置。
怎么避：给每个想法标一个"什么时候动手"，标不出来的就移出当前产品线。
止损清单：产品线膨胀时怎么收
- 数一数手上有几条线，超过 1 条主线就准备砍。
- 写下不服务的对象，写完还觉得模糊，说明定位不清。
- 按用户任务分类，不按技术栈分类。
- 给每个想法标动手时间，标不出的移出。
- 确认老产品是否还在自然进量，还在涨的别砍。
- 确认是否同时在推两个方向，是的话立刻停一个。
动作：今晚就把产品线文档打开，按上面六条逐条过一遍，砍掉的所有内容存到一个"以后再看"的文件里。
独立开发者产品线怎么规划：我现在的样子
只剩一条主线：自媒体创作工具。
从生成到诊断到发布，先自己用起来。这条路我 2026-07-24 立项时就在跑，跑过 7 轮迭代，没有换过方向。
旁边的支线只有一条，而且是被动的——源码出售存在，但不主动推广，有询单就接。
这就是我能承受的产品线宽度。 再多一条，我就得从别的地方抽时间，而我已经没有别的地方可抽了。
常见问题
Q：独立开发者产品线怎么规划才不贪多？
A：先砍到 1 条主线，再给每个想法标动手时间，三个月内不会动手的全部移出。产品线按用户要完成的事来分，不按技术栈分。同时明确写下"我不服务谁"。
Q：砍掉的想法以后还能捡回来吗？
A：能，但要放进单独的"以后再看"文件，不要留在当前产品线里。留在文档里就会持续占用注意力和决策成本，这是膨胀的开始。
Q：怎么判断一条产品线该不该砍？
A：看它有没有独立的目标人群和独立的价值主张。如果只能靠"顺便做做"来维持，就该砍。反过来，老产品还有稳定自然进量的话，别急着砍。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」