产品经理为什么喜欢推翻重建产品？
Kevin改变世界的点滴 前天
近期在网上看到特别有趣的讨论，关于产品经理总是喜欢推倒重做以前同事的产品。是职场潜规则？还是因产品不是自己亲生的，就无法给足够的养育？
我汇总了一些有趣的讨论，分别来自阿里、京东、腾讯、百度、普通企业的产品经理。发现产品经理其实并不是推翻重建的幕后人，很多是被迫在职场中的理由。下面我们来看看他们的讨论话题，
问题描述
当产品经理接手旧的产品的时候，分析过一遍产品后，第一冲动似乎都是推翻重建，为什么这种状况会频繁的出现呢？
你们在做产品的时候接手旧产品，是改良派还是革命派呢？
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://www.pmcaff.com/discuss/index/609776782505024
推荐阅读：
坚持一年，招募100个产品经理
我的第一本书，给你们