产品经理的职责不是“什么都管”，而是对产品的方向和结果负责：从发现用户问题、确定优先级，到推动方案落地、上线后验证并决定下一步。不同团队的叫法不一样，但职责可以按阶段拆清楚。
下面按需求、方案、研发上线和上线后四个阶段，说明产品经理要负责什么、哪些事不负责但必须推动。想先分清和项目经理的分工，可以看产品经理和项目经理的区别。
先给结论：一张表看清职责边界
| 阶段 | 产品经理要负责 | 不负责但必须推动 |
|---|---|---|
| 需求阶段 | 用户问题、证据与优先级排序 | 业务方给不出目标时的对齐与追问 |
| 方案阶段 | 原型、流程、边界条件与验收标准 | 设计细节与视觉风格 |
| 研发阶段 | 解释需求意图、判断变更影响 | 具体排期与资源调配 |
| 上线阶段 | 验收结果、指标解读与迭代方向 | 发布流程与回滚执行 |
需求阶段：把问题和证据分开
用户问题优先于功能清单
先写清谁在什么场景下遇到什么问题、现在是怎么绕过去的，再讨论做什么功能。只收集“我要什么功能”会让需求清单越拉越长，却始终说不清价值。
优先级要有可解释的标准
常用标准是影响面、目标贡献、实现成本和风险。无论用哪一套，都要能回答两个问题：为什么这条排在前面；被推迟的需求在什么条件下重新进入排期。
方案阶段：把需求变成可评审的原型与文档
原型要能回答当前阶段的问题
原型不是画得越细越好，而是要能回答当前问题：信息结构是否合理、关键流程能否走通、异常状态有没有出口。评审前先说明这版原型要验证什么，讨论才不会跑题。
文档要写清验收标准
需求文档至少包含目标、范围、不做清单、关键流程、边界条件和验收方式。缺少“不做清单”的文档最容易在开发中被被动扩张，最后延期却找不到原因。文档结构的写法可以参考产品经理需要写哪些文档。
把原型和需求说明放在同一个项目里评审，能减少来回确认。墨刀原型支持在页面上补充交互说明并保留评审记录，适合边改边对齐的团队。
研发与上线阶段：解释和决策，而不是转达
研发阶段产品经理的核心工作不是“传话”，而是解释需求意图、判断变更是否影响目标、在信息不足时先给出临时结论。遇到技术方案取舍，要明确哪些是必须满足的用户价值，哪些实现方式可以调整。
上线前要把验收清单给到测试和业务方，明确通过标准；涉及数据或权限变更时，还需要确认回滚方式和影响范围。
上线后：用指标决定下一步
上线不是结束。产品经理要在约定周期内看核心指标、用户反馈和异常数据，判断继续迭代、回滚还是停止投入。没有验证方式的需求，等于没有目标。
产品经理不负责什么
- 不替研发决定技术实现路径；
- 不代替设计师做视觉判断；
- 不包揽项目排期与资源协调；
- 不在没有数据的情况下宣布成功。
这些边界不是推卸责任，而是让每个角色的判断都能被检验。划边界的目的不是分家，而是让每个环节都有明确的负责人。
不同层级的产品经理，职责有什么变化
| 层级 | 主要职责 |
|---|---|
| 初级 | 把需求写清楚，完成基础原型与文档 |
| 中级 | 独立判断优先级，推动跨团队落地 |
| 高级 | 对业务目标负责，定义方向与验证方式 |
| 负责人 | 决定做什么与不做什么，并对团队结果负责 |
同一岗位名称下的职责范围差异很大，这也是产品经理分类需要按维度看的原因。软件方向更侧重系统结构与流程，可以对照软件产品经理职责。
常见问题
产品经理需要会写代码吗？
不需要自己能实现，但要能理解技术约束，判断哪些需求受实现方式限制，哪些可以换方案。能听懂研发的风险说明，比写代码更重要。
产品经理要不要懂数据？
至少要能定义指标口径、看懂趋势和异常，并能把结论转成下一步动作。不需要做复杂建模，但要能判断数据是否支持当前结论。
需求被临时插入怎么办？
先判断它是新目标还是既有目标的补充。如果是新目标，需要重新确认优先级和被挤出的需求；如果是补充，要评估对当前版本范围的影响并留下记录。
