产品经理工作中遇到的失败（产品经理要不要承担责任）
产品经理工作中遇到的失败（产品经理要不要承担责任）界定产品的失败没有严格的标准，可以参考的标准包括：作为责任人，如果产品失败，从职责上讲，产品经理一定是有责任的，区别只是责任大小的问题。负责人是对这个事情兜底的人，也就失败的原因和他有没有关系，他都要承担责任，一般是管理者或者公司法人。责任人没有管理责任，他相当于负责人的委托人，处理一般事务。如果出现问题，他是要承担责任的。在大部分企业，产品经理都没有管理权，不是兜底的负责人，而只是执行层面的责任人。
产品经理，职场上的“背锅侠”。一个产品失败了，产品经理要不要承担责任？本文将从五个角度对这个问题进行分析，希望对你有帮助。
近期某招聘网站有个话题引起大家热议，就是“产品失败了，产品经理要不要承担责任？”。在这里分享一下我的观点。
首先澄清几个概念：
一、负责人和责任人“负责人”与“责任人”主要有权力、单位职务的区别：
- 两者权力的不同，负责人是指在规定的一定范围内，该人既有管理权，同时又要承担责任。而责任人没有管理权，只承担责任。
- 两者在工作单位职务的不同， 一般来说负责人应该是领导者，而责任人则是工作人员。
负责人是对这个事情兜底的人，也就失败的原因和他有没有关系，他都要承担责任，一般是管理者或者公司法人。
责任人没有管理责任，他相当于负责人的委托人，处理一般事务。如果出现问题，他是要承担责任的。
在大部分企业，产品经理都没有管理权，不是兜底的负责人，而只是执行层面的责任人。
作为责任人，如果产品失败，从职责上讲，产品经理一定是有责任的，区别只是责任大小的问题。
二、如何界定产品的失败？界定产品的失败没有严格的标准，可以参考的标准包括：
1. 度量指标未达标
指业务度量指标如销售额、活跃用户数、NPS、转化率等未达到预期。
这些指标是在需求识别阶段和利益相关者确认，并作为需求的一部分写入产品需求说明文档中，可以认为是IT部门对投资人的承诺。
如Spuersell这家公司对旗下游戏产品的上市就相当严苛，百万级的营收都可能作为失败的产品被下架和“埋葬”掉。
2. 用户不满意
指用户在使用产品中存在货不对版(不符合SLA)、质量缺陷、用户体验差等情况。
3. 不合规
指产品存在不符合国家标准、行业标准、监管要求、政策要求或者法律要求。如食品企业有食品安全国家标准，保险、金融行业有合规要求。
三、如何界定产品经理的责任？一般情况下，和需求有关的问题，产品经理都是主要责任人。上述第三种情况就属于需求问题，是典型的需求遗漏。
再举个需求遗漏的例子：在校园市场，国家2018年颁布了《中小学数字校园建设规范（试行）》，如果产品经理未能识别到这些监管性的规范要求，会导致产品无法获得市场准入等重大问题。
和用户体验相关的问题，通常是由产品经理和UX（UI/UCD/UED）共同负责。
用户体验的例子：某企业为城市的环卫工程承包商开发了一款智能手环，手环的目的是对环卫工的工作位置进行定位，从而实现轨迹跟踪、调度等管理功能。但产品发布后，手环因为携带不方便、电源续航时间短、员工担心隐私泄露等问题遭到用户不满，最终导致产品使用率低而最终未能量产。
除了需求和用户体验以外，其它情况都要具体分析。如业务指标的实现是需要研发、产品、运营、市场销售部门一起完成的，每个部门都要承担分解后的考核指标。如果出现问题，应该由负责治理的委员会进行问题回溯，确定责任主体和相关责任人。
四、需求是产品经理“创造”的吗？很多人对产品经理有个误解，就是认为是产品经理创造了需求，进而创造了产品。所以如果是产品出了问题，就是产品经理的责任，实际情况是否如此呢？
那么我们就来看下需求是怎么一步步导入到产品中的。
1. 需求收集
先看需求的来源，产品的需求无外乎来自这么几个领域：
- 客户
- End User
- 利益相关者
- 监管部门要求
- 行业标准和规范
- 企业标准和规范
需求收集是一个类似“挖矿”的过程，我要先识别“矿源”再通过工具的方式将需求“挖掘”出来，尤其是那些客户未直接表达的隐形需求。
在BABOK指南中需求收集的英文一词是Elicitation，翻译过来是导出或者引出的意思，也就是说，需求是已经存在的，产品经理只是把它找出来而已。
产品经理会采用访谈、头脑风暴、worshop技术，通过倾听、观察、沟通、潜意识流动等方法将隐藏在用户心中的需求“引导”出来。
在需求产生的过程中，产品经理是“助产士”而不是需求的“爸妈”。
那么有没有创造性的产品需求呢？当然有了，否则人类不会有汽车、飞机这些产品了。乔布斯的苹果手机、张小龙的微信、埃隆马斯克的可往返商用飞船都是创造性的产品。但并非所有产品经理都有这样的机会可以不考虑任何资源限制来设计一款产品，也并非所有产品经理都有乔帮主这样天才级的想象力。
以用户为中心，应用设计思维和精益思维的方法论，通过各种方法和工具把用户脑子里面的需求引导出来并转化为解决方案才是大部分产品经理的常态化工作。
用一个不恰当的比喻，也可以说：产品经理不生产“需求”，只是需求的“搬运工”。
2. 需求优先级排序
收集的需求会汇总在一个需求汇总表中。这时候需要一个需求评审以确定需求的优先级并制定产品路线图。
需求评审是产品经理的第一关。
需求评审的目的是让利益相关者（开发、设计、测试、运营、老板等）理解需求背景、需求目的以及具体的需求描述，并认可原型设计和解决方案。
需求会议上，产品经理需要跟大家明确需要解决的痛点问题，有哪些功能以及对应的计划，然后大家在会议上挑刺，讨论，甚至是撕逼，最终全体成员达成一致意见后开始开干，通常一些项目需求都是要经过几次评审会才能完成的。
在缺乏预先沟通和决策制度的情况下，这种评审产品可能是及其混乱的。争论的焦点到最后几乎都会变成三观问题：谁能代表用户？谁说了算？领导意见要不要考虑？
通过评审的需求，通常各方博弈的结果。这其中，有多少属于产品经理能决定的需求就很难说了。
3. 需求讲解
接下来，你需要针对项目组中所有开发同学的一次需求讲解活动。
具体过程如下：
- PM通过用户故事技术给开发人员讲解需求；
- 开发人员评论需求是否合理，完善；
- 开发人员评估方案和工作量。
这里面当然少不了讨价还价，各种掰扯。这也容易理解，需求文档几页纸可能是开发几十人月的工作量，可谓一发而动全身，这也为什么是开发的小伙伴会把“需求放在火上烤”的原因。
在职场鄙视链中，产品经理在开发小伙伴中眼中怎么看都是“站着说活不腰疼”的主。说到底无非是屁沟决定脑袋，很多产品经理也是技术出生，当他们站在产品经理岗位上时，就能体会各自视角的差异。
4. 需求变更
在开发过程中，会存在对正在开发 的增加新的需求的情况，也就是需求变更，如客户提出希望在CRM软件中增加访客识别功能。
需求变更的原因既有遗漏的情况，又有各种“xx领导”意见。许多公司需求评审制度并不完善，存在会上不谈会下谈，不是领导意见不关心等现象，导致需求评审阶段过后才发现需求遗漏。
总结一下需求管理的整个过程：产品经理首先通过引导收集需求，然后通过需求评审确定需求的优先级，然后给通过讲故事的方式给开发人员讲解需求，然后在产品发布后管理需求变更。
自始至终，产品经理都只是需求的管理员和委托人，而非需求的创造者。
五、不是一个人在战斗“胜则举杯相庆，败则拼死相救”，在华为众多文化中，这是很重要的一条，也激励着无数华为儿女。
产品的成功是个系统工程，产品经理虽然顶着一个产品“责任人”的头衔，但仍然只是团队中的一个成员。产品的成功离不开研发、运营和市场销售部门紧密配合和相互协作。如果产品失败了，作为产品的“责任人”，产品经理是则无旁贷的。
产品经理也会犯错误，也需要成长。产品经理并不害怕责任，而是害怕得不到队友支持，所以当我们抗起责任，摔得土头土脸的时候，希望归来依然少年，我们还可以相约再战。
作者：涛哥，涛哥笔谈。前华为高级产品经理，TOGAF认证专家，PMP认证专家，PPV课数据科学社区创始人，数字化转型实践者
本文由 @涛哥 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
