產品經理的堅持與妥協

最近團隊成員的口頭禪變成了“我太難了”。

身為產品狗的我們還是比較有發言權的，經常會頂著來自各方的壓力去把事情做成，事情做好了還好，做不好的話，就比較難交代了。

由於職責上承上啟下，在協作的過程中，經常需要遊走於各方之間；根據以往的經驗來看，大多數擔心會發生的事情，最終的確發生了，大多數沒強力推動的事情，總歸會卡在哪一環；然而並沒有什麼辦法，除了產品，大多數的職能也確實無需為最終的結果負責。

在推進事情的過程中也總是會有各種狀況，有的時候我們會堅持己見，有的時候我們會由於種種原因而妥協。

本文列舉了幾個高頻的角色，分別是與其他產品，與運營，與開發，與老闆，下面來分別看下。

一、與其他產品

產品之間還算是好溝通，大家就看優先順序和價效比嘛；但這個又分兩種場景，一種是團隊內的，一種是團隊外的。

團隊內的倒還好，本來就比較熟，大家的目標也基本一致，刷個臉，吃個飯，再不行沒有一頓下午茶解決不了的，一頓不行那就兩頓。

團隊外的就不好說了，可能是業務上下游關係，也可能只是求別人合作；如果你們是強勢業務部門，這就比較好過，但如果你們是弱勢業務部分，這就真的比較難了。

跨團隊協作可以分這幾種場景：互利、不損人利己、損人利己。

互利當然是非常理想的情況嘛，大家都好過，但問題在於你這個利對於對方部門而言，是芝麻還是西瓜，不同大小的利，待遇當然不一樣。

不損人利己也是時有發生的，比如需要XX業務部分給提供個介面，或者需要XX部門做一些定製開發；雖然對別人沒啥大的損失，但畢竟是要佔據人力和時間的。

損人利己這種事是最難推的，比如你們需要更大的曝光入口，需要更多的流量；但上級的業務部門需要揹負著點選率和轉化率的指標，一旦放量勢必會導致轉化率下降，這樣別人肯定不願意幫你去做這種事情。

其實大家也都能理解，換個角度，把自己放在對方的位置，可能自己做出來的決策也是類似的。

所以啊，只能儘可能的求同存異，找雙方互利的點；實在不行，只能去求助了，自上而下的去推動這件事情。

二、與運營

大多數時候，運營的目標是以短期目標為導向的，而產品的目標一般是短期目標+長期目標；不能說過完2019年最後一個季度，就不過2020年了，所以有時候難免會出現意見相左的情況。

之前和一個運營小夥伴在一個問題上爭執了很久，當時在制定一個運營策略，我們討論當用戶與商家的利益發生了衝突，這個時候平臺需要偏向於哪一方。

細節記不太清了，當時他認為應該偏向商家，因為我們是從商家手裡拿的提點；我認為應該偏向於使用者，因為有使用者了，商家才能賺到錢，才會留下來，使用者流失最終必然會造成商家的流失，並且舉了美團的一個例子。

當年團購行業對於已下單，未消費的訂單，是一概不退的，這樣平臺上就會沉澱大量的資金，商家平白多了一筆資金，平臺也能有部分資金沉澱，但王興最終決定把這筆錢退給使用者。

支援未消費的訂單退款，看上去是損失了平臺和商家的既得利益，但從長遠看來，未必是一件壞事；假定不支援退款，使用者購買的時候一定會產生顧慮，萬一我有事去不了怎麼辦，還不能退，假定支援退款，使用者就不會有這種顧慮。

現在想想，當時還是比較善良的，因為現在的我發現當時少考慮了一個限制條件，那就是供需關係。

比如同樣是做二手電商平臺，二手書和二手房的邏輯一樣麼，規則應該偏向於使用者還是商家？

個人覺得二手書應該偏向於使用者，二手房應該偏向於商家。

我的邏輯是這樣的，二手書是一個買方市場，使用者有很多選擇，使用者在哪裡商家就會在哪裡，所以平臺需要留住使用者，這樣才能留住商家。

二手房則不一樣，這是一個賣方市場，一個城市二手房的數量是存量市場；總數量就這麼多，同一個小區，你的房源越多，話語權越大，使用者要買只能來你這；所以平臺需要拓展商家，才能留住使用者。

有的時候，運營同學也會提不少需求，有的合理，有的不一定合理，可能是目標不合理，可能是方案不合理，也可能是方案和目標不匹配。

