B端产品经理超级工作台 V2.0 / B2B PM Super Workbench

> "让一个什么都不懂的小学生，用上这个Skill，也能变成高级B端产品经理。"

>

> 整合全球顶级产品方法论 + 中国企业级实战体系 + AI时代全新能力栈。

> 覆盖11个阶段、50+框架、30+交付物、10种角色帽。

> 从战略到落地、从图表到原型、从传统B端到AI产品设计——全链路覆盖。

快速导航：我要做什么？

B端 vs C端：深度认知差异

> 不理解这15个差异，就谈不上真正的B端产品思维。

> B端产品本质公式：产品价值 = (节省的成本 + 避免的损失 + 创造的增量收入) × 用户粘性系数 ÷ 替代方案的成本

11阶段完整产品生命周期

> 每个阶段遵循统一结构：输入物 → 核心流程 → 方法论 → 输出物 → 质量标准 → AI加速

阶段1：战略与市场洞察

角色帽：行业洞察者

输入物

• 公司战略规划 / 高层意图
• 行业报告 / 财报 / 券商研报
• 初步市场认知

核心流程（6步循环）

市场扫描 → 竞争格局分析 → 赛道机会识别 → 产品定位 → 商业模式设计 → 路线图规划
   ↑                                                              ↓
   └──────────────── 季度复盘更新 ─────────────────────────────────┘

方法论工具箱（8+1个）

市场洞察的B端特殊维度

B端市场信号收集渠道：
├── 招投标网站（政府采购网/招标雷达）—— 最真实的需求信号
├── Gartner/Forrester/IDC 魔力象限和报告
├── 竞品招聘JD（技术栈/业务方向/团队规模反推）
├── 上市公司财报/招股书（市场规模、增长率、客户数）
├── 行业会议演讲PPT（产品方向、技术架构）
├── 客户采购行为（询价/RFP/招标预算）
├── 监管政策变化（合规类产品的最大驱动力）
└── 投资机构行研报告（产业链分析、空间测算）

输出物

1. 行业分析报告（15-25页PPT，使用 pptx-2）
2. 竞品分析报告（详细模板：refs/templates/competitive-analysis-b2b.md）
3. 产品战略一页纸（A4，3分钟能讲清楚产品定位）
4. 产品路线图 Roadmap（Now/Next/Later 三段式，draw.io甘特图）

AI加速

• 用Claude进行竞品功能矩阵对比（粘贴竞品帮助文档）
• 用AI分析竞品定价页 → 生成定价对比表
• 搜索竞品招聘JD → AI反推技术栈和团队规模
• 让AI生成SWOT策略建议（SO/WO/ST/WT策略）

阶段2：需求发现与管理

角色帽：需求侦探

> B端产品经理最核心的能力不是"写PRD"，而是"挖出真正的需求"。

> 用户说的80%是解决方案而非需求本身。

输入物

• 客户反馈（工单/NPS/客服记录/CSM反馈）
• 销售反馈（丢单原因/客户诉求/竞品对比）
• 实施交付反馈（上线阻力/数据迁移卡点）
• 产品使用数据（功能采用率/异常行为/流失漏斗）

B端需求来源全景图

需求深度挖掘方法

JTBD（Jobs To Be Done）— B2B改写版

┌─────────────────────────────────────────────────────────┐
│ When [组织中的某个角色]_                                   │
│ I want to [完成某个业务任务]_                              │
│ So that [达成业务指标 / 满足KPI / 通过审计 / 避免罚款]_     │
│                                                         │
│ Current pain: [当前完成这个任务有多痛苦？量化]              │
│ Importance: [这个任务在用户KPI中占多重？]                   │
│ Frequency: [多久做一次？]                                 │
└─────────────────────────────────────────────────────────┘

B2B JTBD示例：
- 财务经理：月底3天内完成3家子公司合并报表，确保审计零问题
- IT管理员：批量新增200名员工账号并分配角色，确保权限最小化原则，满足等保要求
- 采购经理：3家供应商对比报价→走完审批→生成采购单，确保符合集团采购制度
- 法务：合同到期前30天自动提醒相关部门续签或终止，避免合规风险

SPIN需求挖掘法（B端顾问式访谈专用）

5 Whys（五问法）

用户："我需要批量导入功能"
一问：为什么需要批量导入？    → "每次要导入几百条数据"
二问：为什么有这么多数据？    → "每月从ERP导出后再手工录入"  
三问：为什么不直接对接？      → "IT说ERP太老了，没有API"
四问：ERP有没有升级计划？     → "明年有计划但不确定"
五问：升级前怎么办？         → "临时方案是每月导Excel"
→ 结论：短期做批量导入是合理的过渡方案，但要规划API对接
   来消除根本原因。如果只做导入而不规划对接，一年后还是同样问题。

需求管理4级成熟度

输出物

1. 用户画像卡片（B端多角色版本，每角色一页）
2. 用户旅程地图（B2B版：认知→评估→采购→实施→使用→续约）
3. JTBD卡片（每类用户的Jobs To Be Done）
4. 需求池Excel（标准字段：ID/来源/描述/角色/场景/优先级/状态/KANO分类）
5. 用户访谈记录（模板：refs/templates/user-interview-b2b.md）

AI加速

• 用AI分析客服工单文本 → 自动聚类常见问题类型
• 用AI生成访谈提纲（基于已知客户信息和行业）
• 访谈录音转文字 → AI摘要关键发现
• 多个访谈记录 → AI识别跨访谈的共性问题

阶段3：需求分析与排序

角色帽：方案架构师 + 需求侦探

输入物

• 需求池（阶段2输出）
• 产品路线图（阶段1输出）
• 技术资源约束
• 本季度OKR

方法论

KANO模型 — B端特化版

B端加权优先级评分法

综合优先级分 = 
  客户付费意愿(0-10) × 0.20 +
  战略匹配度(0-10) × 0.15 +
  对NRR的贡献(0-10) × 0.15 +
  技术可行性(0-10) × 0.15 +
  竞争覆盖度(0-10) × 0.10 +
  实施复杂度(0-10,越低越好) × 0.10 +
  对NDR的贡献(0-10) × 0.10 +
  合规必要性(0-10) × 0.05

RICE模型（Intercom经典版）

RICE Score = (Reach × Impact × Confidence) / Effort

Reach（覆盖面）：多少个客户/用户在给定时间段内受影响？
  - 用客户数而不是用户数来衡量（B端特有）
  - 区分"受到影响"和"主动使用"

Impact（影响度）：对每个客户的影响有多大？
  - 3 = 巨大影响（客户KPI显著改善）
  - 2 = 高影响
  - 1 = 中等影响
  - 0.5 = 低影响
  - 0.25 = 最低影响

Confidence（信心度）：你对估算有多确定？
  - 100% = 高信心（有数据/用户明确反馈）
  - 80% = 中等信心（有部分证据）
  - 50% = 低信心（直觉/猜测）
  - 20% = 瞎猜（需要验证的假设）

Effort（工作量）：需要多少人月？
  - 用实际人月而非故事点（易于跨职能沟通）

MoSCoW（固定期限项目专用）

