# 产品经理到底负责什么：从“写文档的人”到“对结果负责的人”

用“四类风险谁认领”这条线，讲清产品经理的职责、产出，以及和研发、设计、运营、项目经理的边界

> 产品经理职责 · 角色边界 · 结果导向 · 约 8 分钟 · 09 月 21 日

## 本篇要点

1. 产品经理的职责不能靠“写 PRD、画原型、开评审会”这类动作来定义，而要看他认领了哪一类失败风险。
2. 一个功能要成立，必须同时满足有价值、可用、可实现、商业可行四个条件；产品经理对“有价值”和“商业可行”负责，设计师对“可用”负责，工程师对“可实现”负责。
3. 产品经理要负责的是结果而不是产出：上线了多少功能不算成绩，某个可观测的指标有没有按预期变化才算。
4. 如果公司没有埋点、没有数据、没有事先定义成功标准，产品经理无法对结果负责，此时第一步是把“怎么衡量成功”定义出来。
5. 日常产出分三层：长期判断做什么和不做什么，中期给出排序及其理由，近期把判断变成团队能执行的需求与验收标准；此外还要持续提供访谈、数据、竞品、取舍记录这类依据。
6. 产品经理通常不直接管理团队成员，只能靠信息和判断影响别人，因此依据的质量决定他的话语权。
7. 和研发的边界是“问题与评判标准”对“如何实现”；和设计是“取舍标准”对“交互与视觉方案”；和运营是“改变产品本身”对“在现有产品上做动作”；和项目经理是“做不做、先做哪个”对“怎么排、何时交付”。
8. 边界的判断方法不是看头衔，而是看两类目标冲突时谁拍板；小公司里这些角色常由一人兼任，职责仍应区分清楚。

---

面试里常被问一句：“你觉得产品经理平时做什么？”很多人的回答是：写 PRD、画原型、开评审会、跟进上线、和研发撕需求。

这些回答说的全是动作。动作不是责任。同样的动作，项目经理可以做，设计师可以做，研发负责人也可以做。真正定义一个岗位的，是另一个问题：**出了事的时候，哪一类问题算你的？**

## 一个功能要同时过的四道关

任何一个功能上线，要能成立，至少要同时满足四件事：

- 用户愿意用、愿意买——它**有价值**；
- 用户看得懂、用得上——它**可用**；
- 工程师做得出来，现有技术、时间、人力撑得住——它**可实现**；
- 对公司划算，成本、合规、销售方式、商业模式都说得通——它**商业可行**。

这四件事对应四种失败：没人要、不会用、做不出来、做出来不赚钱。它们不可能由一个人全部扛住——一个人做到“懂用户”就很难同时“懂技术细节”。所以产品团队的分工，本质上就是把这四种风险各自指定一个负责人。

在产品管理领域常被引用的 SVPG 的说法里，产品团队通常由产品经理、产品设计师和若干工程师组成：设计师对“可用”负责，工程师对“可实现”负责，**产品经理对“有价值”和“商业可行”负责**[1]。

于是产品经理这个岗位可以压缩成一句话：**保证团队在做一件用户愿意要、同时公司做得下去的事，并推动这件事真的发生。**

这句话里有三个约束，缺一个都不算数：用户想要、公司做得下去、事情真的发生。只判断不推动，是顾问；只推动不判断，是传声筒。

```mermaid
flowchart LR
  G["一个功能想成立"] --> A["用户愿意用？"]
  G --> B["用户会用？"]
  G --> C["做得出来？"]
  G --> D["公司划算？"]
  A --> PM["产品经理负责"]
  D --> PM
  B --> DE["设计师负责"]
  C --> EN["工程师负责"]
```

## “对结果负责”不是“出了多少活”

新手最容易把产出当成成绩。比如月度总结写“上线了 3 个功能、优化了 12 个交互细节”——这些都是**产出**（output），说明活干了；而产品经理真正要盯的是**结果**（outcome）：某个可观测的量有没有按预期变化。

举个具体的例子。假设你要解决“用户到期后忘记续费”的问题，做了这些产出：自动提醒、一键续费、续费优惠券。但这些本身都不是成绩。要看的是：**续费率有没有上升**，以及上升的幅度是否对得起这些功能占用的开发资源。

SVPG 的 Marty Cagan 把这句话讲得很直白：交付是必要的，但远远不够[1]。所以判断一个产品经理做得好不好，不该只看他上线了什么，要看他上线的这些东西有没有让某个数字变好，或者有没有及时叫停一个不划算的方向。

这里有个重要的边界。如果公司根本没有埋点、没有数据看板、没有事先约定“这次上线成功长什么样”，产品经理其实**没法**对结果负责，只能对判断负责。真遇到这种情况，正确的做法不是硬扛指标，而是先把“怎么衡量成功”定义出来——这本身就是产品经理工作的一部分。

## 日常到底产出什么

把上面这些落回日程，产品经理的产出可以按时间尺度分成三层，加上一层贯穿始终的“依据”。

**第一层，长期：判断做什么、不做什么。** 也就是常说的产品愿景或策略——一段时间内为哪一类用户解决哪个问题，要往哪儿走，明确放弃什么。这一层的产出通常是一份能被反复引用的说法，而不是一份很长的文档。

**第二层，中期：排序。** 路线图和优先级表的真正内容不是“清单”，而是**为什么这个排在前面**。排序本质上是在取舍：价值多大、成本多高、风险多大、和公司目标的关系多近。

**第三层，近期：把判断变成团队能执行的东西。** 需求描述、用户故事、验收标准、流程图、原型评审意见，都属于这一层。格式（PRD、文档、看板卡片）其实不重要，重要的是别人看了之后能做出**正确的决定**——工程师知道边界在哪，设计师知道要保什么、可以牺牲什么。