比如運營過來找你說我要用一個XX功能，這個不是現成的麼，你在上面幫我稍微修改一下就好了；但從產品的角度來考慮，這可能只是個一次性的東西，不太適合功能化，而且也不能和原有的業務耦合性太高，上線之後後期的維護成本可能也不小。

這個時候我們能做的就是一起探討一個相對更合理的方案，有的團隊運營話語權比較強，產品決策的範圍比較有限，但也需要能有著自己的堅持。

三、與開發

產品和開發一直是相愛相殺的存在，優秀的開發會幫你考慮很多臨界情況，有的開發就是你說啥做啥，多了也不做。

一般老大難問題就是，這個實現不了，和預期不相符，或者效果不行。

這個實現不了在大多數開發那裡都會遇到這個問題，曾經為了一個想要的效果跟開發掰持了一個多小時。

一般我會問這麼幾個問題，是技術上實現不了，還是我們目前的情況實現不了？

開發一般會balabala。

如果是技術限制，那就比較難了，如果是後者，我會接著問如果我們想實現這種效果的話，或者類似的效果，需要怎麼做，有什麼好的方案嘛？

開發一般會balabala。

這個時候你一般會獲得一些有效的資訊，比如是工期不夠，還是需要XX業務提供支援，或者是需要翻一下歷史的程式碼，按問題去找對應解決的方案就好。

和預期不相符可能有很多種原因，是文件沒寫清楚還是溝通不到位，還是理解有偏差；沒什麼好的辦法，文件寫清楚一些，多溝通，多解答疑問，不要在開發過程中玩失蹤，然後最後蹦出來說這個不是我想要的效果啊。

效果不行，改唄。

按照目前的經驗來看，一般擔心會出問題的，最終很有可能真的會出問題；如果目前來不及改，後續很可能更來不及，然後我們自己也會變成歷史遺留問題的一部分。

開發同學是我們的戰友，多次專案合作之後，在開發心目中的形象決定著後續他們跟你合作的態度；拿出你的專業程度，靠譜一些，多幫他們解決一些問題，尤其是資源和溝通協作方面，你會發現很多最開始你遇到的問題，後面都不是問題。

四、與老闆

這個是肯定繞不過去的問題。

一般會有這麼幾種情況：

• 老闆覺得靠譜，你也覺得靠譜；
• 老闆覺得靠譜，你覺得不靠譜；
• 老闆覺得不靠譜，你覺得靠譜；
• 老闆覺得不靠譜，你也覺得不靠譜。

情況一、四沒啥好說的，覺得靠譜就做，大家都覺得不靠譜就不做，主要分歧點在二和三。

老闆覺得靠譜，你覺得不靠譜；這裡面又有兩種場景，一是經過歷史證明或者嚴密推導過的，這個就是不靠譜，二是你只是覺得不靠譜，而不知道是否真的不靠譜。

如果是前者，那你去找找資料、使用者反饋來佐證你的觀點，看看和老闆是在目標上不一致，是路徑上不一致，還是節奏上不一致；然後再看後續怎麼說服老闆，自己不行就再拉上幾個團隊成員一起。

如果是後者，把你的想法先說出來，有的時候資訊不對稱，視角會不同，看到的問題和方向也會不同。

老闆覺得不靠譜，你覺得靠譜；這就需要你能說服你的老闆，畢竟沒Ta的支援，後續推進，資源協調可能都是問題。

如果屢次都證明你的老闆的決策比你靠譜多了，那你還是老老實實多學點東西吧；如果屢次都證明你的決策比你老闆靠譜多了，那麼恭喜你，你可以考慮當自己的老闆了。

你需要的是對自己、對結果負責，而不是對你的老闆負責；很簡單的問題，你要是決策和行為都是對你的老闆負責，萬一哪天換了個老闆呢？

你已經非常適應現在環境的生存法則，突然把你丟到一個新的環境，你能適應麼，或者說你有能力去一個新的環境麼？

有的時候折騰一個專案真的挺累的，或者需要各路求爺爺告奶奶，或者需要處理各種突發問題，或者需要說服別人按照自己的意願去做事。

結果是好的固然很好，結果不好也會很令人沮喪。

但看到資料上升，看到使用者好的反饋，看到自己被同事和上司認可，那種成就感會讓你覺得之前所做的一切，都是非常值得的。

最後，附贈網際網路生存指南，拿好不謝。

以上就是本文的主要內容，歡迎斧正、指點、拍磚…

#專欄作家#

王家郴 ，公眾號：產品經理從0到1，人人都是產品經理專欄作家，喜歡網球和騎行的產品汪，目前奔走在產品的道路上，漫漫產品路，與君共勉。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自 unsplash，基於 CC0 協議