产品经理职责有哪些？需求阶段和上线阶段怎么分

产品经理职责指的是一套按产品生命周期切出来的3段责任分工，不是一张岗位说明书，它属于互联网研发体系里的职能岗。落到实际只有3件事：判断该做什么、把方案说清楚、上线之后负责到下个版本。

这3件事对应3个阶段，标准叫法是需求阶段、方案阶段、上线阶段。产品经理职责分不清，问题其实不在人身上，而在3段的产出物没定死。

产品经理职责是什么：一个把「问题」翻译成「可执行的说明书」的岗位

先把定义立住。产品经理负责把用户的模糊诉求，翻译成研发、设计、测试能照着干的说明书。它和项目经理、运营的区别，从这句话里就能看出来：一个管做什么，一个管按时做完，一个管做完之后怎么卖。

还有个更实用的辨认办法：看一个岗位的交付物是不是可被执行。交付的是代码、是排期、是活动页，那就不是产品；交付的是一份别人能照着做的说明，那才是产品经理。这个岗位在体系里的位置是「中间层」。往上，业务方给目标和预算；往下，设计给界面、研发给代码、测试给结论。产品经理是把两头接上的那个人。

3个阶段的产出物可以一句话记：需求阶段交需求文档，方案阶段交竞品分析和原型设计，上线阶段交验收结论和下个版本的计划。哪一段没纸面上的东西，那一段就等于没做。

也有另一种误判，把产品当成传话的：业务说什么就抄给研发，用户说什么就抄给设计。这种角色确实存在，但它的产出物永远是一份转述，不是判断。我见过最多的误判，是把产品经理当成「画原型的」。原型只是方案阶段的一张纸，前面的需求判断和后面的上线验收，才是真正吃功夫的地方。

图源：《王慧文清华产品课（三）-产品篇》（第2页 · 原文）

职责边界最常见的一句解释是：产品对结果负责，不对进度负责。这句话听起来像推卸，其实是在保判断的质量，因为一旦背上进度，产品就会开始向工期妥协。

还有一个上位概念要说清：产品经理和「产品负责人」不是一回事，后者在敏捷团队里还管优先级和资源调配。两者在小团队里经常是一个人干，职责清单却是两份。

产品经理需求阶段：判断该做什么，产出物是一份写清边界的需求文档

产品经理需求阶段的核心动作只有1个：判断这个需求值不值得做。产出物是需求文档，它至少要回答4个问题，给谁用、解决什么、不做什么、怎么算做成。

2024年之后我改了自己的做法，需求文档第一页先写一句用户场景。王慧文在需求课里有个判断我一直在用：Needs 是用户原始的动机成因，Requirement 是由 Needs 派生的设计要求，Demand 是产品做出来之后的市场需求量。三者的关系是 Needs 大于 Requirement 大于 Demand，顺序不能倒过来用。

这个区分解决的是最常见的错位：客户说要一个「导出按钮」，那是 Requirement；他真正要的是「月底能交报表」，那才是 Needs。照着按钮做，下个月他还来提需求。

需求阶段还有一层筛子。他讲过，能满足的需求远远少于不能满足的；能在自然科学框架内解决的里面，正收益的又远远少于负收益的。所以判断标准不是「能不能做」，是ROI 是否为正，以及是否撑得起一个团队。

落地的时候我用一份四问清单，每个需求过一遍再进排期。这份清单同时把3个阶段串了起来，方便对照：

四问清单之外，我还加了一条口径：所有需求都要标一个来源，是用户说的、数据看出来的、还是老板拍的。三个来源的处理方式完全不同，混在一起写，评审时一定吵。

需求文档最容易漏的是「不做什么」这一节。我要求每个文档都必须有一行白纸黑字写清楚本次不做哪些，不然开发做着做着就会自己加。

优先级排序的判法也有讲究。我不用「重要紧急」四象限，因为它太主观。我用两条硬线：不做会不会丢现有用户，做了能不能带来新增，两条都答否就排到后面去。

图源：《王慧文清华产品课（五）-需求篇》（第2页 · 原文）

需求阶段还有个隐形成本，是反复确认。一个小卖家找我改过3轮需求，第3轮改的其实是第1轮已经否掉的方案。原因很简单，第1轮没有把「为什么否」写进文档，下次就重来。