B端需求四象限（按价值/成本）

                    高业务价值
                        │
         ┌──────────────┼──────────────┐
         │   战略项目    │   核心功能    │
         │  (长期投资)   │  (立即做)    │
         │  例：AI能力   │  例：审批流   │
   高 ───┼──────────────┼──────────────┼─── 低
   实现   │              │              │    实现
   成本    │   不做/观望   │   快速迭代    │    成本
         │  (放弃)      │  (小成本快赢)  │
         │  例：过度定制  │  例：批量导出  │
         └──────────────┼──────────────┘
                        │
                    低业务价值

输出物

1. 需求优先级排序表（Excel，含评分明细）
2. KANO分类结果
3. 版本规划建议（Now / Next / Later）
4. 需求评审材料（PPT格式，用于需求评审会）

阶段4：方案设计（B端核心）

角色帽：方案架构师 + 流程设计师

> 这是B端产品经理最核心、最体现专业深度的阶段。

> 方案设计不只决定"做什么功能"，更决定"组织如何运作"。

> 参考杨堃《决胜B端》的五模块知识体系：业务诊断→方案设计→管理落地→架构进阶→能力成长。

B端方案设计 7 大支柱

支柱1：多角色权限模型设计

三种权限模型选型：

RBAC设计步骤（5步法）：

Step 1: 枚举所有操作（页面/按钮/API/数据范围）
Step 2: 定义角色（从组织架构出发，而非技术出发）
  ├── 超级管理员 - 全局配置、组织管理
  ├── 系统管理员 - 日常管理、用户权限
  ├── 部门管理员 - 本部门管理
  ├── 业务操作员 - 核心业务操作
  ├── 审批人 - 流程审批
  ├── 审计员 - 只读+日志查看
  └── 自定义角色 - 允许租户自定义
Step 3: 角色-操作映射（权限矩阵）
Step 4: 用户-角色绑定（支持一个用户多角色）
Step 5: 数据权限策略叠加（行级/列级）

权限粒度层级：

菜单级 → 页面级 → 按钮级 → 数据级(行) → 数据级(列) → 字段级
  ↓         ↓         ↓         ↓            ↓          ↓
 能看到    能访问    能操作    能看到哪些    能看哪些    能编辑
 哪些菜单  哪些页面  哪些按钮  数据范围      字段        哪些字段

数据权限策略：

输出物： 角色权限矩阵表（Excel）+ 数据权限策略文档

支柱2：审批流与工作流设计 (BPMN 2.0)

审批节点类型完整目录：

审批效率设计原则：

1. 审批节点 ≤ 5个（超过需论证必要性）
2. 每个节点审批人 ≤ 3人
3. 必须有超时策略（提醒/升级/自动通过/自动驳回）
4. 移动端必须可以审批（企微/钉钉/飞书集成）
5. 审批详情页包含：完整信息 + 审批历史 + 操作按钮 + 附件
6. 支持批量审批（同类申请一键通过）
7. 审批人视图：待审批列表 + 已审批列表
8. 发起人视图：我的申请 + 审批进度 + 撤销/催办

异常流程处理（B端最容易遗漏的部分！）：

状态机图（核心交付物）：

使用draw.io绘制完整状态机，包含所有状态的进入条件/退出条件/可执行操作。

输出物： 审批流状态机图(draw.io) + 审批规则配置表(Excel) + 异常场景处理表

支柱3：多租户架构设计

四种隔离策略与决策矩阵：

租户隔离决策树：

客户合规要求高？→ 是 → Database per Tenant
             → 否 → 客户定制需求多？→ 是 → Schema per Tenant
                                    → 否 → 客户数量大？→ 是 → Shared Table
                                                      → 否 → Hybrid

租户级可配置项清单：

输出物： 多租户架构设计文档 + 租户配置清单

支柱4：数据字典与主数据管理(MDM)

数据字典标准模板（每张表一份）：

主数据管理(MDM)核心实体：

B端产品必须管理好这些主数据：

• 组织架构（公司→部门→岗位→员工）
• 客户/供应商主数据
• 产品/物料主数据
• 科目/项目/成本中心
• 合同/许可证

数据库命名规范：

表名：t_{模块前缀}_{表名}  → 例：t_pur_purchase_request
字段：snake_case           → 例：created_at, creator_id
索引：idx_{字段名}          → 例：idx_tenant_id, idx_status
唯一索引：uk_{字段名}       → 例：uk_request_no
外键：fk_{表名}_{字段名}    → 例：fk_user_creator_id
布尔型：is_xxx / has_xxx   → 例：is_deleted, has_attachment
时间型：xxx_at             → 例：created_at, approved_at
金额型：xxx_amount (分)    → 例：total_amount → DECIMAL(18,0)

输出物： 完整数据字典(Excel) + ER图(draw.io)

支柱5：集成与开放能力设计

企业集成模式(EIP)选型指南：

企业集成成熟度阶梯：

L1: 文件导入导出（CSV/Excel）           ← MVP至少做到这层
L2: Webhook + 消息通知                  ← GTG阶段做到这层
L3: RESTful API（含API文档）            ← 规模化必须
L4: SSO + 组织架构同步                  ← 企业客户标配
L5: 深度集成（双向同步+嵌入式组件）       ← 行业头部方案

必须支持的集成清单：

• SSO/身份认证：SAML 2.0、OAuth 2.0/OIDC、LDAP/AD域、CAS
• 消息通知：企业微信/钉钉/飞书、邮件(SMTP)、短信
• 电子签章：法大大/e签宝/上上签
• 企业支付：银企直连/对公转账/供应链金融
• 电子发票：电子发票平台对接
• 数据集成：ETL/数据同步/主数据分发

OpenAPI设计规范（如果产品提供开放平台）：

输出物： 集成架构图(draw.io) + API设计文档

支柱6：合规与审计设计

B端产品必须考虑的合规体系：

审计日志设计规范：

每条审计日志必须包含：
├── 谁（operator_id + operator_name + operator_role）
├── 什么时间（timestamp，精确到毫秒）
├── 做了什么（action：CREATE/READ/UPDATE/DELETE/EXPORT/APPROVE）
├── 操作了什么（resource_type + resource_id + resource_name）
├── 操作前数据（before_snapshot，JSON）
├── 操作后数据（after_snapshot，JSON）
├── 从哪里操作（IP + User-Agent + Session ID）
├── 操作结果（success/failure + error_detail）
└── 审计日志本身：不可删除、不可修改、不可手动插入

数据安全基线：

• 传输：全站HTTPS、API签名
• 存储：敏感字段AES-256加密、密钥管理KMS
• 访问：RBAC最小权限、IP白名单、登录时段限制
• 脱敏：手机号/身份证/银行卡号显示时自动脱敏
• 备份：每日全量+增量，异地备份
• 灾备：RPO<1h, RTO<4h

支柱7：B端产品架构设计

从单体到中台的演进路径（杨堃框架）：

阶段1：Excel → 单系统 → 多系统独立 → 系统打通 → 中台化
  │          │           │            │           │
  初创期     成长期      扩张期        成熟期      平台期

中台架构（企业级产品终极形态）：
├── 业务中台：通用业务能力复用（用户/权限/审批/通知/支付/签章）
├── 数据中台：统一数据资产（主数据/指标体系/数据服务/数据治理）
├── 技术中台：技术基础设施（微服务/容器/CI-CD/监控/日志）
└── 组织中台：组织能力沉淀（方法论/工具链/培训体系）

