近期在網上看到特別有趣的討論，關于産品經理總是喜歡推倒重做以前同事的産品。是職場潛規則？還是因産品不是自己親生的，就無法給足夠的養育？
作者彙總了一些有趣的討論，分別來自阿裏、京東、騰訊、百度、普通企業的産品經理。發現産品經理其實並不是推翻重建的幕後人，很多是被迫在職場中的理由。下面我們來看看他們的討論話題：
問題描述
當産品經理接手舊的産品的時候，分析過一遍産品後，第一沖動似乎都是推翻重建，爲什麽這種狀況會頻繁的出現呢？
你們在做産品的時候接手舊産品，是改良派還是革命派呢？
YY産品經理
不能這樣說。每個産品人的思維、眼界、嗅覺、執行力都是不一樣的，而同樣，産品的市場體量、承載的公司戰略也不是一成不變的。
剛入行的産品人承受、適應能力比較初級，對不熟悉業務所遇見的不可控因素諸如成本緊缺、檔期較緊這種問題處理能力較弱，情急下最常見的辦法就是題主所說的推翻重建。把問題調整到可視可控範圍內，但往往這樣做會引起其他員工的不滿和部門資源的不協調，上下層執行不一，觀點沒有統一戰線。最後鐵定會拖垮項目進度。
稍微成熟一點的産品人首先在自我要求上會是産品輸出導向，而非進度導向的。換言之，會花比較長時間去了解、再認識産品，調查業務瓶頸，查看用戶反饋，摸清企業戰略和産品的生命周期到了哪一階段，再針對産品出現的問題，分清哪些是産品本身問題，哪些是技術問題，哪些是業務問題。
對于一款産品來說，業務問題是最先需要解決的，因爲産品核心在于商業價值，通過業務體現出來。如果業務邏輯跟不上用戶行爲，衍生功能解決不了用戶需求，平台體驗和技術實現再好也無濟于事，這部分出現問題確實是需要大刀闊斧甚至重建的。其次産品本身問題介乎到用戶需求的滿足程度，如果是産品本身出現問題，有強需求未能滿足，有潛需求沒有挖掘，有弱需求拖沓資源，有僞需求占用成本，這些則要考慮需求實現的優先級，同時結合考慮公司戰略層階段等角度去考慮，這部分花時間去重建則是下下之策。最後便是技術問題，重建的可能性是最小的，但如果涉及到數據源、架構等基層系統問題需要重建的，成本是三者最大的。同樣，也要考慮諸多因素。
總結，産品人剛接手一款産品，調整是必然的，重建則需要搞清楚是自身的問題還是産品的問題。反之，都是不負責任的。
某後台産品經理
做産品也有2年多了，有自己0-1主推的項目也有接手前任留下的半成品的經曆。因爲我是從事後端産品的，我且從後端産品去討論樓主的這個問題。
首先，接手別人的半成品後第一個想法是推翻，而不是在基礎上去叠代的産品經理是有，但是絕對不會是主流，因爲考慮到重建成本，一般的産品經理都不會這麽幹。第二，即時有這個想法，那麽一定是前任留下的太坑，而接盤的人感覺填坑的難度不亞于重建的難度。說個例子，做後台産品的，很害怕接手半成品的後台，因爲對于後台來說，本身邏輯性就會相對複雜，涉及到的流程和數據交互也會比較多，而且對于後台的設計思路太多太多，有的人會根據工作流去設計，有的人會根據實際功能模塊去進行設計，你還需要花很多時間去摸清楚，前任産品經理是怎麽想的。然後這個後台的邏輯是否有漏洞，是否你之後的改動會對前面的設計産生很大的影響，這個都是很費時間的。所以有的産品，可能一接手第一想法就是直接推翻。第三，就是産品經理都有自己創造的欲望，這個和産品經理的崗位的特殊性有關，每個産品經理都夢想著自己去主導一個産品的誕生，當然不希望“喜當爹”。
最後，我最近也接手了一個十分之重型的後台系統，功能很全，設計的工作流繁多，但是由于是技術自己搭建的，沒有從易用性，操作流程順暢的角度去考慮，整個後台讓人看起來就是一個大雜燴，什麽都給你了，就是需要你自己去找。說實話，我剛接到也是要罵娘的，但是産品人的一大high點不就是去變腐朽爲神奇麽？享受這個過程。
騰訊産品經理
爲什麽喜歡推翻重建産品？
這個問題問得帶有情緒色彩，産品經理並不喜歡重構啊，往往是因爲現實的一些問題。
舉一個切身的例子：以前負責過一款ERP系統，剛開始做的時候，我針對的用戶群是公司內部的四五十名推廣員工，做些簡單的小功能，已經滿足他們的需求了。
後來公司拿到融資，上市了。
公司業務發展快，推廣部的人數也越來越多，後續慢慢地加了很多功能，爲滿足用戶需求。
後來當推廣人員到兩百多人的時候，當前的系統無法滿足需求。
-
由于開始的系統架構就是供四五十人使用的，到了使用人數一多，請求過多導致響應緩慢，系統加載性能效率很低
-
系統並發量增多，導致系統有問題
-
底層數據結構，建表的時候一張表，增加字段都是一張表，涉及到聯表查詢，數據量過多的時候，就有問題。
這時候，我發現，系統已經無法滿足推廣員的需求了。
那麽有沒有必要重構？
重構的成本與重構的收益如何權衡。
成本：一個産品跟兩個開發，從梳理需求、提供解決方案到最後的測試上線，需要花兩個月時間。
收益：重構後，優化業務流程，系統的操作效率加快，提升推廣部的工作效率
經過評估，最後重構了。
其實，沒有無緣無故地重構，只有當系統無法滿足當前的業務需求時，才會想著重構。
百度的産品經理
工作3年有余，一直從事産品工作，接觸産品也是五花八門了。從一開始PC、移動端的細分到更加垂直領域（社交、社區、電商、o2o等）細分再到現在更加的細分領域（商業、數據、策略）等。一般喜歡推翻産品的無非兩種情況；1:剛來的産品負責人，研究過一遍産品後發現到處是坑填都填不完（也許自認爲）推到重來。2:業務、場景等發生重大變化、推到重來。而這兩種情況一般都發生在創業公司，尤其AB輪左右。
推到重構的成本比較大，其實推到的不僅僅是前端上的東西，有些數據方面的兼容，重構，才是核心和重點。個人曾經主導過兩個産品的整合，心累的要死。。
個人感覺還是看看現有産品的坑能不能填完，如果坑不是很大，建議還是改良…..實在不行在動手吧。
京東的産品經理
我可以理解提問題極端化，會簡化問題模型，但是極端的情況在日常的工作中，屬于少數，如果一款産品在你接手的時候，就面臨著是否需要推到重來，那這個産品的問題看來也是相當嚴重，這個時候，需要思考的就不是你要不要推翻了重構吧，而是你們提出的這個解決客戶問題的産品，到底還行不行的問題吧？
本人從事 2B 行業，一個比較細分領域的企業服務，在我看來一款産品的冷啓動，從0到1，是最難的，要說服客戶信任你，甚至是購買你的東西。在真正的工作中，這種天使級的客戶，是非常難得的，如果已經完成了這一步，一個 PM 就算是中途進入了，要做的也是「優化」吧。
重構和優化都是讓産品變好的一種手段，很多産品的生死，PM 都不是重要的一環，要結合企業的經營情況和客戶的需求度來做判斷，合理的判斷成本。
最後，說點不上台面的話，少給自己挖坑，你給自己挖坑的同時也在給你的同事，你服務的企業挖坑，除非你是合夥人，産品是否需要重構，不是一個新手 PM 能決定的。
阿裏的産品經理
怒答一發，因爲剛剛花費1年5個月的時間，推翻重建了産品。
事情的過程是這樣的：
去年7月份的時候接手一款産品。彼時，原産品經理離職，我負責接手。離職的主要原因是該産品表現嚴重不達預期，當時産品的版本號爲V3.2。
本著存在即合理的理念，我小心地優化著每一個功能和交互。約摸到11月底的時候，版本叠代至V3.6，基本解決完該産品現行存在的幾大問題。4個多月的叠代，其實都是治標不治本。其實，當時的産品架構和設計遠遠不能支撐老板的理想。這是大家都明白的。所以，想要産品數據表現和用戶體驗有大的提升，重構和重建是唯一的辦法。
于是，從去年12月份起，開始規劃4.0版本。同時，在3.6版本的基礎上，逐步對原有的功能和交互推到重建。一直叠代至V3.9.7。當然，這樣的重建也是要小心謹慎，既得革新又得兼容，所以走的很慢。所以到今年3月份，才正式發布4.0版本。目前的版本是V4.2版本。從V4.0到V4.2，期間陸續發了30多個小版本。當然，重建之後，無論是體驗還是視覺效果都好多了。如果一定要說數據的話，用戶的在線時長提升了48%。
啰嗦這麽多，是想告訴大家，不是不能推到重建，而是應該如何小心謹慎地推到重建。別說換了産品經理，就是産品經理不換，隨著時間的推移，推到重建也是常有的事。因爲用戶的習慣在變，設計理念在變，你的産品不變，就只能被淘汰。你看，IOS的app store革新了，天貓的客戶端革新了，QQ推出TIM了，微信雖然沒有大改，但現在的版本跟最初的也有巨大的變化，不是麽？
所以，回到問題：産品經理爲什麽喜歡推翻重建？其實不是喜歡，更多是除了重建沒有其他辦法！說白了，都是被KPI逼的。因爲推到重建真不是你想的那麽任性和惬意，個中苦逼，難以言表。
文章來源：Kevin改變世界的點滴
原文鏈接：
https://mp.weixin.qq.com/s/oS_b2l6Qre6ndbE6-58wZQ