MVPM：最小可行产品经理

编者按：本文作者Brandon Chu，译者梵天，36氪经授权转载自译者微信公众号“梵天Daozen”（ID：fantian-daozen），查看原文地址点这里。

你很可能看过下面的这个著名的图了，它很直观告诉你产品管理就是这三种技能的交集。

因为简单明了，这个图成为了产品管理中最广为传播的文化因子之一，也为产品管理的准则做出了贡献。

很久之前，当我还是个产品菜鸟时，这张图帮我意识到我需要广泛涉猎学习。但是它没有告诉我应该专注于哪些方面，于是我开始勇尝百草——然后事后诸葛亮而言，悲剧了。

我们并没有那个美国时间去学习这三个圆圈里面的所涉及的所有东西，所以这张图虽然很有用，但终究并不实际。

要让它更有用，我们应该反过来看，搞清楚这三个圈之间的交集到底包含了什么。

我把这个交集称作最小可行产品经理（MVPM），其中定义了一组知识和技能，掌握了这些能够让你成为一个可以解决绝大部分问题的产品经理通才。

MVPM绝对不是告诉你，要成为一个强大的产品经理需要精通里面提到的技能，对于新人而言这既不实际又会适得其反。相反，要把它看作是一个“传说中的产品管理课程”的大纲而已。

我写这篇东西，是写给过去那个年轻的自己，写给产品新人，也是写给那些寻求上进的老鸟。为了和上面那张图保持一致，我把技能点按照三个大类进行划分，每个大类我提出三个要重点关注的关键的概念/技能，再加上一个不该入坑的。为了方便不熟悉相关主题的人，我会尽量写得平易简单。

1. 技术栈

当工程师们提到“技术栈”这个词的时候，它的意思是指那些应用到你的产品上的技术。从用户加载你的着陆页（Landing Page），到他们删掉自己的账户，技术栈里的技术处理着一切。

最快学习方法：去请教你的开发哥哥帮你概览一遍技术栈，然后把每一种技术记下来。快速地谷歌一下那些术语，你就大概了解到每种被选择的技术的长处和折中之处，以及这些技术之间是怎样和谐共处的。保持概览的程度就可以了，否则你可能会一个不小心就入了大坑（在你谷歌的时候加上“trade offs + benefits + vs” ）。

这如何让你成为更好的PM：开发哥哥们在讨论如何构建时会术语满天飞。如果你了解技术栈的话，起码你能跟上他们的思路，假以时日你还会了解到他们在讨论涉及到多深的技术栈。一般而言，一个变更所动用到技术栈里面的技术层面越多或者越深，就越复杂，风险也会更大。知道这些的话你也许就会重新考虑另一种解决问题的方式了。

2. 系统架构

如果说技术栈代表那些用到的技术，那系统架构就意味着这些技术是如何搭建组装成产品的。相对而言，技术栈基本上是关于纯粹的技术能力（这些技术能做什么），而架构则在其设计之中融合了客户的需求。

最快学习方法：去请你的开发哥哥把系统架构画给你看，然后你应该会拿到类似的东西：

拿到之后，首先，要保持淡定，让开发哥哥帮你过一遍每个组件（盒子）是干什么用的。一些是用来处理网络请求的，一些是用来存储“业务逻辑”的，还有些是用来存储保存的数据。

然后，它对你很有用，不管你信不信，反正我是信了。

这如何让你成为更好的PM：当你了解了系统的架构之后，你会更多地像工程师们一样，把你的产品当作一个系统来考虑。了解到系统里面的每一个组件是如何为整体工作，会帮助你做出更好的选择和折中。

一般而言，系统里面连接最多的组件通常做改变也是最复杂的，因为太多其他的组件要依赖他们的数据或者功能了。你要实现的功能需要改动的组件越多，你就会遇到越多的依赖性问题，你的项目就会越难实施。

在大公司里面，你要改动的组件数量通常和你要去沟通的团队/组别数量成正比，你要实施的项目也就要争取到更多人的同意了。

3. 数据模型和API

数据模型把你的产品所涉及到的信息组织起来，同时把这些信息之间如何关联给标准化。我们说的“信息”，指的是像用户、产品、信用卡等等，统称为实体。这些实体之间会以一种确定、结构化的方式相互关联，例如一个用户会有很多产品，但只会有一张信用卡。

数据模型和系统架构紧密相联，提现在特定的实体存在于特定的组件。你的用户模型可能存在于组建A当中，产品数据可能也一样，但是由于敏感性，信用卡信息会存在于另一个组建B。如果你的需求需要展示拥有某个产品的所有用户，这个功能会相对简单因为这两个信息存在于同一个组件。但是如果你需要知道哪些用户绑定了信用卡，这样组件A就需要连接到组件B来共享数据了。这种需求实现起来会更困难，要完成需要API。

API是建立在数据模型的顶层，代表着任意的两个组件相互之间是如何沟通和交换底层模型信息的。重要的是，API让你可以和外部的组件沟通。当你在谷歌地图上呼叫Uber时，谷歌地图应用便和Uber的一个组件进行通讯。大部分的应用会有公共API和私有API，分别可以让网络上的所有人或者只有你自己能使用。了解你的公共API是搞明白你的产品能怎样和外面的世界打交道的关键。