阶段5：AI产品设计

角色帽：AI产品设计师

> AI正在重塑B端产品管理。AI PM不再是可选项，而是必选项。

> B端产品从"System of Record"升级为"System of Action"，

> AI是这场变革的核心引擎。

参考来源：

• O'Reilly "The Future of PM is AI-Native" (2025)
• Stanford "Getting Beyond the Sandbox" (2024)
• Marty Cagan / Teresa Torres AI时代的产品方法论
• 中国企业级AI产品设计10课框架

5.1 AI PM能力模型（3类AI PM）

> 本Skill覆盖AI-Enhanced PM和AI Experience PM（B端最常见的两种）。

5.2 AI产品设计的10大模块（完整框架）

模块1：模型选型与策略

模型选型决策矩阵：

B端选型决策树：

数据能出企业吗？
├── 是 → 数据量大吗？
│       ├── 是 → 闭源API + RAG（成本可控）
│       └── 否 → 闭源API直接调用
└── 否 → 必须私有化部署
          ├── 场景通用 → 开源模型 + RAG
          └── 场景特殊(如医疗/法律) → 开源模型 + 微调

模型能力边界（每个AI PM必须懂）：

模块2：RAG架构设计

RAG是当前B端AI产品的核心架构。

RAG标准流水线：
┌──────────────────────────────────────────────┐
│ 1. 文档摄入                                   │
│    ├── 文档解析(PDF/Word/HTML/图片OCR)        │
│    ├── 分块(Chunking)：按段落/按语义/按固定长度 │
│    └── 元数据提取(文档名/日期/作者/权限标签)     │
├──────────────────────────────────────────────┤
│ 2. 向量化 (Embedding)                        │
│    ├── 文本→向量 (text-embedding-3-large等)   │
│    └── 存入向量数据库 (Pinecone/Weaviate/Milvus)│
├──────────────────────────────────────────────┤
│ 3. 检索 (Retrieval)                          │
│    ├── 混合检索：稠密向量 + 稀疏(BM25)        │
│    ├── 重排序(Reranking)：对召回结果二次排序    │
│    └── 过滤：按权限/日期/标签过滤             │
├──────────────────────────────────────────────┤
│ 4. 生成 (Generation)                         │
│    ├── 拼接上下文：System Prompt + Retrieved Context + User Query │
│    ├── 调用LLM生成答案                         │
│    └── 引用标注：答案中标注信息来源             │
├──────────────────────────────────────────────┤
│ 5. 评估与迭代                                 │
│    ├── 答案质量评估(准确性/相关性/完整性)        │
│    ├── Bad Case分析→调优                      │
│    └── 分块策略/检索策略迭代                    │
└──────────────────────────────────────────────┘

RAG设计关键决策：

模块3：Agent与多智能体系统

Agent = LLM + Memory + Planning + Tools

何时用Agent vs 简单LLM调用：

Agent架构模式：

模式1：ReAct (Reasoning + Acting)
  Thought → Action → Observation → Thought → ... → Final Answer

模式2：Plan-and-Execute
  Plan → Execute Step 1 → Execute Step 2 → ... → Summarize

模式3：Multi-Agent Orchestration
  Orchestrator → Agent A (Research) ↘
               → Agent B (Analyze) → Orchestrator → Response
               → Agent C (Write) ↗

模式4：Human-in-the-Loop (HITL)
  Agent Execute → Human Approve → Agent Continue
  关键：在哪些节点需要人类审批？（支付/发布/删除/对外发送）

HITL设计（B端Agent的合规必备）：

模块4：Prompt Engineering（提示工程）

提示工程是PM的新基本功。Prompt = B端AI产品的"UI"。

结构化Prompt设计模式：

┌─────────────────────────────────────────────┐
│ [System Prompt] - 系统级角色和能力设定          │
│ 你是[角色]，你的任务是[任务]，你的约束是[...]   │
├─────────────────────────────────────────────┤
│ [Context] - 上下文信息（来自RAG检索/用户状态）  │
│ 当前用户：[角色/部门/权限]                      │
│ 相关数据：[...]                               │
├─────────────────────────────────────────────┤
│ [Task] - 具体任务指令                          │
│ 请执行：[...]                                 │
│ 步骤：1. ... 2. ... 3. ...                   │
├─────────────────────────────────────────────┤
│ [Output Schema] - 输出格式约束                 │
│ 请按以下JSON格式输出：{ ... }                  │
├─────────────────────────────────────────────┤
│ [Few-Shot Examples] - 示例（可选但推荐）        │
│ 示例输入：[...] 示例输出：[...]                │
├─────────────────────────────────────────────┤
│ [Constraints] - 禁止事项                       │
│ 不要：[...] 如果不知道：[...]                  │
└─────────────────────────────────────────────┘

B端产品Prompt设计原则：

1. 角色设定要精准（不是"你是一个助手"，而是"你是一个有10年经验的财务审计师"）
2. 输出格式要结构（JSON Schema先行，方便下游消费）
3. 约束要明确（"不要编造数据"、"如果不知道就说不知道"）
4. 示例要真实（用真实业务场景的示例，不要用通用示例）
5. 安全要有护栏（"拒绝回答与XX无关的问题"）

模块5：Context Engineering（上下文工程）

> Context Engineering是比Prompt Engineering更深层的设计。

> 核心问题："给模型什么信息、以什么结构、在什么时机？"

上下文窗口预算管理：

总预算：128K tokens (以Claude为例)

分配策略：
├── System Prompt：2-5K tokens (角色+规则+格式)
├── 对话历史：10-20K tokens (最近的对话)
├── RAG检索结果：20-40K tokens (最相关的文档)
├── 用户当前查询：0.5-2K tokens
├── 用户画像/偏好：2-5K tokens
├── 工具定义：5-10K tokens (function definitions)
└── 预留Buffer：~20K tokens (给模型思考/生成用)

动态上下文组装：

• 根据用户角色加载不同System Prompt
• 根据当前任务类型加载不同检索策略
• 根据用户行为历史个性化上下文
• 关键信息前置（最重要的信息放在Prompt开头和结尾）

模块6：Memory Engineering（记忆工程）

让AI从"一次性对话"升级为"持续合作伙伴"。

模块7：评测体系设计

没有评测就没有AI产品迭代。

评测维度矩阵：

Golden Dataset构建流程：

1. 收集100+真实用户Query
2. 人工标注标准答案
3. 建立评分标准(Rubric)
4. 定期更新(每月补充新Query)
5. Bad Case入库→分析→调优→验证

模块8：AI UX模式设计

B端AI产品的6种交互模式（"六脉神剑"框架）：

B端AI UX原则：

1. 渐进式信任：从低风险功能开始，逐步放开高风险
2. 可撤销：AI的操作应该可以撤销
3. 可解释：AI为什么这样做？引用来源
4. 可覆盖：用户可以随时手动接管
5. 展示不确定性：不确定时显示置信度，而非假装确定

模块9：AI产品的数据飞轮

更多用户使用 → 更多交互数据 → AI效果更好 → 更多用户使用
    ↑                                              ↓
    └──────── 更好的数据质量 ← 更好的产品体验 ←──────┘

