李獨思

這種問題的好與不好，是我們未開始嘗試之前就能下判斷的嗎？如果真的是這樣，讓他們做產品經理就好了，因為他們判斷是準確的。

現實中很多事情並不是非黑即白的，而是在迭代中探討出更好的解決方案。

對於絕大多數公司和行業，所謂的「研發」，是在探討「組合創新」，而不是「發明創新」。再細緻一點說，就是應用創新，我們不需要重複做輪子，直接拿別人做好的應用，服務，介面來實現我們希望提供的獨特服務。

組合創新看起來比較簡單，因為市場上你能看到的，別人也能看到。但實際上不容易，因為組合並非隨機排列的盲人摸象，而是根據當下的社會環境洞察後的優選。

舉個極端點的例子。

共享充電寶，這種產品的原理背後的邏輯很簡單，大家都看得到，本質上是電池技術這麼多年一直難以突破，而人們用手機等移動裝置的需求極大的增加，造成了充電寶的需求。

一旦電池技術或者充電技術突破了，共享充電寶的需求就很自然的消減。當年王思聰懟陳歐說這事能成他吃翔，判斷基礎也是如此。

現在商業活得下來的邏輯其實沒有變，電池技術還是未能突破，快充是很快，但是需要線和插頭配合。使用者的使用環境幾乎沒有大的變化，很多時候還是容易忘記帶充電寶，或者覺得帶充電寶太重，商鋪裡的共享充電寶成為一種預設的服務。

但幾年前的多數人只能看到的是：這種方案看著要死，為什麼還要做？大家唯一看漏的，就是「一旦電池技術突破」，這過去了四五年，還沒有到來，類似的商業故事經常能看到。

我對共享充電寶的看法跟大家一樣，長期來看生存空間比較少，但我一直對「一旦」這種先置條件保持敬畏，如果我是在共享充電寶的公司，挖掘需求還是一樣義無反顧。

舉這個例子，就是為了說明這些好像所有人都能判斷的產品，有些時候表現出來是反大眾常識的。

需要回答的有兩個問題，一是“解決方案不好為什麼還要做”，二是“別人提出質疑”該如何規避。

對於“解決方案不好為什麼還要做”這個問題，我們必須要明白：這個世界上不存在完美的產品。哪怕是神級的產品經理，他們提出的解決方案也會被無數人噴。只要在知乎搜一下，我們就能看到無數人對微信和iPhone提出意見。可這些解決方案，還是做了，而且在市場上獲得了成功。

可以這麼說：不好的解決方案，還是有可能給公司賺錢並滿足使用者需求的，所以要做。

但僅僅是這樣回答就有點不負責任了，畢竟不是每個方案的預期都好，都值得去冒險。我們需要結合自身條件和市場環境等因素，判斷出什麼樣的方案更具有落地的價值。

一般來講，對於初創企業，或剛剛準備創業的團隊來說，需要的是驗證市場。這個階段的產品方案通常是非常簡單，甚至非常簡陋的。這個時間點去嘗試把產品做的足夠完美，通常只是在浪費團隊的資源。

在使用最初的產品驗證過需求後，要麼發現沒啥需求，團隊開始轉換方向，要麼驗證出需求夠強市場夠大，開始打磨產品，為下一步融資或推廣打基礎。

到了使用者爆發期，解決方案最少也要做到及格線以上，儘可能的去接近“完美”，把不可靠和不可控的方案在腦暴、宣講、開發、測試、灰度等幾個階段儘可能的規避掉。

對於一個合格的產品經理，只要他心裡有譜，哪怕是不及格的垃圾解決方案也會有它的用處。對於大多數創業公司來說，搶佔市場和打磨產品（或者說打磨產品方案）總是會搶奪資源。怎麼去掌握這種平衡不僅僅是老闆的事情，產品經理也應該在裡面起到應有的作用，並最終根據資源量去產出不同層次的解決方案。

那麼“別人提出的質疑”該如何規避呢？非常遺憾，這些質疑是無法規避的。

任何解決方案都可能落地撲街，只要有這種可能性，質疑就會接踵而來。我們只能一次次的直面、PK，儘可能的減少那些影響你決策的質疑。

對於來自老闆的質疑，我們要先明白，老闆通常會掌握比你更多的資訊。這種情況下產品經理應該儘可能的去get老闆內心中真正想表達的那個點，這也是一次挖掘需求的過程。當你瞭解到老闆心中想要的東西，並結合著去給出解決方案後，通常他就不再會質疑了。

