MVPM: Minimum Viable Product Manager最小可行性产品经理——第一期

刚开始入行的产品经理小白们总是试图去学习“用户体验”，“技术”和“商业”的全部知识。疲于学习，而找不到产品经理的侧重点。事实上，我们应当努力专研三者交叉范围内的知识。

你肯定看过下面这张图，这张图展示了产品管理是多种技能的集合点。

最小可行性产品经理告诉你不要去学习所有的知识，因为这不切实际而且效率低下。本文将依照这个图表来分别介绍三个学科的中，产品经理需要掌握的部分。除此之外，我还会介绍一些你尽可能不要关注的知识。

第一期将从技术方面来谈谈产品经理应该重点学习什么。之后两期会陆续向大家介绍用户体验和商业方面的知识。

1.堆栈

堆栈是一个在计算机科学中经常使用的抽象数据类型，是两种种数据结构。当工程师们提到“堆栈”时，他们正在谈论用于为产品提供功能的技术层。从客户加载你的登陆页面到删除他们的帐户的那一刻起，堆栈中的技术就能处理一切。

最快的学习方法是让一个高级工程师跟你讲解堆栈。写下每种技术的名称，通过搜索这些词汇，你能够获得高层次的认知，并能够理解数据之间是如何协调配合的。

这如何能使你成为一个更好的产品经理呢？-当工程师们在房间里用技术术语讨论如何构建一些功能时。了解“堆栈”意味着至少可以跟上他们的节奏，随着时间的推移，您将开始了解堆栈的深度。一般来说，堆栈中需要接触的层越多，层次越深，变化就越复杂，风险也就越大。知道这个概念，能够帮助你以技术思路看待产品。

2.系统架构

如果堆栈代表了正在使用的技术，那么系统架构代表了这些技术是如何构造成一起工作来交付产品的。尽管堆栈主要是关于原始技术能力，但产品的系统结构在设计中包含了客户的预期行为。

让开发给你发一张系统架构图，你可能会看到下图所示：

系统架构能帮助你了解系统中每个组件（方框）的内容。有些是用来处理“网络请求”的，一些将容纳“业务逻辑”，另一些是用来“保存数据”的。

这如何能使你成为一个更好的产品经理呢？-当你理解了系统架构，你就开始像一个系统一样思考你的产品。了解系统中每个组成部分对整体的贡献，有助于你做出更好的决策和交易。一般来说，系统中拥有最多连接的组件是最复杂的，因为许多其他组件依赖它们来获取数据或功能。为了完成构建，涉及更改的组件越多，依赖性就越大，项目执行的难度也就越大。

3.数据模型及其api

数据模型组织产品所使用的信息，并标准化这些信息如何相互关联。通过“信息”，我们真正谈论的是用户、产品和信用卡，它们统称为实体。这些实体可以以某种结构化的方式相互关联；例如，用户可以有许多产品，但只有一个信用卡。

数据模型与某些特定实体的“活”在某个组件中的体系结构密切相关。您的用户模型可能存在于组件A中，因此产品数据也可能存在，但由于它的敏感性，信用卡存在于组件B中。如果您的特性需要显示哪些用户在列表中拥有某个产品，那么这是很容易的，因为它们生活在同一个组件中。但是，如果您需要知道哪些用户存储了信用卡，则组件A需要连接到组件B，以便共享数据。这是比较困难的，为了完成它，他们需要一个API（应用程序编程接口）。

API是建立在数据模型之上的，它代表了两个组件如何相互交流和交换关于它们的底层模型的信息。重要的是，API还允许您与外部组件通信。当你从谷歌地图呼叫Uber时，谷歌地图应用程序正在与Uber的一个组件交谈。大多数应用程序都有公共API和私有API，这些API可以由网上任何人或您指定的那些人使用。了解您的公共API对于理解您的产品如何与外部世界进行交互是至关重要的。

最快的学习方法应该首先关注对公共API的理解，在你的网站开发者文档中就能找到。

这如何能使你成为一个更好的产品经理呢？-了解你的数据模型可以扩展你的能力，知道你能利用什么信息来创造更好的产品，以及获取信息的难度。软件的可扩展性是它最有价值的属性之一，能够与其他产品很好地合作，是一条成功捷径。

4.你不该集中注意力的地方

编程。除非是一个技术含量很高的产品，否则不要花大量时间去学习编程。编程不是PM必须要会的技能。

在接下来两篇文章会为大家带来关于商业和用户体验方面的知识，敬请期待。