还有一种需求来自数据，比如某个页面的跳出率突然涨了。这一类最容易写清楚，也最容易排优先级，因为它自带一个基线，改完就能对照。所以需求文档里一定要留一栏「被否的方案及理由」。它不占篇幅，却能省掉后面无数个来回，这是我做这几年最值钱的一条经验。

方案阶段：竞品分析不是抄，是找出对方不愿改的那一处

方案阶段的核心动作是把需求翻译成具体方案，产出物是竞品分析和原型设计两份材料。这两样东西的共同要求只有一条：让别人看完就能动手。

竞品分析最容易写成罗列。我看过太多把5个竞品的功能截图贴一页的文档，那只是观察，不是分析。有效做法是只挑2个竞品，各找1处「它长期不改的地方」，再问自己为什么。

这类实操材料我平时是从运营动脉上取的。方案、课件、报告、测算表一套一套配着，不用自己从零搭框架，急用的时候能救急。

做这一步的时候，我会给竞品标一个不变天数，比如某个交互3年没动过。这个数字比任何主观评语都好用，因为它能直接推出结论。

它长期不改的地方，要么是它的用户根本不在意，要么是它改不动。前者说明这个点不值得做，后者说明这是你的机会。这一个判断，比10页功能对比表都管用。

原型设计的验收标准我固定用3条：每个页面有没有空状态、有没有加载中、有没有报错。3个状态都画了，方案才算走完；只画了正常态的，交给研发一定返工。

方案阶段还要写一份不做清单给研发看，把这次明确不做的交互写清楚。它和需求文档里的不做什么是两回事，前者管范围，后者管边界。

还有一条实操标准：原型上的每个按钮，都要能回答「点了之后去哪」。答不上来的按钮，先删掉，想清楚了再加回来。

王慧文在产品课里讲 PMF，说最开始要找一个更锐利的切入点，这个 PMF 选得越犀利，早期 ROI 就越高。放到方案阶段，意思就是第一个版本别做大而全，先把一处做到能让人「非用不可」。

他还提到，初期宁可让1000人 love 你的产品，也不要让10000人 like。这句话我用来砍需求：一个功能如果只是大家都觉得还行，那就先不做。

方案阶段的时间分配也值得一说。我的比例是竞品占两成、原型占五成、剩下的三成留给评审和修改。很多人把九成时间花在画原型上，评审一改就全推翻。

图源：《王慧文清华产品课（五）-需求篇》（第3页 · 原文）

评审要拉谁也有讲究。我固定拉4个人：研发负责人、测试、设计、一线客服，前三个看可行性，客服看这个方案上线后会不会被投诉。评审只给3个结论：做、改、不做，不允许再想想，因为没有结论的评审等于没开。需求和方案的边界也能用一句话记住：需求回答要不要，方案回答怎么要。

产品经理上线阶段：验收不是看一眼，是拿上线前定好的标准对一遍

产品经理上线阶段的核心动作是判断「做成没有」，产出物是验收结论加上下个版本的计划。这里有2件容易混的事：验收和验收标准，前者是动作，后者必须在上线前就写完。

验收标准怎么写才管用？我给的是一个三件套：核心指标、观察窗口、回滚条件。指标写具体数值，窗口写几天，回滚写清楚什么情况下必须退。

验收本身要分两层。第一层是功能验收，走一遍主流程和3个异常状态；第二层是数据验收，上线后看核心指标有没有动，没动就说明方案没打到点上。

图源：《王慧文清华产品课（五）-需求篇》（第6页 · 原文）

数据验收最怕的是没基线。上线前不记当前值，上线后看到任何数字都说不出好坏，所以我要求上线前把核心指标抄一份，贴在验收文档第一行。

回滚条件这一项，绝大多数团队会省掉。我的做法是把它写成一句话，例如「次日留存低于基线2个百分点就回滚」，写不出具体数值，就说明这个功能不该上线。

上线不等于交付。产品经理版本迭代的责任，从上线那一刻才正式开始：第1周看数据、第2周看反馈、第3周决定是加码还是下架。

上线后的第一周最重要，因为所有假设都会在这一周被检验一遍。我的做法是每天固定看3个数：访问量、完成率、投诉量，连看7天再做判断。