最快学习方法：你应首先聚焦于了解你的公共API。这些公共API通常容易找到，经常在你们的网站开发文档里面。当你和它们相遇时，你会看到很多代码，你的背景知识可能决定你会不会被这些代码吓尿。不过如果你们的文档比较像样的话，这些代码就不重要了，你应该可以读懂它们。研究你的API的一个妙处在于API往往会体现大部分内部的数据模型，这样你就一举两得了。

这如何让你成为更好的PM：了解你的数据模型可以扩展你的能力，包括知道你能利用哪些信息来创作更好的产品，以及知道要获取某个信息有多难。了解你的API意味着你了解你的合作伙伴和第三方开发者能够你的应用中获取到什么信息，从而知道怎样做整合是可行的。一个程序的可扩展性是最有价值的属性之一，而当今同时能和其他产品（你的用户可能每天都在用的产品）良好协作也正迅速成为筹码。

4. 远离这个坑

别去编程。先别黑我，我喜欢编程，编程也能帮你变得更好，但是除非你在做一个高技术含量的产品，你不需要为了成为一个强大的PM而去学编程。如果你发现自己正在以PM的身份去写代码，你可能就要问问自己在做的是不是高回报的工作，还是说是因为自己也搞不清楚你应该做点什么其他的活。话说回来，我觉得自己开发并部署至少一个应用其实也是个值得又好玩的经验了。

1. 项目管理

我知道这很枯燥，我也很讨厌做项目管理，不过它真的很重要。如果不能运行好一个项目，你就永远称不上是一个好的产品经理，就这么简单。

最快学习方法：这一项其实很难。要做一个好的项目经理需要很多的经验和时间的积累。你可以从书本上读到很多，但终究到底这是人际的问题。要花时间去学习工作中会遇到的各种各样性格的人们，而怎么和他们打交道的建议是否可行，也得看你自己的性格是怎么样的了。

尽管如此，这还是有些软件相关的东西，学习它们可加速你的学习曲线：

了解产品开发过程的基础，可以帮你和团队更有共鸣。学习版本管理（Git）、协同开发（Github）、QA过程，还有大概了解代码是怎样以及何时部署到给你产品的用户。了解困扰软件团队的常见坑，以及其他人用了哪些流程来尝试解决它们的。你会遇到一些例如敏捷、Scrum或者看板管理之类的概念。不管你的公司有没有采用，这些解决方案背后的哲学都是值得研究的。了解公里的决策方式，搞清楚利益相关人。这些一般会包括你的客户、老板、团队成员的上司、以及其他PM。想办法确认大家都在他们关心的层面上，清楚项目的现状和方向（你也得搞清楚他们他们关心哪个层面）。这如何让你成为更好的PM：你可以和你的小伙伴一起做出更多事情，而且大家会喜欢和你工作，大家讨厌管理糟糕的项目。

2. 模型化分析

未经计算量化过的事情很少能做好。任何一个产品都应该有和最终成功相关的量化目标，基础的数据包括用户增长、功能接受度、收入等等。

当你的团队在争论下个版本要做的功能那个最为优先的时候，你能设计一个可以指导产品发展方向准则的模型就显得十分重要了。

最快学习方法：打开你的Excel。一个好的模型应该能清晰地展示两个东西： 一个产品的经济基本单位和创造这些单位的预估：

获取一个新用户的成本是多少？用户使用产品的成本是多少？达成你的商业目标上的成本是多少？对未来的影响和达成这些的预估：

明年这个产品将会如何向目标发展？未来三年呢？我们需要招聘多少人来优化和维护它呢？市场状况如何呢？例如长期内的成本下降、通胀、竞争等等

这如何让你成为更好的PM：上述的为你的产品打造模型的练习可以很好地测试你的直觉假设，也保证了你的产品有足够的潜能值得为之奋斗。这也可以把你的工作变得更简单，它既能让你的项目变得更有说服力，和你的利益相关人共鸣，又能帮助你分析项目的机会成本，和其他项目进行比较。

3. 收集和分析数据

独立收集数据的能力对于快速做出决策很重要。除了那些最常涉及到的分析以外，依赖别人来帮你收集数据不仅会浪费他人的时间，也没办法获得真知灼见，因为那些真正做过分析的人就会知道真知来自于对数据的不断探索，而不是通过你梦想中那种完美的图表。

依赖别人也会降低你根据数据决策的能力。产品在特定的场景下应该如何设计，几乎每天都要做相关的决策，这时候拥有数据来为决策做支撑的话，你和你的小伙伴也会更为自信。

最快学习方法：你的目标做到数据的独立。你公司的数据基础设施决定着你得用自己写SQL语句还是只需要拖拖控件就能够获取数据。不管是哪种方式，你需要投入时间来学习这些工具，自行谷歌吧。

