1、了解产品架构。

B端产品的产品架构是非常重要的底层设计，因为——相比较于C端，B端的客户需求和功能建设都是经过非常复杂、长期的调研、博弈、妥协后的产物。所以你接手的产品，在没有了解的情况下，你会发现有非常多的「你觉得不合理的」地方。但是，你接受的这个奇怪产物，是维系了你现在手里那点平时不出声但开口都是大事的一堆甲方爸爸的。而且，B端产品无论在后续开发还是扩展还是重构，都是一个令你非常绝望的过程。无论是内部需求、还是外部客户、甚至外部的客户之间，都会给你带来各种你无从下手的难题让你解开。

所以，了解好你的产品架构，熟悉它的来龙去脉，搞清十万个「为什么」，是你当前必须、必定要完成的事情。等你了解清楚以后，你才会发现，看似不合理中有合理的地方，而且能帮你自己在后续的开发、拓展或者万不得已的重构中，毙掉非常多的坑的同时，还能妥善满足客户，维系好客户和客户之间的不同需求。

简单来说，干这件事，就是在救你一命，而且让你自己以后工作起来开心许多。

2、了解客户需求。

这句话可能是白说，客户第一嘛，大家都知道的。甲方爸爸，永远第一。

我相信的，大多数人都能做到，客户第一。

但客户和客户之间，哪个第一？

你想选一个是不是？你想好了吗？

我一句话告诉你，哪个客户都是第一！

这句话可能政治不正确，但关键时刻能救你命。

一个标品去面向所有的客户，不可避免的，会有干扰。如果你贸然用C端思维来处理B端客户的需求，一个字，死。C端产品经理做的更多的工作，是抽象群体画像和群体需求。B端，当然也是。但你碰到哪怕只要1个难搞、不妥协的客户，99%的其他客户好评根本挽救不了你。

一句话，你老板和你，都敢得罪1个甚至100个10000个C端——觉得不好用你别用啊？

你去跟你司最最最最小的付费甲方爸爸说这句话试试？你以后在这个行业没法混你信不信？

甲方客户在共性的需求上，都是OK的。但他们也会有自己每个不同规模、不同行业、不同老板、不同工作流的个性的需求。妄图用你所谓的任何「先进」、「高级」、「本质」的对需求的处理，去改变或者说干扰，他的使用体验，都是一个灭顶之灾。哦，对你也是灭顶之灾。

你能做的，就是走到客户心里，充分的了解、明白他的需求，调研、讨论、引导，最后以最低程度的向他妥协的方式。然后搞定你的团队和产品，朝你想要的方式发展。

以上。

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

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

1. 一定不要做什么

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

1.1. 当众诋毁前任产品经理，以及产品现状

这是一种最外行的行为，就像天天有人要教张小龙怎么做微信的吃瓜群众一般，上来就大批评产品的现状是多么的烂，前任产品是多么的无能。传到前任产品耳里不可怕，但如果传到之前为此付出过心血的研发、测试、运营、设计团队那里，你还准备让人跟你一起好好干嘛？

经常有人问，你这个绘本上的字体怎么不能调整字型大小，那谁谁家的就可以。你这个语音评测怎么这么慢，别人家的立即就能立即反馈结果。最开始我还是比较在意的，直到有一天有人安慰到，说：「壳，我相信你当时做了最正确的判断。」是的，你不了解当时的情况，以及这样做的背景。没必要等到自己做的时候，同样的话送给了你自己，让众人嘲笑。

1.2. 给团队及领导画饼

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

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

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

1.3. 立即推进项目

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

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

1.4. 立即推倒项目

比立即推进项目更恶劣的情况就是直接把原有项目推倒重来，按照自己的想法来。怎么说呢，这个按我上面的思路再想想，你即不是皇帝，也不是CEO，初来乍到如果又没有什么成绩，why？不靠谱和不信任的标签将会长期被贴在身上。

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

2. 「接盘」的第一步：了解现状

因为你将接手的项目已经存在，甚至上线过很久，迭代过很多版本。虽然可能会有前任产品，或者上级领导做工作交接，但总会有很多不具体的地方，很多细节即使交接也未必清楚，或者年代久远没有记录。笔者还是推荐自己从以下几个方面更细致的入手，避免之后落入坑中，无法自拔。

2.1. 项目目标

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

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

2.2. 熟悉整个业务流程

大到公司部门、业务线，小到产品、功能模块，它们都不会孤立的存在于公司的体系之外。如何更好的利用其它团队的资源，如何与其它部门产生合力而不是阻力，常见问题的就是下游其实已经有支持能力但作为上游却不知，导致整体效果不理想及项目推进困难。这些都需要我们尽快的熟悉当前项目在整个业务流程中所处的地位。归纳起来：

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

2.3. 熟悉产品，熟悉文档，熟悉团队

一个项目很少有既换产品又换团队的，所以除了你，项目中的研发、设计、运营、测试一般都还是原来那帮人。所以现在，他们是最熟悉这个产品的人，之前团队在项目推进中遇到的困难，他们是最了解的。所以，这里有几件笔者必做的事情，大家可以直接进行参考：

• 自己亲自体验，并且一边使用一边画相应的功能流程图、页面流程图等，做好相应的记录；
• 看之前历次迭代的需求文档，查看之前项目中，遗留的问题，及当时的一些限制；
• 把前面的问题跟团队的研发、设计或者前任产品经理进行沟通，了解当初的一些取舍细节与项目背景；
• 在沟通的过程中，熟悉大家的分工，了解团队的能力，和可能的极限
• 通过反复的沟通也能慢慢的培养相互之间的依赖；

