產品經理，職場上的“背鍋俠”。一個產品失敗了，產品經理要不要承擔責任？本文將從五個角度對這個問題進行分析，希望對你有幫助。

近期某招聘網站有個話題引起大家熱議，就是“產品失敗了，產品經理要不要承擔責任？”。在這里分享一下我的觀點。

首先澄清幾個概念：

一、負責人和責任人

“負責人”與“責任人”主要有權力、單位職務的區(qū)別：

• 兩者權力的不同，負責人是指在規(guī)定的一定范圍內，該人既有管理權，同時又要承擔責任。而責任人沒有管理權，只承擔責任。
• 兩者在工作單位職務的不同， 一般來說負責人應該是領導者，而責任人則是工作人員。

負責人是對這個事情兜底的人，也就失敗的原因和他有沒有關系，他都要承擔責任，一般是管理者或者公司法人。

責任人沒有管理責任，他相當于負責人的委托人，處理一般事務。如果出現問題，他是要承擔責任的。

在大部分企業(yè)，產品經理都沒有管理權，不是兜底的負責人，而只是執(zhí)行層面的責任人。

作為責任人，如果產品失敗，從職責上講，產品經理一定是有責任的，區(qū)別只是責任大小的問題。

二、如何界定產品的失??？

界定產品的失敗沒有嚴格的標準，可以參考的標準包括：

1. 度量指標未達標

指業(yè)務度量指標如銷售額、活躍用戶數、NPS、轉化率等未達到預期。

這些指標是在需求識別階段和利益相關者確認，并作為需求的一部分寫入產品需求說明文檔中，可以認為是IT部門對投資人的承諾。

如Spuersell這家公司對旗下游戲產品的上市就相當嚴苛，百萬級的營收都可能作為失敗的產品被下架和“埋葬”掉。

2. 用戶不滿意

指用戶在使用產品中存在貨不對版(不符合SLA)、質量缺陷、用戶體驗差等情況。

3. 不合規(guī)

指產品存在不符合國家標準、行業(yè)標準、監(jiān)管要求、政策要求或者法律要求。如食品企業(yè)有食品安全國家標準，保險、金融行業(yè)有合規(guī)要求。

三、如何界定產品經理的責任？

一般情況下，和需求有關的問題，產品經理都是主要責任人。上述第三種情況就屬于需求問題，是典型的需求遺漏。

再舉個需求遺漏的例子：在校園市場，國家2018年頒布了《中小學數字校園建設規(guī)范（試行）》，如果產品經理未能識別到這些監(jiān)管性的規(guī)范要求，會導致產品無法獲得市場準入等重大問題。

和用戶體驗相關的問題，通常是由產品經理和UX（UI/UCD/UED）共同負責。

用戶體驗的例子：某企業(yè)為城市的環(huán)衛(wèi)工程承包商開發(fā)了一款智能手環(huán)，手環(huán)的目的是對環(huán)衛(wèi)工的工作位置進行定位，從而實現軌跡跟蹤、調度等管理功能。但產品發(fā)布后，手環(huán)因為攜帶不方便、電源續(xù)航時間短、員工擔心隱私泄露等問題遭到用戶不滿，最終導致產品使用率低而最終未能量產。

除了需求和用戶體驗以外，其它情況都要具體分析。如業(yè)務指標的實現是需要研發(fā)、產品、運營、市場銷售部門一起完成的，每個部門都要承擔分解后的考核指標。如果出現問題，應該由負責治理的委員會進行問題回溯，確定責任主體和相關責任人。

四、需求是產品經理“創(chuàng)造”的嗎？

很多人對產品經理有個誤解，就是認為是產品經理創(chuàng)造了需求，進而創(chuàng)造了產品。所以如果是產品出了問題，就是產品經理的責任，實際情況是否如此呢？

那么我們就來看下需求是怎么一步步導入到產品中的。

1. 需求收集

先看需求的來源，產品的需求無外乎來自這么幾個領域：

• 客戶
• End User
• 利益相關者
• 監(jiān)管部門要求
• 行業(yè)標準和規(guī)范
• 企業(yè)標準和規(guī)范

需求收集是一個類似“挖礦”的過程，我要先識別“礦源”再通過工具的方式將需求“挖掘”出來，尤其是那些客戶未直接表達的隱形需求。

在BABOK指南中需求收集的英文一詞是Elicitation，翻譯過來是導出或者引出的意思，也就是說，需求是已經存在的，產品經理只是把它找出來而已。

