这是一门 AIPMM(产品管理与营销协会)体系的 AI Product Manager Professional Certificate 课程笔记。它面向「想入门或系统化 PM 知识」的人,但本篇笔记的读者是已经在做产品的 PM——所以我只抽「值得一个有经验的 PM 随手记的命名框架 / 模型 / 清单」,把扫盲段(PM 是干嘛的)全部跳过,改成「这门课给了哪些可以直接套用的脚手架」。
重组成六块:①PM 角色与职责(含 AI PM 的差异)→ ②产品生命周期方法 → ③战略与创新框架 → ④干系人协作与沟通风格 → ⑤业务与商业化 → ⑥职业发展。每节给「框架名 + Why + 何时用 / 反例」。
和已有 wiki 的分工:协作中 PM 和 UX「这活归谁」的实证分歧、RACI 落地细节、PLG 增长见 NNGroup 产品与 UX 协作(PM×UX 职责分歧实证 · 重叠工作根因 · PM 角色模型 · RACI 分工 · 合作五建议 · UXer 像产品领导者思考 · PLG · 术语表);AI PM 和工程/设计协作的具体打法见 AI 时代 PM / Design / Eng 三人组协作(跨作者主题综合)。本篇不重写这些,只在相关处指过去——本篇定位是框架词典 + 方法论骨架。
一、PM 角色与职责
1.1 产品管理的定义与边界(Conceive→Retire)
框架:产品管理 = 对一个产品全生命周期负责的方法,涵盖 7 个动作——构思(Conceive)→ 规划(Plan)→ 开发(Develop)→ 测试(Test)→ 上线(Launch)→ 交付(Deliver)→ 退市(Retire)。本质回答三个问题:做什么产品、为什么做、怎么持续让它创造价值。
两条正交的切分,记下来在面试和组织对话里都好用:
- Internal vs External PM:内部 PM 做公司内部工具(HRIS / CRM / ERP),目标是提效;外部 PM 做面向客户的产品(实体 / 数字 / SaaS),目标是收入。
- Upstream vs Downstream:上游偏战略(产品战略 / 路线图 / 新品规划 / 产品组合,「决定做什么」);下游偏执行与商业化(生命周期管理 / 上线运营 / 市场推广 / 销售支持,关注 Growth/Maturity/Decline,「把产品推向市场并经营」)。
Why / 何时用:组织结构没有标准答案(受公司规模 / 行业 / 文化 / 复杂度影响),所以你进一家新公司,第一件事是定位自己落在 internal/external × upstream/downstream 的哪个格——这决定你的成功指标是「效率」还是「收入」、是「方向」还是「运营」。反例:一个 upstream 战略 PM 的岗位,却拿 downstream 的上线运营指标考核你,这是错配,入职前就该问清。
1.2 PM ≠ 项目经理(Product Manager ≠ Project Manager)
这是整门课反复强调的分界,一句话钉死:PM 决定「做什么 / 为什么(What / Why)」,项目经理(PgM)负责「怎么做 / 何时交付(How / When)」。 PM = 业务负责人(business owner),PgM = 交付负责人(delivery owner)。
| 维度 | 产品经理 PM | 项目经理 PgM |
|---|---|---|
| 核心职责 | 管产品 | 管项目 |
| 时间跨度 | 长期(几年) | 短期(几周/几月) |
| 起点→终点 | 产品概念 → 产品退市 | 产品定义后 → 项目完成 |
| 管什么 | 用户 / 市场 / 商业 | 进度 / 预算 / 范围 |
| 成功标准 | 产品成功(收入/份额/留存/满意度) | 项目成功(按时/预算内/范围/质量) |
Why:很多公司「混岗」,一个人同时戴两顶帽(下文 1.6 的 two-hat syndrome)。但理论上分清能避免一个陷阱——用交付指标(按时上线)冒充产品指标(产品赚不赚钱)。一个 VR 头显产品里,PM 关注「用户能否无缝接入现有平台」,项目经理把它拆成硬件 / 平台集成 / 测试多个项目;一个 PM 常对应多个 PgM。反例:团队把「按时上线」当成功,结果准时交付了一个没人要的功能——项目成功了,产品失败了。
1.3 PM 的核心职责清单与技能盘点
最核心的 3 个职责(技能清单视角):Vision(看清市场空白:用户缺什么 / 市场缺什么 / 为什么做)、Collaboration(跨 Engineering/UX/Marketing/Sales/Delivery/Leadership 推动,自己不做产品)、Customer Advocate(替用户说话——工程问「怎么做」,PM 问「用户到底要什么」)。
PM 的位置 = 公司中枢,处在 Technology × Business × Marketing 的交叉点,是连接这些团队的「胶水」,通常汇报给 CPO 或 CMO。完整职责展开:战略 / 用户理解 / 市场竞品 / 产品规划 / 路线图 / 优先级 / 跨团队协作 / Ownership(产品出问题先找 PM)/ Advocacy(产品代言人)/ 生命周期管理 / 创建用户画像(persona)。
何时用这份清单:做自我能力盘点或给团队定 JD 时,对照「Vision / Collaboration / Advocate」三大支柱看哪条最弱。反例:把 PM 做成「需求管理员」(只写 PRD、排需求、跟开发)——课程反复定性这是退化,真正的 PM 是「跨部门业务整合者」。
1.4 商业敏锐度(Business Acumen)——像老板一样想
框架:business acumen = 理解商业怎么赚钱,并在复杂业务里做对公司有利的决策。三类核心商业能力 + 三类配套能力:
- 数据分析能力:看数据 / BI 工具 / 竞品分析 / 趋势预测——看懂用户行为找问题找机会(为什么流失?哪个功能没人用?增长为什么卡?)。
- 财务能力(Financial Literacy):必须懂 6 个基础指标——Cash Flow(现金流)/ Profit(利润)/ ROI(投资回报率)/ IRR(内部收益率)/ NPV(净现值)/ Payback(回本周期)。目的不是做财务,是判断「这产品值不值得做」。
- 市场能力:目标用户是谁 / 用户真正想要什么 / 怎么定位 / 怎么比竞品更有价值。
- 配套:战略能力(产品路线要匹配公司战略:增长?利润?国际化?AI 转型?)、适应力(预算被砍 / 优先级变 / 供应链 / 政策法规——会动态调整路线)、领导力(没有直接管理权也能推动)、沟通影响力(向上讲战略争资源,向下讲目标节奏)。
Why:这是「优秀 PM ≠ 需求管理员」最硬的那块——懂财务让你能在资源争夺里用公司听得懂的语言说话(用 NPV/Payback 论证一个功能值得投)。何时用:给老板做立项答辩、争预算时,把用户价值翻译成 ROI/回本周期。
1.5 AI PM 与传统 PM 的差异(本课的灵魂)
核心命题:AI 产品不是「设计→开发→上线→维护」的线性软件,而是持续学习系统——数据、模型效果、用户信任和功能本身同样重要,「一次上线就结束」不成立。AI PM = 传统 PM + AI 理解 + 数据战略 + AI 伦理治理。
AI 如何改写产品生命周期每一步(这张对照表是全课最值得记的):
| 阶段 | 传统产品 | AI 产品额外要做 |
|---|---|---|
| Conceive 构思 | 定义用户需求 / 场景 | 还要定义数据需求 / 模型目标 / AI 能解决什么 |
| Plan 规划 | 固定路线图 | 迭代型路线图(模型表现会变,留学习调整空间) |
| Develop 开发 | 按需求写代码 | 还要训练 / 调优 / 持续改进模型 |
| Qualify 验证 | Alpha/Beta 测功能 | 还要验证模型在不同数据集下稳定 / 公平 / 可靠 |
| Launch 上线 | 一次正式发布 | 渐进式发布(Progressive Rollout),边上线边调模型 |
| Deliver 运营 | 关注功能表现 | 额外监控 Model Drift(模型漂移),持续 retrain |
| Retire 退市 | 停止支持 | 还要处理模型下线 / 数据处理 / 系统退役合规 |
AI PM 四大新挑战:①数据质量(脏/少/偏 → 模型不可靠,要尽早数据治理)②偏见与伦理(引入 Responsible AI 框架)③人才断层(传统 PM 不懂 AI / AI 工程师不懂产品,需要 hybrid 人才)④用户信任(黑箱难信任,要推 explainability 可解释性 + transparency 透明度)。
真实案例的反直觉点:金融反欺诈 AI——欺诈策略会变,所以模型不能一次训练永久用,要建固定 retraining 机制(如每 3 个月重训)+ 实时监控。
Why / 何时用:这是有经验 PM 转 AI PM 最该内化的——你的产品永远不会「完工」,你的工作里凭空多出「数据策略 / 模型效果 / 风险治理 / 信任机制 / 持续学习」五条线。反例:用做 SaaS 功能的思路管 AI 产品,定个固定路线图、上线后就转维护——模型漂移会让效果悄悄变差,等用户投诉才发现已经晚了。
1.6 软技能与 Two-Hat Syndrome
软技能清单:领导力(团队愿不愿跟你的方向,把分歧转成价值)/ 研究 / 分析思维(把大问题拆成可解决的小问题)/ 沟通 / 创造力 / 团队协作。
双帽综合征(Two-Hat Syndrome):很多 PM 同时戴两顶帽——Hat 1 产品规划(vision/strategy/roadmap,战略)+ Hat 2 项目管理(timeline/资源/执行,执行)。两顶都重,同时戴容易战略被执行吞掉。解法:引入专业项目经理支持,保持角色清晰。
何时用:当你发现自己整天在跟进开发进度、根本没时间想产品方向时,就是被 Hat 2 吞了——这是要求配 PgM 的信号,不是你不努力。
二、产品生命周期方法
2.1 两个生命周期别混(Product Lifecycle vs Product Management Lifecycle)
这是本模块的地基,极易混:
- 产品生命周期(Product Lifecycle) = 产品本身从诞生到退场,4 阶段:导入(Introduction)→ 成长(Growth)→ 成熟(Maturity)→ 衰退(Decline)。描述的是「产品在市场上的状态」。
- 产品管理生命周期(Product Management Lifecycle) = 产品团队推进产品的方法/流程,7 阶段(下文 2.3)。描述的是「PM 怎么干活」。
产品生命周期 4 阶段 + PM 重点:
| 阶段 | 特征 | PM 重点 |
|---|---|---|
| 导入期 | 刚上市,Early Adopters,产品常不完美(bug/体验) | 制定完整上市策略 + 快速收反馈改进;风险最高,可能直接失败 |
| 成长期 | 被市场接受,快速扩张 | 加大推广扩用户;谨慎(已在线上,错误调整直接伤体验) |
| 成熟期 | 增长放缓,用户稳定,停留最久 | 持续优化延长生命周期;营销更精细(从「让你知道」到复杂策略) |
| 衰退期 | 需求下降 / 被新技术替代(CD→流媒体) | 提前识别衰退信号,决定优化 / 退出 / 做下一代,别等市场消失才动 |
Why:判断「产品现在处于哪个阶段」直接决定你该做什么动作——成熟期还在猛推新功能可能是浪费,衰退期还想「继续增长当前产品」是逆势。反例:把所有阶段都当成长期来运营,在衰退期投入大量资源做新功能,而不是规划下一代。
2.2 价值创造的三种交付方式(瀑布 / 迭代 / 增量迭代)
框架:价值创造的本质 = 产出价值 > 投入成本,且用户价值 × 商业价值两边必须同时成立(用户喜欢但不赚钱 = 失败;赚钱但用户不需要 = 也失败)。落到「怎么把想法变成产品」,有三种交付节奏:
| 方式 | 怎么做 | 用户何时拿到价值 | 改动难度 | 适合 |
|---|---|---|---|---|
| Serial / 瀑布 | 一次定全、按序执行 | 最后 | 很难 | 需求稳定、不能试错:汽车/医疗/航空/硬件 |
| Iterative / 迭代 | 做一轮改一轮 | 不一定(可能只是内部版) | 可以 | 需要边做边学、目标待明确 |
| Iterative+Incremental / 增量迭代 | 一边做一边上线 | 很早 | 很容易 | 互联网产品(微信从发消息一路加图片/语音/朋友圈/支付) |
纯迭代 vs 增量迭代的关键区别(最易混):纯迭代可能是内部版本反复改、用户看不到;增量迭代每一轮都对外交付真实用户价值。
Why / 何时用:选错交付方式 = 选错风险结构。造汽车用「先上线看反馈」会出人命;做互联网产品用瀑布则会在几个月后才发现方向错了、代价巨大。PM 在不同方式里的角色也变:瀑布里 PM 是「规划师」(前期想清楚),迭代里是「实验负责人」(持续学习决定下一轮),增量迭代里核心能力是「拆分价值」(把大需求切成可独立交付的小模块)。
2.3 产品管理生命周期 7 阶段 + 关键交付物
框架:Conceive → Plan → Develop → Qualify → Launch → Deliver → Retire。每阶段的目标 + 关键产出(这是「每阶段我该交出什么」的清单):
| 阶段 | 目标(一句话) | 关键交付物 |
|---|---|---|
| Conceive 构思 | 先证明这事值得做 | 市场调研 / 竞品 / SWOT / 找需求 / 多方案 + 优先级 / 产品概念 / 原型 Demo → 产品机会判断 + 产品概念 |
| Plan 规划 | 把「想法」变「项目」 | 组队 / 项目计划 / 商业案例(Business Case) / 实施计划 / 路线图 / 营销策略 / Beta 规划 → 完整执行方案 |
| Develop 开发 | 把 PPT 变成真东西 | 开发 / 设计细化 / QA / 可用性测试 / 定价 / 销售策略 / 客服方案 / 培训材料 → 可上线产品 + 商业配套 |
| Qualify 验证 | 最后一次避免翻车 | Beta 测试 / 收反馈 / 修问题 → 上线决策(上 / 延 / 取消) |
| Launch 发布 | 把产品真正推出去 | 发布准备 / 风险评估 / 应急预案 / 营销素材上线 → 正式发布 |
| Deliver 交付运营 | 上线不是结束,是开始(停留最久) | 交业务团队运营 / 看反馈 / 调产品 / 改定位 / 迭代 → 增长与优化 |
| Retire 退役 | 体面下线 | 停支持 / 终合同 / 库存处理 / 用户迁移 / 合规 → 生命周期结束 |
Why:这套阶段名是 AIPMM/ProdBOK 体系的「官方话术」,在认证考试和正式产品评审里会用到——记住它能让你和走这套体系的人「说同一种话」。注意 Conceive 阶段会用 SWOT(优势/劣势/机会/威胁) 和 PEST(政治/经济/社会/技术) 做战略分析判断时机。反例:跳过 Qualify(Beta 验证)直接 Launch,等于把前面所有假设带着风险一次性推向市场。
2.4 项目管理生命周期:Predictive vs Adaptive
框架:项目推进就两种打法,取决于你面对「确定性问题」还是「变化性问题」:
- Predictive(预测型):先把地图画完再出发(需求/预算/时间排清→严格执行)。适合需求稳定、变更成本高:硬件 / 工厂 / 供应链 / 基建。5 阶段:Initiating(立项,证明值得花钱)→ Planning(详细规划)→ Executing → Monitoring → Closing。
- Adaptive(适应型):边走边调,适合高变化场景(对应敏捷/迭代)。
何时用:和 2.2 的瀑布/迭代是一回事在「项目」层的投影——选 predictive 还是 adaptive,先问「这事改起来贵不贵、需求稳不稳」。
三、战略与创新框架
本节是一组命名分析模型——它们的价值不是「记住名字」,而是当你要做市场判断 / 立项答辩时,有现成的脚手架逼自己想全。
3.1 创新的两套分类法
A. 奥斯陆手册四类创新(Oslo Manual, 1992)——创新对象不止是产品:
| 类型 | 是什么 | 例子 |
|---|---|---|
| 产品创新 | 新/增强功能或更好体验 | iPhone 系列持续改进 |
| 流程创新 | 改进生产/交付方式 | 工厂引入自动化机器人 |
| 营销创新 | 设计/包装/推广/定价新方法 | 社交媒体营销 |
| 组织创新 | 改进业务实践/内部运营/工作方式 | 跨职能团队打破部门边界 |
配套 五步创新流程:Staging(准备:定创新小组/角色)→ Alignment(对齐:和高层定重点范围)→ Exploring(探索:找可改进领域)→ Creating(创建:想法变计划/商业模式)→ Mapping(路线图:排步骤/时间)。
B. 按改变幅度三档创新:
| 档位 | 改变幅度 | 例子 | 配套方法 |
|---|---|---|---|
| 渐进式 Incremental | 小步优化 | iPhone 每代更新 | DMAIC(定义/测量/分析/改进/控制) |
| 激进式 Radical | 大幅重塑 | 座机 → 智能手机 | 鼓励突破常规、允许失败复盘 |
| 颠覆式 Disruptive | 替代旧规则 | 特斯拉电动车替代燃油车 | 新技术/新商业模式,早期利润有限、风险高 |
Why / 何时用:不是所有问题都需要颠覆——市场规则稳定时持续优化更有效,规则在变时才需要重新定义产品。反例:为了「显得创新」在一个成熟稳定的市场强推颠覆式方案,烧钱且容易死;反过来,市场规则已被对手改写时你还在做渐进优化,会被替代。
3.2 分析与抽象思维(双轮)
框架:分析能力回答「数据说明了什么」(把复杂问题拆小、识别模式趋势因果、数据驱动决策、挑战假设);抽象思维回答「这些现象背后意味着什么」(全局视角、更广泛影响、创新解法)。前者让决策可靠,后者让方案有战略性。
反例(课程原例):外卖团队以为用户最看重餐厅评分,数据却显示用户更容易从「菜品选择丰富」的餐厅下单——分析能力的价值就是挑战这种看似合理的假设。结账流失率高,抽象思维不会只加个提示,而是重新设计结账流程减少步骤。
3.3 波特五力(Porter's Five Forces)——市场好不好做
框架(Michael Porter):判断一个市场吸引力 + 竞争压力来自哪。五力:新进入者威胁 / 替代品威胁 / 买方议价能力 / 供应商议价能力 / 现有竞争强度。简记:进入门槛越低、替代品越多、买方或供应商越强、同行越卷 → 越难赚钱。
应对三战略:总成本领先(Overall Cost Leadership)/ 差异化(Differentiation)/ 聚焦(Focus,专注细分)。
何时用:进入新市场 / 新品类前先过一遍五力,判断「值不值得进、压力主要来自哪、产品该怎么定位」。开汉堡店(门槛低)和造喷气式飞机(门槛极高)的竞争结构完全不同。
3.4 科特勒产品五层次(Kotler's Five Levels)——产品怎么创造价值
框架(Philip Kotler):一个产品从「满足需求」到「建立长期竞争力」的 5 层:
- 核心利益 Core Benefit:用户真正想要的(买手机 = 保持连接/获取信息)→ 决定「有没有价值」
- 基础产品 Basic Product:被交付的产品 + 核心功能(通话/短信/上网)→ 决定「能不能用」
- 期望产品 Expected Product:用户默认期待的品质(存储/续航/性能/支持)→ 决定「够不够好」
- 附加产品 Augmented Product:超预期的差异化价值(免费配送/延保/额外功能)→ 决定「为什么选你」
- 潜在产品 Potential Product:未来扩展性(AI 助理/个性化)→ 决定「未来还能否吸引」
配套「用户如何判断价值」三阶段:Need(意识到需要)→ Want(关注想要的体验)→ Demand(愿意付钱)。
关键反直觉点:再丰富的高层级功能,如果核心利益和基础功能没满足,用户依然不买。何时用:做产品定位 / 竞品对标时,逐层填——尤其用第 4 层(附加产品)找差异化抓手。
3.5 市场细分 + 一手/二手研究
市场细分(Market Segmentation) = 把大市场拆成小群体,维度:Needs / Behavior / Interests / Demographics。本质不是「分类用户」,而是「为不同用户提供更精准的价值」(老人要大字体易操作,年轻人要拍照游戏社交)。
两种研究:
| 一手研究 Primary | 二手研究 Secondary | |
|---|---|---|
| 是什么 | 自己去问用户(访谈/问卷/焦点小组/可用性测试) | 看别人做好的(行业报告/数据库/政府统计/学术) |
| 优点 | 精准/新鲜/懂「为什么」 | 快/便宜/快速了解市场 |
| 缺点 | 贵/耗时/易有 bias | 可能过时/质量不可控/不一定答你的具体问题 |
何时用:Research 的本质是「降低产品决策的不确定性」,不是「收集数据」。先用二手研究快速建立市场大图,再用一手研究深挖具体假设。PM 本质是「市场和公司之间的桥梁」,核心职责是 Voice of Customer。
3.6 SWOT + 产品战略五步
SWOT 行动化(别只做 PPT):Step1 优势→机会(我的优势能带来什么机会,把机会变现实);Step2 弱点→威胁(我的弱点会导致什么风险,做行动计划降险)。现实中常是多优势共同造机会、多弱点共同致风险。
产品战略三要素:产品市场(目标用户偏好/动机)+ 独特销售主张(USP,差异化卖点)+ 公司业务目标(增长/利润/份额)。五步制定:①市场研究(基于客观数据,不是主观判断)→ ②创建完整战略计划(含 SMART 产品定义 / 商业案例 / 竞品 / 成本收益 / 里程碑 / 风险缓解)→ ③开发产品(原型 + 持续听 stakeholder)→ ④发布交付 → ⑤跟踪销售/投诉/反馈(产品不再创造价值时考虑退市)。
Why:产品战略不是一次性计划,是贯穿生命周期的持续校准——「制定计划」只是开头,真正难的是上线后根据市场反馈不断调方向。
四、干系人协作与沟通风格
这是 PM 工作量最大、也最难量化的部分。核心认知:PM 本质不是管理产品,是管理「人」——产品成败常不取决于想法本身,而取决于 PM 能否协调好所有关键干系人。协作中「这活归谁」的 PM×UX 实证分歧、RACI 完整用法见 NNGroup 产品与 UX 协作(PM×UX 职责分歧实证 · 重叠工作根因 · PM 角色模型 · RACI 分工 · 合作五建议 · UXer 像产品领导者思考 · PLG · 术语表),AI PM × 工程/设计的具体协作见 AI 时代 PM / Design / Eng 三人组协作(跨作者主题综合);本节给课程独有的命名框架。
4.1 干系人管理 + RACI
按影响力分层沟通(不是一视同仁):CEO 一个决定能终止项目(高影响力)→ 给每周一页简报;工程/测试/客服执行层影响大 → 给细颗粒执行信息。先识别谁是关键角色,再按重要程度定不同沟通策略。内部(管理层/工程/财务/市场/销售/运营/测试/客服)vs 外部(供应商/渠道/最终用户)要同时平衡。
RACI 职责模型:Responsible(执行的人)/ Accountable(最终负责的人,每任务只能一个)/ Consulted(被咨询)/ Informed(被通知)。核心价值 = 防止「所有人以为别人会做」或「所有人被拉进不必要会议」。
何时用:复杂项目启动 / 回顾会后发现「谁谁被漏了 / 任务延迟」时,画 RACI 把责任边界透明化。完整的 R/A/C/I 数量规则、分配时除职位还要看技能/关系/兴趣等细节见 NNGroup 产品与 UX 协作(PM×UX 职责分歧实证 · 重叠工作根因 · PM 角色模型 · RACI 分工 · 合作五建议 · UXer 像产品领导者思考 · PLG · 术语表) 第五节。
4.2 五大障碍金字塔(Five Dysfunctions of a Team, Lencioni)
框架:团队拿不到结果通常不是不够聪明/努力,是掉进 5 个递进陷阱。从底往上逐层解,跳层无效:
Results 结果 ↑ Accountability 问责 ↑ Commitment 承诺 ↑ Conflict 健康冲突 ↑ Trust 信任
链条:没信任 → 不敢真实讨论 → 没真承诺 → 没人负责 → 没结果。
| 障碍 | 表现 | PM 的角色 |
|---|---|---|
| ①缺乏信任 | 不敢认错/求助/暴露弱点(怕丢脸) | 创造心理安全感(说问题不被惩罚) |
| ②害怕冲突 | 假和谐:不反对不辩论,产出平庸 | 制造健康冲突(观点碰撞≠吵架) |
| ③缺乏承诺 | 会上说 OK 会后抵抗(commitment ≠ agreement) | 讨论充分后统一行动(即使有保留) |
| ④逃避问责 | 有人延期没人指出,低标准变常态 | 建立 peer accountability(同级互相指出) |
| ⑤忽视结果 | 各追个人 KPI/曝光,没人管用户买不买单 | 持续拉回共同 business outcome |
Why / 何时用:团队明明很忙却拿不到结果时,用这个金字塔自下而上诊断——通常根子在「信任」这一层,而不是表面的「执行力不够」。反例:看到团队执行差就加 KPI 压问责(④),但底层信任(①)缺失,只会让人更不敢暴露真实风险。
4.3 SMART 目标 + 双层检查清单
SMART:Specific(具体)/ Measurable(可衡量)/ Achievable(可实现)/ Relevant(相关)/ Time-bound(有时限)。「提升用户体验」是口号;「6 周内优化 onboarding,把注册完成率从 42% 提到 55%」才是目标。
关键升级:好目标 = 能执行(SMART)+ 有价值(Business Value)双层检查——即使目标很 SMART,也要过第二层「值不值得做」:是否提升决策能力/客户满意度/参与度/留存采用率/减少沟通阻力/优化空间/产品质量/交付速度/生产效率?两层都 YES 才是合格目标。
现代补充(课程自己点的):SMART 是入门工具,现实互联网产品更关注 outcome 而非 output(「上线 20 个功能」是 output,「把 onboarding drop-off 降 25%」是 outcome),并叠加 OKR / KPI / North Star Metric / outcome-driven roadmap。反例:目标写「本季度上线 20 个功能」——SMART 都满足,但这是 output,没回答「为了什么业务结果」。
4.4 电梯演讲六要素(Elevator Pitch)——产品定位框架
框架:把产品定位压缩成 30 秒能让人懂的表达,本质是定位工具不是演讲技巧。固定六要素模板:
For[目标用户],Who[他们的问题],Our product is[产品类别],That[提供的价值],Unlike[竞品],Our product[核心差异]。
它逼你回答 6 个常被跳过的问题:给谁 / 为什么需要 / 我们是什么 / 用户得到什么 / 为什么选你 / 最大卖点。现代更短的写法是一句 positioning:「用户 + 问题 + 价值 + 差异化」(如 "Airbnb for business travelers")。
何时用:向老板汇报值不值得做、向投资人快速建立认知、对齐团队、写官网/landing page 文案。先有清晰的产品愿景(回答「这个产品最终想解决什么问题」,不是功能列表),再用 elevator pitch 压缩它。
4.5 无权影响力(Influencing without Authority)——六源影响力
核心现实:PM「有责任,但没权力」——对产品结果负责,却不能直接管工程/设计/市场。所以必须靠影响力让人「愿意做」而非「被命令做」。
六源影响力(出自《Influencer》,沿 Motivation × Ability 两轴拆):
| 个人 Personal | 社交 Social | 结构 Structural | |
|---|---|---|---|
| 动机 Motivation | ①自己先 buy in(你真信这事吗) | ③借力找盟友(tech lead/资深设计/业务发起人,social proof) | ⑤(环境/激励设计) |
| 能力 Ability | ②专业即影响力(credibility/expert positioning) | ④联盟运营(动员/建关系/争取反对者) | ⑥(系统/流程/工具支持) |
Why / 何时用:PM 推不动事的时候,别先想「我怎么没权力」,而是过一遍六源——很多时候缺的是「①自己不够坚定(别人能感知)」或「③没找对盟友」。反例:单打独斗硬推,不去找支持你的 tech lead 当 social proof,导致关键人不点头其他人都观望。
4.6 5 步问题解决法 + 决策矩阵
5 步问题解决法:①定义问题(写 problem statement + 和 stakeholder 对齐,问题定义错后面全白费)→ ②找根因(头脑风暴/brainwriting,从 People/Process/Policy/Tools/Systems 找)→ ③排序根因(Nominal Group Technique 名义小组法,结构化让每人公平表达,避免「声音大的赢」)→ ④抓重点(Pareto 80-20,80% 结果来自 20% 关键原因)→ ⑤验证迭代(解决就记录经验,没解决回上游重新分析)。
决策矩阵(Decision Matrix):把多方案放进统一评分体系减少主观,常见维度 Impact / Effort / Risk。stakeholder 评分分歧时,用「多方案 × 多评委 × 多维度」打分(High=3/Med=2/Low=1),取平均或预先约定权重,选最高分——本质是减少「谁声音大谁赢」。
何时用:跨团队为「先做哪个」吵不下时,搬出决策矩阵把争论从「谁对」转成「分数」。注意它是把主观打分系统化,不是消灭主观——价值在透明和可复盘。
4.7 四种沟通风格 × 塔克曼 × 情境领导(本课最体系化的一块)
A. 四种沟通风格(Emergenetics) —— 同样内容,表达不匹配对方就降低理解和推动:
| 风格 | 在乎什么 | 怎么沟通 | 赢得信任 / 失去信任 |
|---|---|---|---|
| 分析型 Analytical | 逻辑/事实/数据/价值 | 给数据/证据/逻辑链,别只讲感受 | 赢:精准数据省时间 / 失:夸大价值、错误数据 |
| 结构型 Structural | what/when/where/how,流程/责任/时间线 | 给里程碑/RACI/检查清单/回滚方案 | 赢:清晰指导稳定方向 / 失:频繁改指导、微观管理 |
| 概念型 Conceptual | 大图景/可能性/创新 | 留发散空间,用愿景/未来场景/路线图草图 | 赢:留头脑风暴空间 / 失:不给探索、只要求收敛 |
| 社交型 Social | 关系/故事/人的影响 | 当面聊+真实故事,强调协作和谁参与 | 赢:强调团队合作友好互动 / 失:讽刺、负面非语言信号 |
B. 塔克曼阶梯(Tuckman Ladder, 1965) —— 团队发展 4 阶段:Forming(形成,不熟,生产力低)→ Storming(震荡,冲突显现,生产力降)→ Norming(规范,冲突减、信任增)→ Performing(表现,自驱高效)。
C. 情境领导(按团队阶段调领导方式) —— 把 A 和 B 结合:
| 阶段 | 领导方式 | 做什么 |
|---|---|---|
| R1 形成 | Tell / Direct 告知 | 一页「北极星+里程碑+RACI」讲清方向/分工/决策机制 |
| R2 震荡 | Sell / Facilitate 引导化解 | 把争论拆成「共同指标/必做可做/决策截止」,要每方给最低让步 |
| R3 规范 | Participate / Support 参与支持 | 减命令,每周 15 分钟做「障碍清单」打通依赖,别微观管理 |
| R4 表现 | Delegate / Monitor 授权监控 | 授权自驱,只看「监控指标+回滚策略」,关键里程碑校准 |
Why / 何时用:这套是 PM 「因人/因阶段调沟通」的完整操作系统——新拉起的项目群该 Tell,评审会三方互怼该 Facilitate,顺风团队该 Delegate。反例:对形成期(R1)还很懵的团队过早放手授权(R4),团队缺共同理解会原地空转;对表现期(R4)的高自驱团队还逐条指挥(R1),会被嫌微观管理、伤士气。
4.8 建立信任六法
框架(信任 = 敢于开放表达失败/弱点/担忧,不是「关系好」):①主动倾听(追问「你最担心哪段」并复述确认)②情绪智能(先承认想法再引导可行性,别直接泼冷水)③有效沟通(注意非语言信号:别边听边低头回消息)④文化意识(有人重视「公开场合的体面」,先私聊再会上呈现)⑤建立关系(让对方在熟悉的沟通方式里被理解)⑥解决冲突(把「谁对谁错」拉回「共同目标」,给双方台阶)。
何时用:这六法是 4.7 沟通风格的「关系底座」——风格匹配解决「听得进」,信任六法解决「愿意说真话」。尤其跨国/跨部门协作,文化意识(④)常是隐性雷区。
五、业务与商业化
5.1 商业发展(Business Development)
PM 不只「做产品」也推「商业增长」:研究销售线索 / 说服客户 / 研究用户行为与市场机会。工具是 SWOT(见 3.6)。核心定性:PM 既是「产品角色」也是「商业增长角色」。
5.2 产品组合管理(Portfolio Approach)
框架:一个 PM 负责一整组相关产品(而非单个),从更高视角统一战略 / 优化资源 / 避免重复建设 / 提升整体回报。两个维度:产品线宽度(多少种产品:可乐/雪碧/茶)× 产品线深度(单品多少变体:可乐有原味/无糖/樱桃/无咖啡因)。
Portfolio PM vs 普通 PM(这是高级岗位的分水岭):
| 普通 PM | Portfolio PM |
|---|---|
| 管一个产品 / 看功能 / 做执行 | 管一组 / 看业务战略 / 做方向 |
| 关注用户需求 / 做 roadmap | 关注 ROI / 做 portfolio strategy / 管 business risk |
为什么公司这么做:①统一战略(避免品牌混乱/定位冲突,如全公司走低糖战略)②资源有限(把钱和人放最值得处)③风险控制(避免过度依赖单一产品,diversification)。常见岗位名:Senior PM / Portfolio PM / Product Line Manager / Director of Product。
一句话:单产品 PM 是「把产品做好」,Portfolio PM 是「决定公司该把哪些产品做好,以及为什么」。何时用:当你从管一个 SKU 升到管一条产品线,关注点要从「功能细节」整体迁到「投资优先级 + 业务风险」。
5.3 面向公众沟通:PR 计划 + 营销物料清单
PR 计划:管理与公众/干系人的沟通(目标/策略/战术),选媒体渠道(广播/出版/互联网),持续强化核心主题。
上线前营销物料清单(发布准备的 checklist):Messaging(传达价值)& Positioning(定义愿景/市场位置)/ 产品名与商标 / 营销物料(logo/网站/宣传册/线上广告)/ 销售点 POS 物料 / 广告 / 新闻稿与媒体关系 / FAQ / 白皮书(给理性深入型客户)/ 案例研究与客户证言(增可信度)/ 展会 / 社交媒体。
面向四种风格做传播(同一产品不同表达):分析型给关键事实+成功标准+对照实验;结构型给 what/when/where/how 的清晰步骤;概念型给 pitch+想象空间+差异化;社交型给故事+情感点+「让贡献被看见」。
何时用:产品 Launch 阶段(见 2.3),用这份物料清单逐项核对「上线必备资产齐没齐」,并用四风格传播覆盖不同客户。
六、职业发展
6.1 PM 行业现状与机会
PM 几乎适用所有行业(软件/公用事业/基建/客服/制造/消费品),因为任何有「产品」的公司都要持续回答「用户要什么/还有没有竞争力/下一步优化什么/何时升级或淘汰」。需求持续增长,转岗来源多:工程师(技术理解强)/ 项目经理(熟开发流程)/ 供应链(懂市场和供应体系)——不必科班出身。晋升路径:PM → Senior PM → PM Lead/Manager → Director。
何时用:做职业定位时,先认清自己会落在「偏增长 / 偏战略 / 偏交付 / 偏商业」哪一类 PM——不同公司的 PM 职责差别很大。
6.2 简历:fit-not-identity
核心心法:简历不是「展示你是谁」,是「展示你适不适合这个岗位」——先看 JD 再写,一份简历不能海投(技术 PM / 增长 PM / 战略 PM / 平台 PM 差别大,要针对岗位改)。少写空话(Good communication/Team player 基本没用),多写「具体做过什么」(不是「我会协作」,而是「协调设计+研发+运营 12 人团队,把项目从 0 做到上线」)。
最值钱的 PM 能力:协作 / 推进(想法→执行→上线全链路)/ 项目管理(流程/节点/风险/优先级)。任何经历都能映射成 PM 能力:工程师→ownership+技术协作;老师→课程设计+用户理解;工厂→流程优化+质量管理。
反例:把简历写成流水账自我介绍、海投所有 PM 岗——招聘只关心「你符不符合这个岗位」,无关经历会淹没真正有价值的信息。删掉废话,简历空间很贵。
6.3 认证与 AI PM 崛起
AIPMM Certified Product Manager(本课程对应认证)是职业加分项,非必须,核心还是能力和项目经验。趋势上:AI PM 不是 niche 岗位会变主流,未来会负责 AI 合规 + 人机协作体验(用户敢不敢用/信不信/好不好用)+ 跨行业扩张(Healthcare/Energy/Transportation/Government)。适合转 AI PM 的人:传统 PM / UX 设计师 / 技术 PM / 创业者(懂用户体验+产品逻辑+能理解 AI 能力边界)。
源自 will-design-notes / AI Product Manager Professional Certificate(AIPMM 体系,87 篇,8 模块)。本篇做综合提炼(ingest_quality: synthesized),精读了 8 个模块纲领 + 全部高密度框架小节(约 35 篇)。协作与沟通中 PM×UX 的实证职责分歧、RACI 完整规则、PLG 增长见 NNGroup 产品与 UX 协作(PM×UX 职责分歧实证 · 重叠工作根因 · PM 角色模型 · RACI 分工 · 合作五建议 · UXer 像产品领导者思考 · PLG · 术语表);AI PM 与设计/工程协作的落地打法见 AI 时代 PM / Design / Eng 三人组协作(跨作者主题综合)——本篇定位是「AI PM 方法论骨架 + 框架词典」,与两者交叉引用不重写。术语表(各模块 Glossary)等扫描类内容保留在 sources 原档。