但總會有一些例外，比如老闆的水平太低。這種情況其實非常常見，尤其是在那些特別小的創業公司。我曾見過一個老闆不管他的屬下提出什麼方案，他總是要質疑，質疑的細節到了圓角尖角、按鈕大小的程度。而他的理由竟然是：“不這樣說說他他該不好好做了。”

對於這種情況，我建議你考慮下換個老闆。

更常見的是來自開發人員的質疑。事實上願意質疑你的開發，都是優秀負責的開發。我見過太多的開發啥也不問就說懂了，一通胡寫上不了線，最後甩鍋產品垃圾。這種情況下產品經理確實要負很大的責任，但這樣的開發對公司和團隊無疑是沒有責任心的。

提出質疑的開發通常會有兩類，一類是質疑技術問題。這種情況最好虛心一些，態度好一些。在你掉坑前拉你一把的都是好同事。還有一類則是出自產品角度或業務角度去質疑。對這種質疑無需害怕，只要你能就事論事的討論，和大家講明白你的判斷依據和設計目的，通常都能化解掉。

當然還有一些產品經理遇到開發質疑是由於和開發相處的不好。這種情況我遇到的不多，就先不贅述了。

最後是來自同行的質疑。這類質疑通常沒啥意義，畢竟他不負責你在做的這款產品，而且每個人的能力、能調動的資源、每個企業所佔據的市場都不一樣。但如果你的產品經驗很少，最好還是多參考一下，有則改之，無則加勉。這樣能更快的提升自己。

而所有的質疑都有一些共性的原因，這些原因多在產品經理自己。

很多新人被質疑是因為沒能展現出自己的專業性。展現專業性有兩層，首先是你確實要有專業性，其次是把他們展現出來。展現專業性要靠你和不同質疑者一次次的PK，只有在PK中持續讓對方心腹口服，才能讓他們不再質疑。

再比如產品方向不明確也會帶來大量的質疑。當然這中間有一部分原因是老闆亂改方向，這種情況可以考慮換個老闆。但如果產品方向基本明確，產品經理應該產出一份符合邏輯的產品路線圖，並持續推動老闆確認和迭代。產品路線圖能給團隊方向感和信心，進而減少質疑。

我曾經在國家機關呆過7年的時間，後面辭職跑業務，再後來辦過廠，現在的經理的概念很模糊，或者說外延太大了，現在就假設你是產品銷售經理，下面有3-5個業務員。我自個的經驗是，水至清則無魚，任何一個制度總是有漏洞的，作為一個領導，要學會平衡，同時也要有業績的進步，記得90年代一部電影林則徐，大致是說，裡面有個副官（或許是幕僚）對林則徐說，還有很多貪官汙吏，林則徐說，我知道，但是你要我把他們都殺完嗎？殺完了，去哪裡馬上找人來禁菸，禁菸已經刻不容緩了。講的就是這個道理，水那麼清，魚都沒有的吃了，還不跑完？

以上是總的方針策略，下面跟你說說具體的問題，1，嚴格把控產品的質量，這個沒話說的，現在的老百姓或者客戶不是錢的問題，因為他們都懂一分貨一分錢，（一分錢不一定是一分貨，但是一分貨起碼要你一分錢），所以產品的質量是非常重要的，這就給你源源不斷的開拓客戶打下了良好的基礎，反之，你的客戶只能越來越少。

2。給下屬靈活的上班時間，因為他面對的客戶如果是老闆的話，經常睡覺到中午才起來的，那麼你的下屬還是朝九晚五的話，他的效率必然會很低很低。那樣你也就沒有業績了。

3.給你的下屬一定的許可權，假設你沒有的產品，而客戶需要你的下屬幫忙找你沒有的產品，在不衝突的情況下，你不要干涉你的下屬，因為客戶已經認可你下屬這個人了，而不是認可你或者你的公司，讓下屬也有點掙外快，或者不掙外快都好，可以增加信任度，而不是一味的干涉。

4，獎勵懲罰制度要公開，公正，透明，假設你的下屬完成了你的目標任務，你一定要兌現承諾，哪怕你怎麼困難，哪怕是公司的老總有藉口不允許，哪怕是你掏錢，你都要獎勵他，如果是你的下屬受罰了，那麼你一定要嚴格的執行，執行完以後，要安撫，假設你的下屬因為各種原因，導致被罰款1000元，那麼你自己貼個3-500，一定要安撫好，但是同時告訴他，下不為例。同時在生活上，多點關心，傾聽下屬的生活工作的各種問題，哪怕是嘮叨。

