近期在網上看到特別有趣的討論，關於產品經理總是喜歡推倒重做以前同事的產品。是職場潛規則？還是因產品不是自己親生的，就無法給足夠的養育？
作者彙總了一些有趣的討論，分別來自阿里、京東、騰訊、百度、普通企業的產品經理。發現產品經理其實並不是推翻重建的幕後人，很多是被迫在職場中的理由。下面我們來看看他們的討論話題：
問題描述
當產品經理接手舊的產品的時候，分析過一遍產品後，第一衝動似乎都是推翻重建，為什麼這種狀況會頻繁的出現呢？
你們在做產品的時候接手舊產品，是改良派還是革命派呢？
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逼的。因為推到重建真不是你想的那麼任性和愜意，箇中苦逼，難以言表。
原文鏈接：
https://mp.weixin.qq.com/s/oS_b2l6Qre6ndbE6-58wZQ
閱讀更多 IXDC 的文章
