B端产品经理初接手老产品有哪些注意事项？
不要一上来就提出改这里改那里，先了解背后逻辑。特别是一些一下就能看出“很蠢”的设计，也许并不是真的因为上一任产品太笨了。 B端的产品相对C端，没有这么的“直觉”，而更多是不断深挖和妥协的产物，任何的设计都有目的，都有背后的利益博弈。 有很多的设计都是有背后的故事和原因的，当年可能也是做过系列的调研和逻辑推理，要尊重并善用这些前人的经验。 所以，在你看到一切“看不懂”的功能时，先问问知道这里历史的人，这里当年为什么这么做，是怎么考量的，有什么对应的支撑和原理。有机会再和上级老板们聊聊，问问背景和原因。 既然是临时接手的项目，大概率就是或多或少有一些问题和一些积怨。而切割的意思，就是让所有兄弟部门和上下游明白，“有些你们看到的问题我现在也看到了，但这里之前不是我管的，我现在接手，之前的问题不是我造成的，但未来我都会陆续优化掉。” 把矛盾留在昨天，我们一起面向未来（。。。） 所以，上一条里提到了向上级和老板问具体“问题设计”的背景，其实也有与过去做切割的一种方式——这地方是之前的人做的哈，我已经在看优化了。 ——但建议还是先找个完美的练手对象。 团队的重新磨合需要时间，你对行业or细分范畴的理解需要时间，理解背后逻辑需要时间，不可能在短期内就能完美接手的。 但初期你啥都不动也不行，所以，从一些“明显但不难”的事情入手，就是最好的选择了。 明显：这个改动应该是能够让其他人迅速感知到并切实有效的； 不难：牵扯的地方比较少，不会因为一个改动而出大篓子； 你前期的所有沟通、调研、同上级同级下级的聊天，都可以围绕找这么一个适合练手的“明显但不难”来进行，这样当你真的准备下手时，就知道去做什么了。 于是，从一个小需求的改动开始，到一个中等需求，到最终考虑重构整个能力或系统，让它变成符合你产品观的“长相”，这大概就是“如何接手一个产品”的合理顺序与答案吧。  希望有帮助。