5.一定要拜訪下屬的重點客戶，傾聽客戶對下屬的評價，對產品的評價，順便問一句客戶，有些你需要的東西，但是我們沒有，你看是否需要幫忙或許介紹個朋友給你認識，這句話就可以從客戶那裡找到下屬做的工作是否與本質工作有衝突的地方了。

6.另外一個

因素就是多做市場調查，這種調查統計是很有必要的，對同類競爭的對手產品的價格質量樣式銷售情況進行統計對比，逆水行舟，不進則退，這樣子你才會在市場上處於不敗之地。

7.如果你的企業足夠大，聘請一個常年的法律顧問，防範於未然，總比亡羊補牢好。

一、出現問題

在《軟體工程》中提到一個專業化的軟體的四個特性中，可依賴性和安全性居於首位。

軟體的穩定是保證業務運轉的基石，但是總有業務阻斷的風險。如電商平臺，交易系統等半分鐘的宕機就會造成巨大的損失。

筆者遇到的業務異常的情況分為以下幾種：

交易系統業務全部阻斷，查詢，下單，支付等功能全部崩潰；產線業務整體正常，總有個別產品異常。

1. 第一種情況

對於一個產品汪來說，這無疑是從睡眼朦朧到瞬間清醒的狀態，立刻做好背鍋的準備。

常人的第一反應是系統宕機崩潰。但是，從產品汪的角度，還應該考慮，是否是新上線的功能未測試完全導致對原有功能的影響，亦或者是臨時動了哪個配置引數，導致產品邏輯變化。出現這種情況，肯定是以最快的速度修復系統問題和或者是還原產品配置。

2. 第二種情況

產線整體業務正常，個別產品由於軟體問題，產生異常，這種時候產品經理就要作為一個偵探的角色去還原場景，梳理流程，整體分析此異常出現的原因及修復合理性。

下面就第二種情況作個淺談。

二、業務診斷

業務診斷能力，貫穿所有B端產品的設計，運營，管理等。

不管系統新增需求還是迭代最佳化，業務診斷是一個產品經理抽象問題的基礎。

全面的業務診斷，抽象出問題，最終提供一個合理有效的產品解決方案；為企業提升運轉效率，經營管理輔助，是一個好的B端產品的價值所在。

當出現業務異常時候，我們應該怎麼診斷問題呢？

我們可以從下面兩個步驟來分析：

1. 業務背景調研

1）理解當前業務“目標”

業務背景調研的第一步，理解當前業務目標：這部分業務要實現一個怎麼樣的訴求，此業務問題出現在整個業務流轉中的哪個節點，這個節點的目標是什麼？

換句話說就是迴歸初心。

舉個例子：

簡訊運營商經常會給使用者傳送簡訊提醒使用者流量使用情況，目的是為了告知使用者剩餘流量，提示使用者，防止使用者在不知情的情況下流量用超。

此簡訊業務的目標便是告知使用者簡訊使用情況，剩下的流量酌情使用，中國移動在發簡訊的時候，簡訊內容顯示了還剩多少MB的流量可使用。

對於使用者來講，平時使用APP或者上網，流量用多少是不知道的，使用者只知道每個月大概會用多少流量，並不容易知道剩下的這些（比如23643MB）流量會用多久。

相比中國移動，中國聯通在傳送簡訊時，加了一句“剩下XX%流量”可使用，這樣不僅直觀，而且達到了傳送簡訊的業務目標。

2）梳理當前業務的“操作流程”

這一點是最坑爹的，有些問題本質上是流程問題，而不是軟體的設計或者BUG。

業務流程涉及到多個業務角色操作，這一步我們應該梳理出當前各業務方現有的操作流程。

3）梳理當前業務“正確”的“產品邏輯”

為了實現以上的目標，梳理原有業務邏輯，和產品設計的“正確”流程。

這裡的正確流程不是指絕對正確，是指基於此目的，原有產品邏輯的設計。這個設計現在可能看來不合理，但是因為需要快速上線等各種原因而被一直沿用，此時暴露出了問題，而此刻我們需要理清這個邏輯。

4）分析原有邏輯與業務目標的匹配度

在理清了現有產品邏輯之後，既然業務能正常運轉肯定有它的穩定之處。但是也出現了瑕疵，說明當前產品設計不是最完美的解決方案，存在漏洞。

基於此，我們下面進一步分析。

2. 問題分析維度

1）從使用者場景進行分析

使用者場景在和研發梳理需求的時候，是一種溝通工具，而在分析問題或者產品設計的時候，更是一種思維工具。

