深度文章

先别急着写代码：十小时的用户访谈，能省三个月返工

十小时的用户访谈，能省三个月返工

本文回答的问题：用户访谈该做多久怎么做　先写代码还是先访谈用户　十小时用户访谈能省多少返工
一句话结论：十小时的用户访谈，能省三个月返工

51Kaifa · 2026-10-18 · 约 6 分钟读完

常有创始人带着写好的需求文档来找我们：功能清单两页，原型图十几张，开口就问「这个多少钱、多久能做完」。我们一般会先反问一句：这些功能，你跟几个目标用户当面聊过？大部分时候，答案是零。

这不是挑刺。创业项目死得最多的原因，不是做不出来，是做出来没人要。CB Insights 复盘过上百家倒闭的初创公司，排在第一的死因是「没有市场需求」，占 42%，比「钱花光了」（38%）还高。也就是说，一个项目最大的风险不在开发阶段，在动笔之前。

十个小时的访谈，顶三个月的开发

尼尔森诺曼集团做过一个著名测算：找 5 个目标用户做测试，就能暴露约 85% 的可用性问题——样本再往上加，新发现的问题急剧递减。我们陪跑项目的经验也类似：认真访谈 10 到 15 个目标用户，聊到第八九个的时候，听到的抱怨就开始重复了。重复出现的那一刻，需求清单就自己浮出水面了。

算笔账：10 个用户，每人聊 30 分钟，加上约人和整理记录，总共十几个小时。而一个做歪了的核心功能，开发两三个月，推倒重来再花一遍钱、再烧一遍团队士气。我们见过最可惜的一个项目：团队闷头做了四个月的「多账户管理仪表盘」，上线才发现真实用户九成只有一个账户——这个事实，三个电话就能问出来。

理由都差不多：「用户自己也不知道要什么」「问出来的都是伪需求」「乔布斯从来不做市场调研」。这些话半对——用户确实说不清解决方案，但他们说得清自己遇到过的问题。访谈要问的不是「你想要什么功能」，而是「你上次遇到这个问题，是怎么解决的」。前者换来的是客气话，后者换来的才是事实。

《The Mom Test》里有条原则值得直接抄下来：别问未来的承诺（「出了这个功能你会付钱吗」——没人会当面说不），只问过去的行为（「你上次为解决这个问题花钱是什么时候、花了多少」）。用户过去为一个问题付过的钱、花过的时间、绕过的弯路，才是需求强度的真实刻度。嘴上说的「肯定会用」，一分钱不值。

写代码前，访谈 10 个目标用户，每人半小时。只问三件事：这个问题你多久遇到一次？上次是怎么解决的？为此花过多少钱或多少时间？全程记录原话，不按自己的理解改写——原话里的词，以后就是产品文案和页面标题的词。
把访谈整理成一页纸假设。谁、在什么场景、因为什么痛、愿意付出什么。写得出一页纸，才轮到画原型；写不出来，说明访谈还不够，回去继续问。
用最小的方式验证假设，再正式开发。一张 landing page 收预约、一个可点击的 demo、甚至一份人工服务的「假产品」，都能先验一轮。验证本身花不了多少钱，验证错了也不亏钱——亏钱的从来都是跳过验证直接开工。

一句话总结：好产品不是猜出来的，是问出来的。十个小时的访谈换三个月不返工，是早期项目里性价比最高的一笔交易。

这也是 51Kaifa 接项目时的固定动作：开发排期之前，先和客户一起把目标用户、核心场景、验收标准写成一页纸，对齐了才动工。需求清楚了，两周的 MVP 才不会拖成三个月的返工。方向对了，做得快才有意义。