歪果仁说产品｜MVPM—产品经理也有MVP模型

全文约7000字，读完本文大约需要10分钟，此文为英文译文

下面这张图也许你在以前就见过，它既简单而又优雅的展现出了产品经理本身是众多技能交集体。

这张简单明了的数学集合图，恰如其分的说明了产品经理应该拥有的技能以及其内在的能力界限，非常完美的诠释了一个产品经理应该拥有的能力模型。

在很久以前，作为一个产品菜鸟，这张图告诉我必须自觉地学习各种各样的知识和技能从而去构建自己的技能树的广度。但是，它似乎没告诉我，我到底应该专注在什么地方；所以，在最开始作为一个小白时，我总是狼吞虎咽的学习着所有我能接触到的知识和技能。到头来，却发现这是一个天大的错误。

很显然，在这个地球上我们是没有足够的时间去学习上图中那三个圈里面的所有知识和技能的。图的展现的东西虽然很有用，但终究来说却是不切实际的。

所以，如果我们要让这张图对我们有所帮助，我们应该先了解清楚，图里面交集的部分到底包含了什么？

交集的部分就是我要说的MVPM，即最小可行的产品经理（Minimum Viable Product Manager）。MVPM完美的定义了一个合格的产品经理应该拥有的知识和技能。

但MVPM并不意味着你需要很快速地去精通其中提到的所有技能，这样对于一个小白来说不但不切实际，而且还会有适得其反的效果。相反，你应该把它看作一个小白产品经理刚入行学习的教学大纲。

这篇文章，写给过去那个年轻的自己，写给产品小白，同样也写给那些希望提升自己的产品老鸟。为了和上面那张图里面的三个圆一一对应，我将我要说到的点分为技术、商业和用户体验三个大点进行描述。并且，每个大点相对应的指出三个必须聚焦的知识或技能和一个不能踩的坑。为了让更多的小白和行外人能快速读懂，我将尽可能描述得通俗易懂。

当程序猿们在谈论技术栈时，程序猿们在谈论什么？

“技术栈”是一个相对抽象的概念，它可以泛指用来实现你的产品功能的各种前后端技术，它让一切产品需求得以实现。从一个用户加载到你的产品的登录着陆页，到他主动地把他的用户账号注销，技术栈都默默地在背后处理着这一切。

如何快速学习——请教开发大神们，让他们帮你从“一览众山小”的角度去review一遍所有的技术栈。接着把你听到的各种技术记录下来，并且快速的谷歌一遍所有的专业术语。这样，你就会大概了解到产品开发中所用到的每种技术的优点和不足之处，也会清楚这些技术在内部是如何和谐并高效地运作的。记住，在快速了解技术时一定要以“一览众山小”的角度切入，否则你会掉入技术学习这个大坑无法自拔。

成为一个更好的PM——当程序员们在办公室里讨论产品架构应该如何搭建，顿时，各种专业术语总会满天飞。这时，也许你会一脸懵逼。但是，当你了解了技术栈的相关知识，这意味着你可以跟得上他们讨论的节奏。假以时日，你将会逐渐明白程序猿们到底在讨论哪一个层面的技术问题（比如，是前端的问题还是后端的问题；是数据库的问题还是服务器的问题…）。通常来说，一个产品的技术栈中需要接触的东西越多，涉及的层次越深，那么这个产品的需求变更后的开发难度就越大，风险也更大。当你了解了这一切，在下一次考虑如何解决产品问题时，你可能就会用另一种方法去解决问题。

如果说刚刚提到的“技术栈”代表着那些经常被我们使用到的技术，那么系统架构就控制着这些技术如何共同搭建，高效运转，并最终诞生出产品的。与更抽象的“技术栈”比起来，系统架构则更加贴近于产品本身，它的设计构想恰恰会体现出用户的产品需求。

如何快速学习 ——同样的，还是要请教开发大神们，让他们给你画一个系统的架构图，那么你将会得到类似一张这样的图：

在看到这张图后，你懵逼的概率达到了百分之99，但是，一定要蛋定。首页，你必须跪教（跪着请教）程序猿大哥们，让他们告诉你图中所有不同形状的组件（包括各种客户端、服务端及数据库）都是干什么用的；如果你请教的姿势是对的话，那么，他们会告诉你哪些东西是用来处理网络请求的，哪些是用来实现业务逻辑的，哪些是用来储存用户数据的。

当然，你不要作死的认为程序猿哥哥在忽悠你，他刚刚说的一切对你都是非常有用的。

成为一个更好的PM——当你大致了解了系统的架构后，你就会逐渐的像程序猿们一样的把你的产品看做一个系统来去思考。这样，当你清楚的了解了产品中的每一部分在总体中起的作用时，你就会做出更好的决策和需求权衡，在考虑需求方案时，会更加的周全以及更加清楚它的可行性。

一般来说，如果一个产品中的某个模块与系统的其他模块的关联越多，那么它的变动则会越复杂和困难，因为产品中的其他模块都要依靠它来提供数据传输或是功能支持。如果在实现某个功能的时候，你的产品需要改变的模块越多，对外部的数据或功能依赖越多，那么，你的这个功能将会很难执行并实现。

在大公司里，产品执行工作中涉及的不同模块的数量通常是和你要去沟通的部门或团队的数量是一样的，所以，这也意味着你要获得同等数量的人的同意和支持。

数据结构负责把产品中用到的各种数据高效的组织起来，并且标准化了这些数据是如何与其他“信息”关联起来的。而这里说的“信息”指的是用户、产品、信用卡等等，那些具体的东西。这些东西通过确定的、结构化的方式相互关联，例如一个用户可以拥有很多的产品，但通常情况下只有一张信用卡。

数据结构与上面说到的系统架构有非常紧密的联系，之所以这么说，是因为特定的数据信息是存放在特定的系统模块中的。你的用户信息以及与用户相关的产品数据可能存放在A模块中 ，但是由于用户隐私信息的敏感，信用卡信息可能会存放在B模块中。所以当你有一个需求是需要将一个产品拥有的用户的信息展示在一个列表中时，那么这将相当简单，因为这些信息是存放在同一个模块中的。但是，当你需要知道这些用户当中哪些用户绑定了信用卡时，A模块就需要与B模块进行关联，以此达到数据传输的目的。这样做有一定难度，需要用到API来去实现。

编辑：未知