用户提出的'多选功能'背后，往往隐藏着未被言明的真实需求。从表面功能到深层痛点的挖掘，正是产品经理的核心价值所在。本文通过一个真实案例，揭示如何通过关键提问将用户提出的解决方案翻译回原始问题，最终实现超出预期的产品设计。

前两天团队里来了个刚毕业的产品新人，很有热情，接需求特别快。

有一次她收到一个用户反馈：“任务列表这里需要加个多选功能，可以一次选多个任务操作。”

她马上动起来了，画列表、勾选框、批量操作栏… 交互稿整齐又清晰。

但在需求评审时，我多问了一句：“用户为什么要在这里多选？选了之后通常是要做什么？”

她愣了一下，说：“用户就说要批量处理…”

“那批量处理的这些任务，之间有关系吗？比如都是同一个项目的？还是同一个客户的？还就是随便选几个？”

她答不上来了。

那一刻，我从她脸上看到了自己刚入行时的样子——接需求像接订单，用户说要什么，我就做什么。直到后来踩过坑才明白：用户给你的，往往不是需求，而是他基于自己认知拼凑出来的“解决方案假设”。

那个“多选”，真的只是多选吗？

我们后来一起回访了用户。聊深了才发现：

用户之所以想要多选，是因为他每个月要集中处理一批“关联任务”。

比如，某个客户合同到期前，需要同时关闭与之相关的“服务工单”、“账单计划”、“定期提醒”等一系列任务。

他现在得一个个找、一个个勾选，不仅慢，还容易漏。

所以，他要的不是“多选”，而是：

“当我选择某个主线任务时，系统能不能自动把和它相关的子任务都识别出来，一并处理？”

你看，从“多选”到“关联识别”，问题的本质完全不同了。

如果我们只做了多选，他依然要手动从几百条任务里挑出那几条关联项——体验根本没解决。

所以，接到需求时，先别急着画界面

我现在养成了一个习惯：每当接到一个明确的功能描述时，先停一步，问自己几个问题：

“这个动作，是在什么场景下发生的？”

（比如：是月底集中处理？还是随时随机操作？）

“用户做这个动作之前，之后，还连着哪些其他事情？”

（多选之前是不是要先搜索筛选？多选之后是不是要流转到另一个系统？）

“他真正想达到的效果是什么？”

（是想快一点？还是怕出错？还是不想来回切换？）

“如果我不做这个功能，有没有更轻量的方式帮他实现目标？”

（比如：能不能先做个“一键关联选择”？或者甚至优化现有筛选逻辑？）

从“听功能”到“挖痛点”，其实就两步

第一步：把解决方案翻译回问题

用户说“要A”，你就多问一句：“你是不是想解决B？”

用上面的例子就是：

“你说要加多选——是不是因为经常要同时操作好几个有关联的任务，现在选起来太麻烦？”

第二步：追问“为什么”直到触底

“为什么这些任务要一起处理？”

→ “因为它们都属于同一个客户合同。”

“为什么合同到期要处理这么多任务？”

→ “因为这是我们公司的服务关闭流程。”

“那流程里还有哪些相关动作？”

→ “还有通知客户、释放资源、更新财务状态…”

问到最后，你可能会发现：

用户要的不是“更好的多选”，而是“合同到期时，自动触发并跟踪整个服务关闭流程”。

写给那位新人，也写给自己

产品做久了，容易陷入两种状态：

一种是“用户说什么就做什么”，沦为功能组装工；

另一种是“我觉得用户需要什么”，陷入自嗨设计。

好的产品思维，大概是在中间某个位置——

既尊重用户的表达，又看透他未说出口的困境。

所以下次，当你再听到“这里加个按钮”“那里加个筛选”时，不妨先笑着问一句：

“咱们不急画图，你先跟我说说——你最近到底被什么流程困住了？”

或许那个真问题，就藏在他说出的“方案”背后。

后记

那个新人后来修改了方案，做成了“主线任务勾选后，自动推荐关联任务”。

上线后用户特别高兴，说“你们怎么知道我还需要这些？”

她跟我说：“原来做产品最爽的时刻，不是把功能做上线，而是猜中用户自己都没说全的那部分。”

我想，她已经开始“产品化思考”了。