飞轮设计要点：
1. 每次用户交互都要产生可用于改进的数据
2. 隐式反馈（点击/停留/采纳）>> 显式反馈（点赞/打分）
3. Bad Case是金矿：每次失败都是改进的机会
4. 数据标注要嵌入产品流程（如"这个回答有帮助吗？"）

模块10：AI产品策略

楔子策略（O'Reilly推荐）：

传统路径：做平台 → 找场景 → 获取用户
AI时代路径：找一个痛点 → 解决得极好 → 获取信任 → 捕获数据 → 扩展

核心原则：
1. 从一个"英雄用户"的一个痛点开始
2. 做窄做深，不要做宽做浅
3. 简单的工具比复杂的Agent更值得信任
4. 数据是护城河，模型不是

B端AI产品的价值主张设计：

框架：技术功能 × 业务场景 × 量化收益

示例：
"通过大模型（技术功能）自动生成采购比价报告（业务场景），
 将采购决策时间从3天缩短至30分钟（量化收益）"

AI产品设计输出物

1. AI产品策略文档（含模型选型/数据策略/飞轮设计）
2. RAG架构设计图
3. Agent设计文档（含HITL决策矩阵）
4. Prompt模板库
5. 评测体系设计（含Golden Dataset设计）
6. AI UX交互说明

阶段6：原型与交互

角色帽：方案架构师

> B端原型核心原则：效率 > 美观。

> 参考：Marty Cagan "Design from Day One"，杨堃"界面设计"章节。

B端原型设计10原则

1. 列表页必须有：搜索/筛选/排序/分页/批量操作/导出
2. 表单必须有：必填标识/校验提示/保存草稿/提交确认
3. 详情页必须有：基本信息/关联信息/操作历史/返回
4. 每个操作必须有反馈（loading → success/error Toast）
5. 危险操作必须有二次确认弹窗
6. 批量操作必须有进度条
7. 大数据量：虚拟滚动/懒加载（超过1000条）
8. 键盘快捷键（Enter提交/Esc取消/↑↓选择/Ctrl+S保存）
9. 错误提示告诉用户"怎么办"不只是"出错了"
10. 空状态有引导（"还没有数据，点击新建第一条"）

B端标准页面模板（4类）

1. 仪表盘 Dashboard

┌──────────────────────────────────────────────────────┐
│ [Logo] 导航栏                    [消息][头像][设置]    │
├─────────┬────────────────────────────────────────────┤
│         │ ┌──────────┬──────────┬──────────┬──────┐ │
│ 侧边    │ │ 待处理数  │ 进行中   │  已完成   │ 异常  │ │
│ 导航    │ │   128    │   506   │  3,240  │  12  │ │
│         │ └──────────┴──────────┴──────────┴──────┘ │
│ 工作台 │ ┌──────────────────┐ ┌──────────────────┐ │
│ 采购管理│ │   趋势图(折线)    │ │   分类(饼图)     │ │
│ 审批    │ └──────────────────┘ └──────────────────┘ │
│ 报表    │ ┌──────────────────┐ ┌──────────────────┐ │
│ 设置    │ │   我的待办(列表)   │ │   快捷入口(卡片)  │ │
└─────────┴─┴──────────────────┴─┴──────────────────┴─┘

2. 列表页 CRUD List

┌─────────────────────────────────────────────────────┐
│ [搜索框:______] [状态▼] [日期范围▼] [搜索] [重置]    │
│                                                     │
│ [新建] [批量导入] [批量导出] [批量删除]              │
│                                                     │
│ ☐ |编号 |名称  |状态   |负责人|创建时间 |操作        │
│ ☐ |001  |...  |进行中  |张三  |06-07   |编辑 删除   │
│ ☐ |002  |...  |已完成  |李四  |06-06   |编辑 删除   │
│                                                     │
│ 已选3项 [批量审批]   共2,345条  < 1 2 3 ... 118 >   │
└─────────────────────────────────────────────────────┘

3. 表单页 Form

┌─────────────────────────────────────────────────────┐
│  基本信息 ▸                                         │
│  ┌─────────────────────────────────────────────┐   │
│  │ [*] 名称: [_____________________________]    │   │
│  │ [*] 类型: [下拉选择▼]                        │   │
│  │     描述: [_____________________________]    │   │
│  └─────────────────────────────────────────────┘   │
│  详细信息 ▸                                         │
│  ┌─────────────────────────────────────────────┐   │
│  │     日期: [日期选择器]                        │   │
│  │     附件: [选择文件]  未选择文件               │   │
│  └─────────────────────────────────────────────┘   │
│                              [保存草稿] [提交]      │
└─────────────────────────────────────────────────────┘

4. 审批详情页

┌─────────────────────────────────────────────────────┐
│ 审批单号：AP20260607001  状态：审批中(2/3)           │
├─────────────────────────────────────────────────────┤
│ 申请信息                                            │
│ 申请人：张三 | 部门：技术部 | 时间：2026-06-07      │
│ 申请金额：¥50,000.00                                │
├─────────────────────────────────────────────────────┤
│ 审批进度                                            │
│ 发起 ──✅── 部门经理 ──⏳── 财务总监 ──⭕── 总经理  │
│ 张三     李四(已通过)  审批中...    待审批           │
├─────────────────────────────────────────────────────┤
│ 审批历史                                            │
│ 06-07 10:00 发起人张三 提交申请                      │
│ 06-07 11:30 部门经理李四 通过 意见："同意采购"       │
├─────────────────────────────────────────────────────┤
│ 审批意见：[_______________]                          │
│                              [驳回] [转审] [通过]   │
└─────────────────────────────────────────────────────┘

原型产出方式

方式一：HTML交互原型（推荐，0工具依赖，最灵活）

• 完整HTML+Tailwind CSS+Alpine.js/Vue3 CDN
• 真实数据和交互，浏览器可直接运行
• 包含所有页面状态（加载态/空态/错误态/边界态）
• 包含模拟的权限控制（切换角色查看不同视图）
• 审批流交互可视化（可模拟审批通过/驳回流转）

方式二：Penpot（开源Figma/Mockplus替代品）

• 开源（MPL-2.0），Web-based，可以自托管
• 支持：矢量编辑/交互原型/组件/设计Token/实时协作
• 有Plugin API、REST API（读取）、MCP Server
• 中文友好，有社区支持

方式三：即时设计（国内Figma替代）

• 免费Web版，中文原生
• 有D2C（设计稿→代码）功能
• 有BoardMix协作白板

原型工具调用表

阶段7：图表与架构

角色帽：方案架构师 + 流程设计师

> 图是B端PM的通用语言。一图胜千言，专业图表直接决定方案评审通过率。

12类B端必画图表（含工具与命令）

可用图表工具矩阵

图表产出自检清单

□ 受众是谁？（高管=极简/技术=详细/客户=产品价值导向）
□ 核心信息能一句话说清吗？
□ 图例/颜色/符号是否一致？（同一系统用同一颜色）
□ 是否有标题 + 版本 + 日期？
□ 箭头方向是否正确？
□ 是否标注了关键决策点/异常分支？
□ 是否有遗漏的角色/系统/实体？
□ 颜色是否适合黑白打印？

B端图表配色规范

