为什么「简洁」是 B 端产品的第一原则？

几个月前，我参与了一次 SaaS 产品的客户演示。销售同事在台上展示了 20 分钟，把 50 多个功能逐个介绍了一遍。台下的客户代表面无表情。演示结束后，客户说了一句话：「你们的功能确实很多，但我们团队只有 5 个人，我只想知道能不能帮我解决排班问题。」

那一刻我意识到：我们习惯性地用「功能多」来证明产品价值，却忘了客户真正关心的从来不是功能数量，而是能否用最低的认知成本解决他的问题。

一、B 端产品为什么容易「变重」？

B 端产品和 C 端产品有一个根本性的区别：买单的人和用的人往往不是同一批人。老板关注 ROI，一线员工关注好不好用。为了签下客户，销售会不断要求加功能——「竞品有这个我们没有」「客户说没有 XX 功能不签」。产品经理如果来者不拒，产品就会变成一个臃肿的瑞士军刀：什么都能做，什么都做不好。

还有几个常见的「增重」驱动力：

• 大客户定制需求：一个头部客户要求的功能，可能只适用于他一家，但为了合同金额，不得不做。
• 内部团队博弈：设计团队想做「体验标杆」，研发想做「技术挑战」，结果产品承载了太多非用户价值的东西。
• 缺乏「做减法」的决策机制：加功能容易（没人会因为提需求被追责），砍功能难（砍掉了出问题谁来担？）。

二、简洁 ≠ 简陋

这里需要澄清一个常见的误解：简洁不是功能少，而是认知负担小。

举两个例子：

• Salesforce：功能极多，但通过模块化设计让每个角色的用户只看到自己需要的部分。对单个用户来说，它很简洁。
• Notion：底层能力非常强大（数据库、公式、自动化），但新用户打开就是一个空白页面，可以像写文档一样开始用。这就是「渐进式披露」。

好的 B 端产品设计，是把复杂性封装起来，把简洁暴露给用户。

三、我在项目中实践「减法」的三个原则

原则 1：用「不做」来定义产品

在校园社团管理 SaaS 项目中，我们收到了很多需求：财务报销、场地申请、活动签到、成员考核……但 MVP 阶段，我明确把范围收敛到「活动管理 + 成员管理」两个模块。判断标准很简单：没有这两个功能，社团就不能正常运转吗？如果不是，就放进 V2 需求池。

原则 2：从「用户任务」出发，而非「功能列表」出发

做运营数据看板时，我们的初始方案是一个可自由配置的仪表盘。但调研后发现，运营同学每周五下午都要做同一件事：把 5 个系统的数据拉出来，拼成一张周报表。于是我们把 V1 做成了「一键生成周报」，而非「通用 BI 工具」。上线第一周就有 12 个运营同学自发使用。

原则 3：定期做「功能体检」

每个功能上线后，我会在 30 天后回看数据：使用率、完成率、是否产生了预期的行为改变。如果一个功能连续 2 次体检都不达标，就进入「待砍」清单。产品经理的勇气不只是「敢做」，更是「敢砍」。

四、总结

回到标题——为什么「简洁」是 B 端产品第一原则？

因为 B 端用户是被迫使用你的产品的。他们没有探索的耐心，不会觉得「功能多」是赚到了。他们只想快点完成手头的任务，然后下班。

尊重用户的注意力，就是最好的用户体验。