产品失败了，产品经理要不要承担责任？

近某招聘网站话题引起家议，就“产品失败了，产品经理要不要承担责任？”。在这享一下的观点。

首先澄清个概念：

负责人和责任人

“负责人”“责任人”主要有权力、位职的别：

1. 两者权的同，负责人是指在规定的一定范围，该人既有管权，同时又要承担责任。而责任人没有管权，只承担责任。
2. 者在工作位职的不同， 一来说负责人应该是领导者，而责任人则是工作人员。

负责人是对这个事情兜的人，就失败的原因和他有没有系，他都要承担责任，一般是管者或者公司法人。

责任人没有管理责任，相当于负责人的委托人，理一事。如果出现问题，是要承担责任的。

部分企业，产品理都理权，不兜底的负责人，只执行层面的责任人。作责任人，如果产品失败，从职责讲，产品理一责任的，区别只责任小的问题。

如何界定产品的失败？

界产品的失败严格的标准，可以参考的标准包括：

度量指标未达标

指业务度指标如售额、活跃用户数、NPS、转化率未达到预。

指标是在需求识别阶段和益相关者确认，并为需求的一部分写产品需求说明文档中，以认为是IT部门对投资人的承诺。

如Spuersell这家公司旗下游戏品上市相严苛，百级收都可能作为失败品被下架和“埋葬”掉。

用户不满意

指用户在使用品存在货不版(不符合SLA)、质量缺陷、用户体验等情况。

不合规

指品存在不符合国家标准、业标准、监管要求、策要求或者法律要求。如品企业有品安全国家标准，保险、融业有合规要求。

如何界定产品经理的责任？

般情况下，和需求有关问题，品经理都是主要责任。上述第三情况属于需求问题，是典型需求遗漏。

再举个需求遗漏的例子：在园场，国2018年颁布了《中小数字园建设规范（试行）》，如果产经未识别到这些监管性的规范要求，会导致产无法获得场准入等重大问题。

和用户体验相关的问题，通常是由产品经理和UX（UI/UCD/UED）共同负责。用户体验的例：某企业为城市的环卫工程承包商开发了一款智能环，环的目的是对环卫工的工作位置进行定位，从而实现轨迹跟踪、调度等管理功能。但产品发布后，环因为携带不方便、源续航间短、员工担心隐私泄露等问题遭用户不，最终导致产品使用率低而最终未能量产。

除了需求用户体验以外，其它况都具体分析。如业务指标的实需研发、产品、运营、市场售部门一起完的，每部门都承担分解后的考核指标。如果出问题，应该由负责治理的委员会行问题回溯，确责任主体相关责任人。

需求是产品经理“创造”的吗？

很多人对产品理误解，就认产品理创造了需求，创造了产品，所以如果产品出了问题，就产品理的责任。实际况否如此呢？

么我们就来看下需求是怎么一步步导到产品中的。

需求收集

先需求的来源，产品的需求无外乎来这个领域：

Ø 客户

Ø End User

Ø 利益相关者

Ø 监管门要求

Ø 行业标准和规范

Ø 企业标准规范

需求收集是一个类似“挖矿”的程，我要先识别“矿源”通工具的方式将需求“挖掘”出来，尤其是客户未直接表达的隐形需求。

在BABOK指南中需求收集的英一词是Elicitation，翻译过来是导或者引的意思，就是说，需求是已经存在的，产经只是把它来而已。产经会采访谈、头脑暴、worshop技术，通过倾听、观察、沟通、潜意识流等方法将隐藏在户心中的需求“引导”来。在需求产生的过程中，产经是“助产士”而是需求的“爸妈”。

那么创造性的产品需求呢？当然了，否则人类不会汽车、飞机这些产品了。乔布斯的苹果手机、张小龙的微信、埃隆马斯克的可往返商用飞船都创造性的产品。但并非所产品理都这样的机会可以不考虑任何资源限制设一款产品，也并非所产品理都乔帮主这样天级的象力。

以用户为中心，应用设计思和精益思的方法论，通各种方法和工具把用户脑子里面的需求引导出来并转化为决方案才是大部分产品经理的常态化工。

用个不恰比喻，也可以说：产品理不产“需求”，只需求的“搬运”。

需求优先级排序

收集的需求会总在一个需求总表中。这候需要一个需求评审以确定需求的优先并制定产品路线图。

需求评审是产品经理的一关。

需求评审目是让利益相关者（开发、设计、测试、运、板等）理解需求背景、需求目以及具体需求描述，并认可原型设计和解决案。

需求会议上，产品经理需要跟大家确需要解决的痛点问题，有哪些功能以及对应的计划，然后大家在会议上挑刺，讨论，甚至是撕逼，最终全体成员达成一致见后开始开干。通常一些项目需求都是要经过次评审会才能完成的。

缺乏预先沟通决策制度的况下，这种审产品可能及其混乱的。争论的焦点到后几乎都会变三观问题：谁能表用户？谁了算？领导意见不考虑？

通评审的需求，通常各方博弈的结果。其中，有少属产品经理能决定的需求就很难说。

需求讲解

接下来，你需要针对项目组中所有开同学的一次需求讲活动。具程下：

1. PM通过用户故事技给发人员讲解需求；
2. 开人评论需求是否合理，完善，
3. 开发员评估案和工作量

里面当少不讨价还价，各种掰扯。也容易理，需求文档几页纸能是开几人月的工量，谓一而动身，也为什么是开的小伙伴把”需求放在火上烤”的原因。

在职场鄙视链，品经理在开发小伙伴眼怎么看都是“站着说活不腰疼”主。说到底是屁沟决定脑袋，很多品经理也是技术出生，他们站在品经理岗位上时，能体会各自视异。

需求变更

在开发过程中，会存在对正在开发 的增的需求的情况，就是需求变更，如客户希望在CRM软件中增访客识别功。需求变更的原因既有遗漏的情况，又有各种“xx领导”意见。许多公司需求评审制并善，存在会上谈会谈，是领导意见心等现象，导致需求评审阶过后才发现需求遗漏。

总结一下需求管理的整个过程：产品经理首先通过引导收集需求，然后通过需求评审确定需求的优先，然后给通过讲故事的方式给开发人员讲解需求，然后在产品发布后管理需求变更。始至终，产品经理都只是需求的管理员和委托人，而非需求的创造者。

不是一个人在战斗

“胜则举杯相庆，败则拼死相救”，在为众多文化中，这是重要的一条，也激励着无数为儿。

产品的功系统程，产品理虽然顶一产品“责任人”的衔，但仍然只团队中的一员。产品的功离不研发、运营市场售部门紧密配合相互协作。如果产品失败了，作产品的“责任人”，产品理则无旁贷的。
产经会犯错误，需要成长。产经并害怕责任，而是害怕得到队友支持，当我们抗起责任，摔得土头土脸的时候，希望归来依然年，我们还可相约再战。