產品經理應該設身處地把自己當成一線業務員，或者直接到一線觀看操作業務的流程；某些問題可能並不是因為軟體問題，是業務流程的問題。

對業務員來說，他會透過最方便但可能不是正確的操作流程來達到他的目的，造成這種情況的原因可能是業務員對這個業務的理解脫節，只關注到了他的節點業務，也可能是業務培訓不到位造成。

當產品經理走了一遍全流程，或者進入一線使用者場景調研分析後，便不會容易出現想當然的分析結果。

2）從使用者角色進行分析

分析業務流程中相關的角色，各個角色對應的需求，他要實現的業務目標。

區別於整體業務目標，這裡的目標是角色目標，對應崗位上的職責則不同。

3）分析使用者角色之間的協同關係

產品最佳化方面來說，基於各個角色的業務目標分析，瞭解他們的訴求之後，在這個角色之間要實現一種協同平衡，實現業務穩定，效率提升，考慮該業務目標的主要受益方是誰，業務需求契合度最高的一方，此時最佳化方案應該偏向該角色。

對於問題查詢來說，可能各個業務角色之間的協同流程都有問題，而不是軟體本身的問題，規範流程，或許會豁然開朗。

這裡筆者想起一個例子：

一個產品經理，手上有個正在開發的緊急專案，當到最後一天專案計劃要完成開發工作的時候，產品經理發現有個研發所開發的模組還沒開發完，專案整體出現延期風險。

研發給出的理由是總經理臨時讓他改一個其他專案的緊急需求，兩邊都是緊急專案，這個研發選擇了先做領導總經理的專案。

這個產品經理氣的不行，和研發吵了起來，去找老闆理論；老闆讓這個產品經理分析哪裡出了問題。

產品經理說總經理不懂先來後到，不知道研發手上有緊急的專案。

老闆說，總經理和研發都沒有錯，站在研發的角度，迫於領導的壓力，先做領導的專案；站在總經理的角度，手上的專案確實緊急。

那到底是哪裡出了問題？下次遇到同樣場景豈不是還是會出現這種衝突？

老闆說，是流程出現了問題。

如果在流程上規避了此種風險，出現臨時資源排程的情況，根據提前制定出的流程，當出現這種情況時，申請走相應的流程，需要各部門稽核，這樣就可以提前獲得各方支援協調，而不至於出現專案延期。

現在說來，與其說是流程，不如說是規範，各業務方按照統一規範協同合作。

三、解決方案 1. 問題深度和廣度判斷

不管是業務異常問題，還是產品最佳化，都需要判斷其是否有改進及迭代的價值。

透過影響的深度和廣度來判斷，深度即出現該業務異常後對整體生產的影響；廣度及出現的頻率和機率等。

而最佳化即是對此問題作出改進後，是否會對原業務穩定性，效率有提升。判斷的依據最好可以量化。

2. 考慮最快替代方案

在《軟體工程》理論中提到，任何系統，進行更新最佳化成本都是巨大的。

首先應該想到的是在原有基礎上進行復用：其一是從業務的操作流程上進行最佳化；其二是從現有系統功能中使用其他功能方式替代。

這種方式不僅成本最低，也是最穩定及快速解決問題的最優方式。

3. 重新開發，成本和可行性分析

如果是需要最佳化該業務流程或者解決業務異常，需從產品角度重新進行可行性分析及規劃。

