产品经理是如何当“后爸”的：如何快速接手别人的产品

编辑导读：当产品经理接手了一个已经成型的产品时，我们应该怎么做？应该注意什么？本文作者从六个方面展开分析，希望对你有帮助。

一个合格的产品经理应该如何快速接手一个新产品，这里的新产品往往会分成两种情况，一种是正真意义上的新产品，以前没有这个产品，由产品经理负责从0到1创造这个产品。

另一种是对产品经理而言的新产品，这个产品本身就有，现在由于人员调动、新员工入职、老员工离职等原因要找一个以前没参与过这个产品的产品经理来接手，那对这个即将接手的产品经理来说，这也是一个新产品。

从0到1的产品能力就是完整的一套产品经理的工作流程，是每个产品经理的必修课，所用到的知识和技能也就是对一个合格产品经理的全面要求，如果聊这个今天这一篇文章可就放不下了。

我们今天要聊的是第二种情况，接手已经成型的产品时我们应该怎么做，在实际的工作中接手别人产品的场景事实上也是远远多过自己做一个新产品的，所以其实对大多数产品经理而言，接手已成型产品的经验才是更常用的，下面我们就来聊聊它。

一、产品背景

千万不要一上手就把自己扎根到细节中去，要了解一个产品一定是要先从整体认知上知道这个产品是做什么用的，是在什么情况下被发现需要有这样一个产品的，它能够帮用户解决什么问题，在公司的整个产品架构中它充当的是一个什么样的角色，它的价值主要体现在哪些方面等等，先要了解到这些比较宏观的概念，对产品的整体情况有一个比较清晰的把控。

这一点是很重要的，你对产品整体把控的准确程度直接决定未来能否在产品发展的决策上做出正确的判断。而且这种整体把控的事情，往往是经过原来产品团队抽象过多次的，是可以几段话就明确概括的，所以最先了解这个维度的事情，本身是不会占用产品经理太多时间的。耗时少作用大，最先做整体背景了解可以说是一件性价比非常高的事情。

二、产品框架

已经成型的产品正常情况下会有两个维度的产品框架，一个是现有框架，是已经落实到当前产品功能上的框架；另一个是规划框架，是产品创建初期做整体规划时绘制的产品蓝图，正常情况下产品经理会根据这个产品蓝图来逐步完善产品功能。

这两个框架都非常重要，了解现有框架可以帮助产品经理快速了解产品的功能结构，知道哪些功能点是被归类到哪个模块下的，以及各个功能模块之间是如何配合的，或者各个功能模块之间有哪些影响关系。了解了现有框架以后，产品经理就可以对产品有一个比较模糊的把握，基本可以做到别人提到一个功能点的时候，你知道该去哪个菜单下找到相应的内容。

而了解规划框架，则是给未来升级改造这个产品所做的准备。既然这个产品还是需要新的产品经理来接手管理的，那大概率这个产品还是需要继续迭代升级的，那产品经理怎么做后面的产品升级工作，就得看规划框架、看产品蓝图了。产品要知道哪些规划是现在已经实现的，哪些是未来要进一步去做的，就需要对两种框架都有明确的把握。

三、了解业务

这是很多产品容易忽略的一点，尤其是在这种接手成型产品的情况下，因为已经不是产品的定义期，所以产品经理就很容易忽略真实的业务场景，而是更多关注用户对产品的使用，这样就很容易顺理成章地进入前面产品经理所设定的产品使用路径中，而不太容易发现产品可能存在的不合理之处。有些用户在使用产品一段时间后就会被产品驯化，他们渐渐将一些不合理的地方理解成一种新的规则，自然而然跟着产品设定的路径去执行，所以靠用户使用其实是很难发现这些不合理的地方的。

这就要求新接手的产品经理在真正介入产品生产工作之前，最好能深入产品用户的业务场景，了解一下当用户在没有产品提供支持的时候是如何完成相应的事项的。这就类似于在产品初期了解业务的原始需求一样，每个产品经理对原始需求的解读都可能不同，你只有自己真正了解用户的真实诉求了，才能判断现在的产品是不是真的符合用户的预期，你才可能及时发现前面的产品经理有没有给你留下一下潜在的隐患，及时发现这些问题并解决，而不是等到问题爆发的时候才推卸责任给前面的产品经理。

举个不恰当的例子，你的继子犯错误的时候警察也会来找你这个法定监护人，而不是去找他已经失踪的亲爹。我们做产品常常说把产品当成自己的孩子，那这种从别人手上接过来的产品不就是继子吗，那你现在既然已经被安排当这个爹了，就要负起责任来把儿子的方方面面都了解清楚，当好这个继父。

四、熟悉功能

当你真正了解业务场景以后，再带着业务的视角去了解产品的功能，这个时候你可以给自己定义一个角色，那就是一个懂产品的业务线同事，在了解产品的过程中可以给这个角色加一个特点，那就是爱找茬。一个产品经理在接手一个新产品的时候可能只有这一次机会能够以这种视角和心态去面对这个产品，在这个对产品基本陌生的阶段，是最有可能、最容易找到产品设计不合理之处的，所以各位一定要把握好这次机会。

