客户说要一个审批流程，产品经理画了一个审批页面
一家SaaS公司接到客户需求："我们需要一个采购审批功能。"产品经理的第一反应是打开Axure，画了一个审批表单页面——提交按钮、审批按钮、驳回按钮，界面清清楚楚。
交付之后客户说不对。不是页面不好看——是流程不对。
客户的采购审批不是"提交-审批"两步。实际流程是：采购员填单→部门主管初审→财务复核→采购总监终审；金额超过五万的走分管副总加签；驳回后不是回到采购员，是回到上一级审批人。这些规则在"画页面"之前就该搞清楚。
翻车的根因：C端习惯从界面入手——先画页面再想逻辑。B端必须先理清业务流程——角色、条件、分支、异常——然后界面只是流程的可视化。
纠偏路径：拿到B端需求的第一件事不是画原型，是画流程图。流程里的每个节点、每个分支、每个异常情况确认完了，原型画起来反而快。
上线前一切正常，实施阶段项目失控
一个HR SaaS产品，功能开发完成、测试通过、演示效果很好。签约之后进入实施阶段，产品经理觉得"交给实施团队就行了"。
两个月后客户投诉爆发。问题不在产品——在实施。
客户原有数据格式和新系统不兼容，迁移花了三倍时间。各部门的权限需求不一样，配置方案改了五版。HR部门的操作习惯和系统默认流程冲突，培训做了三轮还是天天有人打客服电话。
翻车的根因：C端产品上线就是终点。B端产品上线是实施的起点——部署、迁移、培训、定制化配置，每一步都可能出问题。产品经理如果在上线那一刻就撒手，后面一定失控。
纠偏路径：B端产品经理的职责边界必须延伸到实施阶段。至少要参与实施方案评审、关键节点跟进、客户反馈回收。"上线后的事不归我管"这句话在B端不成立。
所有角色共用一套权限，上线后天天改
一个项目管理工具做到MVP阶段，为了赶上线进度，权限设计用了最简单的方案：管理员和普通用户两个角色。
客户试用第一天就提了一堆需求：项目经理要看所有项目的数据，普通成员只能看自己的；财务角色需要看成本数据但不能看工时细节；外包人员可以看任务但不能下载文件。
每来一个权限需求，开发就得改一次底层逻辑。改了两个月，权限代码变成了一团面条。
翻车的根因：权限设计是B端产品的隐性地基。C端产品权限简单——登录和未登录。B端权限是多维度的：角色权限、数据权限、功能权限、组织权限。这四个维度在架构层面就要想清楚，不能上线后打补丁。
纠偏路径：B端产品做需求分析阶段，权限矩阵必须和业务流程同步输出。先列出所有角色、每个角色能做什么操作、能看什么数据。矩阵确认完了再设计功能。
按C端习惯做竞品分析，结论全是错的
转B端的产品经理做竞品分析，习惯性地注册竞品、点一遍功能、截屏、写报告。结论是："竞品功能和我们差不多，界面比我们丑，所以我们有优势。"
投标时客户问了三个问题：你们能和我们的SAP对接吗？你们支持多租户隔离吗？你们的SLA是多少？产品经理一个都答不上来。
翻车的根因：B端竞品分析不能只看前台界面——客户决策看的是架构能力、集成能力、实施能力、售后保障。这些在竞品的注册页面上看不到。
纠偏路径：B端竞品分析至少要覆盖四个维度——功能覆盖度、技术架构能力、实施方法论成熟度、售后服务体系。前台界面只是其中最不重要的一个维度。