业务设计
B端产品经理的核心方法论——不是画表单/按钮/审批流，而是穿透客户字面需求，提炼业务实体/业务事件/业务规则，重构客户业务流程。区别于”功能设计”（解决”怎么做”），业务设计解决”为什么做”和”做什么”，是初级PM与资深PM的核心分水岭。落地路径是”业务场景画布→As-Is流程→价值机会点→To-Be业务模型+功能”四步法。
简介
业务设计（Business Design）是B端产品经理（B端产品经理）区别于功能设计的核心方法论。雨柒在 2026-05-27-woshipm-b2b-pm-business-design 中明确指出：B端产品经理要做的是业务设计，业务设计明白了以后设计功能承接，而非单纯的功能设计——这一认知恰恰是区分初级产品经理与资深产品经理的核心分水岭。
业务设计与功能设计的核心差异在于起点和关注的问题：功能设计的起点是”客户说要什么就做什么”，关注”怎么做”（HOW）——画一个表单、一个按钮、一个审批流；业务设计的起点是”客户说要什么 → 先问为什么要这个”，关注”为什么做”和”做什么”（WHY + WHAT）——这个环节为什么需要审批？数据流转背后的业务规则是什么？如何通过这个功能优化客户现有业务流程，甚至重构流程？只做功能设计的后果是客户用得别扭——系统在硬套客户旧流程，或只是把线下表格搬到线上；做业务设计的角色是客户的”业务咨询顾问 + IT落地专家”，能帮客户发现流程瓶颈、规避风险、提升效率。
退货案例直观演示了这种分水岭：PM-A按客户字面要求做退货表单（提交→生成单→打印给库房），上线后被客户用”库房收到未审批退货 / 财务不知道是否退款 / 退货单被重复提交三次”反击，被迫不断打补丁（审批流 / 防重复校验 / 财务确认按钮）导致系统臃肿；PM-B先问三个问题（涉及哪些角色 / 哪个环节最乱 / 客户最怕什么），画现状流程图发现核心问题是”退货商品状态不可见”和”审批与实物脱节”，重新设计业务模型（退货单→库房扫码核验→系统自动判定是否需财务复核→状态同步客户），用4个核心功能解决了80%的问题——A交付了10个功能，B交付了1个业务模型，这就是初级PM与资深PM的差距。
业务设计的输出物不是原型图或功能清单，而是业务模型——由业务实体（客户/订单/工单/库存）、业务事件（下单/审核/发货）、业务规则（满减/审批权限/退款条件）三者组成的完整业务逻辑结构。业务模型与功能的关系，如同筋脉与表体——筋脉贯通全身，决定生命力；表体承载交互，直接服务客户。二者结合，才能真正为客户提供价值。
关键信息
- 类型：方法论 / PM核心能力
- 领域：B端产品 / 企业软件 / 业务系统
- 核心问题：如何穿透客户字面需求，重构客户业务流程而非把线下表格搬到线上
- 核心输出：业务模型（业务实体 + 业务事件 + 业务规则）
- 落地路径：业务设计四步法（定范围→描现状→找痛点→设计未来）
- 核心心智：先讲业务能力，再对应到功能点
- 核心反义词：功能设计（按客户字面要求画表单/按钮/审批流）
- 关联角色：B端产品经理、业务架构师
- 关联方法：反向立项、工作SOP、Skill
核心特性
业务设计 vs 功能设计：分水岭对照表
| 维度 | 功能设计思维（初级PM） | 业务设计思维（资深PM） |
|---|---|---|
| 起点 | 客户说要什么就做什么 | 客户说要什么 → 先问为什么要这个 |
| 关注的问题 | 怎么做（HOW） | 为什么做 + 做什么（WHY + WHAT） |
| 输出 | 表单 / 按钮 / 审批流 | 业务实体 + 业务事件 + 业务规则的完整模型 |
| 与客户关系 | 需求传声筒 | 业务咨询顾问 + IT落地专家 |
| 异常流程处理 | 后期不断打补丁 | 在设计阶段就识别雨天路径 |
| 落地结果 | 系统越来越臃肿，客户”也能用但别扭” | 用更少功能解决更多业务问题，客户”真好用” |
| 退货案例对应 | A交付10个功能 | B交付1个业务模型 |
业务设计四步法（落地方法论）
第一步：定范围（业务场景画布）
核心目标：明确系统的核心服务范围和涉及角色，避免”包打天下”式的需求蔓延。
核心动作：用用例图从用户视角描述系统功能。
PM话术示例：
“张经理，咱们今天聚焦的是’销售退货’这个场景对吗？涉及的角色有：销售员、库管、财务、客服？”
输出物：用例图 / 服务范围说明。
第二步：描现状（As-Is 业务流程）
核心目标：完整还原客户当前业务流程，识别”灰色地带”。
核心动作：快速画出现状流程图并与客户面对面确认。
PM话术示例：
“您能按时间顺序讲一下，从客户提出退货，到最终退款/换货，每一步谁做什么、用什么表单、有什么规则吗？”
关键提醒：很多产品经理在这一步偷懒，觉得”我都听明白了”。但你画出来的流程图，十次有八次客户会说”哦，这里我忘了说……”——画图是消除信息差的最有效手段。
输出物：现状业务流程图（必须画出来与客户确认）。
第三步：找痛点（价值机会点）
核心目标：找到业务流程的突破口——最耗时、最易错、客户投诉最多的环节。
核心动作：运用需求分析三要素区分”症状”与”病因”。
需求分析三要素：
- 用户描述的是”症状”（库房收到未审批的货 / 同一退货单被重复提交三次）
- 用户建议的是”治标的偏方”（“加个审批流就行” / “做个防重复校验”）
- PM真正的价值是找到”病因”，开出”治本的药方”（“审批与实物脱节” → 扫码核验 + 自动判定的业务模型）
PM话术示例：
“这个流程里，哪个环节最耗时？哪个环节容易出错？哪个环节客户投诉最多？”
输出物：痛点清单 + 病因分析（避开治标偏方）。
第四步：设计未来（To-Be 业务模型 + 功能）
核心目标：先讲业务能力，再对应到功能点。
核心原则：先讲业务能力，再对应到功能点——让客户感受到你在解决他的业务问题，而不是在推销一堆功能。
PM话术示例：
“如果新系统支持以下能力，您希望哪个先解决？”
- 能力A：库管扫码自动核验退货商品（功能：PDA扫码 + 校验逻辑）
- 能力B：系统根据退货原因自动判定是否需财务审核（功能：规则引擎）
- 能力C：客户在APP端可看到退货进度（功能：状态同步 + 进度条）
输出物：To-Be业务模型 + 优先级排序的功能清单。
“匹配”的艺术：客户成熟度 × 系统边界
业务设计不是一刀切的”最佳实践”，而是要对两个维度做双层匹配。
第一层：匹配客户成熟度
| 客户类型 | 业务特征 | 对应的业务模型 |
|---|---|---|
| 初创公司 | 流程混乱但求快 | 轻量、灵活、可配置——不要强加大企业的复杂审批 |
| 成熟大企业 | 流程严谨但僵化 | 符合合规、权责清晰——必须兼容已有的OA/ERP习惯 |
核心判断：如果给初创公司装”五级审批 + 法务会签”，客户会因为”还没赚钱就被流程拖死”而弃用；如果给成熟大企业装”一键操作 + 全员可改”，客户会因为”权责不清出事没人背锅”而拒绝上线。
第二层：匹配系统边界
- 哪些事系统做（自动化、强控）：低风险高频场景。例如”金额超标自动驳回”——规则明确、责任清晰、不需要人判断。
- 哪些事人做（人工决策、例外处理）：高风险低频场景。例如”大客户经理特批”——涉及商业判断、客户关系、个性化让利。
核心判断：匹配就是要找到自动化与人工操作的最佳结合点。系统接管过多→失去灵活性，人工保留过多→失去效率优势。
业务设计自检清单（接需求时逐条核对）
雨柒给出了7条自检清单，每次接到需求都应该在脑海中过一遍（前期可以打印出来加强记忆）：
- 我是否理解了客户的业务背景以及背后的业务目标，而不是只听他说的功能？
- 我是否画出了现状流程图，并和客户确认过？
- 我是否识别出了至少3个异常分支（雨天路径）？
- 我是否区分了”症状”和”病因”？
- 我的方案是先设计业务模型，还是直接画了原型？
- 我是否向客户展示了”业务能力”，而不仅是”功能列表”？
- 我是否考虑了这个客户的企业成熟度，匹配了合适的复杂度？
PM三档价值阶梯（业务设计的进阶路径）
雨柒提出的PM三档价值阶梯，描绘了业务设计能力从入门到精通的进阶路径：
| 档位 | 交付物 | 核心能力 | AI替代风险 |
|---|---|---|---|
| 初级PM | 功能 | 把客户口头需求转成原型/PRD | 高——AI可以自动生成 |
| 高级PM | 业务模型 | 提炼业务实体/事件/规则，重构客户流程 | 中——需要业务洞察 |
| 专家级PM | 对客户商业效率的提升 | 用业务设计带动客户ROI实质改善 | 低——AI暂时无法替代”人性洞察”和”商业判断” |
核心结论：当AI可以自动生成原型图、自动编写代码的时候，PM的不可替代性，恰恰在于对业务本质的深刻理解——这是AI暂时无法替代的”人性洞察”和”商业判断”。
不同素材中的观点
-
2026-05-27-woshipm-b2b-pm-business-design（雨柒，人人都是产品经理）：业务设计的奠基性方法论文章。明确提出”业务设计 vs 功能设计是B端PM的核心分水岭”的命题，用”10个功能 vs 1个业务模型”的退货案例形成强对比，给出业务建模4项核心能力（抽象建模/流程解构/场景识别/领域迁移）、四步法落地（定范围→描现状→找痛点→设计未来）、匹配艺术（客户成熟度×系统边界）、7条业务设计自检清单、PM三档价值阶梯（初级交付功能/高级交付业务模型/专家级交付商业效率）。明确指出2026年AI对B端PM的三重冲击（业务知识不再是壁垒/按效果付费/ToB哑铃型市场）使得”只会做功能设计的B端PM将面临被淘汰风险”。
-
2026-05-23-woshipm-sop-as-cot-agent-clone-expert（忘机·G7易流）：从企业级Agent工程化角度补充——业务设计的下一步是把业务模型编译成可被AI执行的SOP思维链。本文的”业务建模4项能力”中的”抽象建模能力”和忘机的”业务抽象能力”高度同源。雨柒聚焦客户对接侧的话术和落地方法（如何让客户买账），忘机聚焦内部Agent化的工程实现（如何让AI接管业务流程）。两者共同构成B端PM在AI时代的能力升级路径——从业务设计师进化为 业务架构师。
实用信息
适用场景
- B端SaaS产品需求接入：客户提需求时，先做业务设计再做功能设计
- 企业内部业务系统：OA / ERP / CRM / WMS / MES 等需要重构客户流程的场景
- AI Agent项目立项前：先用业务设计提炼出清晰的业务模型，再考虑哪些环节交AI（详见 业务架构师）
- 跨部门系统改造：涉及多个角色协同的业务流程改造（销售/库管/财务/客服等）
基本用法（5步执行流程）
-
拿到客户需求时不画原型，先问3个问题：
- 这个流程涉及哪些角色？
- 目前哪个环节最乱（最容易出错/最耗时/投诉最多）？
- 客户最怕什么（什么后果是不可接受的）？
-
画现状流程图（As-Is）并与客户当面确认：
- 不要默认”我都听明白了”——10次有8次客户会补漏
- 跨部门的协作必须画出来，不能只画自己负责的那段
- 状态机图要画完整生命周期（创建/审核/执行/异常/撤销/归档）
-
运用需求分析三要素区分症状和病因：
- 用户描述的是”症状”
- 用户建议的是”治标的偏方”
- 你的价值是找到”病因”，开出”治本的药方”
-
设计To-Be业务模型而非功能列表：
- 先讲业务能力（如”系统自动判定是否需财务复核”）
- 再对应功能点（如”规则引擎 + 状态同步”）
- 让客户感受到你在解决他的业务问题，不是在推销一堆功能
-
用7条业务设计自检清单核对一遍（见上文）
注意事项
-
警惕功能堆叠陷阱：客户每提一个新问题就加一个功能 → 系统臃肿 → 越加越复杂 → 客户越用越别扭。正确的应对是回到业务模型层重新设计，而非在功能层打补丁。退货案例中PM-A的”加审批流 / 加防重复校验 / 加财务确认按钮”就是典型的功能层打补丁。
-
不要怕画图：很多PM在”描现状”这一步偷懒——但画图是消除信息差最有效的手段。画出来的流程图，10次有8次客户会补漏。即使你觉得”已经听明白了”，也要画。
-
不要直接做客户字面需求：客户说”我要一个退货登记功能”——A按字面做，B问了三个问题才动手。差距就在这里。客户的”字面需求”是症状，PM要找的是”病因”。
-
不要忽视异常流程：B端产品最体现价值的不是主流程（晴天路径），而是对异常流程（雨天路径）——超时、退回、撤销、合并、并发、争抢等真实业务里频繁出现的边界情况——的优雅处理。设计阶段就要识别至少3个异常分支。
-
不要在错误的客户成熟度上用错的复杂度：给初创公司装五级审批是灾难，给成熟大企业装一键操作也是灾难。复杂度必须匹配客户能消化的程度。
-
2026年开始不要只做功能设计：AI正在快速蒸馏SOP和文档（详见 Skill 和 业务架构师），“只会做功能设计”的B端PM面临被淘汰风险。立刻补上业务设计能力。
业务设计与传统方法论的关系
- 业务设计四步法（定范围/描现状/找痛点/设计未来）本质上是PDCA闭环在B端需求场景的具体落地版（详见 工作SOP）
- “描现状必须画图”对应PDCA的check环节——必须用客观证据校验
- 业务设计三要素（业务实体/业务事件/业务规则）对应DDD领域驱动设计的核心概念
- 业务设计的”症状 vs 病因”分析与 用户调研 的”用户撒谎是本能”哲学同源——用户/客户描述的现象 ≠ 真实问题
与其他方法论的关系
- 与 B端产品经理 的关系：业务设计是B端PM的核心方法论，是这个角色区别于C端PM的核心能力。本实体页是”这个职业最核心的方法”，B端PM实体页是”做这个职业的人”。
- 与 业务架构师 的关系：业务架构师是业务设计能力的进化形态——业务设计提炼业务模型，业务架构师把业务模型编译成AI可执行的SOP思维链。前者的输出物是给开发看的业务模型，后者的输出物是给Agent执行的思维链。
- 与 反向立项 的关系：反向立项解决”做什么”——从行业全链路拆解中找AI切入点；业务设计解决”怎么做出来让客户买账”——把找到的切入点设计成客户真正需要的业务模型。两者都强调”行业Know-How密度”是B端PM的真正护城河。
- 与 AI产品PRD 的关系：业务设计是AI产品PRD的输入——先有业务模型，才能在PRD里定义不确定性治理的边界（哪些环节AI做、哪些环节人做、哪些是红线一票否决）。
- 与 Skill 的关系：Skill是写给AI的SOP，业务设计是写给开发的业务模型——两者都是把隐性经验显性化的方法，前者目标是AI执行，后者目标是系统落地。
- 与 工作SOP 的关系：业务设计四步法（定范围→描现状→找痛点→设计未来）本质上是PDCA闭环（plan→do→check→act）在B端需求场景的具体落地版。
- 与 用户调研 的关系：业务设计的”症状 vs 病因”与用户调研的”用户撒谎是本能”哲学同源——用户/客户描述的是表象，PM要挖的是真实需求。
- 与 AI产品经理工作流 的关系：业务设计是AI产品经理工作流中”用户研究→需求拆解→PRD→评估”链路的前置环节——没有业务设计，所有后续动作都在错误的地基上盖楼。