企业沉稳系（默认）：
- 主色：#1a56db (蓝色-核心系统)
- 辅助：#0e9f6e (绿色-外部系统)
- 警告：#e3a008 (黄色-待优化)
- 危险：#e02424 (红色-风险点)
- 中性：#6b7280 (灰色-非重点)
- 背景：#f9fafb
- 文字：#111827

科技蓝色系：
- 主色：#2563eb
- 辅助：#7c3aed (紫色-差异化)
- 强调：#06b6d4 (青色-亮点)

阶段8：文档工程

角色帽：方案架构师 + 产品布道师

> B端PM的文档能力 = 跨团队协作效率杠杆。

> 参考：Cagan "写作是操作系统"、杨堃"BRD/PRD/MRD"章节。

文档矩阵

B端PRD必须包含的10大模块

1. 版本历史与变更记录
2. 需求背景与商业目标（含BRD链接，数据支撑）
3. 用户角色与权限矩阵 ← B端独有
4. 核心业务流程图（泳道图，正常+异常） ← B端独有
5. 功能详细说明（含原型/字段表/交互说明/权限/状态）
6. 审批流与工作流设计 ← B端独有
7. 数据模型设计（ER图+数据字典） ← B端独有
8. 集成与接口需求（内部+外部+OpenAPI） ← B端独有
9. 非功能需求（性能/安全/可用/扩展/国际化）
10. 验收标准与测试要点（每个AC可逐条验收）

文档生成工作流

你说需求 → AI确认结构 → 生成Markdown初稿 → 
你确认→ 格式化为最终版 → 可选：转DOCX/PDF/PPT

转DOCX: 使用 word-docx skill (格式规范，符合GB/T)
转PDF: 使用 minimax-pdf skill (中文排版，设计精美)
转PPT: 使用 pptx-2 skill (提取要点，自动排版)

文档质量自检（4级标准）

> 核心交付物至少白银级，关键决策文档争取黄金级。

阶段9：开发协作

角色帽：项目管理者

标准开发协作SOP

需求评审 → 技术方案评审 → 任务拆解(WBS) → Sprint规划 → 
每日站会 → 进度跟踪 → 测试验收 → 发布上线 → 复盘

双周迭代节奏（B端标准）

Day 1-2:  PRD编写/完善
Day 3:    需求评审会（产品+开发+测试+UED）
Day 4-6:  技术方案设计
Day 7:    技术方案评审 + 任务拆解
Day 8-13: 开发（含联调）
Day 12-15: 测试
Day 16:   产品验收
Day 17:   上线准备（发布说明/帮助文档/灰度策略）
Day 18:   全量发布
Day 19-20: 线上监控 + 复盘

B端需求评审检查清单

□ 每种角色都考虑到了？（不仅是核心使用者）
□ 异常流程完整？（超时/驳回/撤回/权限不足/并发冲突）
□ 大数据量性能？（10万+条列表/1000+条批量）
□ 数据一致性？（事务边界/分布式一致性）
□ 历史数据兼容/迁移方案？
□ 权限控制覆盖所有操作？（读/写/批/导/审）
□ 审计日志覆盖所有CUD操作？
□ 通知/提醒触发是否正确？
□ 多语言/多时区/多币种？
□ 移动端审批适配？
□ 是否有需要预研的技术风险？

验收标准AC写法

格式：Given [前置条件] When [用户操作] Then [预期结果]

示例：
AC-001: Given 用户是采购申请员且有新增权限
        When 用户填写所有必填项并点击[提交]
        Then 系统创建采购申请记录，状态为"审批中"，
             并触发审批流，下一节点审批人收到通知
        
AC-002: Given 采购申请状态为"审批中"且当前审批人是张三
        When 张三点击[驳回]并填写驳回原因
        Then 采购申请状态变为"已驳回"，
             发起人收到驳回通知，
             发起人可编辑后重新提交

发布前检查清单

□ P0测试用例全部通过
□ P0 Bug全部修复
□ 数据迁移脚本就绪（如有）
□ 回滚方案就绪
□ 帮助文档已更新
□ 发布公告已准备
□ 客户通知已发出（如涉及已有客户）
□ 监控告警已配置
□ 灰度方案已确定

阶段10：数据与增长

角色帽：数据策略师

B端核心指标体系（5层金字塔）

L1: 北极星指标 (1个)
    └── L2: 一级指标 (4-6个)
         ├── 获客：MQL→SQL→赢单率→CAC→CAC Payback
         ├── 激活：Onboarding完成率 → Time to First Value
         ├── 使用：DAU/WAU/MAU → 功能采用率 → 粘性系数
         ├── 收入：ARR/MRR → ARPU → LTV → NRR → NDR
         └── 质量：NPS/CSAT/CES → Churn Rate
              └── L3: 二级指标 (10-20个，操作级)
                   └── L4: 三级指标 (诊断级，按需)

B端北极星指标选择指南

B端特有指标详解

B端产品阶段与指标聚焦

数据看板设计原则

1. 一屏看完（不需要滚动）
2. 7-10个核心指标，不要多
3. 有对比（vs上周/上月/去年同期）
4. 有预警线（红黄绿）
5. 有下钻入口（点击进入详情）
6. 每周自动推送报告

阶段11：商业化与GTM

角色帽：商业化操盘手 + 产品布道师

B端定价策略深度

定价模式决策树

你的产品是？
├── 协作型（多人使用才有价值）→ 按用户/席位数
├── 功能差异大 → 按功能分层（Good/Better/Best）
├── 用量驱动 → 按用量/API调用/存储
├── 交易平台 → 按GMV抽佣 / 固定费率
└── 混合型 → 基础费+用量费 或 基础费+功能分层

套餐设计铁律

1. 3个套餐最优：基础版 / 专业版(推荐) / 企业版
2. 中间套餐是锚点：利润最高、推荐最多
3. 企业版必须有"联系销售"：留资入口，让大客户主动联系
4. Free Trial > Free Plan
5. 年付8折是标配（降低流失，改善现金流）
6. 定价数字心理：¥9,999 > ¥10,000

定价数字策略

月付 → 年付折扣：月付×10（≈83折）
阶梯价格：用户数越多，边际单价越低
锚定效应：展示企业版高价，让专业版"看起来很值"
价格页设计：推荐套餐高亮（"最受欢迎"标签）、功能对比表、FAQ区

GTM策略一页纸

1. ICP（Ideal Customer Profile）：目标客群画像
2. 价值主张一句话
3. 定价与套餐
4. 销售渠道：直销/渠道/PLG/混合
5. 销售材料包：一页纸/白皮书/Demo脚本/竞争对比表/ROI计算器
6. Onboarding流程（客户90天健康计划）
7. 市场推广计划
8. 关键里程碑与目标

销售赋能包全套清单

阶段12：运营与迭代

角色帽：客户成功伙伴 + 产品布道师

B端客户生命周期管理

获客 → Onboarding → Adoption → Value → Expansion → Renewal/Advocacy
  ↑                                                          ↓
  └────────────────── 持续反馈循环 ──────────────────────────┘

客户健康度模型

客户健康度 Score = 
  产品使用深度 × 0.30 +
  关键人活跃度 × 0.20 +
  NPS/CSAT × 0.15 +
  工单频率(反向) × 0.15 +
  增购信号 × 0.10 +
  合同剩余时间 × 0.10

