SaaS从业者如何与客户沟通好软件需求？

客户不懂软件，但他们懂业务。

“SaaS 从业者”——这个身份本身很广。

可以是客户成功，可以是产品经理，甚至是销售、实施顾问、解决方案架构师。但无论哪一个身份，我们都是需要通过跟 B 端客户沟通具体的业务需求来抽象出我们的产品、方案的定义。

那对于我们而言，“软件需求”又是什么？

这也有层次——是客户想要一个新功能？是他们不满意现有逻辑？是他们看到了竞品有某个能力？还是他们其实根本没想清楚要啥，只是说“你们能不能支持 XXX”？这里面很多时候需求本身是不成形的。

如果你只是做一个收集工作的话，其实很简单，有沟通技巧，简单地“听清楚客户想要什么”记录好交差就行了。

但如果想要你收集到的信息有效，你必然得——

1. 怎么识别客户说的，是表达的愿望、已有的流程，还是真实的痛点；
2. 怎么引导客户讲清楚自己都没捋清的需求；
3. 更难的是，在这背后，你怎么在“做不到”、“不适合做”、“不能做”中选一个体面但真诚的答复方式。

而我觉得这事之所以在 SaaS 里更突出，是因为软件是虚拟的，功能是抽象的，交付是滞后的，从 CS 的“成功”角度来看，客户说的“我想要一个报表导出”可能意味着潜台词是“我们老板不信你这个系统”，这时候你不能真的以为加个 Excel 按钮就能解决。

反过来说，客户其实也很痛苦。他们不是产品经理。他们表达的方式也许就是“能不能改一下 XX 的颜色”，但他们的真实问题是：“我们老板抱怨看不清那个按钮”。

所以我现在意识到——“沟通软件需求”不是“翻译”客户的语言，而是“再建构”这个语言的底层动机，并和内部团队一起去协商：我们要不要为这个动机开发功能？还是通过其他方式解决？

这让我想到几个关键词：同理、提问、澄清、翻译、再定义、博弈。

• 同理是你得站在客户那边看问题，不然你会觉得客户“要求太多”；
• 提问是你得问得动脑，不然你听到的只是“你们能不能做这个功能”；
• 澄清是你要确认“需求”真的成立，而不是客户的一拍脑门；
• 翻译是你得把客户的语境还原成产品团队能理解的语言；
• 再定义是你能不能基于系统能力重构客户的问题；
• 博弈是你明知道这个功能不能做，你怎么让客户接受替代方案。

所以某种程度上我其实挺欣赏产品经理的“独断”的，因为我也认同客户需求不是拿来“满足”的，而是拿来理解、筛选、引导、折中、重构的。

当然，这句话的前提是针对于真正的价值承载/交付物——产品而言。

只有你真正看懂客户，也真正理解产品，你才能在这两者之间，搭起那座有价值的桥。

而这，才是 SaaS 从业者，尤其是客户成功、产品经理、实施顾问们真正的核心能力。