面试里常被问一句：“你觉得产品经理平时做什么？”很多人的回答是：写 PRD、画原型、开评审会、跟进上线、和研发撕需求。
这些回答说的全是动作。动作不是责任。同样的动作，项目经理可以做，设计师可以做，研发负责人也可以做。真正定义一个岗位的，是另一个问题：出了事的时候，哪一类问题算你的？
一个功能要同时过的四道关
任何一个功能上线，要能成立，至少要同时满足四件事：
- 用户愿意用、愿意买——它 有价值；
- 用户看得懂、用得上——它 可用；
- 工程师做得出来，现有技术、时间、人力撑得住——它 可实现；
- 对公司划算，成本、合规、销售方式、商业模式都说得通——它 商业可行。
这四件事对应四种失败：没人要、不会用、做不出来、做出来不赚钱。它们不可能由一个人全部扛住——一个人做到“懂用户”就很难同时“懂技术细节”。所以产品团队的分工，本质上就是把这四种风险各自指定一个负责人。
在产品管理领域常被引用的 SVPG 的说法里，产品团队通常由产品经理、产品设计师和若干工程师组成：设计师对“可用”负责，工程师对“可实现”负责，产品经理对“有价值”和“商业可行”负责1。
于是产品经理这个岗位可以压缩成一句话：保证团队在做一件用户愿意要、同时公司做得下去的事，并推动这件事真的发生。
这句话里有三个约束，缺一个都不算数：用户想要、公司做得下去、事情真的发生。只判断不推动，是顾问；只推动不判断，是传声筒。
“对结果负责”不是“出了多少活”
新手最容易把产出当成成绩。比如月度总结写“上线了 3 个功能、优化了 12 个交互细节”——这些都是 产出（output），说明活干了；而产品经理真正要盯的是 结果（outcome）：某个可观测的量有没有按预期变化。
举个具体的例子。假设你要解决“用户到期后忘记续费”的问题，做了这些产出：自动提醒、一键续费、续费优惠券。但这些本身都不是成绩。要看的是：续费率有没有上升，以及上升的幅度是否对得起这些功能占用的开发资源。
SVPG 的 Marty Cagan 把这句话讲得很直白：交付是必要的，但远远不够1。所以判断一个产品经理做得好不好，不该只看他上线了什么，要看他上线的这些东西有没有让某个数字变好，或者有没有及时叫停一个不划算的方向。
这里有个重要的边界。如果公司根本没有埋点、没有数据看板、没有事先约定“这次上线成功长什么样”，产品经理其实 没法 对结果负责，只能对判断负责。真遇到这种情况，正确的做法不是硬扛指标，而是先把“怎么衡量成功”定义出来——这本身就是产品经理工作的一部分。
日常到底产出什么
把上面这些落回日程，产品经理的产出可以按时间尺度分成三层，加上一层贯穿始终的“依据”。
第一层，长期：判断做什么、不做什么。 也就是常说的产品愿景或策略——一段时间内为哪一类用户解决哪个问题，要往哪儿走，明确放弃什么。这一层的产出通常是一份能被反复引用的说法，而不是一份很长的文档。
第二层，中期：排序。 路线图和优先级表的真正内容不是“清单”，而是 为什么这个排在前面。排序本质上是在取舍：价值多大、成本多高、风险多大、和公司目标的关系多近。
第三层，近期：把判断变成团队能执行的东西。 需求描述、用户故事、验收标准、流程图、原型评审意见，都属于这一层。格式（PRD、文档、看板卡片）其实不重要，重要的是别人看了之后能做出 正确的决定——工程师知道边界在哪，设计师知道要保什么、可以牺牲什么。
贯穿始终的第四层：依据。 用户访谈里听到的原话、数据里的异常、竞品的动作、上个月做过的取舍记录。这一层看起来最不像“产出”，却最决定产品经理有没有话语权。因为产品经理这个岗位有个特点：头衔里有“经理”，但通常 不直接管理团队里任何一个人，不能命令工程师加班，也不能给设计师打绩效。他影响别人的方式，就是提供别人没有的信息和判断1。信息越具体、越可信，越有人愿意听；只会说“老板要求”“竞品都这么做”，很快就会失去信任。
和四个相邻角色的边界
和研发。 产品经理负责说清“要解决什么问题、判断好坏的标准是什么”，研发负责给出“怎么实现”，包括技术选型、架构、工期估算。产品经理可以提技术偏好，但技术方案的最后决定权在研发手上——因为他要对“做得出来、长期维护得起”负责。反过来，产品经理也不该把工期完全交出去：需求范围是可以谈的，砍掉哪个功能属于产品判断，不属于技术判断。
和设计。 设计师对“用户能不能看懂、用得顺”负责，产品经理不替设计师决定交互细节和视觉方案。但产品经理要给出设计需要的判断依据：这个流程服务的是哪类用户、在什么场景下用、我们更在意转化还是更在意降低学习成本。这些取舍标准定不出来，设计师只能靠猜。
和运营。 一个常见的分法是：运营在 现有产品 上做动作——渠道投放、活动策划、内容、社群、用户召回；产品经理改变 产品本身。比如“到期提醒”这件事，运营可以靠人工发消息提醒，产品可以做成自动推送——后者就是产品经理的活。运营还有第二个作用：它离用户最近，会把一线的抱怨和提问带回来。产品经理要主动去接这些信息，而不是等它们变成投诉。
和项目经理。 这两个岗位名字最像，边界也最容易混。项目经理对“这个有始有终的项目在时间、范围、预算内交付”负责，负责排期、跟踪进度、管理依赖和风险，但不负责决定做不做、先做哪个3。产品经理对“做的是不是对的事、值不值”负责。同一个功能：做不做、先做哪个是产品经理的判断；怎么排、什么时候能交付是项目经理的判断。
需要说明的是，这套划分是“职责应该落在谁身上”，而不是“每家公司都这么设岗”。小公司里一个产品经理往往同时在干设计、运营和项目管理；大公司里还会把 Scrum 框架下的 Product Owner 单独设出来，他主要负责把优先级翻译成开发团队可执行的任务条目4。所以判断边界，别从头衔看，要看 当两类目标冲突时，谁拍板——时间要延后还是范围要缩，功能要不要砍，这件事能带来什么结果。
收束
回到最初那个问题：产品经理负责什么？
他负责两件事的成立——用户真的想要，公司真的做得下去；并对由此产生的 结果 负责，而不只是对交付了东西负责。他每天产出的是判断、排序、可执行的定义和支撑这些判断的依据。他和研发、设计、运营、项目经理的区别，不在于谁写文档，而在于 四类风险里谁认领了哪一个。
一个自测练习
回想你最近用过的某个 App 里让你很不爽的一个地方，然后回答：
- 这更接近“没人要”“不会用”“做不出来”还是“不划算”？
- 如果要改，产品经理、设计师、工程师各自该交出什么？
- 改完怎么判断是否成功？看哪个具体数字？这个数字现在有地方看到吗？
第 3 题如果你答不出“去哪儿看”，那正是这份工作真实的一部分：很多时候产品经理的第一件事，是让结果变得可观测，而不是急着写需求。