在小团队里这一点尤其要紧，小团队没有专职数据岗，产品要自己拉数、自己解读、自己决定下一步，慢一天就多亏一天。上线不是终点，是第一次真正拿到数据。没有数据的那一版，等于没上线。

和项目经理、运营的职责边界：3个岗位，3种「做完了」

先把三者的一句话定义摆出来，后面的边界才好谈。这3个岗位最容易被混成一团，因为它们天天一起开会。分开看其实很清楚：产品经理对「做什么」负责，项目经理对「按时做完」负责，运营对「做完之后怎么用起来」负责。

这3句话对应3种考核。产品考做对了几件，项目考按期交付率，运营考用起来的人数，三套指标不能混着用，混着用就是三条线互相牵制。混着用的后果很具体：三个岗位都去追同一个数字，其余两个数字就没人盯。

图源：《王慧文清华产品课（五）-需求篇》（第10页 · 原文）

判断边界有个很实用的问法：出了问题，第一句该找谁。功能做错了找产品，进度拖了找项目，上线后没人用找运营。答得上来，边界就是清的；三个都要找，说明职责没定。

流程管理的资料里有个说法，流程是一系列把输入转化为输出的活动，战略目标是「做正确的事」，流程是「正确地做事」。这组对照正好对上产品和项目：一个定正确的事，一个保证正确地做完。

跨部门协同最容易卡的地方，是产品经理替项目经理去催进度。一催，项目就失去了自己的节奏，产品也失去了判断的余量。我见过项目里产品天天盯排期，结果需求质量反而下降。

协同最怕的是三不管地带，比如空数据时该显示什么。这种细节既不属于功能，也不属于运营，最后往往悬在那里，等用户撞见才被发现。

另一头是产品替运营背结果。上线后数据不好，运营说「功能不行」，产品说「你们不会推」。这时候要看上线前有没有把指标写进验收标准，写了就按标准对，没写就是产品的责任。

还有一个岗位容易漏，就是数据分析。它不管做不做，也不管什么时候做完，只管做完之后到底有没有效果。小团队里这一环常被产品兼掉，兼掉的风险是既当运动员又当裁判。

再补一个岗位对照：设计不是产品的执行手。设计对「好不好用」负责，产品对「该不该有」负责。两者冲突时，砍功能的决定权在产品，改交互的决定权在设计，这个分工写进文档最省事。

这3个阶段最常错的地方，以及什么时候职责清单反而有害

先说个反例，把三段的缺失摆在一起看更清楚。第一个错：需求阶段跳过去，直接进方案。表现是文档里只有页面没有理由，做完了没人说得清为什么做。后果是上线后无法判断成败。

第二个错：方案阶段只画正常态。空状态、加载、报错3个都没画，研发只能自己猜，猜错就返工，一次返工通常吃掉整个迭代的余量。

第三个错：上线阶段没有基线。验收变成「看一眼觉得挺好」，下个版本做不做、加不加码，全靠感觉。

职责清单也有不适用的时候。3个人的团队，产品、项目、运营常常是一个人干，这时候照搬大公司的清单，只会把人绑死在流程上。我的建议是3人以下只留需求文档和上线验收两样纸面产物，中间的过程能省就省。

图源：《王慧文清华产品课（五）-需求篇》（第7页 · 原文）

还有一种情况值得单说：业务还在验证期，做的是「先上线看看」。这时候需求文档可以只写一页，但验收标准和回滚条件必须写全，因为验证期最怕的不是做错，是做错了还退不回来。

职责写在岗位说明书上是分工，写进文档里才是责任。没有落到纸面的那些，最后都会变成会议上互相看一眼。

产品经理的活，一半在写，一半在问。写的是文档，问的是那句「你到底想解决什么」。

下一步怎么落地？建议你先把自己手上的活按3个阶段归一次类，看看哪一段完全是空的。产品经理职责真正考验的是三段的产出物有没有落地：需求文档、竞品加原型、验收结论，缺一段就等于这一段没做。你可以直接照上面那份清单，从需求阶段开始补，先补「不做什么」那一行。记住一句话：一件事如果说不清谁来负责，那它就一定没人负责。

延伸阅读：更对口的站内文档

按「产品经理职责」这个题目，读者下一步最可能需要的资料，我从站内挑了 3 份，都是能直接看原文的：

相关文章