作為一名混跡網際網路四年多的產品狗來說，來回答這個問題是再合適不過了，不知題主是否和我一樣也是同行呢？行業內流傳有一句名言：產品=背鍋俠。可想而知，我們所面臨的生存環境是多麼複雜和兇險，系統任何環節出了問題，都能夠和產品掛上鉤，為什麼？因我產品是整個產品或者需求的源頭，火車頭差一毫釐，那做出來的東西就可能差之千里。作為一個踩過無數坑，背過無數鍋的產品狗，結合自己的心路歷程，來分享一下，我們該如何儘可能多的考慮異常情況，少埋一些坑，少踩一些雷～第一、熟悉系統功能/模組無論你是剛入職的新產品，還是在公司待了很久的老產品，熟悉自己所負責的系統功能，是最基本的要求。通常來說，一個系統集成了很多模組的功能，就拿訂單系統來說，有抓單模組、配貨模組、發貨模組等等。每個模組所承載的核心功能都不一樣，但每個模組之間的資料互動又都是耦合的。如果，你不熟悉各個模組之間的功能，很可能在改動一個小小的需求時，影響到其他的功能，正所謂牽一髮而動全身。如此，可能對業務的影響就非常大了~通常，半夜的時候一定會有人call你。而且，只有在熟悉了各個模組的功能，才能站在系統的角度給業務提供最好的方案，不斷健壯你產品的服務和功能第二、熟悉業務如果說把產品思維比作骨架的話，那業務思維就是流動的血液。一個不懂業務的產品，一定是走不遠，爬不高的，因為我們所做的任何形式的產品功能和服務，都是為了幫助業務成功。也就是說，要真正解決使用者的痛點，而不能為了做功能而做功能。那麼，我們該如果熟悉業務呢？首先，我們要理清楚業務的主幹線，就拿訂單來說，從支付-成單-抓單-配貨-發貨-再到wms揀貨/分拈出庫-最後到TMS運輸；其次，我們要理清楚，每個關鍵節點，所涉及到的分支業務流和資料流，比如，在支付的時候，我們要按照不同的支付渠道去呼叫支付的服務，校驗使用者的風控安全性，支付完成的瞬間根據不同的場景是否要呼叫拆單引擎，還要校驗庫存等等；最後，我們還要考慮各種可能發生的異常情況，比如，呼叫支付失敗怎麼提示？使用者餘額不足怎麼處理？庫存不足要怎麼引導使用者？萬一介面呼叫失敗，資料異常怎樣記錄跟蹤等等。業務線是應用層的表現，而資料流是底層服務的支撐。每一個數據從哪兒來，到哪兒去？正常怎麼走，異常怎麼處理？這些都是要產品經理在非常熟悉業務的情況下，集合自己的專業去梳理出來的功能。第三、學習學習學習

重要的事情說三遍，不斷學習是一個產品經理完善自己我，避免踩坑，成為職場老司機的唯一途徑。那麼，我們要向誰學習呢？一般來說，我們學習的途徑分為三個方面。

一、向身邊優秀的產品經理學習。聽他們的評審會，看他們的需求文件和流程圖，看他們是如何在關鍵節點考慮異常的情況，看他們是如何考慮不同場景下的使用者需求，看他們是如何處理不同請求下的資料互動；

二、向自己開發、測試學習。為什麼？他們是我們的下游，開發思維在處理資料流時會經常來問你很多異常場景的功能該怎麼設計，也會考慮到很多我們在產品層面疏忽的問題，而測試更是我們要好好學習的物件，他們不僅僅只是疏通業務，更重要的是他們在業務流程層面加了資料驗證和校驗，一般我們產品很容易疏忽資料層面的異常情況，比如資料輸入框輸入了文字要怎麼提示？是允許還是報錯？等等很多的問題

既然我們決心成為一名合格的產品經理，那在這條曲折的道路上踩坑肯定是無法避免的，也是合情合理的。而作為一個產品既要大膽假設，也要小心求證，不拘一格才能有所創新，科學實踐才能有所產出。從我的個人經驗來說，要儘可能多的考慮異常情況，我們要做到即熟悉系統功能，又要熟悉業務，更要堅持學習、反思總結。『用心打磨，野蠻生長』送給每一個真正在從事產品經理，或即將從事產品經理的同學，我們的夢想就是：改變世界！哈哈哈~

需要注意的

永遠沒有完美的答案，很多問題消耗太多精力不值得。再好的答案也要有合適的呈現方式，給秦始皇看英文版的史記他會發飆的。相關的邏輯很可能解決問題，也可能搞砸了問題。抓住問題的本質很重要，很多貌似完全和問題不相關的東西才是本質，這是最要命的。不要鑽牛角尖，不要完全信任任何一種已知理論，不要完全相信自己，要敢於懷疑權威，專業人士，自己已知的知識和現有經驗。切勿眼高手低。答案完成後，驗證是否可靠，是否可以依據此答案進一步提煉生活。一些問題解決後，答案往往對思想有重大的影響。和其他人討論問題的時候，一定要找準位置，不要兩個人話題跑偏。思考問題前一定要吃飯……不然會沒力氣思考。

現在好多單位都有自己書面的各種應急預案，作為企業來說，更應該做在前面，因為企業員工跳槽更是家常便飯，所以作為企業的經理或是主管，要給自己或是企業留後手，後續的應對措施，防止人員，人才的流失。平時要和員工多交流溝通，瞭解員工的想法，對單位的各種評價等等，不斷的出臺各種措施推動企業良性發展，只有這樣，才能留得住員工，退一萬步說，即使出現了員工離職潮，企業不至於驚慌失措，而有自己的後續應對措施。