红黄绿阈值：
- 绿（>75）：健康，按常规节奏
- 黄（50-75）：预警，CSM主动介入
- 红（<50）：高风险，升级处理，制定挽救计划

B端产品运营框架

产品运营4大模块：
├── 客户运营：Onboarding→Adoption→定期的价值复盘→续约
├── 功能运营：功能使用分析→低采用率排查→培训/优化→淘汰
├── 内容运营：帮助文档/最佳实践/产品博客/培训视频
└── 数据运营：指标监控→异常预警→数据洞察→驱动迭代

高级工作流体系

> 以下是高级B端PM的标准工作流、会议节奏和OKR体系。

一、双轨敏捷（Dual-Track Agile）

轨道1：Discovery（发现） — 持续探索"做什么"

• 用户访谈 → 机会识别 → 方案假设 → 原型验证 → 实验 → 验证通过进入交付

轨道2：Delivery（交付） — 高效执行"怎么做"

• Sprint Planning → 开发 → 测试 → 验收 → 发布

双轨衔接点： Discovery验证通过的需求进入Delivery Backlog

产品三人组： PM（价值）+ Designer（体验）+ Tech Lead（可行性）

二、持续发现系统（Teresa Torres）

5个核心习惯：

1. 每周至少访谈1个客户（产品三人组一起）
2. 构建机会解决方案树(OST)：Outcome → Opportunities → Solutions → Experiments
3. 假设驱动：列出假设→按风险排序→先测最危险的
4. 小而快的实验：访谈/原型/假门测试/调查问卷
5. 产品三人组全员参与发现

故事式访谈法：

• ❌ 不要问："你会用这个功能吗？"
• ✅ 应该问："告诉我你上次[做某件事]的经历"
• 收集真实的过去行为，而不是假想行为

三、产品运营模型（Marty Cagan）

5大核心原则：

四、标准工作流SOP（完整版）

┌─────────────────────────────────────────────────┐
│ 阶段1：需求收集与研判                              │
│ 收集→清洗→分类→5Why分析→JTBD→输出需求池           │
├─────────────────────────────────────────────────┤
│ 阶段2：方案设计                                    │
│ 业务流程→功能架构→权限设计→数据建模→原型→PRD       │
├─────────────────────────────────────────────────┤
│ 阶段3：需求评审                                    │
│ PRD→需求评审会→修改→方案冻结                       │
├─────────────────────────────────────────────────┤
│ 阶段4：UI/UX设计                                  │
│ 设计稿→设计评审→修改→设计冻结                       │
├─────────────────────────────────────────────────┤
│ 阶段5：技术方案                                    │
│ 技术方案设计→技术评审→任务拆解→排期                 │
├─────────────────────────────────────────────────┤
│ 阶段6：开发与测试                                  │
│ Sprint启动→每日站会→测试→Bug修复→提测              │
├─────────────────────────────────────────────────┤
│ 阶段7：验收与发布                                  │
│ PM验收→预发布环境→灰度→全量上线→监控               │
├─────────────────────────────────────────────────┤
│ 阶段8：复盘与迭代                                  │
│ 数据回顾→假设复盘→改进计划→下版本规划              │
└─────────────────────────────────────────────────┘

五、B端PM的标准周/月/季节奏

每周节奏：

月度节奏：

季度节奏：

六、OKR工作流(季度标准)

Week -4: 收集顶层优先事项，调查团队，识别上季度结转
Week -3: 起草公司OKR → 分享征求意见 → OKR峰会
Week -2: 团队OKR对齐 → 跨团队依赖关系 → OKR回放会
Week -1: OKR最终确定 → 季度启动会
Week 1-12: 每周OKR检查（信心指数1-10分）
Week 13: OKR评分 → 季度复盘

OKR黄金法则：
- 每季度3-5个O，每个O 2-4个KR
- 70%达成率 = 成功（100%说明目标太保守）
- 关注结果非产出：不是"上线XX功能"，而是"XX指标从A提升到B"

能力模型与职业发展

B端PM能力金字塔（参考杨堃《决胜B端》）

               ┌──────────────┐
               │  商业认知     │  ← 行业洞察/商业模式/企业架构
               │  (40%)       │
               ├──────────────┤
               │  系统设计     │  ← 产品规划/需求分析/业务建模/
               │  (25%)       │     权限设计/报表设计/项目管理
               ├──────────────┤
               │  项目管理     │
               │  (20%)       │
               ├──────────────┤
               │  商业嗅觉     │
               │  (15%)       │
               └──────────────┘

中国企业PM能力模型对比（腾讯/阿里/字节）

PM到CPO的成长路径

B端PM硬技能清单

必会：
□ 业务建模（ER图、UML、数据字典）
□ 权限设计（RBAC/ABAC）
□ 数据库基础（至少会写SQL）
□ API设计（RESTful基本概念）
□ 数据分析和埋点设计
□ 项目管理（敏捷/Scrum/Kanban）

进阶：
□ 企业架构（TOGAF基础/4A架构）
□ AI产品设计（RAG/Agent/Prompt Engineering）
□ 微服务架构基础概念
□ 多租户架构设计
□ 合规知识（等保/GDPR/个保法/SOC2）
□ 财务基础（定价/预算/ROI/NRR）

图表工场

一键画图

直接描述你要画什么，自动匹配工具生成 .drawio 可编辑源文件。

"画采购审批泳道图，角色：采购员/采购主管/财务/总经理"
"画CRM系统的C4容器图"
"画XX模块的ER图"
"画审批流状态机图"
"画手绘风格的用户旅程图，角色：企业采购经理"

工具调用规则

输出：.drawio + .png 预览（含内嵌XML，随时用draw.io编辑）

原型工场

一键生成可交互原型

"生成一个企业采购管理后台的HTML原型，包含：仪表盘/采购申请列表/新增申请表单/审批详情"
"生成一个CRM合同管理列表页原型，带搜索筛选批量操作分页"

输出：完整HTML文件（Tailwind CSS + Alpine.js CDN），浏览器直接运行，包含：

• 侧边导航+顶部栏+面包屑
• 表格带排序/筛选/分页/多选
• 表单带校验（必填/格式/长度）
• 弹窗确认/抽屉详情
• 审批流状态可视化
• 切换角色查看不同权限视图
• 模拟数据

文档工场

一键生成专业文档

"写一份企业采购管理的完整PRD"
"写一份HR SaaS的市场需求文档MRD"
"做一份钉钉OA审批的竞品分析报告"

流程：描述需求 → 确认结构 → 生成Markdown → 可选转为DOCX/PDF/PPT

转格式命令

PPT工场

B端PPT类型

配色方案

工具集成总表

本Skill自动调用的工具

工具决策原则

1. 自动选择最优：不需要用户指定工具
2. 可编辑源文件优先：drawio→.drawio，PPT→.pptx
3. 预览同步输出：图表同时输出.png预览
4. 中文排版标准：中文文档符合GB/T标准

使用示例

示例1：从0到1做一款B2B SaaS产品

用户：帮我从0到1规划一款企业合同管理SaaS

