产品经理如何做好“接盘侠”

2020年11月9日 280点热度 0人点赞 0条评论

编辑导语：作为一名产品经理，在接受一个已经开始的项目时，一定会遇到很多问题；首先要弄明白这个项目进度以及现状，其次，由于你是“接盘”，所以要打好团队的关系，因为他们才是最了解项目的人；本文作者分享了产品经理如何做好“接盘侠”，我们一起来看一下。

相信每个产品经理都梦想自己能够从0到1的完成一款自己的产品，但更实际的情况是无论是换工作、还是换项目，产品经理总避免不了当“接盘侠”，负责别人留下的“烂摊子”。

早期笔者接手别人的项目，或者是把项目给别人接手，都会有新产品经理接手后，处处碰壁的现象；很多时候在回想，只能感叹当初：“草率了”。

一、一定不要做什么

无论你的前任是怎么离开的，总会有些说不清道不明的原因，否则好的项目凭什么轮到你？所以在遇到项目真正的困难前，以下几件事情一定不要做，给自己增加难度了。

这是一种最外行的行为，就像天天有人要教张小龙怎么做微信的吃瓜群众一般，上来就大批评产品的现状是多么的烂，前任产品是多么的无能。

传到前任产品耳里不可怕，但如果传到之前为此付出过心血的研发、测试、运营、设计团队那里，你还准备让人跟你一起好好干嘛？

经常有人问，你这个绘本上的字体怎么不能调整字号，那谁谁家的就可以；你这个语音评测怎么这么慢，别人家的立即就能立即反馈结果。

最开始我还是比较在意的，直到有一天有人安慰到，说：“壳，我相信你当时做了最正确的判断。”是的，你不了解当时的情况，以及这样做的背景；没必要等到自己做的时候，同样的话送给了你自己，让众人嘲笑。

有自信是好事，有行业经验也是好事，但换了个新环境、新团队、新公司就想把之前的经验照搬，给大家定目标，给领导画饼。

见过两次有人接手我的项目：

一个是没做过这样类似的项目，但是是从大厂来的，想当然的迷之自信；笔者花半年时间才从2万做到10万顶峰日活，就敢给团队定个次年200万日活的目标，瞬间之前的研发、运营、设计都来给我吐槽，啥不也不懂，啥也不是。

另一个是之前做过类似项目，可能还挺成功，来了一个月却不和我进行深入的沟通和交流，成天沉迷商业模型的设计和PPT；结果去给高层做汇报，被当场diss到体无完肤；都说成功是不可复制的，你过去的成功未必能在新的平台和团队里做好，何况最后我仔细看了一眼，真是空中楼阁，浮夸。

这种可能是少数产品经理特有的一些特性。

笔者之前带过整条业务线，总会希望各小组（研发、运营、设计等）保持住一种“状态”，有点像一辆车从静止到跑上高速，总会需要有一段加速的过程；那么我会希望在更重要的需求确定下来之前，先做一些简单不会错的事情，让大家热身起来，也是个磨合。

说实话，结果其实有好有坏，但实际推进过程中会遇到很多问题，特别是很难回答灵魂问题：“你的目标是什么，你做这个的收益是什么？”如果答不上来，难免会遇到一些尴尬，这种尴尬如果持续扩大，会产生更多的不信任。

比立即推进项目更恶劣的情况就是直接把原有项目推倒重来，按照自己的想法来。

怎么说呢，这个按我上面的思路再想想，你即不是皇帝，也不是CEO，初来乍到如果又没有什么成绩，why？不靠谱和不信任的标签将会长期被贴在身上。

我司的CTO来公司观察和学习小半年后，才做出了大刀阔斧的改革，他也没有借着之前的管理经验就硬上呀。

因为你将接手的项目已经存在，甚至上线过很久，迭代过很多版本；虽然可能会有前任产品，或者上级领导做工作交接，但总会有很多不具体的地方，很多细节即使交接也未必清楚，或者年代久远没有记录。

笔者还是推荐自己从以下几个方面更细致的入手，避免之后落入坑中，无法自拔。

首先关注的自己是项目当前的目标是什么，目标制定的好坏将直接关系到你后面的一系列动作，以及产品规划。

那么一个好的目标是什么样的？

可计算：这一点可以问问你的直属leader，看是否有目标达成的计算模型；如果没有在后面的项目了解后，就要自己能得到，比如最基本的日活，就需要从当前的日活、次留出发，进行推导演算；
有挑战：如果没有一些难度，就很难体现出自己的价值，所以计算完后，需要在一些节点，增加一些幅度，以作为里程碑式的成果；
有价值：一个项目存在的意义肯定是要向公司交付价值的，无论是GMV、用户活跃、人效等等，如果没有直接和公司的战略目标关联，要想象从当前目标到最终目标会以何种方式关联上。就像用户活跃的最终目标也是能够产生GMV。

大到公司部门、业务线，小到产品、功能模块，它们都不会孤立的存在于公司的体系之外。

如何更好的利用其它团队的资源，如何与其它部门产生合力而不是阻力；常见问题的就是下游其实已经有支持能力但作为上游却不知，导致整体效果不理想及项目推进困难。

这些都需要我们尽快的熟悉当前项目在整个业务流程中所处的地位，归纳起来：

上层业务是谁？谁需要你提供的服务，可能有市场、运营，也可能是C端用户侧，应用层，他们的使用场景是什么样的，可以自己体验一下；他们具体需要些什么，可以再亲自去跟他们聊一聊；
下层服务有哪些？比如：AI平台、内容管理的数据库、中台服务、CRM系统、CMS系统等基础服务；需要了解当前使用了他们的哪些服务，以及他们的一些潜在能力；
最后，可以横向的观察公司其它的产品线，看是否有业务上的合作，以及别人是如何使用你的下游服务，或者承接上游需求的。