作者：霹靂

?來源：人人都是產品經理

編輯：善小倩

 

 

互聯網行業發展的這些年，培育了一批又一批產品經理。

 

起初大家都統稱為“產品經理”，后來進一步分成了app產品經理、網頁產品經理、后端產品經理、桌面軟件產品經理。到了現在，分得就更細了，可以結合類型（如社交、游戲、電商、金融），可結合模塊（如消息推送、支付、訂單等），也可以結合業務（招聘網站上常常出現XX業務產品經理）。

 

但是這些都是各個公司根據業務和發展的需求進行的區分，并不能體現出產品經理在能力上本質的差別。

 

甚至，很多所謂的高級產品經理和產品總監也名不副實——不過是在一家公司的一個崗位上的時間久而已，和同行優秀者相比并不具備競爭力。

 

那么，產品經理的競爭力體現在什么地方呢？

 

筆者私以為：產品經理競爭力上的差別，很大的程度上取決于其能否發現問題和解決問題，也就是是否做正確的事和正確地做事，這才是體現思維能力和思維層次的地方。

 

見過不少同行工作了多年還是不具備獨立思考的能力，對于做過的項目還能正常推進，但是一遇到不熟悉的項目就懵逼不知道怎么入手。

 

筆者也經歷過這樣的階段，即使到現在也不能保證項目交到手里、在沒有指導的情況下也能完成。

 

不過，在經歷過多次磨練后小有心得，形成了自己的方法論。

 

在此把它概括成七步：

 

1. 面臨的問題是什么（只能有一個）？

2. 問題的背景是什么，利益相關方有哪些？

3. 導致問題出現的原因是什么？

4. 用什么方法可以解決問題？

5. 目前欠缺什么資源和條件？

6. 如何搞定資源？

7. 怎樣進行任務排序，時間規劃如何？

 

以下結合案例來說明（純屬虛構）。

 

第一步：思考問題是什么？

 

S是活動產品經理，主要對接用戶運營部門，跟進各類活動項目的需求-開發-上線，工作中涉及的系統有運營平臺的活動管理模塊及app端的活動banner位。

 

時間是周五下午3點，S在wiki上寫完周報。雖然為了趕下周上線的排期，RD周六要來公司加班一天，自己作為負責任的PM也要來，但是最近項目進展還比較順利，心情大好。

 

這時上級T在內部通訊工具里@S讓她過去一趟。

 

T：老板剛剛組織了一個電話會議，要求下周一上線一個預約活動，運營部門已經制定好活動規則，現在開始協調庫存。你出一個產品方案，找研發協調人力，明天加班趕一下，下周一晚上就上線。

 

相信多數PM都有經歷過類似的情況，如果S是菜鳥，可能不問三七二十一就按上級吩咐的做了，畢竟有這張免死金牌也能把項目推起來。

 

但是結果不一定盡如人意，在研發超負荷工作的上線關鍵階段，突然插進緊急的新需求，將使兩個項目的質量都受到影響。

 

如果S是老鳥，她可能會這樣思考：為什么要做這個項目？

 

今天是周五，雖然老板不靠譜（員工多少會有這種想法），但是現在人力超負荷的情況他是知道的。

 

而且開發中的項目也是一個大型活動，早就規劃好了，是不論如何都不能延期的，在這種情況下還有新增一個活動，是出于什么考慮呢？

 

運營制定好活動規則一般會先同步給PM，為什么這次跳過PM直接匯報到老板那？運營方案才通過就開始協調庫存，這個節奏也不正常，是什么原因需要做的這么匆忙？

 

S：我們做這個項目要達到什么目的和目標呢？

 

T：老板聽說對手Q想要做一個與我們對標的活動，而且有可能先于我們上線，所以緊急批了預算并且找運營新加了預約的活動，目的是狙擊對手和給大型活動預熱，并沒有具體的目標。

 

到這里，情況相對比較清晰了，S分析目前的情況：

 

