黑帕云是怎么响应客户的需求

01 当需求来了

我们通常喜欢把已经付费的企业称为我们的客户，比如苏泊尔、诺瓦云、小特科技这样的企业。
对于客户，通常有足够多、足够深入并具体的业务场景来支撑他们的需求，所以作为产品经理的我会非常喜欢这类需求。

在黑帕云的需求反馈流程中，客户成功同事是客户的接头人。
是的，我们每位客户都有一位他充分信任的客户成功经理（Customer Success Manager，简称 CSM），当客户遇到了任何难题时，CSM 同学会非常周到地解决他的问题，无论是将业务数字化的过程还是对功能的疑惑。
当然，我们的产品也不是十分完美能覆盖客户想要的任何能力。遇到这样的情况时，我们的 CSM 会尽量给产品经理提供更多的上下文业务信息，以便于节省我们之间的沟通成本。经过几次简单的引导，CSM 已经完全可以称为一个优秀的用户访谈研究员了。

我们一般需要这些信息来帮助自己做采纳决策和功能设计：

• 身份信息：客户在企业中的角色、业务中的角色
• 业务信息：客户在什么业务场景下有这样的需求
• 目的信息：客户想要这样的能力来做什么，或者说我们提供这样的能力能帮助他怎么样

02 要采纳这个需求吗？

收集到以上信息之后，产品经理会首先辨别这个需求有没有目前的解决方法，如果有则告知客户可以利用其他方式来达到他的目的。如果没有，那就需要考虑需求的价值，我个人会从以下三个方面进行思考。

🔹协作效率

黑帕云是一个帮助企业信息化、数字化的工具，所以使命必然是要为企业提供效率，以此在一定程度上实现增收降本。
所以一切能力都是为了提升用户使用的效率。

在下结论之前，我们首先要做的就是理解客户和业务。
如果在业务中，客户提的需求只是代表他自己的一个使用习惯的期望，那么这个需求 90% 的概率将会被我判断为“真不幸，你要被拒绝了”，剩下 10% 的概率是如果有这个功能，多数人的使用效率会大大提升。

“真不幸，你要被拒绝了”这类需求有这样一个共同点：出发点非常私人化，并且场景和我们想要提供的服务不那么匹配。
比如在前阵子，我们收到了这样的需求反馈：“我的工作电脑经常被其他人使用，我希望我可以为我的几个黑帕云的应用分别设置独立的密码，防止那些机密信息被别人看到。”
据大众所知，现在已经很少有一台工作电脑让多个人使用的情况了。如果有，那可能是公共的一些设备，比如图书馆的查书系统、医院的打印报告系统、商场的帮助系统。而这些，并不是我们要服务的客户。
至少在现在完善企业核心业务场景的这个阶段，我们不会采纳这样的需求。
不过或许有天我们发现，工作电脑被借用的情况非常普遍，非常有必要像有道云笔记那样给文档上锁的时候，再来回头看看这个需求吧。

如你所想，「拒绝」和「采纳」只是相对的。有些结果只是当下阶段的决策，“当下阶段”有时候会久一点，有时候也可能只维持了三个月。

剩下 10% 的符合多数人的使用习惯的情况，可以举这个例子来解释：
“在表格中，我想要在指定位置插入一条数据。”

这条需求来自一个刚注册的用户，他甚至还没有付费就向我们反馈了一些使用上的需求，但我们毫不犹豫采纳了。
毫无疑问，这是使用 Excel 的习惯。当他在黑帕云中看到熟悉的表格时候，他想要做一些和 Excel 操作一样的事情，比如上述的“指定位置插入数据”。
当他笃定地认为我们一定提供了这样的能力，并且自信地选中一个单元格点击了右键，他看到的结果让他傻眼了。我猜他内心 OS 一定是“WTF？？你们是来搞笑的吗？？”

虽然在一个正经的数据管理系统中，不太可能让你点击一条订单或者一个销售线索，然后右键就有“向上添加一条订单/向下填写一条订单”的操作选项。
采纳的原因就不多赘述了，毕竟大家都会这么干。不然你以为设计师们从 Sketch 为什么那么容易替换成 Figma？

🔹需求的普适性

在此之前，我们先要共识一下产品的定位，然后再谈需求普适性。因为如果这个需求不符合产品定位，那就完全陷入了伪命题的陷阱中了。

