从三个圆说起
下面这张图也许你在以前就见过，它既简单而又优雅的展现出了产品经理本身是众多技能交集体。
这张简单明了的数学集合图，恰如其分的说明了产品经理应该拥有的技能以及其内在的能力界限，非常完美的诠释了一个产品经理应该拥有的能力模型。
在很久以前，作为一个产品菜鸟，这张图告诉我必须自觉地学习各种各样的知识和技能从而去构建自己的技能树的广度。但是，它似乎没告诉我，我到底应该专注在什么地方；所以，在最开始作为一个小白时，我总是狼吞虎咽的学习着所有我能接触到的知识和技能。到头来，却发现这是一个天大的错误。
很显然，在这个地球上我们是没有足够的时间去学习上图中那三个圈里面的所有知识和技能的。图的展现的东西虽然很有用，但终究来说却是不切实际的。
所以，如果我们要让这张图对我们有所帮助，我们应该先了解清楚，图里面交集的部分到底包含了什么？
交集的部分就是我要说的MVPM，即最小可行的产品经理（Minimum Viable Product Manager）。MVPM完美的定义了一个合格的产品经理应该拥有的知识和技能。
但MVPM并不意味着你需要很快速地去精通其中提到的所有技能，这样对于一个小白来说不但不切实际，而且还会有适得其反的效果。相反，你应该把它看作一个小白产品经理刚入行学习的教学大纲。
这篇文章，写给过去那个年轻的自己，写给产品小白，同样也写给那些希望提升自己的产品老鸟。为了和上面那张图里面的三个圆一一对应，我将我要说到的点分为技术、商业和用户体验三个大点进行描述。并且，每个大点相对应的指出三个必须聚焦的知识或技能和一个不能踩的坑。为了让更多的小白和行外人能快速读懂，我将尽可能描述得通俗易懂。
一、MVMP：技术
1.技术栈
当程序猿们在谈论技术栈时，程序猿们在谈论什么？ “技术栈”是一个相对抽象的概念，它可以泛指用来实现你的产品功能的各种前后端技术，它让一切产品需求得以实现。从一个用户加载到你的产品的登录着陆页，到他主动地把他的用户账号注销，技术栈都默默地在背后处理着这一切。 如何快速学习——请教开发大神们，让他们帮你从“一览众山小”的角度去review一遍所有的技术栈。接着把你听到的各种技术记录下来，并且快速的谷歌一遍所有的专业术语。这样，你就会大概了解到产品开发中所用到的每种技术的优点和不足之处，也会清楚这些技术在内部是如何和谐并高效地运作的。记住，在快速了解技术时一定要以“一览众山小”的角度切入，否则你会掉入技术学习这个大坑无法自拔。 成为一个更好的PM——当程序员们在办公室里讨论产品架构应该如何搭建，顿时，各种专业术语总会满天飞。这时，也许你会一脸懵逼。但是，当你了解了技术栈的相关知识，这意味着你可以跟得上他们讨论的节奏。假以时日，你将会逐渐明白程序猿们到底在讨论哪一个层面的技术问题（比如，是前端的问题还是后端的问题；是数据库的问题还是服务器的问题…）。通常来说，一个产品的技术栈中需要接触的东西越多，涉及的层次越深，那么这个产品的需求变更后的开发难度就越大，风险也更大。当你了解了这一切，在下一次考虑如何解决产品问题时，你可能就会用另一种方法去解决问题。2.系统架构
如果说刚刚提到的“技术栈”代表着那些经常被我们使用到的技术，那么系统架构就控制着这些技术如何共同搭建，高效运转，并最终诞生出产品的。与更抽象的“技术栈”比起来，系统架构则更加贴近于产品本身，它的设计构想恰恰会体现出用户的产品需求。 如何快速学习 ——同样的，还是要请教开发大神们，让他们给你画一个系统的架构图，那么你将会得到类似一张这样的图：
在看到这张图后，你懵逼的概率达到了百分之99，但是，一定要蛋定。首页，你必须跪教（跪着请教）程序猿大哥们，让他们告诉你图中所有不同形状的组件（包括各种客户端、服务端及数据库）都是干什么用的；如果你请教的姿势是对的话，那么，他们会告诉你哪些东西是用来处理网络请求的，哪些是用来实现业务逻辑的，哪些是用来储存用户数据的。
当然，你不要作死的认为程序猿哥哥在忽悠你，他刚刚说的一切对你都是非常有用的。
成为一个更好的PM——当你大致了解了系统的架构后，你就会逐渐的像程序猿们一样的把你的产品看做一个系统来去思考。这样，当你清楚的了解了产品中的每一部分在总体中起的作用时，你就会做出更好的决策和需求权衡，在考虑需求方案时，会更加的周全以及更加清楚它的可行性。
一般来说，如果一个产品中的某个模块与系统的其他模块的关联越多，那么它的变动则会越复杂和困难，因为产品中的其他模块都要依靠它来提供数据传输或是功能支持。如果在实现某个功能的时候，你的产品需要改变的模块越多，对外部的数据或功能依赖越多，那么，你的这个功能将会很难执行并实现。
在大公司里，产品执行工作中涉及的不同模块的数量通常是和你要去沟通的部门或团队的数量是一样的，所以，这也意味着你要获得同等数量的人的同意和支持。
3. 数据结构和API
数据结构负责把产品中用到的各种数据高效的组织起来，并且标准化了这些数据是如何与其他“信息”关联起来的。而这里说的“信息”指的是用户、产品、信用卡等等，那些具体的东西。这些东西通过确定的、结构化的方式相互关联，例如一个用户可以拥有很多的产品，但通常情况下只有一张信用卡。 数据结构与上面说到的系统架构有非常紧密的联系，之所以这么说，是因为特定的数据信息是存放在特定的系统模块中的。你的用户信息以及与用户相关的产品数据可能存放在A模块中 ，但是由于用户隐私信息的敏感，信用卡信息可能会存放在B模块中。所以当你有一个需求是需要将一个产品拥有的用户的信息展示在一个列表中时，那么这将相当简单，因为这些信息是存放在同一个模块中的。但是，当你需要知道这些用户当中哪些用户绑定了信用卡时，A模块就需要与B模块进行关联，以此达到数据传输的目的。这样做有一定难度，需要用到API来去实现。 API是建立在数据结构之上的，它体现了不同的两个模块（前后端）之间在是如何进行通信以及做数据传输的。更重要的是，API也可以让你与第三方（外部模块）进行数据上的通信。当你在谷歌地图上叫Uber时，谷歌地图则会调用Uber提供的API，与Uber的相关模块进行数据通信。大多数的产品会有它的“公共API”和“私有API”，“公共API”是产品开放提供给外部所有人都能使用的API，也就是我们经常会用到的“第三方API”，“私有API”则是我们自己的产品使用不对外公开的API。 如何快速学习——第一时间去了解你产品开放或提供出来的一些API。这些API大多数都很容易找到，它们大多数存放在产品开发文档下的API接口文档中。当你看到这些API接口文档时，你会看到上面写着一些代码，这时，你到底会不会被这些代码吓一跳将取决于你的背景知识；但是，如果API接口文档写得比较规范的话，你还是会比较容易读懂它们的，毕竟他比写在程序上的代码还要简单。API通常常体现了一个产品的内部数据结构，这样，当你研究完API时，也会对产品的数据结构有一个大致的了解，可谓一石二鸟。 成为一个更好的PM——了解清楚产品的数据结构，它可以扩展你的能力，让你知道你可以利用哪些信息来创造出更好的产品，同样的，你也会清楚获取该信息的难易程度，自己心里会有个底。了解清楚产品的API意味着你也了解清楚了你的合作伙伴和第三方开发者会从你这里获取到什么样的信息，所以你也应该知道产品上哪些外部合作或是可行的。一个产品拥有的可扩展性是其最具有价值的属性之一，一个产品能与外部的产品（你的用户每天都在使用的产品）进行良好的协作变得越来越重要。4. 不能踩的坑
别去敲代码。先别误解我的意思，我也喜欢敲代码，他确实也让我变得更加专业；但是，除非你负责的是一个包含着黑科技的产品，否则你不需要依靠敲代码来去成为一个好的产品经理。如果你正以产品经理的身份去敲代码，你就要问问你自己是不是在干着一份高回报的工作，又或者是你根本不知道自己应该做些什么。但是话说回来，我觉得一个人至少开发过一次APP产品或是Web产品，并把产品部署到生产环境上，那么这会是一次值得而又好玩的经历。二、MVPM：业务
1. 项目管理
我知道这很枯燥，我也不喜欢做项目管理，但是它却非常重要。如果你不能很好的运作管理一个项目，那么你将永远不能成为一个好的产品经理。 如何快速学习——这是一件很困难的事情。想要成为一名好的项目经理，一方面需要大量的经验和时间积累；另一方面，项目管理是一个关于人际处理的问题。你需要发时间去了解那些跟你一起工作的同事的性格，而你要怎么样跟你的同事交流同样也取决于你的性格。 话虽如此，你还是可以学习一些软件方面的知识来去加速积累你的硬技能的。- 了解产品开发过程中的基本知识，这样在和团队共同工作时你将会有更多换位思考的能力。学习版本控制的知识和技能（比如GIt）、了解协同开发的工具（比如GitHub）、了解质量控制（QA）的流程，最后还要知道你的产品是如何以及何时部署到用户手上的。 2.了解那些常见的困扰团队的问题，并且要知道解决这些问题的方法。在项目管理的过程中，你也许会遇到一些新的项目管理方法，例如敏捷开发流程、Scrum开发流程、看板开发流（具体意思可自行Google）。不管你的团队有没有用这些项目管理方法，他们背后的哲学精髓都是值得你去学习的。 3.了解清楚团队的决策方式，弄清楚你的利益相关人。一般情况下，他们可能会是你的用户、你的老板、团队成员的上司，亦或是其他产品经理。确保团队中每一个人都清楚自己工作的进展和未来的方向，同时也要让同事们清楚他们关心的事情的进展和方向，或者你去了解清楚他们到底关心什么。
2. 业务模型分析
工作上的事情如果没有事先做好计划和估算，是很少可以出色的完成的。产品也一样，任何一个产品都应该定下一些关乎产品成功的量化目标，例如用户增长量、产品功能接受度、产品收入等等。 当你的团队在争论着下一个版本应该优先上什么功能时，如果你能为产品提供一个指导产品发展方向的参考模型就显得十分重要了。 如何快速学习——所以，是时候建立一个产品发展的参考模型，一个好的模型应该清晰的展示以下两点： 产品建设成本的预估：- 获取一个新用户的成本是多少？
- 产品的运维成本是多少？
- 实现产品的每一步目标需要的成本是多少？
- 未来一年产品会怎样一步一步向目标发展？未来三年呢？
- 团队需要招聘多少人来去支撑产品的优化和运维？
- 长期来看市场力量对产品会有怎样的影响？例如成本下降、通货膨胀以及行业竞争等等。
3. 数据收集与分析
一个团队如果能够用独立的收集各种数据，那么对于团队做出快速决定是非常重要的。对于那些复杂的数据分析，依赖其他人来帮你你收集数据不但是浪费别人的时间，而且这样也不会让你领会到数据的真正作用；因为那些懂得做数据分析的人都知道对数据的理解和敏感度是通过不断对数据的挖掘和分析养成的，而并不是你天天看着PPT里那些漂亮的图片就能学会的。 依赖别人来去收集和分析你的数据同样也会削弱根据数据来去做决定的能力。几乎每一天我们都在决定着产品在某个特定的用户场景应该如何去设计，这时有数据作为支撑的决策就会变得很简单。 如何快速学习——你的终极目标是做到可以通过自己的能力获取产品的数据。当然，你是要通过写SQL语言还是通过拖拽控件来获取数据就要看你的产品采用是怎样的数据技术支撑。不管用什么方法，你还是需要投入时间去学习相关获取数据的工具，自己找时间谷歌吧。 成为一个更好的PM——当数据很容易获取时，你就会更加频繁地使用到它。不管你是考虑着产品的下个版本应该做什么，还是看看产品的进展如何，你都会形成条件反射，会把数据作为你做决策的重要输入，而这样你的产品将会变的更好。4. 不能踩的坑
一个有着商业学位的朋友给我的教训：不要把你的时间浪费在做什么商业策略、三年计划、或者其他MBA的事情上。虽然我还不至于跟你说这些东西啥也不是，但是可以肯定的是这些东西在做产品上是不怎么行得通的。 弄清楚产品的愿景，找到实现愿景需要解决的问题，想出解决问题的办法，然后尽快地通过用户来验证你的办法，并不断重重复以上步骤。三、MVPM：用户体验
1. 了解产品的设计模式
大部分产品经过长时间的打磨后，都会形成自己的设计模式，不管你有没有刻意地去规划它。设计模式是指在产品中一直使用着的相同的视觉效果和交互组件。“产品按钮上的字体使用25号大小的字体；所有的表单都不超过3个字段；每次的报错都会有一个爆炸的音效反馈，并给用户发送一份关于这个错误细节的邮件。”——这些都是设计模式。
了解产品的设计模式是让你清楚你的用户是如何理解你的产品以及让他们很快的接受你的产品的新功能的关键。如果你以前都是用绿色的写着“添加新功能”的按钮，通过点击来启动某些功能，这次你把它换成了橙色的写着“来点新意”的按钮，这样你可能会把用户搞晕的。
随着产品的不断成长，运用一致的产品设计模式将变得越来越重要，因为这样既能够样产品团队中的每个人独立地工作，也能够让产品看起来更加浑然一体。
设计模式一般是会和技术模式相互和谐发展的，像一些样式或是前端组件，技术都是可以拿同样的代码来复用的，这样开发的速度和效率都会更高，因为他们不需要再去设计或是实现一个同样的功能了。
如何快速学习—— 请教一下你们的设计师，他们都应该知道这些设计模式，当然也希望他们能给你一份设计模式的相关参考。同样的，请教一下你们的前端工程师，他们也会给你一个关于设计模式的相关参考。
成为一个更好的PM—— 坦率地说，使用设计模式会让你产品工作更加简单更加快速。设计模式让你站在设计大神的肩膀上，以至于你的产品做得非常简单易用。如果你想打破产品现有的设计模式，你必须想清楚为什么要这么做，准备好向团队说清楚为什么这么做对产品的长期健康发展是有必要的。
2. 知道怎么做用户体验调研
产品经理应该代表着用户的声音。如果你不懂你的用户，你永远也不可能打造出牛逼的产品。从做一个面对面的用户访谈，到量化分析数以万计的产品行为，了解清楚做好用户研究的基础，对你的工作来说是非常必要的。 如何快速学习——有用的研究是一个非常大的领域，所以避免把你引到一个大坑里去，我推荐你搞懂以下几点：- 了解清楚研究样本的大小，知道怎样计算统计结果；
- 了解清楚怎样让你的样本更具代表性，以及它为什么如此重要；
- 了解清楚在调查和采访过程中如何提出不带偏见、不具诱导性的问题；
- 了解清楚如何得出全面的研究结果并避免得出错误的结论。
3. 知道怎样把你的想法输出为原型
这里所说的原型是指能够做出可以高效表达你的想法的产品视觉原型草图。原型做得足够好，你就能做好以下几点： 清晰的表达出产品的概念：要传达好一款产品的体验，无论是从口头表达还是书面表达，都是非常困难的。而一个可以让人们看到产品大致样子的原型（最好可以加上交互效果；你不需要写代码就能实现这一切）会有效十倍。 之所以这样，是因为有两点的原因：一、产品原型可以清晰地描述用户最终如何与产品进行交互；二、因为人类天生喜欢视觉化地思考，可视化的原型可以拉平不同领域的看法和差异，以至于团队里的每个人都可以用共通的语言来沟通，并高效地给出自己的意见。在必要的时候帮设计师一把：
在大多数项目中，产品设计走在产品开发的前面是非常重要的。设计师努力“跑在开发的前面”，因为一旦开发人员按照既定的方向去开发产品，之后产品方向的变更产生的成本将会很高。 因为很多产品的设计都是需要不断的迭代并且是与产品开发并行的，当产品设计遇到瓶颈（例如，用户调研证明设计是不够好的），设计的进度就会很快的落在开发后面。遇到这种情况的时候，产品经理就应该能够马上卷起袖子充当设计师的助理，让设计图能够按时交付，保证产品的开发进度。如何快速学习——这个我就不花时间说了，赶快把Sketch用起来吧，它就是微软画图和Photoshop的完美结合、一个神器。 成为一个更好的PM——通过原型，你可以告诉人们你在想什么，而不是假装他们已经懂你的意思了。同时，你也会从你的同事那获得更多更好的反馈，也减少了沟通不畅导致的人力浪费。
MVPM
我不会把学习以上说到的东西不当回事。学习以上的东西并不简单，它需要花费很多的时间，所以，一步一个脚印去解决每一个难题，并为自己学到的东西感到高兴。我希望这篇文章能够在你成为牛逼亦或是最小可行的产品经理的路上，给你带来一点帮助。译后随感
一个平常的夜晚，翻Medium看到了这篇文章，认真看完觉得写得很不错，又想起了在掘金看到很多人翻译各种文章。 于是，就有了翻译此文的想法。 第一次尝试翻译一篇全英文的文章，译前也在看了许多不同类型的文章的原文和译文。全文翻译下来并不是易事，断断续续的利用空闲时间翻译，也花了好几周的时间。 翻译，是一场漫长的修行。 最后，如果你想一睹英文原版文章，请自备梯子，点击Medium原文连接。 本文转自微信公众号：addoilbuddies【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