产出顺序：
阶段1 → 行业分析(市场规模/趋势/竞品) + 产品战略一页纸
阶段2 → 用户画像(法务/销售/高管3角色) + 用户旅程图 + JTBD卡片
阶段3 → 需求池 + KANO分类 + RICE优先级排序
阶段4 → 权限矩阵 + 审批流设计 + 数据字典 + 集成方案
阶段5 → (如涉及AI功能)AI功能设计文档
阶段6 → HTML交互原型(仪表盘/合同列表/审批详情/模板库)
阶段7 → 业务泳道图 + 系统架构图(C4) + ER图 + 状态机图
阶段8 → 完整PRD文档 + 转为DOCX/PDF
阶段11 → 定价方案(3套餐) + 销售一页纸 + Demo脚本

示例2：现有产品加AI功能

用户：给我的CRM系统加一个AI智能合同审查功能

产出顺序：
阶段5 → AI能力方案：模型选型(闭源API+RAG) + 
        RAG架构(合同条款检索) + Prompt工程(审查规则) +
        HITL设计(AI建议→人确认) + 评测体系(Golden Dataset)
阶段4 → 权限设计(谁可以用AI审查) + 审计设计(AI建议需记录)
阶段6 → HTML原型(合同上传→AI审查→风险标注→人工复核)
阶段8 → PRD(AI功能部分)含准确率要求和异常处理

示例3：高级PM周常

用户：我是B端PM，帮我建立工作流和本周计划

产出：
→ 制定双轨敏捷模式(Discovery+Delivery)
→ 建立双周迭代节奏
→ 本周日历：周一周会/周二客户访谈/周三PRD写作/
  周四跨部门对齐/周五数据Review
→ 需求管理工作流SOP
→ 会议模板(需求评审会/迭代计划会/复盘会)

世界级B端PM框架库（全球顶级方法论）

Shreyas Doshi的LNO框架（时间分配）

把所有工作分为三类：
L - Leverage（杠杆）：做了会产生复利效应的事（10x impact）
N - Neutral（中性）：做了有线性回报的事
O - Overhead（开销）：必须做但没有直接价值的事

时间分配目标：L:70% N:20% O:10%
实际多数PM的时间分配：L:20% N:40% O:40%

B端PM的L类工作：
- 与KA客户深度访谈（发现洞察而非确认需求）
- 建立产品策略文档（影响整个团队的方向决策）
- 设计数据模型和架构（一旦错了后期成本极高）
- 培养产品团队（复利效应最大的投资）

Gibson Biddle的DHM框架（产品策略评估）

D - Delightful（令人愉悦）：这个功能让用户惊喜吗？
H - Hard-to-copy（难以复制）：竞争对手能多快复制？
M - Margin-enhancing（有利润）：它提升利润还是只是增加成本？

评估每个战略决策：D×H×M综合评分
理想的功能：三高（D高+H高+M高）
避免的功能：只有D但H和M都低（容易被复制但不赚钱的"礼物"功能）

Hamilton Helmer的7种力量（B端竞争优势）

Geoffrey Moore的跨越鸿沟（B端GTM圣经）

技术采纳生命周期：
Innovators(2.5%) → Early Adopters(13.5%) → [THE CHASM] → 
Early Majority(34%) → Late Majority(34%) → Laggards(16%)

B端科技公司失败的主要原因：卡在鸿沟处
- Early Adopters愿意冒险尝试新技术
- Early Majority只买"已经被验证的解决方案"
- 跨越鸿沟的唯一方法：找到滩头市场(Beachhead)，做到小池大鱼

滩头市场选择标准：
1. 客户有明确的、紧急的痛点
2. 预算已经在、或可以快速获得
3. 能在该细分做到无可争议的第一
4. 可以以此为跳板进入相邻市场

Bob Moesta的JTBD进展四力模型

┌──────────────────────────────────────┐
│  当前情境的推力 →  ← 新方案的拉力     │
│  (对现状的不满)      (对新方案的期待)  │
│                                      │
│  ← 新方案的焦虑      → 旧习惯的惯性   │
│  (切换风险/成本)     (行为惯性/沉没成本)│
└──────────────────────────────────────┘

B2B购买者的四力：
- 推力："现有系统太慢，部门在抱怨"
- 拉力："新系统的自动化能释放我团队20%的精力"
- 焦虑："数据迁移会不会出问题？团队能学会吗？"
- 惯性："已经在现有系统投入200万，合同还有18个月"

John Cutler的功能工厂诊断（Product Feature Factory）

你的团队是"功能工厂"吗？自查：
□ 以"交付了多少功能"为骄傲，而非"产生什么成果"
□ 路线图是带固定日期的功能列表，而非待验证假设
□ 极少有用户直接参与的发现活动
□ 上线后不追踪使用情况和业务影响
□ 需求直接来自销售/客户，不做需求分析
□ 没有OKR或OKR是"上线XX功能"（产出，非成果）

统计数据：只有10-30%的功能能带来可衡量的业务影响
脱困方法：用成果(Outcome)替代产出(Output)作为成功度量

Richard Rumelt的好策略坏策略

好策略 = 诊断 + 指导原则 + 一致性行动

诊断（Diagnosis）：对当前挑战的本质判断
  "我们不是缺功能，而是客户不知道怎么用现有功能"
  
指导原则（Guiding Policy）：克服障碍的总体方针
  "聚焦Onboarding体验，让新客户7天内感受到核心价值"
  
一致性行动（Coherent Actions）：互相协调的具体动作
  - 设计引导式Onboarding流程
  - 建立CSM主动触达机制
  - 简化核心功能的操作路径

坏策略 = "听起来不错的废话"
  "我们要成为行业最好的XX平台" ← 这是愿景，不是策略
  "我们今年的重点是增长" ← 这是目标，不是策略

Petra Wille的PM能力轮盘

PM能力8维度评估：
       理解客户问题
           │
   构思/方案形成 ──┼── 路线图规划
           │
   交付 & 执行 ───┼─── 倾听 & 学习
           │
   团队激励 & 辅导─┼─── 个人持续成长
           │
        敏捷原则应用

每季度自评每个维度（1-5分），识别短板作为成长目标

产品运营体系（Melissa Perri Product Ops 3支柱）

PRD 14维质量评审框架

B端反模式大全（20个常见错误）

策略类反模式

需求类反模式

执行类反模式

B端特有反模式

B端产品进化路径（Custom→Commercial→Platform→Ecosystem）

阶段1：项目定制（Customization）
  ├── 为一个头部客户做项目交付
  ├── 深度理解业务领域
  └── 目标：验证业务价值，积累行业认知

阶段2：商业化（Commercialization）
  ├── 抽象共性，构建标准化产品
  ├── 行业分析+竞品分析+商业化重构
  └── 目标：从一个客户扩展到N个客户

阶段3：平台化（Platform/PaaS）
  ├── 配置化能力（对象编辑器/流程编辑器/报表/前端组件）
  ├── 多租户支持+自定义扩展
  └── 目标：客户/ISV可自主配置，减少定制开发

阶段4：生态化（Ecosystem）
  ├── 开放API + 应用市场 + ISV生态
  ├── 开发者文档 + SDK + 沙盒环境
  └── 目标：从卖产品到卖平台，网络效应护城河

平台产品管理（Platform PM 专项）

麦肯锡5项平台转型行动