**贯穿始终的第四层：依据。** 用户访谈里听到的原话、数据里的异常、竞品的动作、上个月做过的取舍记录。这一层看起来最不像“产出”，却最决定产品经理有没有话语权。因为产品经理这个岗位有个特点：头衔里有“经理”，但通常**不直接管理团队里任何一个人**，不能命令工程师加班，也不能给设计师打绩效。他影响别人的方式，就是提供别人没有的信息和判断[1]。信息越具体、越可信，越有人愿意听；只会说“老板要求”“竞品都这么做”，很快就会失去信任。

## 和四个相邻角色的边界

**和研发。** 产品经理负责说清“要解决什么问题、判断好坏的标准是什么”，研发负责给出“怎么实现”，包括技术选型、架构、工期估算。产品经理可以提技术偏好，但技术方案的最后决定权在研发手上——因为他要对“做得出来、长期维护得起”负责。反过来，产品经理也不该把工期完全交出去：需求范围是可以谈的，砍掉哪个功能属于产品判断，不属于技术判断。

**和设计。** 设计师对“用户能不能看懂、用得顺”负责，产品经理不替设计师决定交互细节和视觉方案。但产品经理要给出设计需要的判断依据：这个流程服务的是哪类用户、在什么场景下用、我们更在意转化还是更在意降低学习成本。这些取舍标准定不出来，设计师只能靠猜。

**和运营。** 一个常见的分法是：运营在**现有产品**上做动作——渠道投放、活动策划、内容、社群、用户召回；产品经理改变**产品本身**。比如“到期提醒”这件事，运营可以靠人工发消息提醒，产品可以做成自动推送——后者就是产品经理的活。运营还有第二个作用：它离用户最近，会把一线的抱怨和提问带回来。产品经理要主动去接这些信息，而不是等它们变成投诉。

**和项目经理。** 这两个岗位名字最像，边界也最容易混。项目经理对“这个有始有终的项目在时间、范围、预算内交付”负责，负责排期、跟踪进度、管理依赖和风险，但不负责决定做不做、先做哪个[3]。产品经理对“做的是不是对的事、值不值”负责。同一个功能：**做不做、先做哪个是产品经理的判断；怎么排、什么时候能交付是项目经理的判断。**

需要说明的是，这套划分是“职责应该落在谁身上”，而不是“每家公司都这么设岗”。小公司里一个产品经理往往同时在干设计、运营和项目管理；大公司里还会把 Scrum 框架下的 Product Owner 单独设出来，他主要负责把优先级翻译成开发团队可执行的任务条目[4]。所以判断边界，别从头衔看，要看**当两类目标冲突时，谁拍板**——时间要延后还是范围要缩，功能要不要砍，这件事能带来什么结果。

## 收束

回到最初那个问题：产品经理负责什么？

他负责两件事的成立——用户真的想要，公司真的做得下去；并对由此产生的**结果**负责，而不只是对交付了东西负责。他每天产出的是判断、排序、可执行的定义和支撑这些判断的依据。他和研发、设计、运营、项目经理的区别，不在于谁写文档，而在于**四类风险里谁认领了哪一个**。

<details>
<summary>一个自测练习</summary>

回想你最近用过的某个 App 里让你很不爽的一个地方，然后回答：

1. 这更接近“没人要”“不会用”“做不出来”还是“不划算”？
2. 如果要改，产品经理、设计师、工程师各自该交出什么？
3. 改完怎么判断是否成功？看哪个具体数字？这个数字现在有地方看到吗？

第 3 题如果你答不出“去哪儿看”，那正是这份工作真实的一部分：很多时候产品经理的第一件事，是让结果变得可观测，而不是急着写需求。
</details>

## 术语表

- 四类风险：一个功能可能失败在四个地方——没人要（价值）、不会用（可用）、做不出来（可实现）、不划算（商业可行），产品团队的职责划分就是给这四类风险各指定一个负责人。
- 产出与结果：产出指做完了哪些东西，结果指某个可观测的量有没有按预期变化；产品经理要对后者负责。
- 产品愿景与策略：一段时间内为哪类用户解决哪个问题、往哪走、放弃什么，是产品经理最长周期的判断。
- 优先级排序：决定先做哪个，本质是在价值、成本、风险与公司目标之间做取舍，产出的核心是排序的理由。
- 无授权领导：产品经理通常不管理团队成员的绩效与人事，只能靠信息、判断和共同目标影响他人。
- 项目经理：对某个有始有终的项目在时间、范围、预算内交付负责，管排期、依赖和风险，但不决定做不做、先做哪个。
- Product Owner：Scrum 框架里的角色，负责把优先级翻译成开发团队可执行的任务条目并排好顺序，职责范围比产品经理窄。

## 来源

1. [SVPG: Product Manager Job Description — 设计师对可用、工程师对可实现、产品经理对有价值与商业可行负责；交付必要但不充分](https://www.svpg.com/product-manager-job-description/)
2. [SVPG: Process vs. Model — 产品团队在发现阶段正面处理价值、可用、可实现、商业可行四类风险](https://www.svpg.com/process-vs-model/)
3. [Atlassian: Product manager vs. project manager — 产品经理管“做什么、为什么”，项目经理管“怎么做、什么时候做完”](https://www.atlassian.com/agile/project-management/product-vs-project-management)
4. [Curotec: Project Manager vs. Product Manager vs. Product Owner — 三个角色的职责对照，含 Product Owner 负责 backlog 与可执行定义](https://www.curotec.com/insights/project-manager-vs-product-manager-vs-product-owner/)

---

原文：https://pangzhengboyin.com/articles/what-product-managers-are-accountable-for-fe7c5348

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com