宝软数字 · 产品设计哲学 · 2026-01-20
在绝大多数B2B软件公司，需求评审会是内部人员的闭门会议。产品经理汇报需求方案，技术负责人评估可行性和工期，设计负责人审视觉稿和交互流程。客户在这过程中的角色是被动的——他们被调研、被访谈、被测，但从来不会坐在评审会的桌子旁，更不用说对设计方案投否决票。
我们在EIOS的产品设计流程中做了一个违反行规的决定：邀请客户参加核心功能的需求评审会，并且给予他们一票否决权。如果一个新功能的设计方案在产品团队内部全票通过，但被与会的客户代表投了反对票——这个方案就必须回炉重做。这不是一个姿态性的"听取客户意见"，这是一个有实际约束力的制度设计。这篇文章将完整阐述我们为什么要在产品设计流程中给客户如此大的权力，以及这个机制在实践中的运行方式和效果。
B2B产品经理面临的一个根本困境是：他们不是产品的真正使用者。一个EIOS的产品经理可能从未管理过一家制造企业，从未做过库存周转分析，从未为一个百万级的销售合同做过决策。他可以通过访谈、调研和二手资料来理解这些场景，但这种理解的深度和精度，永远无法与一个每天都在做这些事情的人相提并论。
这个困境在产品设计中体现为一种常见的模式：产品经理基于自己的理解设计了一个自认为合理的解决方案，交付给客户后发现根本不符合实际工作流，然后开始漫长的修改和适配。这不仅是资源浪费，更严重的是它消耗了客户对产品的信心——"他们连我们怎么工作的都不了解，这产品能做好吗？"
我们在EIOS的早期版本中就踩过这个坑。当时我们设计了一套"智能日报"功能，逻辑是根据前一天的数据自动生成一份图文并茂的经营分析日报。产品团队内部觉得这个设计无可挑剔——自动化的、数据驱动的、可视化的，简直完美。但当我们在一个客户试点中展示这个功能时，客户的销售总监只看了一眼就说："你们的日报里没有对比去年同期，这对我们来说是一份废纸。我不知道这周增长了5%是好是坏——如果去年同期的增长率是15%，那就是严重下滑。"
这个对比维度在我们产品的所有前期调研中都没有被提到过——不是客户隐瞒了什么，而是对于从业十几年的销售管理者来说，"同比分析"是他觉得理所当然的基础需求，他甚至不会想到需要专门提出来。这就是产品经理永远无法仅通过调研来弥补的认知鸿沟。如果我们在设计阶段就让这位销售总监坐在评审会上，这个"理所当然的需求"在需求阶段就会被体现，而不是等到开发完成后再推倒重来。
给客户一票否决权，听起来很容易引发混乱——客户会不会滥用这个权力？会不会因为个人偏好而否决一个对大多数客户都有价值的功能？这些担忧是合理的，而我们的回答是：制度设计可以防止滥用，而完全不用这个机制的风险远大于适当使用的风险。
EIOS的客户评审机制有严格的运作规范。第一，否决权是有限的。客户否决的不是"做不做这个功能"，而是"这个功能的设计方案是否符合我们这类企业的实际使用场景"。如果一个客户否决了某个设计方案，他必须给出具体的、可操作的改进建议——"这样做不行，因为XXX；如果改成YYY就更符合我们的工作方式"。否决权附带了解释义务，这让否决从一个情绪化的"我不要"变成了一个建设性的"这样做会更好"。
第二，参与评审的客户代表是轮换的。每个核心功能的评审会邀请2-3位客户代表，他们来自不同行业、不同规模的企业，确保观点多元而非被单一大客户主导。一个设计方案要想通过，必须获得大多数客户代表的认可。这防止了单个客户的特殊偏好绑架整个产品方向。
第三，产品团队保留最终的技术和可行性判断权。客户可以否决设计方案的用户体验和业务流程层面，但不能要求产品团队做出技术上不可能或成本上不可接受的实现。这个边界是清晰的——客户决定"做什么才对"，产品团队决定"怎么做得到"。当这两个判断发生冲突时，由产品负责人主持协商，寻找既满足客户需求又在技术和成本上可行的折中方案。
一票否决权最精妙的设计在于它倒逼产品团队在设计阶段就以客户的视角审视方案。知道客户会在评审会上提出尖锐的问题，产品团队在设计时就会反复自问：如果是王总（某制造企业的运营总监）看到这个界面，他会怎么用？这个预警的触发条件在他的实际业务场景中合理吗？这种预防性的思维，比任何评审反馈都更有价值。
很多产品团队误解了"听取客户意见"的含义。他们以为就是请客户来，问"你需要什么功能"，然后记下来，排优先级，逐个实现。这种做法的结果是：你得到了一张功能需求列表，但你并不真正理解这些需求背后的问题是什么。
亨利·福特有一句被广泛引用的名言："如果我问人们需要什么，他们会说要更快的马。"这句话的精髓在于：客户表达的是他们认知范围内的解决方案，而不是他们真正要解决的问题。当客户说"我需要一个能导出自定义格式Excel报表的功能"时，他真正需要的可能是一个能在董事会汇报时五分钟内拿出漂亮数据的能力。如果你只听到了"导出Excel"并按照他描述的格式做出来，你可能只是给了他想要的"更快的马"，而不是他真正需要的"汽车"。
我们的评审会设计特意规避了这个陷阱。在评审会上，我们不问"你觉得这个方案怎么样"，而是做一件事：给客户一个真实的使用场景，让他们用设计方案中的交互原型实际完成一个任务，然后观察他们的行为。客户在哪里停顿了？哪里反复点击了？哪里做出了和设计师预期不同的操作路径？哪里自言自语说"这不对啊"？这些行为数据比客户口头表达的任何意见都更真实、更持久。
有一次，我们在评审一个客户筛选功能的设计方案时，一位客户代表在使用原型的过程中不断地来回切换两个不同的筛选条件组合。我们问他为什么，他说："我想比较华东区和华北区的高风险客户的差异，但你们的筛选器一次只能看一个区域的数据。"他从来没有在调研中说"我需要一个区域对比功能"——在他的认知里，他只是在尝试完成他的日常工作（"了解不同区域的风险状况"），但他使用的操作方式暴露了产品缺失的核心能力。如果我们没有观察他的行为而只是听他的评价，我们永远不会发现这个需求。
邀请客户参加评审会、给他们一票否决权，在短期内确实增加了产品设计的成本和时间。一个设计方案在产品团队内部通过后，还要经历客户评审、可能的否决、重新设计、再次评审的循环——而传统的产品设计流程只需要内部评审通过就可以进入开发。这个差异是实实在在的时间成本和金钱成本。
但如果我们把视角放到产品的整个生命周期中，这笔账的计算方式就完全不同了。在需求阶段花一周修改一个设计方案，比在开发完成后花一个月返工要便宜得多；在开发前发现一个设计缺陷，比产品上线后被客户投诉然后紧急修复要便宜得多；在设计阶段获得客户的认可，比产品交付后因为"不符合实际使用场景"而被客户退订要便宜得多。客户参与设计的前期投入，在产品的整个生命周期中被反复偿还。
我们来算一笔具体的账。一个中等复杂度的功能，产品设计阶段如果需要两周时间，其中客户评审增加了一周（邀请客户、准备原型、组织评审会、根据反馈修改设计）。这多出来的一周成本，大约是产品经理和设计师各一个星期的工资。但如果这个功能在没有客户评审的情况下进入开发，上线后发现需要返工，返工的开发成本至少是两个人两周——加上设计师的返工、测试的返工、项目管理的协调，总成本很容易达到初始评审成本的三到五倍。
更关键的是，这还没有计入客户信任的无形成本。一次"上线后发现不符合需求"的事件对客户信任的伤害，可能需要五次"完美交付"才能弥补。尤其是对于早期客户来说，他们是冒着风险选择了一款新产品的先行者，每一次不符合预期的交付都在消耗他们的信任储备。当你连续两三次让客户觉得"你们怎么连这个都没想到"之后，续约的难度会指数级上升。
理论说多了不如看实际案例。以下是EIOS客户评审会上客户行使一票否决权的三次真实案例，每一次否决都让产品变得更好。
案例一：供应链分析Agent的风险预警逻辑。产品团队设计了一套基于统计学偏差的自动预警模型——当某个供应商的交货准时率连续两周低于历史平均值两个标准差时，系统自动标记为"高风险"并推送预警。在评审会上，一位制造企业的采购总监否决了这个方案。他的理由是："在制造业，供应商交期波动的原因是多样的——可能不是供应商的问题，而是我们自己的需求计划有问题，或者是物流环节出了岔子。如果系统只给一个'高风险'标签，我看完之后还是不知道该怎么办。我需要的是风险原因的可能性排序——是产能问题、是物流问题、还是我们自己的计划问题——这样我才能采取对应的行动。"这个否决直接推动我们重新设计了预警模型，从"给出风险等级"升级为"给出风险原因分析和建议行动"。
案例二：数据权限的默认值。产品团队设计的数据权限默认值是"部门级隔离"——销售部的人默认只能看到销售部范围内的数据，需要管理员额外授权才能跨部门查看。在评审会上，两位来自中小企业的客户代表同时否决了这个默认值。他们的理由是："我们公司总共就三十个人，销售和运营坐在一起办公，大家本来就是信息协同的。你给我默认搞一套权限隔离，意味着我每次新加一个功能，都要额外做一次权限配置，这对我不是保护而是负担。"这个否决推动了我们在数据权限设计中增加了"组织规模感知"——系统根据企业的员工规模自动推荐合适的默认权限级别，大型企业默认隔离，中小企业默认开放。
案例三：移动端数据展示的信息优先级。设计团队在移动端日报中按照"重要性"排列了八项指标——销售额、利润率、客户数、库存周转率……评审会上一位CEO直接否决了这个排列。他说："销售额和利润率每天第一个数字跳到我眼前，我一看到就知道今天大概什么情况。但你们的排列把这八个指标一视同仁，字号一样大，颜色一样重，我看完八个数字之后还是不知道今天到底好不好。我需要的是两秒钟内能回答'今天怎么样'。"这个反馈促使我们重新设计了移动端信息架构，将核心结论（"今日经营状况：良好，销售额同比增长12%但利润率略有下降"）作为首屏唯一的突出内容，后续滑动才展示细节指标。
三次否决，三次让产品变得更好。这不是巧合——当你把最了解业务场景的人请到设计决策桌旁，他们给出的反馈一定比你关起门来自己琢磨要精准得多。
客户参与评审、拥有一票否决权，这些机制只是表象。更深层的转变是团队产品文化的演变——从"我们为客户设计产品"变成"我们与客户共同创造产品"。
这种文化转变不会在一夜之间发生。它需要产品经理放下"我最懂产品"的自我认知，需要设计师接受"使用者的直觉有时比设计的直觉更准"，需要工程师理解"客户否掉的不是一个技术方案，而是一个不符合业务现实的假设"。这对团队中的每个人来说都是一个心理挑战，但它带来的回报是巨大的——当你真正把客户视为产品设计的合作者而非调研对象时，产品与市场之间的鸿沟在每一个设计决策中就被消弭了，而不是在交付之后才暴露出来。
客户参与设计最终指向的是一种深度的信任关系。当一个客户在评审会上行使了否决权，产品团队不仅没有抵触反而认真采纳了他的建议，这个客户对产品的信任会显著提升——他会觉得"这个产品有一部分是我参与创造的"。这种情感连接是任何营销手段都无法替代的，它会转化为长期的忠诚度、主动的口碑推荐和高价值的反馈贡献。
我们还在探索客户参与设计的更多可能形式——比如让客户代表加入产品顾问委员会、定期举办行业闭门设计研讨会、建立客户共创积分体系。这些探索的核心都指向同一个信念：最好的B2B产品，不是为客户建造的，而是与客户一同建造的。