这里更深一层的多说一点，一个产品经理在面对自己产品的时候，其实也可以尝试用这样的第三方视角去审视自己的产品，去挑自己产品的毛病，找它设计不合理的地方，不要担心会对自己有什么不好的影响，要敢于质疑自己，要不断去挑战自己，这样你的产品和你自己才能不断的成长和进步。

说回了解新产品功能的部分，大多数人习惯使用的方法是直接把自己当成一个真实的用户去使用该产品，从注册登录到账号设定再到系统操作，所有的产品细节都来试用一次，去感受产品的特点和能力，这是最快了解产品能力的方法，也是最容易发现产品问题的方法。除此之外，产品经理还可以通过查询前任产品经理需求文档来了解产品的相关功能，这种方法则是能够更深入了解产品设计之初的理念和想法，有些使用时觉得有问题的地方也可能会在需求文档中找到当初这样设计的原因。

最后产品经理还可以通过给产品写操作手册来进一步熟悉产品功能，可以在完全试用完一次产品以后来给产品写一份现有功能的操作指导，尽可能详细地描述产品的使用方法，并在其中标注需要注意的内容。完成上面这一整套操作以后基本就对产品现有功能基本掌握了。

五、梳理需求池

正常情况下一个产品都会有一个专属的需求池，也就是需求管理清单，分门别类地记录该产品已经做了哪些需求，用户提了哪些需求，后面规划还要做哪些需求等等，接手产品的时候找相关对接人员问一下看有没有产品需求池，有的话一定要接手过来，并且找前任产品经理了解清楚里面涉及到的相关内容。

如果前任的产品经理没有整理这样的需求池，那我们就需要自行梳理了，还记得前面提到的规划框架吗，可以根据规划框架和现有内容的对比梳理出下一步要做的需求，还有我们在熟悉产品功能时所记录下来的问题，以及一些你认为产品需要改进的地方等等，这些都可以演变成需求内容汇总到该产品的需求池中。

当然，如果前任留了需求池，我们也还是要梳理自己的内容，可以把自己了解过程中梳理的内容跟前任留下的内容做一个整合，相同或相似的内容合并，不同的内容保留，最后形成一份属于自己的需求管理清单。

六、产品升级&团队磨合

前面的内容都完成以后就要考虑产品升级的事情了，接手新产品以后最好不要一直停留在运营产品的阶段，接手以后这个产品就是你的了，你就要开始推动这个产品迈向新的台阶了。前面该了解的内容都了解了，需求池也已经准备好了，接下来就可以先选一些相对比较简单的功能项，快速安排一次产品升级。

为什么要选相对比较简单的功能来做升级呢，一方面简单的功能各方的工作量都不会太大，适合速战速决；另外产品经理这边作为一个刚接手不久的新成员处理简单功能的话也不会出现什么太大的失误，算是把风险控制在可接受的范围内；还有一个原因就是，这次小的升级是你跟这个产品团队的第一次合作，拿一些简单的功能来做不容易产生分歧。

这次产品升级是有两个目的，一个就是让产品快速打上属于你的烙印，只要做这么一次简单的小升级，你就真的在心理层面认同这个产品跟你的关系了，就跟游戏里面的宝藏兵器滴血认主一样，这是一个很有仪式感的操作。

另一个其实就是为了快速融入团队了，在公司大的产品生产制度之下，每一个产品团队都有自己的工作习惯和配合方法，都有属于自己小默契，这个默契是没办法通过产品交接来传递的，最好的办法就是大家整刀真枪合作一次，拉几次评审会，讨论几轮问题，大家基本上也就相互了解对方和做事风格了，这就是团队磨合。用一次小的产品升级完成团队磨合，后面打硬仗的时候大家配合起来自然就会顺利很多了。

七、结语

以上就是接受一个新产品的时候核心要做的几个事情了，这个过程基本包含了从认识一个产品到了解到熟知，最后再一步一步把这个产品真正变成自己的产品。企业人员变动产品交接真的是一件非常常见的事情，所以掌握这一整套快速接手新产品的技能应该是每个产品经理的必修课，说不定哪天你就被委以重任安排到哪个新产品上工作了。

当然我这里所能整理出来的基本是一些比较主线的任务，还有一些细节上的点这里并没有展开描述，比如之前跟朋友聊这块内容的时候他提到一个很重要的点是学习新领域的各种专业名词，他的习惯是先去把这些可能会造成阻碍的东西先摆平，然后再去推进事情前进，而我的习惯则是先推进事情，过程中遇到什么事情再见招拆招解决事情，这两种方法都可以，具体使用就看个人习惯了，你只要选择你自己喜欢的方式就可以了。

最后，我这里所写的东西都是我在日常工作中沉淀和积累的内容，并不一定可以完美适配所有人的工作场景，大家如果觉得有不合理的地方，或者有需要补充的地方可以在评论区给我留言，我们可以共同探讨，一起进步。

 

作者：多云转晴，公众号：互联网从业笔记

本文由 @多云转晴 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。