產品經理會采用訪談、頭腦風暴、worshop技術，通過傾聽、觀察、溝通、潛意識流動等方法將隱藏在用戶心中的需求“引導”出來。

在需求產生的過程中，產品經理是“助產士”而不是需求的“爸媽”。

那么有沒有創(chuàng)造性的產品需求呢？當然有了，否則人類不會有汽車、飛機這些產品了。喬布斯的蘋果手機、張小龍的微信、埃隆馬斯克的可往返商用飛船都是創(chuàng)造性的產品。但并非所有產品經理都有這樣的機會可以不考慮任何資源限制來設計一款產品，也并非所有產品經理都有喬幫主這樣天才級的想象力。

以用戶為中心，應用設計思維和精益思維的方法論，通過各種方法和工具把用戶腦子里面的需求引導出來并轉化為解決方案才是大部分產品經理的常態(tài)化工作。

用一個不恰當的比喻，也可以說：產品經理不生產“需求”，只是需求的“搬運工”。

2. 需求優(yōu)先級排序

收集的需求會匯總在一個需求匯總表中。這時候需要一個需求評審以確定需求的優(yōu)先級并制定產品路線圖。

需求評審是產品經理的第一關。

需求評審的目的是讓利益相關者（開發(fā)、設計、測試、運營、老板等）理解需求背景、需求目的以及具體的需求描述，并認可原型設計和解決方案。

需求會議上，產品經理需要跟大家明確需要解決的痛點問題，有哪些功能以及對應的計劃，然后大家在會議上挑刺，討論，甚至是撕逼，最終全體成員達成一致意見后開始開干，通常一些項目需求都是要經過幾次評審會才能完成的。

在缺乏預先溝通和決策制度的情況下，這種評審產品可能是及其混亂的。爭論的焦點到最后幾乎都會變成三觀問題：誰能代表用戶？誰說了算？領導意見要不要考慮？

通過評審的需求，通常各方博弈的結果。這其中，有多少屬于產品經理能決定的需求就很難說了。

3. 需求講解

接下來，你需要針對項目組中所有開發(fā)同學的一次需求講解活動。

具體過程如下：

• PM通過用戶故事技術給開發(fā)人員講解需求；
• 開發(fā)人員評論需求是否合理，完善；
• 開發(fā)人員評估方案和工作量。

這里面當然少不了討價還價，各種掰扯。這也容易理解，需求文檔幾頁紙可能是開發(fā)幾十人月的工作量，可謂一發(fā)而動全身，這也為什么是開發(fā)的小伙伴會把“需求放在火上烤”的原因。

在職場鄙視鏈中，產品經理在開發(fā)小伙伴中眼中怎么看都是“站著說活不腰疼”的主。說到底無非是屁溝決定腦袋，很多產品經理也是技術出生，當他們站在產品經理崗位上時，就能體會各自視角的差異。

4. 需求變更

在開發(fā)過程中，會存在對正在開發(fā) 的增加新的需求的情況，也就是需求變更，如客戶提出希望在CRM軟件中增加訪客識別功能。

需求變更的原因既有遺漏的情況，又有各種“xx領導”意見。許多公司需求評審制度并不完善，存在會上不談會下談，不是領導意見不關心等現象，導致需求評審階段過后才發(fā)現需求遺漏。

總結一下需求管理的整個過程：產品經理首先通過引導收集需求，然后通過需求評審確定需求的優(yōu)先級，然后給通過講故事的方式給開發(fā)人員講解需求，然后在產品發(fā)布后管理需求變更。

自始至終，產品經理都只是需求的管理員和委托人，而非需求的創(chuàng)造者。

五、不是一個人在戰(zhàn)斗

“勝則舉杯相慶，敗則拼死相救”，在華為眾多文化中，這是很重要的一條，也激勵著無數華為兒女。

產品的成功是個系統(tǒng)工程，產品經理雖然頂著一個產品“責任人”的頭銜，但仍然只是團隊中的一個成員。產品的成功離不開研發(fā)、運營和市場銷售部門緊密配合和相互協(xié)作。如果產品失敗了，作為產品的“責任人”，產品經理是則無旁貸的。

產品經理也會犯錯誤，也需要成長。產品經理并不害怕責任，而是害怕得不到隊友支持，所以當我們抗起責任，摔得土頭土臉的時候，希望歸來依然少年，我們還可以相約再戰(zhàn)。

作者：濤哥，微信公眾號：濤哥筆談。前華為高級產品經理，TOGAF認證專家，PMP認證專家，PPV課數據科學社區(qū)創(chuàng)始人，數字化轉型實踐者

本文由 @濤哥 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議