首先，必须要说的是：互联网产品经理的进阶之路，这是一个比较大的话题，我们可能需要分开几次来讨论，因为产品经理本就是一个比较复杂的岗位，涉及设计、运营、技术、营销等多个方面。本次，我们着重讨论的是：就产品设计而言，如何站得更高来思考整个产品的架构？
产品经理的基本功
低年级的产品经理，最重要历练的，是产品的基本功。
在诸多需要的基本功中，我觉得最需要成长的是功能设计的能力，我们常说的产品设计就泛指功能设计。
好的功能设计，我觉得有几个点是很关键的。
1. 简单
讲到功能的时候，首先要提及的，是简单。
很多人都读过一些关于简单的书，比如《简约至上》、《Don’t make me think》等等，这些书无一例外都是在设计思路上给出简单的各种定义。
其实，在简单这件事上，最关键的一个深层道理，是依赖于心理学上的一种被称之为“知识诅咒”的玩意儿。
所谓知识诅咒，就是说：现在我明白一件事情，但是要完整清楚的讲授给你，是很难的；因为我们所拥有的知识背景不同，我们对同一件事情的理解不同。这也就解释了，为什么很多老师在上课的时候索然无味，很多人做Presentation的时候显得苍白无力，这其实是知识诅咒在起作用。
知识诅咒表现在产品设计时，有两个关键的定义，一个是设计思维，一个是用户思维。
我们先来了解一下用户思维。
当我们首次见到一个陌生人时，我们会根据第一印象对这个人进行一个快速的定位。比如，一个帅气阳光，发型齐整，穿着一身休闲装，身高180、身材匀称的男生站在你面前，你的第一反应会是什么？也许是“嗯，这个哥们儿应该蛮有趣的”，或者是“这个小伙儿应该在工作上挺不错”。你应该不会立刻觉得“这是个混蛋，我要远离他”。这是为什么呢？
其实，这是我们的用户思维在起作用，我们首次见到一个新鲜的事物时，会根据我们已有的知识体系进行类比，人类天生的类比能力无比强大，正是因为我们的知识体系中，将“有趣的人、不错的人”这种属性，和“帅气、阳光、身材棒”这些外在的形象关联在了一起，才会让我们在见到这个陌生人时，产生这些快速的判断。
所以，我们做用户画像的目的也是如此，为的是拿到用户的知识背景体系，更好地了解他们的用户思维。
那我们再回来说一说设计思维。
当你要在页面中增加一个button，那么你的思维模式是什么？可能会有三种：一种是要够好看直观，一种是要用户理解，一种是要和其他交互相得益彰。在这三种里，后两种是高级的产品经理思考的模式，我们这里重点来说用户理解。
初级的产品经理对用户理解这个事情，其实会容易建立在“我的理解”这点上，误以为自己就是用户。其实你未必是用户。
比如我们设计一篇文章的显示，我们会从文章的结构、展示、内容长度、分页等等几个角度去考量。但是有一种情况一定要加入其中，那就是你的用户是谁。如果是IT圈里的人，那他们习惯了阅读长文档，而且会自动解析文章布局，平铺直叙也许是最简单的；可如果是父母，他们过往阅读的都是报纸、杂志，而且因为年龄增大，对色彩敏感度下降，他们需要更大的字，更亮眼的色彩，更结构化的布局，所以你的设计会更加接近web 1.0时代。
最早的定义这两种思维，是在工业设计中，《设计心理学》中有比较深入的讨论，我们暂不展开。我们想要表达是：最简单的设计，就是让用户不去思考，不思考则是建立在“设计思维=用户思维”这个公式之上。
我们去描绘用户画像，并非只是为了了解用户的一些简单的行为方式，更重要的是剖析他背后的用户思维，这将很有趣，我们以后可以展开谈得更多一些。
2. 路径设计
产品路径我在之前的文章已经提过很多次，这里就再简单聊一下。
所谓产品路径，其实是我们希望如何引导用户来使用产品。在产品路径的设计上，有分新用户的路径和老用户的路径，展开来讨论会比较复杂，我们在这里只讨论产品的主路径。
所谓产品主路径，是指所有用户在产品使用中依据产品功能频次和功能间关系引导，所形成的一条流量转化路径。这个定义稍微有一些拗口，我们来拆分理解一下。
首先来看产品功能频次。
在产品中，不同的功能是有频次预期的，比如微信，它的最高频功能是“聊天”，同时这也是微信的核心，而其他功能，比如“摇一摇”、“附近的人”、“支付”等，都是频次偏低的功能；所以你会看到，在微信的首页中，聊天永远是最高优先级展示，微信的提醒也是以聊天为基础的。
这个时候，你可能会问：朋友圈也算是高频功能，是不是也是主路径呢？其实不然，朋友圈并非微信的功能属性，而是运营属性，它的存在是为了活跃留存微信用户，我们可以在以后产品运营相关的文章中再详细讨论。
有了产品功能的频次预期，以及产品的核心功能（核心功能一定也是高频功能），然后我们就要看各个功能之间的关系了。
回到微信这个例子，我们会看到，通讯录是第二优先级的页面，这是因为聊天的第一辅助功能是找人，所以我们也同时看到了像类似“摇一摇”、“附近的人”这些功能的存在意义，因为它们都是辅助核心高频功能的次高频功能。
如此便引出了一条产品的主路径，这条主路径定义了产品的定位和核心。
我们往后在这条主路径上可以衍生出许多的分支路径，包括附属增值功能路径、运营路径、流量变现路径等等，这些是产品经理需要打下的夯实基础。
3. 生命周期管理
说清楚产品的一些功能设计规则之后，我们来探讨一个比较深远的话题，产品生命周期管理。
在产品的向下发展中，有两个关键的原则，其一是向后迭代，其二是向前兼容。
我们先来看向后迭代。
因为我们已经设计了产品的主路径，那么向后迭代的关键依据则是在主路径中如何进行丰富化。
在我们实际的工作中，比较容易出现一种情况：需求集中爆发，许多人回来向产品经理提需求，包括老板、用户、客户、运营同事、其他同事、自己等等。这些需求的筛选考验着每一个产品经理的功力，这其中的一个关键依据，则是这些需求在主路径中的价值和作用。
我们一般会把迭代分为三种，一个是旧功能优化，一个是运营支撑，一个是新功能研发。这三种都是生长于主路径的生态之中，如何区分优先级虽然依赖于许多方面，但是主路径决定了迭代的节奏。关于向后迭代中节奏更深层的讨论，我们以后可以再写文章来探讨。
然后我们来看看向前兼容。
向前兼容是一种要求产品经理提前做好向后迭代设计，同时保持克制的原则。许多产品经理最容易犯的错误，就是在设计新功能时不考虑已有的东西。在《备忘录》一书中，提到一个关键点，就是产品必须要让用户觉得平滑过渡。平顺的产品迭代拥有很强的继承属性，我们会发现手边好的产品都具有这种特性，虽然迭代更新了许多版，但是从来没有失去它最早的样貌。
能够保持向前的兼容，这表示产品在最早规划时就已经做好了向后迭代的设计，也就是主路径很清晰。所以才能使产品始终保持继承一致性。相反，如果产品在迭代中发现主路径错了，或者要调整，那么势必导致产品的设计发生很大的变化，这对用户是一种很大的伤害。结合我们前面提到的“用户思维”，你好不容易建立起来的用户知识体系，就是因为你设计上的变故，导致了用户的流失。
产品是分层的
现在我们来讨论一个更深层次的东西，我谓之为“产品层次感”。
所谓产品层次感，是说在产品的设计中，除了功能的设计与叠加，还有在产品垂直逻辑分层中拥有分层的特性。这种分层，是一种自下而上的，这种分层的理解对产品经理提出了一种新的要求，你需要懂得产品的架构逻辑。
产品经理并不需要懂得什么编程的细节，而是需要懂得产品的逻辑设计，这种逻辑设计比较抽象，我在这里进行了一个分层的描述。
基于软件工程理论，产品本来就是至少要分为三层的，即典型的MVC（Model、View、Controller），这种描述对产品经理理解产品分层帮助极大。
首先是底层数据。
数据并不是数据库，而是数据模型。我们进行数据模型的设计理解，有助于帮助产品经理了解产品的角色划分，以及各个角色之间的关系与区别。
此外，由于了解数据模型，你会更清楚产品在功能层面上如何进行数据切割，以及权限设置的真谛。
然后是业务逻辑。
在如今的互联网产品研发中，云服务的使用变得越来越流行，这也间接影响了互联网产品的设计开始追求模块化。模块化的设计很类似SaaS的理念，就是基于功能服务进行模块划分。
我们在许多产品中可以看到大量的功能模块可以被反复调用，其实映射到产品内部也是一样，逻辑模块解耦，将核心功能模块变成基础设施（内聚性提高），都是业务逻辑层的事情。
在谈表现层之前，我们谈一个新概念，功能层。
功能层和表现层的关系，就是功能逻辑设计和界面原型设计。这种时候的功能层，是面向用户思维去考量的。功能层是建立在逻辑层之上的一个过渡层，是对产品在最终设计之前的一种逻辑设计。
比如，设计一个登陆功能，考量登陆的操作步骤和交互逻辑，这个是属于功能层，而其中的状态流转则是属于逻辑层。
有了功能层的设计，我们再向上表现，就是产品最后的交互设计了。交互设计是将功能更好的表达，也就是我们常说的用户体验优化。到了这一层，产品就是要面向用户了，所以表现层也叫做UI（User Interface）层，即用户接口层，在这里，友好的交互设计是这一层的宗旨。
我们拥有分层的理念之后，就可以更加清楚我们在哪一层，在做哪一个阶段。
架构设计是一种什么样的体验
看完上面两个部分，我们喝口水，然后回顾一下这中间的关系。
有了逻辑分层的概念，我们可以看到，产品的本质其实在于逻辑设计，而用户体验的设计是产品最后一环。这也就解释了，很多产品刚出来的时候体验很糟，但是用户量增长很快，那是因为产品的逻辑足够清楚，即使最后一环差一些，也不伤大雅（当然你不能老出bug）。
我们发现，产品因为分层和模块化，使得产品呈现出架构感。
产品架构是一个及其复杂的问题，但是简单理解，可以看成是不同的系统、功能模块之间，沿着整个产品的“商业主路径”形成的一套逻辑体系。
这里我们沿用了一个新的名词：商业主路径，它是与整个产品的商业模式相关的，它背后印证的是整个商业体系中流量的流转规律，以及变现机制。因为整个问题太大，我们以后有机会慢慢聊。
互联网的本质是“连接”，这是互联网区别于传统供应链的最关键部分。
在互联网的体系中，早期的投入成本巨大，但是往后随着规模的复制，其边际成本下降，从而形成网络效应。有了网络效应，互联网才能有变现的机会。因此，互联网的关键是管理流量，并且像大浪淘沙般产出价值和现金流，这也几乎是所有互联网产品的运转模式。
因为有了流量，我们必须让产品的主路径分解到逻辑的每一个层面，让各个模块之间有机的配合。
比如：
当一个社区的流量随着社区的活跃丰富起来之后，需要商城来分流实现变现，这时就需要在整个产品架构中产生新的业务线来支撑。
一个商城包含了仓储系统、支付系统、订单管理系统、客服系统、财务系统等等，这又是一个新的架构，这相当于从主路径中长出一个大分支。
这时你会发现，你的整个产品架构变得丰满，如果客服系统可以成为一个基础设施的话，它甚至又可以服务于原来的社区产品。
系统架构设计是一个高级或者资深的产品经理需要不断去探索的事情，初级的产品经理完成的往往只是整个架构中某个子模块中的某个子功能设计。
这就是整个产品架构设计的体验，你需要站得更高来看你处在哪里，向上看你的未来在哪里，向左右看你的产品在哪里。
延展下去，是商业本质
最后，我们简单讨论一个开放的问题：产品的最深层依赖于什么？
我认为：产品向深层延展，就是商业的本质。
在这里，我举一个我前东家的例子：微软为什么会花费260亿美金收购LinkedIn？
在微软的整个商业体系中，其最核心的利润池来自于ToB业务的变现，可以说微软是全球最大的ToB业务公司，包括Azure云服务、Office 365、Windows 10 专业版等等。这些可以渗透到不同体量、不同业务的企业中的服务，帮助微软建立了庞大而丰富的盈利模式，这也是为什么微软40年来依然营收能力强劲。
然后我们看微软收购LinkedIn。LinkedIn是全世界最大的中小型企业的社交平台，具体数据量有多大我们不好估算，但是可以明确一点，LinkedIn会为微软在ToB的客源上引来丰富的流量，而且还能帮助微软实现更加多样化的ToB业务售卖机制，比如拆分办公协同工具，这也是为什么微软近期在Office 365体系中同步推出了Microsoft Team这款产品。
其实，无论是产品还是运营，都是为了商业的本质。
作为产品经理，特别是进阶的产品经理，更需要了解自己所在企业的商业核心是什么，这样才能更好地理解我们所做的产品到底是在做什么。
前几年的互联网老炮们把“免费”炒作得有些跑偏了，因为做产品核心并不是服务用户这么简单，而是要为企业商业提供价值。
本文由 @帅帅的帅 原创发布于人人都是产品经理。
