大家之前可能已经看到过这张图表，这张图表很好地展示出：产品管理是多种技能的集合。
很久以前，作为一个年轻的实习产品经理，这张图表让我意识到，我需要扩充学习的广度。但它却没有告诉我，重点应该放在哪里，于是我开始努力学习每一样东西，事后看来，大错特错。
这世上哪有那么多时间，让你把三环中的每一样都学起来？所以这张图表或许有用，但不切实际。或者说，根本算不上有用。
要说更有用的，应该是弄明白那个交集究竟是由哪些部分组成的：
我们把这个交集称之为最小可行产品经理（MVPM），当中包括了一系列知识或技能，这些知识和技能几乎可以解决实际工作中的所有问题，让你实实在在成为一个产品管理通才。
MVPM绝不意味着你一定要对这些技能达到熟练掌握的程度。对于想要入门的人而言，这一点不仅不切实际，还会适得其反。我们应当把这些技能当成是产品管理这门学问的课程大纲，了解即可。
我写这篇文章，一是为了年轻时候的自己，同时也是为了新入行的产品经理，甚至是一些在业内工作多年，经验颇丰，但还想更进一步发展的产品经理。
为了跟图表一一对应，我把所需技能按照图表上的科目进行了划分，我会提到三样关键概念/技能，以及一样不需要关注的概念/技能。鉴于很多读者此前完全没有接触过这些学科，我会尽量用平实的语言来阐述。
堆栈
当工程师提到“堆栈”的时候，往往谈论的是为产品提供功能的技术层面。从客户开始访问你的登录页面到删除账户，“堆栈”会层层把控。
想要了解“堆栈”，不要从最基础的开始学，最快的方法就是去找一个工程师，从较高的层面带你过一遍。你要做的就是记录下每一项技术的名称，通过谷歌快速浏览这些术语，权衡每一项技术的利弊得失，以及它们如何在一起协同工作。做这项工作的时候，一定要高屋建瓴，否则很容易就会被绕进去，两眼一抹黑。
为什么这样做就会让你成为一个更好的产品经理呢？
因为工程师在谈论产品设计构造的时候，从来都是专业术语满天飞。了解这些术语，你至少能跟得上他们的节奏，随着时间的推移，你就会慢慢耳濡目染，更深入地明白他们都在谈些什么。
通常，他们谈论中涉及“堆栈”的层面越多，或涉及的层面越深入，就意味着修改越复杂，风险度越大，明白这一点，你就知道要重新考虑一个问题解决方案了。
系统架构
如果说堆栈体现的是技术层面，那么系统架构体现的就是这些技术如何架构才能合力打造出一款产品。堆栈主要是一些未经实际检验的技术能力，产品的体系结构则包括了客户的预期行为。
想要了解系统架构，最快的方法就是让工程师画给你看。你要做到的是：
首先，不要恐慌。让他们带你过一遍系统中的每一个组成部分，了解其功能。其次，不管你信不信，这对你很有用。
为什么这样做就会让你成为一个更好的产品经理呢？当你弄明白架构之后，你就能开始系统性地看待你的产品，而通常这正巧也是工程师看待产品的方式。对系统中的每一个组成部分对整体有怎样的功用有一个了解，会帮助你做出更好地决定利弊、权衡得失。
通常情况下，系统中关系最复杂的组成部分是最难改变的，因为很多其他组成部分都要依赖其提供数据和功能。在完善产品的过程中，你改变的部分越多，而部分之间的依赖性越强，你的执行难度就越大。
数据模型和应用程序接口
数据模型集成了你产品所使用的各种信息，并对这些信息之间的相互关系进行了规范。通过“信息”，我们才能真正谈论用户、产品和信用卡这些被称之为实体的东西。
这些实体彼此之间会以某种形式有机联系起来。打个比方，一个用户可以有很多产品，但只有一张信用卡。
数据模型和系统架构密切相关，因为某些实体就“活”在特定组件当中。你的用户模型可能就存在于组件A中，那么产品数据也会在这个组件当中，于是因为数据的敏感性，信用卡就会存在于组件B。
如果你需要拉一行列表，显示哪些用户拥有产品，那就非常简单了，因为用户和产品数据都在同一个组件当中。但如果你需要知道这些用户当中哪些拥有信用卡，那就需要把组件A和B相连才能分享数据了。这一步要复杂一些，为了完成这一步，你需要一个API（应用程序接口）。
API是建立在数据模型之上的，负责任意两个组件之间的相互对话和有关底层模型的信息交流。最重要的是，API还会让你和外界组件进行交流。当你从谷歌地图上叫一辆Uber专车时，谷歌地图应用就会和Uber的组件发生对话。
大多数应用都有公共API和私人API，前者任何人都能联网使用，后者则是个人私有的。明白你的公共API至关重要，这样你就能明白你的产品是怎样和外部世界互动的。
最快的了解方法——首先，你应当重点了解你的公共API。很好找的，它通常就在你的网站开发者文档里。找到它们之后，你会看到一大串代码。研究的过程中最棒的一点就是，它们通常会显示出你大部分的底层数据模型，这样你就能一箭双雕。
为什么这样做能让你成为一个更好的产品经理呢？因为通过了解数据模型，你可以扩展自己的能力，知道可以利用什么信息来创建更好的产品，以及这些信息的获取难易度。知道自己的API就意味着你能弄明白合作伙伴或者第三方开发者能从你的应用当中获取何种信息。软件的可扩展性是一种非常有价值的属性，和其他产品（你的用户日常可能使用的）的兼容性也是一大杀器。
不该关注的地方
编程。别误会我的意思，我非常喜欢编程，会编程也会对你的工作有所帮助。但除非是一个高度技术性的产品，否则作为产品经理，你没必要太精通这个。
如果你发现作为产品经理你居然在编程，那么你就得问问自己，你做的事情有意义么？还是你根本不知道该做什么呢？
项目管理
很磨人的，我知道。我也讨厌，但它非常重要。如果你不能把项目运营好，你就永远没法成为一个优秀的产品经理。
最快的方法——这一点是很的一点。一个优秀的产品经理需要丰富的经验和大量的时间积累。你可以通过阅读相关书籍来学习项目管理，但最终落到实处还是人际往来的问题。你要花时间去了解打交道的人的个性，然后对症下药。
话虽这么说，但你一定想要缩短学习曲线的话，也不是没有办法的，你可以做以下三件事情：
1. 掌握一点产品开发的基础知识，这样你就能够和你的团队感同身受。你要了解版本控制（Git）、协同编程（GitHub）、品质保证程序等等，还要大体知道代码应当何时、怎样部署到产品用户中去。
2. 了解困扰软件团队的普遍难题，以及其他人努力解决的工序。无论你的公司最终是否采用，你要知道，从这些方法的背后，你能学到很多有价值的东西。
3. 了解公司的决策制定，标出利益相关者。这些人通常是你的客户、老板，你的团队成员的老板们以及其他产品经理。想办法确保他们每一个人都能意识到项目的状态正按照他们所希望的方向发展（当然首先你要弄明白他们关心的是什么）。
为什么这样做就会让你成为一个更好的产品经理呢？因为你将能够帮团队把各种糟心的事情搞定，这样大家伙就会喜欢跟你共事，没人会喜欢一个管理不善的项目。
模型影响
没有衡量标准的项目很难取得成功。每一个产品都应当有一个量化目标，比如基本用户增长、功能采用率、收入等等。
你需要开发一个模型，让自己的产品和指标一一对号入座。
最快的方法——是时候打开电子数据表了，一个给力的模型可以清晰展示出两件事情。
产品单位经济效益：
♦ 获取新客户的支出。
♦ 服务产品的支出。
创建设想：
♦ 产品在未来几年中会有怎样的改变？
♦ 我们需要雇佣多少人来应对这种改变？
♦ 长期来看，成本降低、通货膨胀和市场竞争这些市场力量将导致什么？
为什么这样做就会让你成为一个更好的产品经理呢？尝试给产品创建一个模型，能够让你很好地检测假设，确保你的产品有足够的潜力，值得去做。
同时，这也会让你的工作更加轻松，因为它会向你证明项目的可行性，和利益相关者产生共鸣，同时你也有机会进行项目对比。
收集和分析数据
能够独立收集数据对于快速决策而言是至关重要的。依赖旁人帮你收集数据，不仅浪费别人的时间，还会降低你对数据的洞察力。而这种洞察力来自于对数据的反复探索研究，而不是凭空捏造出的完美报告。
让人代做数据分析还会降低你做数据相关决策的能力。几乎每一天，你都要做决策，而有数据支撑的决定会让你和你的团队更加有信心，决策方向也会更加正确。
最快的了解方法——你的目标是数据独立性。无论是写SQL查询，或使用拖放界面，都依赖于公司的基础数据架构。你需要好好谷歌一下，了解相关工具。
为什么这样做就会让你成为一个更好的产品经理呢？当信息充斥身边，唾手可得时，你就会更多去使用它，反复去研究它。无论做任何决策，你都会条件反射地将数据作为重要参考因素，这样就会创建出更好的产品。
不该关注的地方
不要浪费时间去做什么商业策略实例、三年计划等等，软件的成功靠这些基本没用。你要去观察，找一个值得解决的问题，创建假设，然后尽可能快地和真实客户互动，验证假设，这一过程请不断重复。
知道产品设计模式
大多数产品设计模式都会随着时间发生调整，无论有意或是无意。所谓模式，就是产品一贯以来的视觉和交互元素。
弄明白你的产品模式，你就能更好地明白用户心里是怎样定位你的产品的，贯彻这个模式，你就能明白怎样增添新功能才最有效，最能抓住用户。如果你之前推出新功能时一直是用绿色的按钮，上面写着“添加新功能”，而这次却换了橙色按钮，写着“让你痴狂”，那用户一定会一头雾水。
随着产品的发展，对模式的坚持显得越发重要。顺着模式走，大方向就不会偏离。
设计模式一致，还会提升团队速度，因为同样的功能，很多代码都是重复的，你就不必重新设计了。最快的了解方式——和你的设计人员对话，他们应该非常了解这些模式，你还可以去问问你的前端工程师，他们也会给你一些模式库的链接。
为什么这样做就会让你成为一个更好的产品经理呢？说白了，沿用模式来设计产品，会让产品设计更加轻松和快捷。立足团队过去的设计决策，会让你看得更高更远，也会让用户更加顺手。如果你一定要更改当前的模式，请确保有充足的理由，如果是为了长期考虑非变不可，那你就动手改变吧。
知道如何进行用户体验调查
产品经理必须了解用户的心声，如果你都不了解自己的客户，那就无法创建出好的产品。从单独一对一沟通，到量化分析数以百万计的用户行为，学会基本的研究方法，非常重要。
最快的了解方法是：
♦ 了解样本规模和如何计算统计价值；
♦ 了解如何规范样本，并清楚其重要性；
♦ 在调查访问中，如何保证提问的公正，避免诱导性问题；
♦ 如何归纳结果，避免结论出错。
为什么这样做就会让你成为一个更好的产品经理呢？通过不断和客户沟通，你可以验证很多猜测。在项目开始之前，你能够验证其可操作性；在产品设计和创建过程中，你可以测试产品易用度，以及自己的产品是否切入了用户痛点；在产品推出后，你也可以验证产品是否很好地解决了用户的问题。
知道如何把点子落实成模型
在这里提到的模型，指的是能够有效表达你的点子的视觉模型。模型足够好，你就能：轻松进行产品概念沟通。
口头或者书面沟通产品体验，难度简直要上天。而模型一设（不用编码也能做到的），难度立马降低十几个档位。理由有两个：首先，它展示出了产品的细节；其次，人都是视觉性的动物。
设计走在发展前面：在大多数项目中，设计一定要走在发展前面。因为对于开发者而言，一旦确定方向，开始创建产品，再想改变，代价就很大了。
产品创建的过程中，设计师都是要反复更改调试的。一旦设计出了问题，产品经理要能卷起袖子上阵，帮助设计师做一些简单修改，这样工程师才能继续工作。
最快的了解方式——从Sketch（草图大师）开始吧，理由我也懒得说了，总之这款应用就像MS paint和Photoshop的结合体，棒呆了。
为什么这样做就会让你成为一个更好的产品经理呢？运用模型向团队展示你的想法，而不是假设他们能理解，这样你才能获得更多反馈，降低因为沟通不畅导致的风险。同时，做一些实际产品出来，感觉也会更好。
不需要注意的地方
会一点设计就行了，别跟设计师抢饭碗，除非你是专家。有时候你觉得你的设计炫酷到不行，但实际上那就是一坨翔。
我不希望大家把这些繁琐的东西全部学起来，这太耗时间，也太累了，所以你可以一点一点充实自己，享受学习的乐趣。希望这篇文章多少能够帮助到大家。