问客户想要什么行不通

“问客户想要什么”的局限

• 很多人认为，客户往往描述的是接近他们现有方案的东西，而不是真正能帮助他们的东西。
• 需求经常彼此矛盾或互相排斥；人们只有在被追问时才会意识到其中的取舍。
• 叫得最响的少数人会扭曲感知到的需求（例如，小手机、带口袋的连衣裙）。
• 也有人认为，这个标题式观点被过度使用，常被当作忽视真实用户需求的借口。

聚焦问题 / Jobs-to-be-Done

• 很多人强烈支持去问：“你在解决什么问题？”或者“你雇用这个产品来做什么工作？”
• 奶昔和通勤的故事：只有理解了真正的任务（开车时方便吃早餐、更短的通勤时间），改进“产品”才说得通。
• 同样的视角也被应用到 AirPods、Segway 对比滑板车、汽车对比“更快的马”。

观察 vs 直接提问

• 观察用户如何工作（屏幕录制、跟随观察、支持例会）被认为比用户自报需求更有洞察力。
• XY 问题：用户描述的是他们自己提出的解决方案；你必须深入挖掘才能找到底层痛点。
• 不过，也有人抱怨，过度热心的“你其实并不想要 X”式回应在 X 确实经过深思熟虑时会让人非常恼火。

产品愿景 vs 反馈

• 这里区分了两类：
  • 有远见的产品创造（直觉、先前研究、时机）。
  • 迭代式打磨（可用性测试、修复 bug、理顺混乱流程）。
• 像触屏手机这样的例子表明，即使违背了用户明确表述的偏好，只要整体体验更好，仍然可能成功；不过失误（没有应用/3G/复制粘贴）也说明愿景并非万无一失。

验证、MVP 与实验

• 有些人坚持“在验证之前不要动手构建”；另一些人则说，他们最好的作品来自先为自己已知的问题做产品。
• 验证可以意味着：存在一个痛点、用户已经用拼凑方案在解决、用户愿意付费承诺，或者在完整实现前进行快速低成本实验（人工流程、快速开关）。

企业/B2B 的复杂性

• 买家 ≠ 用户：某些功能可能只是为了满足采购、合规或检查清单而存在（例如 SAML/SSO），即使几乎不用。
• 销售驱动的功能需求（“没有 X 就签不下来”）很常见；有时合理，但往往并不正确，而且会带来长期维护上的高成本。

总体结论

• 广泛倾听，但不要照单全收；要综合提炼，而不是逐字落实。
• 询问用户想要“做什么”、他们“不想要什么”，以及他们实际上愿意为什么付费。
• 自己真正在用自己的产品，这一点反复被提到，被认为是极强的指引。