先说结论：不会写需求文档，不耽误开发
被问「需求文档呢」吓退的客户，我们见过很多。实际情况是：需求文档本来就不该客户写——那是开发方的输出物。
客户真正要做的，是把三件事讲清楚。讲清了，文档和原型由开发方整理，双方确认无误再动工。
第一件：谁在用
用户是谁，决定了产品长什么样。
- 是来消费的顾客？年龄层大概多少？用微信的原生用户，还是要装 APP 的重度用户？
- 是来采购的经销商？内部员工？还是给门店店员用的工具？
同一句「做个商城」，卖给大学生和卖给经销商，是两个完全不同的产品。先定义人，再定义功能。
第二件：解决什么问题
这个问题要具体到场景，不能是「提升效率」这种口号。
试着回答：
- 现在这件事是怎么做的？（纸质登记？微信群里接龙？Excel 倒来倒去？）
- 麻烦具体在哪一步？
- 做好了之后，哪一步会消失？
举个例子：「现在门店接单靠微信群，客人发地址截图、店员手抄，经常抄错电话」——这句话比「想要数字化」有用一百倍。开发方从这句话里能提炼出地址库、自动填充、订单状态跟踪这些功能点；从「数字化」里什么也提炼不出来。
第三件：达到什么效果
效果要能验证。「做得高大上」不算效果，「上线三个月复购率从 15% 到 25%」才算。
如果暂时没有数据目标，至少回答：做到什么程度，你觉得这钱花值了？这个答案会成为功能优先级的排序依据——预算有限时，先保核心链路，装饰性功能往后放。
讲清三件事之后，流程怎么走
以我们的流程为例：
- 免费需求沟通：把上面三件事过一遍，我们出技术路线、开发周期和费用区间。免费，不付定金；
- 功能清单确认：开发方把口头需求整理成逐条功能清单，双方逐条过，该砍的砍。清单双方签字，成为合同附件；
- 原型与设计确认：界面长什么样、流程怎么走，原型阶段定。确认后再写代码——改原型比改代码便宜一个数量级；
- 进入开发：双周交付可运行版本，每两周你能看到、点到真实跑起来的东西。
一个常见反例
「我就要个和某某一样的小程序」——这句话我们每周都听到。
它的问题在于：你看得到对方的界面，看不到对方的后台逻辑，也看不到他们砍掉了什么。直接抄结果，往往抄出一堆自己用不上的功能，还漏掉自己业务的关键链路。
正确做法是把对方当参考，回到三件事：你的用户是谁、解决什么问题、做到什么效果。想清楚这些，参考才有意义。
最后
不会写文档完全不是障碍，讲不清那三件事才是。如果现在你只能说出「我想做个东西，让某某事方便一点」——足够了，从这里开始聊就行。