2.4. 数据

If you can』t measure it, you can』t improve it（如果你无法衡量它，你就无法改进它）

好目标的第一点就是可计算，计算的底层来源就是有数据，以及数据的准确性，合理性等。这里首页是要拿到之前的历史数据，拿到后尽快做分析，其中的异常点，比如活跃的暴增或者暴跌，这些产生的原因需要进行了解，这些是之后产品突破的关键。

其次，到目前为止，笔者接手过的项目，或者观看其它产品团队项目的数据，基本上是数据收集混乱，数据定义不清楚等，这里大家可以根据笔者之前写的《产品经理数据埋点文档指南（入门）》，进行整理。

请记住数据几乎会是未来你工作成果的唯一指标，而不是你有多能加班，做了多少功能。

2.5. 竞品、市场

如何自己不熟悉，之前也没有调研报告之类的东西，就需要立即著手去做相应的调研。这种都可以参考市面上常见的竞品分析、市场报告等文章。

可以参考笔者前文《作业盒子产品体验分析报告》这个就不再赘述了。

3. 几种增加难度的情况

笔者这里再根据自己的亲身经历，列出几种如果能力及阅历不足，强行「接盘」将会身心俱疲、事倍功半，请做好心理准备。

1. 前团队成员频繁更换。会极大的增加你的沟通成本，把大量的时间浪费在无意义的事情中，笔者最郁闷的时候一个需求跟四组不同的研发进行沟通，虽然可以让研发之间进行交接，但你能想像交接四次之后的效果嘛？但反过来想，可能会促进你的思考，锻炼你的思维能力，以及耐心；
2. 业务方过于强势。比如每天都是紧急需求，今天提，明天就得上，又或者业务方有专业技能知识而你又不懂，只能被牵著鼻子走。这种基本就是产品经理在主导项目了，如果不得不接，基本上前期就只能忍著，在此期间尽快补齐自己的短板吧，然后再以业务方的成果再反向提要求，提高提需求的门槛；
3. 没有公司大佬支持。第一，没有大佬在后台支持，这个项目的资源会难到位（其实就算有，有时候也很难）；第二，就算你千辛万苦的做项目做好了，被其它大佬眼红也会被抢走。至于大佬大到什么程度，各家有各家的情况。此类情况请尽早做好后事；
4. 目标经常更换。说明公司对这个项目的定位不清，如果你经过前面的思考也没有想明白项目的价值，只能说你不合适。但反过来，你能帮助公司想清楚，就是个机会；
5. 目标无法实现。了解了市场，了解了团队的现状，了解了项目在公司的定位，给你一个运营让你下个月实现100万的用户增长，这种目标如果不能据理力争去改变，坚决不接；

4. 下一步：做出自己的判断

看到这里，其实以上有些做法及观点可能会有些理想，实际情况可能会更糟糕。但再难的事情也会有人来解决，别人不行你能行，自然是你牛逼。看你自己愿意为此牺牲什么，从中获得什么。

祝大家好运，欢迎大家有问题可以添加后面的微信，向笔者诉苦、吐槽、交流。

作者：核桃壳，微信：walnutshell911

原文：核桃壳：产品经理如何做好「接盘侠」

其他不说了，如果你不会看代码的话。

①如果前任还没有离职，把他摁在工位上整理交接资料，越细越好，业务图、系统图、流程图、需求文档、会议纪要、需求池、使用手册、业务关系联系人清单，能想到的一切文档……

②尽量让前任跟著走一段时间，能拖久一点尽量多掌握一些（自学要快，不然老板会怀疑你能力）……

③前任真的要走，如果有可能，有那么一丝可能，把他的硬碟（包括系统盘）都打包一份留存～你会感谢我的～

接手已在实施的产品，有利有弊。

利在于一是前期市场调研和可行性评估已完成，商业目标与产品目标已明确，业务蓝图初步形成。这部分对于大部分产品经理而言还是很费心的。二是内部立项、团队组建和计划安排等都已经处理好。相关繁琐的事项你不需要操心。

弊在于产品框架和方向已经基本确定，如果你是一个特别有想法的人，可能需要作出适当取舍。

因此，在刚开始的时候有以下建议。

对事，先摸透再调整。在刚接手掌握足够信息，了解清楚情况之前，无论觉得哪里不合理，和你平时的工作习惯多么不一致，也不要急于改变什么，还是要先了解前因后果，搞清楚原来那位产品经理的意图，再根据实际情况做出相应调整。切忌急于求成。这样才能更好的对症下药，实现产品目标，发挥产品价值。

对人，多沟通，尽快熟悉团队成员。对于团队成员，初期要高频率的沟通，了解他们的基本情况和想法，也让他们了解你。尽快彼此互相熟悉，以便后续工作的开展。这一点经常容易被人忽略，很多管理者接手新团队以后，总是匆匆忙忙想让团队做出调整，以适应自己的工作风格。往往忽略了要让一个团队更好更快的动起来，是需要团队成员之间更好的默契。磨刀不误砍柴工，先把团队凝聚起来，再去做你想做的事，会更加轻松容易些。

---

看到不合理的东西不要轻易改变，深入了解一下，这么做往往是有现实原因的

---

推荐阅读：