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

起初大家都統稱為“產品經理”，后來進一步分成了app產品經理、網頁產品經理、后端產品經理、桌面軟件產品經理。

到了現在，分得就更細了，可以結合類型（如社交、游戲、電商、金融），可結合模塊（如消息推送、支付、訂單等），也可以結合業務（招聘網站上常常出現XX業務產品經理）。

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

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

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

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

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

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

在此把它概括成七步：面臨的問題是什么（只能有一個）？問題的背景是什么，利益相關方有哪些？導致問題出現的原因是什么？用什么方法可以解決問題？目前欠缺什么資源和條件？如何搞定資源？怎樣進行任務排序，時間規劃如何？以下結合案例來說明（純屬虛構）。

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

時間是周五下午3點，S在wiki上寫完周報。

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

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

T：老板剛剛組織了一個電話會議，要求下周一上線一個預約活動，運營部門已經制定好活動規則，現在開始協調庫存。

你出一個產品方案，找研發協調人力，明天加班趕一下，下周一晚上就上線。

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

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

如果S是老鳥，她可能會這樣思考：為什么要做這個項目？今天是周五，雖然老板不靠譜（員工多少會有這種想法），但是現在人力超負荷的情況他是知道的。

而且開發中的項目也是一個大型活動，早就規劃好了，是不論如何都不能延期的，在這種情況下還有新增一個活動，是出于什么考慮呢？運營制定好活動規則一般會先同步給PM，為什么這次跳過PM直接匯報到老板那？運營方案才通過就開始協調庫存，這個節奏也不正常，是什么原因需要做的這么匆忙？S：我們做這個項目要達到什么目的和目標呢？T：老板聽說對手Q想要做一個與我們對標的活動，而且有可能先于我們上線，所以緊急批了預算并且找運營新加了預約的活動，目的是狙擊對手和給大型活動預熱，并沒有具體的目標。

到這里，情況相對比較清晰了，S分析目前的情況：有一個高優先級的項目緊急插入；（不用協調也知道）RD資源不足，可能會顧此失彼；以現在的資源情況，不能完全開發好活動并且按時上線。

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

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

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

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

這樣問題就明確了。

第二步：分析背景和利益相關方外部背景：Q是公司的死對頭，在過去幾個月一直打得不分上下，一方有動靜另一方馬上跟進。

現在S的公司稍占上風，目前集中全公司的力量都在設法保證優勢能持續下去。

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

利益相關：老板和上級自不用說，這個項目必須要能在他們預期的時間上線；運營方面需要盡快去了解他們的活動規則是什么，這樣才能出方案；研發方面，研發leader已經知道情況，表示后端人力都在項目上，前端有一個人力可以支持；既然做活動，肯定需要UI的支持，雖然她們在項目上，但是調整一下優先級是OK的。

第三步：分析產生問題的原因這一點上面已經說過，是因為時間和資源沒有什么調整空間，但是還要盡量保證質量。

第四步：用演繹法列舉出所有可能的解決辦法用歸納法得出每個解決辦法的優點和缺點。

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

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

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

第五步：分析現在還欠缺的資源和條件假設S和上司、老板、運營都溝通完畢，確定了選擇第三套方案。

現在S需要需求文檔、前端、UI、QA資源，還需要使用公司統一的外部表單賬號，所有這些到現在為止都沒有確定。

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

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

第七步：要做的事情清楚了S羅列出先后順序（創業公司的節奏）。

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

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

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

拆解的能力非常考驗PM的功力，也是很多招聘者在面試中喜歡考的問題。

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