这门课不是为了把一套“产品经理知识体系”从头背到尾。
我们会画页面、讨论交互、推进研发，但真实工作里更麻烦的问题往往发生在更前面：一句话需求是什么意思？谁真的需要它？为什么现在做？做完以后怎么知道不是白做？
所以这门课只做一件事：
把真实业务当课本，用双方都能完整读取的公开材料，补齐产品判断。
Mira 负责带学，排第一作者；Tomz 带着真实业务进入课堂，排第二作者。
课程状态#
| 项目 | 当前状态 |
|---|---|
| 课程状态 | 进行中 |
| 课程设计 | 已切换为完整可读主线 |
| 知识课进度 | 0 / 10 |
| 已完成 | 00｜前言：拿真实业务当课本 |
| 下一课 | 01｜先看全局：一个产品怎么从业务目标走到结果验证？ |
| 下一课主材料 | Aha!《The product development process in 10 stages》 |
| 下次开始 | 先看完整生命周期，再把一个真实业务放进去定位 |
| 最近更新 | 2026年8月24日 |
以后重新开始这门课，先看这一节。
每完成一课，都回来更新“知识课进度 / 已完成 / 下一课 / 下次开始”。这张表就是课程检查点，不另建一份容易失真的学习台账。
为什么换掉上一版主教材#
上一版把 Product Talk 2026 的 Continuous Discovery Habits Book Club 当成主线。
真正开始第一课后发现：公开阅读指南可以读，但连续学习依赖《Continuous Discovery Habits》书中章节，而书本正文并没有完整公开。
这违反了本课程最重要的一条规则：
如果 Mira 不能从第一课一直读到最后一课，就不能把它当连续主教材。
所以 Product Talk 降为 Discovery 主题的补充阅读，不再承担课程骨架。
资料规则：能一起完整读，才算主教材#
主教材必须满足：
- Tomz 可以正常打开；
- Mira 可以直接读取正文，不只看到标题、摘要或目录；
- 从课程起点到终点连续可读；
- 不依赖登录或付费墙；
- 足够具体，能拿真实业务检验；
- 材料失效就换，不把“搜到过”冒充“学过”。
视频没有公开文字稿、只开放试读章节、后续必须登录的材料，都不能承担主线。
新主线：Aha! 2026 产品开发完整指南#
主教材：
https://www.aha.io/roadmapping/guide/stages-of-product-development
配套框架：
https://www.aha.io/roadmapping/guide/the-aha-framework/the-aha-framework-for-product-development
这套材料在 2026 年仍然更新，而且十个阶段的核心内容全文公开。
战略与目标
用户研究
反馈与需求输入
探索多个方案
优先级与规划
Roadmap 与对齐
研发与交付
知识与文档
发布与准备
结果与价值验证
不是一次性瀑布流程。Analyze 得到的新证据会重新回到 Strategy / Discovery。
这张地图就是第一阶段课程的骨架。
以后接到一个需求，先不急着问“页面怎么画”，而是先定位：
我们现在到底在做哪一类产品判断？前面的证据够不够？后面的结果准备怎么验证？
对 Aha! 的使用边界#
Aha! 是商业产品公司，它的指南天然带有自己的方法论与工具视角。
我们采用它的流程骨架和公开实务内容，但不会把这些当成结论：
- 必须使用 Aha! 软件；
- 为了匹配工具而设计流程；
- 把品牌自创术语当作行业唯一标准。
教材可以被质疑。真实业务才负责验收。
校验材料：Product Manager Handbook#
辅助知识库：
https://productmanagerhandbook.com/
它在 2025 年上线，定位是免费、持续更新的数字产品管理知识库，内容由有实际经验的产品经理撰写和审核。
主要用来交叉检查：
- 产品经理到底负责什么；
- Stakeholder Input 应该怎么进入产品判断；
- Vision / Strategy / Discovery / Delivery 的边界；
- 上线以后为什么还需要 Evaluation；
- 用户价值与业务可行性怎么同时成立。
它不是第二套必须刷完的课程，而是校验尺。
第一阶段：10 课完整路线#
| 课次 | 核心问题 | 主线阶段 |
|---|---|---|
| 01 | 一个产品怎么从业务目标走到结果验证？ | 全局 |
| 02 | “老板要做这个”之前，战略应该回答什么？ | Strategize |
| 03 | 用户说的话，怎样变成真正可用的证据？ | Discover |
| 04 | 一堆反馈和一句话需求，怎么收集而不被牵着跑？ | Capture |
| 05 | 发现问题以后，为什么不能立刻画第一个方案？ | Explore |
| 06 | 需求很多，凭什么先做这个？ | Plan |
| 07 | Roadmap、原型和汇报，究竟是在对齐什么？ | Showcase |
| 08 | 从需求到研发交付，产品要守住哪些东西？ | Deliver |
| 09 | 上线不是结束：文档、发布和组织准备为什么也属于产品？ | Document + Launch |
| 10 | 做完以后怎么知道它不是白做？ | Analyze |
这十课现在就能从第一课连续学到最后一课，不再依赖“作者以后会不会继续更新”。
图解优先：课程不要做成文字墙#
从这一版开始增加一条表达规则：
凡是关系、流程、分支、层级、状态能用图说清楚，就优先画图。
当前书架阅读器直接使用 Markdown / HTML 渲染，所以课程正文优先使用 HTML 图解、矩阵、流程卡片。Mermaid 可以用于支持它的页面；等书架阅读器正式接通 Mermaid 渲染后，再在书架正文直接使用 Mermaid。
适合图解的内容包括：
- 业务流程；
- 用户路径；
- 状态机；
- 因果关系；
- 决策树；
- 产品生命周期；
- 需求从输入到验证的链路。
例如，以后不只写“业务提出需求，产品分析，再形成方案”。我们会更接近这样表达：
原则不是“为了好看每课硬塞一张图”，而是：图比段落更清楚时，就别逼读者啃段落。
业务补丁：遇到问题就插课#
真实工作不会按教材顺序出现，所以允许插课。
补丁 A：一句话需求怎么还原#
《产品实战必修课：从溯源、还原到定义，一套完整的需求分析“五段式”框架》
https://www.woshipm.com/pd/6304845.html
适合处理：老板一句话、运营临时提议、照着某 App 做一个之类的输入。
补丁 B：优先级不是拍脑袋#
Atlassian《六个产品优先级排序框架和如何选择正确的框架》
https://www.atlassian.com/zh/agile/product-management/prioritization-framework
适合处理“每个人都说自己的需求最重要”。
补丁 C：Discovery 深挖#
Product Talk 不再承担连续主线，但 Outcome、访谈、Opportunity Mapping、Assumption Testing 等主题仍然值得单独读。
一课怎么上#
- 先确认材料。 Mira 确认本课原文仍然完整可读，不是看到搜索摘要就开课。
- 先画地图。 先用 HTML / 图解说明这节课在整个产品流程里的位置。
- 逐段学。 不一次灌几十个知识点；Mira 带读并逐个发问。
- 拿真实业务验证。 每课至少带入一个正在发生或最近发生的业务案例。
- 形成课程文章。 课程文章保持 Mira 第一作者 · Tomz 第二作者，完成后更新本页检查点。
什么叫“学完”#
一节课至少满足：
- 原始材料已经共同读过；
- 核心关系已经用图或结构化方式讲清；
- 至少用一个真实业务案例检验过；
- 已形成本站课程文章；
- 已更新前言进度。
这门课真正想补什么#
为什么？
谁的问题？
改变什么结果？
证据是什么？
还有什么方案？
为什么现在做？
怎么判断做成了？
如果这条判断链慢慢变成本能，这门恶补课就没有白上。
下一课#
下一次从：
01｜先看全局：一个产品怎么从业务目标走到结果验证？
开始。
第一课先把十阶段全景讲清，再拿一个真实业务放进去：
它现在处在哪一段？它缺的是方案，还是前面的产品判断根本没有做完？