很多B2B产品经理一开始就犯迷糊，觉得用户就是打电话来咨询的那个人。其实在企业采购场景里，有决策者、使用者、影响者、还有采购部门的人。举个例子，我们给一家制造企业做仓储管理系统时，车间主任关心的是操作快不快，仓库主管关心的是库存准不准，而CEO关心的是成本降了多少。如果你只盯着车间主任的需求做功能，最后可能连项目验收都过不了。
我习惯的做法是做一个角色矩阵图，把每个角色的痛点、决策权重、使用频率都列出来。比如财务总监对数据报表的准确性要求极高，但他可能一个月才登录一次系统；而一线拣货员每天要用八小时，他们对页面加载速度特别敏感。产品规划时必须平衡这些矛盾，说白了就是要找到那个让所有人都能接受的中间点。
另外还有个容易忽略的点，B2B产品的用户往往不是一个人，而是一个团队。这意味着你要考虑权限管理、工作流协同、数据隔离这些底层能力。我见过不少初创公司做的SaaS产品，连最基本的角色权限都设计得乱七八糟，最后客户试用两天就放弃了。说实话，这些基础能力虽然不炫酷，但它们是B2B产品的骨架。
B2B产品的需求来源特别分散，而且很多需求是隐性的。我经历过最离谱的一次是，客户说“想要一个自动生成报表的功能”，我们做出来之后他们又说“不是这个意思”。后来才明白，他们真正想要的是能把多个系统的数据自动汇总到一个看板上。所以现在我做需求调研时，会先让客户用白板画出他们现在的业务流程，然后再问“你觉得哪里最痛”。
还有个小技巧，就是一定要去客户现场看他们怎么工作。
坐在办公室里凭空想象出来的需求，十有八九都会跑偏。
上个月我去一家物流公司调研，发现他们的调度员每天要手工抄写20多张单据，原因是系统间的数据不互通。这个痛点他们自己都没意识到，因为已经习惯了这种低效的方式。现场观察往往能发现那些被客户当作“理所当然”的改进机会。
需求优先级排序也是个头疼的事。我的原则是优先解决那些影响业务正常运转的阻塞性问题，其次才是效率提升和体验优化。比如电商平台的订单处理系统，如果并发量上来就崩溃，那什么花里胡哨的功能都是白搭。说白了，B2B产品要先把“能用”这件事做到极致，再谈“好用”。
B2B产品的原型设计和C端有很大区别。C端产品可以只做一个功能点，比如一个滤镜或者一个分享按钮，用户觉得好用就会用。但B2B不行，你做的每个功能都必须能融入到客户的业务流程中。比如你做采购审批流，那就得把提交申请、上级审批、财务复核、采购执行、到货确认、发票匹配这一整条链路都考虑进去，缺一个环节客户就用不起来。
我习惯在画原型之前先画业务流程图，把数据流向、状态变化、异常处理都标清楚。比如库存扣减这个操作，正常情况扣成功，但万一网络超时怎么办？库存不足又该怎么提示？这些边界情况在B2B产品里特别多，处理不好就会导致客户数据混乱。说实话，B2B产品的原型图看起来往往很“丑”，因为到处都是表单、表格、状态标签，但这就是企业级应用的真实面貌。
还有一个容易被忽视的点，就是异常流程的处理。C端产品用户遇到问题可以退出重来，但B2B不行，订单一旦提交就不能随便取消。所以设计时要预判各种异常场景，比如单据被驳回后怎么修改、数据导入出错怎么回滚。这些功能虽然平时用不上，但一旦出了问题，就是产品口碑的生死线。
再好的产品规划，如果执行不到位也是白搭。B2B产品的开发周期通常比较长，三个月到半年很常见，这期间需求变更几乎是必然的。我的做法是把项目拆成多个迭代，第一个版本只做核心流程，保证客户能跑通业务，后续版本再逐步完善。比如做CRM系统，第一期先做客户管理和跟进记录，第二期再做数据分析，第三期才考虑AI预测。
跟开发团队沟通时，一定要把业务逻辑讲透。我见过太多产品经理丢个原型图就完事，结果开发理解偏差，做出来的东西完全不能用。正确的做法是拉着开发一起过业务流程，给他们讲清楚每个字段背后的业务含义。比如“客户等级”这个字段，不是简单的A/B/C三级，而是关联着不同的折扣政策和审批流程。只有让开发理解业务，他们才能做出真正符合需求的产品。
上线后的数据跟踪也特别关键。B2B产品好不好用，看客户的使用频率和操作时长就知道了。如果某个功能客户很少用，要么是入口太深，要么是设计得不好用。我会定期查看后台数据，比如哪个页面跳出率高、哪个操作耗时最长，然后针对性优化。说实话，产品上线只是开始，真正的考验在后面漫长的迭代过程中。