这如何让你成为更好的PM：当获得数据很简单的时候，你会更多地去使用这些数据，这会让你更加勇于不断尝试。不管你是考虑下个版本做些什么，或者是看看进展如何，你都会形成条件反射，把数据作为你决策的重要输入，这样你的产品就会变得更好。

4. 远离这个坑

从学商科的人那吸取教训吧：不要浪费时间去搞什么战略商业案例、三年计划还有其他MBA的东东。虽然我还不至于叫这些东西垃圾，不过这些在软件行业是行不通的。搞清楚愿景，找到实现这个愿景需要解决的问题，假设解决问题的方案，然后尽快用真实的用户来验证你的方案。周而复始。

1. 了解你产品的设计模式

不管是不是刻意安排，大部分的产品会慢慢形成自己的设计模式。模式是指在产品中持续使用相同的视觉和交互控件。所有按钮上的字体都是25px；所有表单都不能超过3个字段；每次错误发成我们都会弄个爆炸声然后把详情发邮件给用户——这些都是模式。

了解你自己产品的模式是让你的用户如何理解你的产品，还有如何持续有效地让他们接受新特性的关键。如果你以前都是让用户通过写着“添加新功能”的绿色按钮来启动，然后这次却把它换成“来点惊喜吧！”的橙色按钮，你会把用户给弄晕。

当产品不断成长时，一致地运用模式会变得越来越重要，只有这样团队才能独立地工作还能让产品保持一致。

设计模式一般会和技术模式和谐发展，例如风格指导和组件，他们是基本的可重用代码库，这样可以帮助团队保持高效，因为他们不需要重新设计和重新实现同样的功能了。

最快学习方法：和你的设计师聊聊，他们应该会知道这些模式和（希望能）给你一份风格指导的链接。同时拜访你的前端工程师，他们应该同样地能给你一份模式库。

这如何让你成为更好的PM：我就直说吧，沿用模式来设计产品更简单也更快。模式让你站在过去你的团队的决定的肩膀上，而那些决定是能让产品对于用户来说更易用。如果你要打破现有的模式，那得拿出足够好的理由来这么做，要准备好说明这为什么对于产品的长期是有益的。

2. 了解怎么进行用户体验研究

PM应该代表着用户的声音。如果你不清楚你的用户，那永远不可能打造伟大的产品。从面对面做一个人的访谈，到量化分析千万用户的行为，了解如何做好的研究的基础是工作中的迫切需要。

最快学习方法：有效的研究是一门大学问，所以相对于把你引导大坑，我推荐你集中了解以下的方面：

了解样本大小和如何计算统计显著性如何让你的样本具有代表性和为什么这很重要如何在调查和访谈中作无偏见、无诱导性的提问如何综合出结果和避免错误的结论这如何让你成为更好的PM：通过不断经常地和你的用户一起来测试产品，你可以解决掉很多的产品开发中的猜测（和风险）。在你的项目开始之前，你应该通过测试来验证你要解决的问题真的是个问题。当你在设计和构建时，你要测试产品的设计是否易用和能够解决用户的问题。在上线以后，你应该验证你想为用户解决的问题确实解决了。

3. 了解怎样把你的想法输出为原型

在这里所说的原型指的是能够做出可以有效表达你的想法的视觉草图。原型要做得足够好，你才能做到：

清晰地传达产品的概念 要传到出一款产品的体验，用口头还是用书面来表达都是及其困难的。而用一个人们可以看得见（最好能交互）的原型（你甚至可以不用写代码就做出来）会有效十倍。

之所以这样有两点原因：首先，这促使产品通过描述用户最终如何和产品交互的方式来表达产品，第二，因为人类天性喜欢视觉化地思考，原型可以提供一个平台，让团队大家用共同语言沟通和有效给出他们的意见。

当设计落后或者缺失的时候填坑 大部分情况下，保持产品设计进度在开发之前很重要。设计师们努力“领先着开发进度”，因为一旦按照确定的方向去开发，开发人员的变更成本会很高。

因为很多产品的设计都是需要不断迭代以及和开发并行，当设计遇到返工的时候（例如用户调研证明设计是无效的）进度就会变得迅速落后于开发。遇到这种情况的时候，PM要能够马上动手帮设计师打下手，帮助设计图能按时完成来保障开发的持续进行。

最快学习方法：我就不花时间解释为什么了，尽管开始去学习Sketch吧，他就像M$的画图程序和Photoshop两者的完美结合。

这如何让你成为更好的PM：通过展示原型给你的伙伴，而不是假装他们已经懂了，你会从你的队友那获得更良好的反馈，也减少了沟通不畅导致浪费人力的风险。偶尔能够做出实际可以看到的东西那是极好的。

4. 远离这个坑

别想着去做视觉设计高手。你可以去做出很精细的界面，但是这种能力是多余的，也会打击到那些深入研究产品设计的同事的信心。除非你真的是个设计大师，不然你可能以为自己很擅长，但实际上根本不是那回事。

MVPM

我不想小看学习以上所述的东西。学习这些并不简单，要花很多时间，一步一个脚印而自得其乐吧。我希望这篇文章能够帮你成为一个强大（或者说最小可行的）的产品经理。