1. 有一個高優先級的項目緊急插入；

2. （不用協調也知道）RD資源不足，可能會顧此失彼；

3. 以現在的資源情況，不能完全開發好活動并且按時上線。

 

1是問題嗎？

 

第一感覺好像是，但是類似情況到處都有，而且沒有說明危害性如何，所以這只是問題的表象。

 

2呢，資源不足是問題嗎？

 

有道理，但是在互聯網公司資源不足是常態，沒見哪家公司因為這個原因掛掉的。

 

3才是問題！在項目管理里，時間、質量、成本是“不可能三角”，強行提高其中一個指標都會對其余兩個指標造成影響。

 

現在的情況是要在短時間內以有限的資源完成項目，那么只能犧牲一部分質量。

 

這樣問題就明確了。

 

第二步：分析背景和利益相關方

 

外部背景：

 

Q是公司的死對頭，在過去幾個月一直打得不分上下，一方有動靜另一方馬上跟進?，F在S的公司稍占上風，目前集中全公司的力量都在設法保證優勢能持續下去。

 

內部背景：

 

大家連續幾個星期周六加班，已經有些疲憊，而且早就安排了研發任務，也不可能抽調更多人力投入新任務。

 

利益相關：

 

老板和上級自不用說，這個項目必須要能在他們預期的時間上線；運營方面需要盡快去了解他們的活動規則是什么，這樣才能出方案；

 

研發方面，研發leader已經知道情況，表示后端人力都在項目上，前端有一個人力可以支持；既然做活動，肯定需要UI的支持，雖然她們在項目上，但是調整一下優先級是OK的。

 

第三步：分析產生問題的原因

 

這一點上面已經說過，是因為時間和資源沒有什么調整空間，但是還要盡量保證質量。

 

第四步：用演繹法列舉出所有可能的解決辦法

 

用歸納法得出每個解決辦法的優點和缺點。

 

 

我們假設S有這三種選擇，而且很清楚地知道每個方案的優缺點。

 

實際上，任何一個方案都可能是個好方案，也可能是個錯誤，關鍵是需要根據實際的情況進行拿捏，選擇投入小收益大的方案，這里所說的收益不單是短期的收益而且還是長期的，不單是個人的收益而且是所有利益相關方的。

 

比如：S可以狐假虎威、威逼利誘讓RD同學加班完成項目，但是這種方案不能常用，特別是這樣做對公司沒有帶來什么好處的時候，因為這既傷害了長期利益也傷害的別人的利益。

 

第五步：分析現在還欠缺的資源和條件

 

假設S和上司、老板、運營都溝通完畢，確定了選擇第三套方案?，F在S需要需求文檔、前端、UI、QA資源，還需要使用公司統一的外部表單賬號，所有這些到現在為止都沒有確定。

 

第六步：搞定欠缺的資源

 

需求文檔S自己寫就行，因為是項目組的組織形式，所以前端、UI、QA都掛在一個leader下面，而且他已經得到了新項目的消息，S和這個leader溝通一下方案即可。

 

表單工具的賬號還未注冊，而注冊表單賬號需要使用公司的對外郵箱，郵箱由項目組內的一位同事負責。

 

第七步：要做的事情清楚了

 

S羅列出先后順序（創業公司的節奏）。

 

 

這樣整個方案就出來了，之后按照計劃執行即可。

 

很多情況下，當PM對配合的團隊和流程熟悉后，對于簡單的項目，在無意識中就可以完成思考。

 

但是對于復雜的情況，特別是涉及面廣、牽扯的團隊多、項目流程長、不可控因素多的時候，是很有必要進行方案拆解的。

 

拆解的能力非?？简濸M的功力，也是很多招聘者在面試中喜歡考的問題。

 

而且不止于此，在日常生活中，如果好好培養和運用這一能力，很多問題將迎刃而解，生活效率也將得到提高，這里就不具體舉例了，讀者感興趣的話可以試試。

 

 

— end —