黑帕云的定位从来都是是企业级的数据协作工具。
想传递给用户的是“像Excel一样熟悉，又像数据库一样强大”的感受，所以指导我们做产品的方针一直都是给用户提供无缝切换 Excel 的体验，又强如数据库一样的业务系统。
我们会格外注意企业的业务场景，比如会严格把控企业对数据完整性的要求，通过字段类型、必填、格式校验、数值校验来保证填写规范。

当一位企业客户提出：“我是一个财务，我要管理发票的回款。在填写回款明细的时候，我希望“回款日期”不能超过今天。”这样的需求的时候，我们毫不犹豫地说：“Yes! I DO! 🌹”

确定了是否符合产品定位后，我们需要辨别这个客户的场景是有独特的业务属性吗？
在了解客户的业务之后，我就开始了疯狂找场景的阶段。搜索自己的记忆或者在 CSM 维护的需求反馈表中找出其他客户有没有遇到同样的困扰。

一个具备「普适性」的功能，我能找出 100 个这么能打的场景：

• 某旅游团只允许 18 岁-65 岁的用户下订单，所以出生日期需要早于 2003-01-01，晚于 1956-12-31 年
• 某博物馆门票预定只能购买第二天门票
• 酒店预定只能预定最近 7 天（不含今天）的入住订单
• ……

这些无需多言的场景，也都在后面成为支撑我做功能设计的论据。
不过一定要注意，辨别场景的真伪。比如说你发散思维头脑风暴了“万一用户可能想要这样的能力：填写博物馆门票订单时，管理员可以填写今天的日期，但是普通申请人不能填写今天的日期。（因为管理员想走后门给亲戚便利）”——但是实际上没有人想这么干😅。

🔹实现成本

做产品也是做生意，成本是一个重要的决策因素。
这就要求我们有一点点技术感知或者足够的程序员友好度。在分析完用户真的想要啥之后，在具体功能设计方案前，大概判断一下要实现这个需求有哪些方案。接着用你的方式评估方案成本，看看方案们会花费多少人力。

03 优先级的决策没那么容易

即便是已经决定“采纳”客户的需求了，那总要有个先后顺序吧。
计划，是大家通用的做法。我们每半年做一次“战略性”计划，每季度做一次“指导性”计划，每个 Release 做一次详细的“发布”计划。

战略性计划最难，它不是随便由产品经理们决定的。我们需要紧贴 CEO 对产品的规划，市场对产品的反馈，甚至销售对产品的建议。

举个不那么敏感的例子：黑帕云移动端在 2021 年下半年的战略计划是「为存量用户提供移动场景的使用」。

所以一切发布都是围绕“现在的用户”，基于此，我们的手段是以下两招：

拆解到季度计划中，会包括大概的季度主题。

有了这样的“指导性”计划后，所有的优先级就可以找到理由了。

不过这些计划不一定都会落实，因为总会有一些突发状况。比如销售的压力，请参考下一章「小成本和大价值」。

04 小成本和大价值

如果有一天，销售同事或者客户成功同事跑来找你说，做了这个功能我们将获得一个多少钱的合同，你会怎么考虑？
作为一个产品型公司，我们的初心是缩短企业信息化建设的进程，让每个企业都能用上数字化工具，好用、解决问题、为用户提供价值才是我们关注的重点。我们绝对、当然不能被销售左右产品发布计划。

人人都想当站着挣钱的姜文。但是一个合同金额不菲的签单诱惑就在眼前，并且这个功能投入的研发成本只有半周时间；如果只是这个客户的需求只是加速了原本事情的发生呢？——他没有破坏产品的计划，只是这个事本来在年底发生，但是九月份被提出了。你还那么想吗？

05 写在最后

每个公司都有自己对用户需求的响应方式，本文无任何引导倾向和是非判断。并且以上方式仅代表笔者个人，无关公司立场。
😉希望仅对广大读者一些参考和思考。

写在最最后

如果你觉得这篇文章语气措辞有点奇怪，这一定是我最近看《欲望都市》看多了的原因。
欢迎和交流吐槽 Big 这个渣男和没啥界限的女主 Carrie。看到第四季 Carrie 邀请 Big 来她和 Aidan 过周末的乡下小屋那段，代入 Aidan 我直接是气疯了🙂。
我的联系方式见关于我。