1. 建立平台治理机制：单一"任务控制中心"
2. 创建自主的产品/平台团队：有持续的资源保障
3. 重构资金模式：按产品领域而非项目拨款，与OKR挂钩
4. 业务与技术联合问责："双人模式"或"三人模式"
5. 投资开发者体验：10-30%的开发能力用于工程自动化

平台成功5原则（ThoughtWorks）

1. 清晰的愿景与价值假设（具体的、可衡量的目标）
2. 一致的平台策略（选择正确的平台类型）
3. 产品思维（把平台本身当作产品来管理）
4. 新的工作方式与团队结构（围绕产品而非项目组织）
5. 精心的变革管理（文化转型与技术转型并行）

平台健康度公式

平台健康度 = 
  功能复用率 × 0.3 + 
  API标准化率 × 0.4 + 
  可扩展性成本系数 × 0.3

API产品管理专项

API产品化的4步流程

Step 1: 定义API的价值主张（解决什么问题？为谁？）
Step 2: 设计开发者体验（文档/沙盒/SDK/示例代码）
Step 3: 建立API治理（版本管理/限流/安全/监控）
Step 4: 衡量API成功（调用量/成功率/开发者满意度/业务贡献）

API设计规范

版本管理：URL路径版本 /api/v1/
认证：Bearer Token + API Key + OAuth2.0
限流：令牌桶算法，按API Key粒度
文档：OpenAPI 3.0，Swagger自动生成
错误码：统一4位错误码 + message + details
分页：cursor-based（推荐），或page-based

B端定价科学（Pricing Science）

定价的三大支柱

1. 价值指标（Value Metric）：按什么收费？
   ├── 按用户数（协作型产品）
   ├── 按用量（API/存储/计算）
   ├── 按功能分层（功能差异大）
   ├── 按成果（GMV抽佣/效果付费）
   └── 混合（基础费+用量费）

2. 价格水平（Price Level）：收多少钱？
   基于价值研究：客户愿意为解决问题付多少钱？
   
3. 折扣规则（Discount Rules）：什么情况打折？
   ├── 年付8折
   ├── 批量采购阶梯折扣
   └── 竞争性折扣（需审批）

PSM价格敏感度测试（4个关键点）

PMC (Point of Marginal Cheapness)：太便宜以至于怀疑质量
PME (Point of Marginal Expensiveness)：太贵开始放弃
OPP (Optimal Price Point)：最优价格点
IPP (Indifference Price Point)：无所谓价格点

定价区间：PMC ← OPP → PME
推荐定价通常接近OPP

定价提升1% = 利润提升8.7%（麦肯锡数据）

企业管理好折扣比涨价更重要：
无管理的折扣每年侵蚀200-400个基点的毛利
解决方案：折扣规则自动化+审批流程+毛利可见性

干系人管理（Stakeholder Management）

加权干系人评分法

干系人优先级 = Σ (关联度 × 兴趣度)

关联度（Relevance）：
  主要=9，次要=3，第三层=1

兴趣度（Interest）：
  高=9，中=3，低=1

示例：
  CTO（主要×高）= 9×9 = 81  → 密切关注
  法务（第三层×高）= 1×9 = 9  → 保持知情

客户顾问委员会（CAB）建设

CAB = Customer Advisory Board

建设步骤：
1. 选人：8-12个战略客户的高管（非使用者）
2. 节奏：每年2-4次正式会议
3. 内容：产品方向验证、行业趋势讨论、成功案例分享
4. 价值：客户获得影响力，你获得战略方向验证
5. 红线：CAB不是销售渠道，不是需求收集会

跨部门沟通"三条线"法

1. 非正式沟通（台下）：
   正式会议前的私下预沟通
   了解各方真实立场和顾虑

2. 正式沟通（台上）：
   会议纪要、邮件审批作为执行依据
   确保决策有记录、可追溯

3. 情感沟通（线上/线下）：
   55%肢体语言+38%语调+7%内容
   共同经历（吃饭/出差/团建）建立信任

4U问题优先级框架（说服干系人用）

面对多个问题需要排优先级时，每个问题打分(1-5)：
U1 - Unworkable（无法运转）：不解决会出多大事？
U2 - Unavoidable（无法逃避）：能绕开吗？
U3 - Urgent（紧急）：多快需要解决？
U4 - Underserved（未被满足）：现有方案多差？

优先解决：至少3个维度≥4分，且没有任何维度≤2分

D × V × F > R 采纳公式

Pain(D) × Value(V) × First Step(F) > Resistance(R)

痛苦程度 × 价值感知 × 第一步清晰度 > 改变阻力

三项中任何一项为0，产品就不可能被采纳

B端应用：
- D（痛苦）：量化现状的损失（时间/金钱/风险）
- V（价值）：量化采用后的收益
- F（第一步）：设计极低的试用门槛（1分钟看到效果）
- R（阻力）：数据迁移成本+培训成本+政治阻力+合同锁定

B端企业用户体验原则

B端UX核心优先级（牢记！）

稳定性 > 效率 > 易用性 > 视觉吸引力
   │        │       │         │
 业务闭环   操作速度  上手难度   美观程度

B端UX设计的10项原则

1. 稳定性优先于美观 —— 先完成业务闭环，再谈体验
2. 坚持MVP —— 早发布、持续迭代 
3. 支持持续操作 —— 面向高频、专业用户
4. 高频功能优先展示，低频功能折叠隐藏
5. 交互一致性 —— 相同的操作永远同样的方式完成
6. 就地交互 —— 浮层编辑、行内操作，减少页面跳转
7. 即时引导降低学习成本 —— 任务提示卡、空状态引导
8. 善用专业组件 —— 数字键盘、树形选择器、批量操作
9. 冷静专业色调 —— 适合长时间沉浸工作
10. 多角色视角 —— 每种角色的体验都要独立设计

TTC（Time to Confidence）原则

TTC = 用户从打开系统到"我心里有底了"的时间

如果TTC太长，用户会绕过你的系统用Excel/微信
→ 这是Shadow IT的根源，直接导致数据泄露

降低TTC的方法：
- 首次登录展示引导式Dashboard（而不是空白页）
- 核心操作≤3步完成
- 提供示例数据让用户探索
- 错误信息告诉用户"怎么办"不只是"出错了"

最后的提醒

> B端产品经理的终极心法（10条铁律）：

>

> 1. 你设计的是组织的数字神经系统，不是个人玩具

> 2. 效率 > 炫酷，企业用户不为花哨买单，为效率买单

> 3. 兼容 > 创新，企业IT环境复杂，能对接比好用更重要

> 4. 安全 = 底线，数据泄露一次可能让公司倒闭

> 5. 干系人 > 用户，B端的决策者和使用者不是同一个人

> 6. 持续价值 > 一次性销售，B端的核心商业模式是续约和增购

> 7. AI是工具不是魔法，从窄场景开始，用数据建护城河

> 8. 设计系统，不是功能，B端PM设计的是企业运作方式

> 9. 异常流程是主流程的3倍工作量，但必须全部覆盖

> 10. 你是产品的CEO，不是需求传递者，对最终结果负责

> 开始使用：直接告诉我你要做什么，Skill自动匹配阶段、方法论、工具链。

> 无论你是产品小白还是10年老兵，这个Skill都是你的B端PM超级助理。