黑帕云Office

黑帕云如何响应客户的需求

黑帕云产品经理日志。

🐨 是黑帕云的产品经理。

作为黑帕云的用户，你提出的大部分需求，都会由客户成功同事传达给 🐨，而她会通过一系列判断来确认你的需求会不会出现在我们的下一次迭代中。

那么她是如何确定是否采纳某个需求的呢？

下面这篇文章给你答案：

当需求来了

我们通常喜欢把已经付费的企业称为我们的客户，比如苏泊尔、诺瓦云、小特科技这样的企业。

对于客户，通常有足够多、足够深入并具体的业务场景来支撑他们的需求，所以作为产品经理的我会非常喜欢这类需求。

在黑帕云的需求反馈流程中，客户成功同事是客户的接头人。

是的，我们每位客户都有一位他充分信任的客户成功经理（Customer Success Manager，简称 CSM），当客户遇到了任何难题时，CSM 同学会非常周到地解决他的问题，无论是将业务数字化的过程还是对功能的疑惑。

当然，我们的产品也不是十分完美能覆盖客户想要的任何能力。遇到这样的情况时，我们的 CSM 会尽可能给产品经理提供更多的上下文业务信息，以便于节省我们之间的沟通成本。经过几次简单的引导，CSM 已经完全可以称为一个优秀的用户访谈研究员了。

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

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

要采纳这个需求吗？

收集到以上信息之后，产品经理会首先辨别这个需求有没有目前的解决方法。

如果有则告知客户可以利用其他方式来达到他的目的。如果没有，那就需要考虑需求的价值，我个人会从以下三个方面进行思考。

协作效率

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

所以一切能力都是为了提升用户使用的效率。

在下结论之前，我们首先要做的就是理解客户和业务。

如果在业务中，客户提的需求只是代表他自己的一个使用习惯的期望，那么这个需求 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 天（不含今天）的入住订单

这些无需多言的场景，也都在后面成为支撑我做功能设计的论据。

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

做产品也是做生意，成本是一个重要的决策因素。

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

优先级的决策没那么容易

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

战略性计划最难，它不是随便由产品经理们决定的。我们需要紧贴 CEO 对产品的规划，市场对产品的反馈，甚至销售对产品的建议。举个不那么敏感的例子：黑帕云移动端在 2021 年下半年的战略计划是「为存量用户提供移动场景的使用」。

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

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

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

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

小成本和大价值

如果有一天，销售同事或者客户成功同事跑来找你说，做了这个功能我们将获得一个多少钱的合同，你会怎么考虑？

作为一个产品型公司，我们的初心是缩短企业信息化建设的进程，让每个企业都能用上数字化工具，好用、解决问题、为用户提供价值才是我们关注的重点。我们绝对、当然不能被销售左右产品发布计划。

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

每个公司都有自己对用户需求的响应方式，本文无任何引导倾向和是非判断。并且以上方式仅代表笔者个人。

😉希望可以解答你关于“我的需求会不会被黑帕云采纳”这类问题的疑惑。

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