接手MVP产品，这场仗该怎么打思维导图

可以通过前任产品经理输出的产品规划文档或思维导图来了解，如果时间紧迫，前任经理没有任何规划类文档输出，那么你一定要把握工作交接的机会——讨论产品定义规划的思路，过程中一定要注意了解这个人的性格，来分析她的工作方式。

比如如果你了解她，不用问你就知道她为什么会在icon旁放一个文字类的解释说明； 她一定担心的是使用者是中老年人，对中老年人来说，一个确切的告知的文字，比任何表现形式都来的重要。

那你就可以根据他的原因判断，这个对于你目前的发展方向以及面向客户来说是否应该保留。

很多时候通过问答的形式，了解到前任产品经理每一个功能定义的原因是非常有限的，这时你已经对她的产品有了初步的分析， 但有些地方你很难理解的时候，去咨询是非常有用的。

但通过问答，去了解一个人相对来说会轻松很多，你也可以根据她的习惯思维去判断，哪些功能对她来说价值在哪里，对你是否有用。

当前公司的态势，对产品的影响是十分巨大的，当然也只有两种结果，做还是不做。

但其中的灰色地带会告诉你你该怎么做。

比如在大公司，这个目前是公司的创新型项目，那对这个项目可能不会有过多投入，如果没有外界因素影响，你能利用的资源会非常有限，大概率会应用到你自身积累的人脉或者资源才能将这件事完成。

如果资源都向你所在的项目倾斜， 那你更要注意了，每一步都要经过谨慎思考，要合理利用现有的资源，以最终目的为目标力求把所有事情做到最好。

因为你的一举一动可都在被人关注着，但求成功不过也别怕失败（心里状态一定要调节好，不然会直接影响到后面的工作，好的有意义的失败大公司也是可以接受的，怕的就是寻死觅活一蹶不振）。

不过不管公司如何，既然给你分配这项任务了，肯定是想做这件事的，无论态度是否明确，只要你感兴趣，愿意接手，最好都要打起十二分的精神把这件事做好。

即便没有给你合理的资源，但你依旧把这件事完成的很好，这个漂亮仗一定有机会让你翻身做主人的。

你要做一个产品， 最基础的就是场景、对象、目的。

你可以参考前任产品经理的整理资料，但一手资料，才能让你更深刻的认识问题。

你得贴近客户，了解客户的业务流程、操作习惯、工作环境、他们经常会面临哪些问题、他们遇到最讨厌最害怕最生气的问题分别是什么。

设计产品的时候千万不要把自己剥离开，觉得客户可能会遇到什么问题，自以为然闭门造车；而是充分了解客户以后带入自我，我在这样一个工作环境中最希望有一个什么样的产品帮我解决问题。

通常前期准备资料的文档里会覆盖一些这部分内容，但肯定不全面，如果有机会近距离接触客户，参与一线，人家工作里的一个动作，就可以透露出很多信息解答你设计中的疑惑。

产品设计是为了解决现实工作生活中遇到的问题，或提供一些新方式新思路，千万先不要考虑技术实现。

技术是可以配合产品的，除非是绝对的技术产品，大部分产品只要定义明确了，实现就是没有问题的，有问题也是可以讨论攻克的。

产品设计一开始就考虑技术实现问题只会禁锢你的思维，让你偏离目标航线越走越偏；结果本来是一个可以充分获得用户满意的产品或功能需求，最后只能让客户勉勉强强接受，就不值当了。

这是我们把前期了解好以后面临的第一个问题，当前的MVP产品是否符合发展规划。

一般情况下，MVP的产品都是紧急仓促下定义的，但直接废弃不用的概率还不高，一般都是留到后面；待原有的架构满足不了业务流程最后进行架构重构，架构重构复杂性到了一定地步的时候就需要从头重新开始了。

如果现阶段就可以考虑到未来最大情况的发展规划，对后面的业务发展肯定是利大于弊的，这样在代码中尽量低耦合高内聚、 灵活性高、可靠性高就可以满足扩展大部分的业务场景了。

不过如果发现不合理的地方，甚至会直接影响产品的未来，那么一定要做好判断。

长远评估来看，现阶段重新开始比已经发展一个阶段获得了一批稳定用户、发展了定向稳定业务以后再重新开始的成本可小多了。

最不应该由偷懒现象存在的除了防控安全的职业人， 就是产品经理了，所以我指的偷懒也不是指不经过思考的决策。

我本意想指知道权重会省事儿，知道什么该省、什么不该省、哪些需要多花心思、哪些地方可以暂且忽略不计，这也是一门学问。

首先方向上一定不能省，需要经过我们反复缜密的思考。

我们走路都是奔着目的地去的，目的地决定着我行走的路线，直走还是拐弯；行走的方式，我是开车还是公交，骑行还是步行。目标一旦有问题，那你出行的基础就不成立了，很容易返工哦。

细节上可以省，这个细节是指在你的综合判断中不确定且未经过实践验证无法明确知道结果的细节。

比如弹窗的关闭icon应该放上边还是下边，logo是放在上边还是下边，这个遵从一般的系统现状就可以了，或者也可以先吸取重要相关方的意见；在迭代反馈中有收到相关意见或者有一定的原因理论基础需要放在其他地方，调整起来难度也不大。

其实接手一个在迭代过程中的产品难度是比初创的难度要低一点的，因为前期已经有例子可以参考，但成长的速度是非常快的，基本都是你在掌握着这个产品的命脉成败。

假设只是一个demo，MVP不足以让产品活下来；假设产品迭代的比较稳重成熟了，产品的作用就无非是锦上添花，做的稍微没有那么好，也不会大范围的直接给产品造成负面影响（我说的是产品人哈，是有重重评审的，代码那个删库的不要算在内）。

一个产品，打下基业固然重要，更重要的就是迭代发展， 把人家的MVP完善发展成一个巨无霸可是一个漫长的过程，一环都不能错。