产品经理从零到上岗 · 系列十课 ｜ 本文是02/10（共十课），所属：第一部分 · 建立全景 全系列学习路径见《系列总览》
? 系列总览 ｜ 上一篇：第一课 · 产品经理的完整工作流 ｜ 下一篇：第三课 · 从"坐地铁"到"设计地铁"
本课定位：上一课画完了全景图，这一课回答一个更具体的问题：刚入职、领导还没交代任务时，你该干什么？
从"微信拍一拍为什么不用短信提醒"说起——一堂课讲透：入职后如何用四份文档量化工作、用户调研的两大目的与四种方法、需求管理七阶段，以及需求文档的六要素框架。
产品经理的日常工作，本质上是以需求为主线展开的。但"需求"两个字背后，是从市场调研、用户调研，到需求文档、需求池、产品设计的一整套方法论。
这一堂课从一个"拍一拍"的案例开场，讲透了"设计理由"到底该怎么拆；接着系统梳理了产品经理入职后的市场调研阶段（四大文档）、贯穿全程的用户调研阶段（收集需求 + 验证需求），最后落到需求管理七阶段与需求文档撰写。信息密度很高，值得完整复盘一遍。
一、课前回顾：几个容易被面试官追问的细节
课程从抽查昨天讲过的内容开始，几个问答其实都是面试高频题，值得先记住：
1. 需求从哪来？
产品经理的需求，80% 来自公司同事（内部协作方），20% 来自自己通过数据分析主动收集。这是标准的回答结构，面试直接照这个框架答。
同事提需求的方式有两种： - 口头表述 → 整理成需求文档 → 与对方确认记录无误 → 归入需求池文档； - 文档形式 → 直接与需求来源方确认内容无误 → 归入需求池文档。
2. 什么时候能进入研发阶段？
必须产品设计评审通过之后，才能进入研发阶段。
3. 产品经理和 UI 怎么配合？
产品经理把设计产出分发给 UI → UI 做视觉设计 → 产品经理、前端、需求变更方一起评审 → 通过后 UI 切图 → 交给前端开发。评审不过则把 feedback 打回给 UI 重做。
这里有个经典追问：三方评审时各自的目的是什么？
- 需求变更方
：看 UI 设计符不符合他们的业务要求； - 产品经理
：从用户角度、易用性角度分析，看符不符合产品整体定位； - 前端
：评估这个视觉设计能不能做得出来。
4. 项目管理进度计划表是谁定的？
这是很多人会答错的一题。产品经理在研发阶段要产出项目管理进度计划表，但表里的排期不是产品经理规定的——UI、测试、开发拿到原型图和 PRD 文档后，会各自制定团队内部的排期计划，由各部门负责人传递给你。产品经理的角色是整理、归纳、跟踪，以项目管理的身份做进度跟进。
一句话：排期是别人给你的，不是产品定的。 千万别在面试或工作中答反。
二、作业讲评：从"拍一拍"学会拆设计理由
上一节课的作业是：针对自己找的对标软件，分析其中功能点的设计理由。课上用一份"微信拍一拍"作业做示范，讲了一个非常实用的拆解模型。
第一步：这个功能解决的问题是什么？
那位同学的作业写的是"个性化的回应""彰显个性、增加用户粘性"——结果被直接判定：方向不对。
拍一拍的本质是一个提示性功能：在沟通场景出现停滞、对方没有及时看到信息时，通过拍一拍的强提醒（页面抖动等），提示对方查看并回复消息。它解决的是"沟通停滞、沟通障碍"的问题，而不是什么"个性化表达"。
先想清楚功能解决什么问题，再去谈设计，这是拆解的第一步。
第二步：枚举所有能解决这个痛点的方案
如果目标是"提示用户查看并回复消息"，有哪些设计方法？
大家当场列出了一堆：消息加急（点击后信息直接浮现在对方页面）、邮件提醒、小红点视觉提示、短信通知……
第三步：为什么偏偏用拍一拍，而不是短信？
这才是"设计理由"的真正含义。用"短信 vs 拍一拍"做对比分析：
先分析短信本身：现在短信最常见的用途是验证码、订单通知、官方强制提醒——它的本质是一个通知工具，作用是定向告知你一个结果。
再分析微信本身：微信是轻量化的社交平台，核心是多人之间的社交连接。它不希望给用户造成打扰，而是营造一种无压力的线上社交氛围。
最后对比：短信确实能解决"提醒"这个诉求，但它属于外部场景的强打扰、强提醒，不切合微信的生态本质，也不符合社交场景下的应用。所以提醒这个动作，要覆盖在微信自身场景内完成——于是有了拍一拍。
拆设计理由的通用方法：先枚举所有解法 → 再分析"方案本身"与"平台本身" → 最后对比为什么选这个而不选那个。
这套思路，日后做任何功能设计决策都会用到。
三、市场调研阶段：入职后如何"量化"自己的工作
市场调研阶段与日常的产品工作流程（需求分析、产品设计、开发、上线）不同，它出现在两种情形下：一是你刚入职，二是公司要开展一个全新项目。
刚入职：即使领导没交代任务，也要主动产出
很多新人入职后，领导只说"了解一下公司产品"，然后就没了下文。如果你傻看三天说"我看完了"，等领导真交代任务时一问三不知，等于给自己打了差评。
正确的做法是：在这个阶段主动产出文档，量化自己的工作内容。刚入职时要产出四份文档：
文档一：行业分析报告
先辟个谣：网上那些写"行业机遇、威胁、切入机会"的分析报告，不是新人能做的，那是高级产品经理或产品总监的活儿。新人做的行业分析报告，框架是这六块：
- 行业概况
（用 PEST 分析：政治、经济、社会、科技，SWOT 是总监级用的，新人一般用 PEST） - 业务模式
（一个业务事件流程，比如共享单车：造车 → 投放 → 扫码使用 → 返场维修） - 商业模式
（业务流程中变现的那个点，共享单车就是"扫码付费"） - 市场竞争格局
- 用户画像
（这个行业在解决谁的问题） - 解决的核心需求
（行业面临的痛点是什么）
资料去哪找？课程里给了几个渠道：IT 橘子、艾瑞咨询、易观智库、起点财经，甚至淘宝上几块钱就能买到打包的行业报告。
文档二：竞品分析报告
先区分两个容易混淆的文档：
- 产品体验报告
：入职初期领导让你"体验一下竞品/自家产品"时写的宽泛分析，基于用户体验五要素：战略层 → 范围层 → 结构层 → 框架层 → 表现层。 - 竞品分析报告
：这才是真正的工作产出，市场调研阶段写它的目的是——通过对竞品的整体分析，提升未来对需求的理解程度。
市场调研阶段的竞品分析报告，框架四块：
- 需求背景
：分析竞品能解决的需求场景有哪些； - 业务模式
：分析你所在公司的业务模式、商业模式在竞品上是如何体现的（即竞品怎么解决你们的业务）； - 商业模式
：同上，对照竞品了解它的盈利方式； - 产品迭代路线
：用七麦数据这类网站查看竞品各版本迭代内容，为后续自己的功能迭代做参考。
记住"七麦数据"这个网站。后面写项目经历时，要选近期迭代的功能来做——2010 年就上线的老功能，面试官没法相信是你做的。
文档三：用户消费场景调研报告
这份报告一般由中级产品经理来做，对应的是产品盈利场景的调研——用真实的用户消费案例，验证公司商业模式的可行性。新人基本写不了，了解即可。
举个例子：以共享单车为例——调研 20 位真实用户的付费骑行记录，看"单次 1.5 元扫码付费"在通勤场景下是否成立、月卡转化是否可持续。这就是"用真实消费案例验证商业模式"。
文档四：企业内部情况调研报告
这份更高级，由高级产品经理和产品总监撰写，目的是确认公司现有资源范围能否覆盖产品的长期发展，如果覆盖不了，产品总监要第一时间找公司领导补充资源，别耽误产品周期。
新项目场景：初级 PM 的角色
如果公司要开 0→1 的新项目，作为实习生或初级产品经理，你的角色基本没什么作用——项目的决策、分析、战略规划不会交给你，你更多是协助收集资料、整理文档，领导交代什么就完成什么。
四、用户调研阶段：贯穿产品工作全程
用户调研贯穿于产品工作的整个过程。注意这里的"用户"是广义的：公司内部的业务同事、销售、运营，外部的客户、终端用户，所有角色统称为用户。
用户调研的目的有两个：收集需求和验证需求。
收集需求：定性调研 + 定量调研
两者有个重要关系：定量调研可用于验证定性调研的结论是否正确。比如你访谈了同事 A，他说爱吃草莓，你据此想卖草莓——结果大规模问卷发现只有 5% 的人爱吃草莓，80% 的人爱吃西瓜。定量调研就推翻了你定性调研的结论。小样本结论可能失真，大样本才能定夺。
验证需求：什么时候做、怎么做
在设计需求时，你可能会遇到"对需求设计把握不明确"的情况——不知道自己的设计是对是错、思路是否正确、能否有效解决问题。为了减少开发成本的投入，这时可以做用户调研来验证设计思路。
验证需求的三种方法： 1. 定性调研：通过用户访谈、口头沟通，让目标用户确认方案可行性； 2. 定量调研：发放问卷收集反馈； 3. 竞品分析：分析竞品对相同需求的功能设计，判断自身方案的合理性。
用户调研流程五步
确定调研目的 → 调研方案 → 采集研究数据 → 数据分析 → 产出调研报告
图 · 用户调研流程五步：采集研究数据是全程最重要的环节
其中采集研究数据是整个流程中最重要的环节，核心动作是数据清洗，目的是保证两类有效性：
① 数据有效性（答题人是否认真作答） 规避方法： - 计算问卷答题时长（3 秒答完的问卷直接作废）； - 设置矛盾或陷阱问题（比如前面问"哪年出生"后面问"今年多大"，答案对不上就说明没认真答）。
② 问卷有效性（答题人是否是目标用户） 规避方法： - 设置用户画像问题（性别、学历、职业等筛选条件）； - 选择合适的投放渠道（调研男大学生，就别往师范院校投）。
调研报告的结构大致是：调研背景 → 调研目的 → 调研投放渠道 → 调研题目 → 调研数据 → 数据分析 → 调研总结。
五、需求管理：贯穿工作流程的七个阶段
产品经理的核心工作是解决需求，后续所有工作都围绕需求展开。需求管理共有七个阶段，贯穿产品经理的工作流程：
- 需求调研阶段
- 需求池阶段
- 需求分析阶段
- 产品设计阶段
- 需求验证阶段
- 需求管理阶段
- 需求跟踪阶段
这一课重点讲的是第一阶段的起点——需求文档的撰写。（七阶段逐段拆解与对应的八大会议，见第四课。）
六、需求文档：六要素框架
需求文档由两种角色撰写：需求来源方（提出痛点的人）和产品经理。它分两种情况：有解决办法和无解决办法。
文档框架六要素：
① 需求目的：这个需求要解决什么问题（结果层面）。
② 需求场景：用一段话描述需求发生的场景，推荐 5W1H 场景表述法（课程中也称 WEH 简化表述法）——什么事件、什么地点、因为什么、要做什么事、怎么做的。
③ 需求描述：按两种情况写—— - 有解决办法：写清楚你的解决方法是什么； - 无解决办法：详细描述你明确的痛点（因为目的只是结果，这里要把过程细节补全）。
④ 涉及人员：注意！这里写的是需求场景下的角色，不是 UI、开发、测试！比如做一个购买电影票的软件，涉及人员是：买票的用户、后台上传影片的管理人员、审核的财务、设置场次的影院工作人员等。写它的目的是让产品经理在做解决方案时不漏掉任何一个角色。每期都讲，但每期都有人把 UI/开发/测试写上去——千万别犯。
⑤ 预计上线时间：不是产品经理拍脑袋定的。两种情况：一是在项目立项评审会上，结合需求优先级与迭代计划讨论出来的；二是需求变更方（业务方）指定的——比如运营要过年做活动，需求必须春节前上线，这个不用讨论。
⑥ 三方配合：指需求是否需要与公司外部的系统进行对接。有就写，没有就写"无"。比如拍一拍这个功能，提醒动作完全在微信生态内完成，不需要对接任何外部系统，所以三方配合就是"无"。
七、自测练习与课程小结
这一课配套的动手练习有三项：
- 撰写三份需求文档
（带解决方案）：C 端方向去七麦数据网站找对标产品近期迭代的功能来写；B 端方向则单独确定要做的功能。 - 绘制"乘坐地铁"流程图
：以产品设计视角解决用户乘坐地铁的整个过程，起点是"地上地铁口"，终点也是"地上地铁口"——这不是乘客视角的体验图，而是产品设计视角的解决图（下一课会重点讲评——它的下场与讲评，正是第三课的全部内容）。 熟记市场调研、用户调研阶段的所有框架内容——后面课程会不断回到工作流程的主线上，不知道这些文档"什么时候用、目的是什么"，就不知道自己到底在做什么。
复盘总结，这一课的关键词是三个：
- 量化
：刚入职没有明确任务时，主动产出行业分析报告、竞品分析报告，让领导看到你的工作内容，而不是"傻看三天"。 - 方法
：拆设计理由先枚举再对比；收集需求分清定性与定量；调研数据先做清洗——方法论永远比结论值钱。 - 边界
：排期是各部门给的、上线时间是评审会或业务方定的、SWOT 是总监级做的——知道什么事情该你做、什么事情不该你做，是产品经理的成熟标志。
把这三点记牢，无论是应付面试，还是入职后真正开展工作，都会从容很多。
