腾讯产品方法论精炼课
假设我们正在维护一款学习产品。某次周会上，团队收到一个需求：“最近大家都在做 AI，我们也应该在首页增加一个 AI 助手入口。”
这个提议听起来很合理。竞品已经上线了类似功能，客服记录里也出现过几次“能不能让 AI 帮我解释”的反馈。团队很快确定了方案：在首页右下角放置一个悬浮按钮，用户点击后进入对话页面，可以提问、总结内容，也可以生成学习计划。
接下来的工作按照熟悉的流程展开。产品经理画原型，设计师确定按钮样式，研发接入模型和对话接口，测试确认主要流程可以运行。两周后，功能开始灰度；又过了一周，入口向全部用户开放。
上线七天后，首页产生了十万次有效曝光，AI入口只获得七百次点击，点击率为0.7%。进入对话页的用户中，还有相当一部分人在发送第一条消息后直接离开。
数据不理想，团队却无法立即判断问题在哪里。可能是悬浮按钮不够明显，用户根本没有看到；也可能是用户看到了，却不知道AI助手可以完成什么任务。还有一种可能是，用户确实需要帮助，但首页并不是需求发生的场景。甚至可能从一开始，团队看到的几条反馈并不足以支持投入完整开发。
不同解释会导向完全不同的下一步。如果问题在入口位置，团队可以调整布局；如果问题在功能说明，可以增加示例和引导；如果回答质量不足，就需要继续改进模型；如果用户需求并不成立，继续优化入口只会增加更多沉没成本。
此时，团队缺少的不是另一个功能方案，而是一条能够支持决策的证据链。项目开始前，没有明确记录目标用户、使用场景、核心问题和最关键假设；项目上线后，也没有提前约定结果指标、护栏指标与停止条件。0.7%因此只是一个现象，还不能直接告诉我们应该继续、调整还是停止。
这套课程研究的正是这个缺口。我们会从项目为什么做开始，依次学习怎样理解用户、判断需求、确定定位、设计MVP、建立指标并记录迭代。最终目标不是保证每个项目都成功，而是让团队在每个关键节点上都能说明：当前判断依据什么，下一步准备验证什么，什么证据会让我们改变原来的决定。
课程从哪里来
我们以腾讯学堂、腾讯大学历史公开内容、腾讯招聘培养项目、腾讯大讲堂和腾讯产品团队公开复盘为主要材料。原始内容中重复出现的“用户、需求、定位、数据、迭代”等主题被合并到同一章节，不再按发布平台重复讲解。
完整纳入范围、来源等级和课程映射见公开资料来源与合并规则。
八门核心课
- 立项与机会判断：项目为什么做
- 用户研究与需求验证：怎样确认问题真实存在
- 定位、竞争与产品边界：选择做什么，也选择不做什么
- MVP、产品设计与落地：把判断变成可验证产品
- 指标、实验与效果评估：上线后怎样判断有效
- 迭代、运营与增长：一轮又一轮究竟在改什么
- 商业化、风险与长期价值：增长之后仍要成立
- 协作与产品决策：让团队共同完成正确的事
完成八门课后，可以进入腾讯案例实验室，再把方法迁移到Stage 1 产品证据链。
学完后的最小交付
学习结果不是一份概念笔记，而是一份可以接受质询的产品档案：
- 一页立项判断，说明用户价值、业务价值、时机与资源条件；
- 一份需求证据表，区分用户表达、观察事实和我们的解释；
- 一句产品定位，以及明确的不做清单；
- 一个只验证关键假设的 MVP；
- 一棵指标树，包含北极星指标、过程指标和护栏指标；
- 至少三轮“假设—动作—证据—结论—下一步”记录；
- 一次失败复盘，说明哪个解释被证据推翻。
这里的“三轮”是本课程为了教学完整性设置的最低要求，不是腾讯公开课规定的固定迭代次数。