你知道俄罗斯套娃吗？中国也有相似的传统工艺品，就是那个盒子装盒子的，只是没有统一的名称，所以今天，我借用一下“俄罗斯套娃”来给大家分享一下，产品的“包含”性质。
先给大家科普一下，什么是“俄罗斯套娃”， 简单的来说，就是一个娃娃肚子里，装了另一个娃娃，并且一直循环下去，可以装很多个娃娃。
当然了，这有几个特殊的 “性质”:
1. 这些娃娃的形状 是“差不多的”
形状差别越大，浪费的空间就越大，这样就装不了太多的娃娃了
2. 这些娃娃的尺寸一定是不一样的
我们没有办法让两个相同尺寸的娃娃，产生“包含关系”
3. 每个娃娃都是独立且完整的
这表示，即使我们不小心弄丢了，弄坏了，都不会影响整体的套娃，而每一个套娃 单独拿出来，都是一个工艺品，所以你买了一套俄罗斯套娃，就等于买了若干个不一样的娃娃。
当然，我并没与在代购“套娃”，所以我们带着这四个特性，来说说“产品套娃”吧。
“产品套娃”
一款产品诞生到产生极大的价值，从根本上说他还是一款产品，但却又不是一款产品。
微信这款产品诞生于2011年，到现在有6年了，你意识到一个问题了吗？
这些产品在生长过程中，发生的一个小小的变化，大概就像细胞裂变一样的微小变化，2016年的微信，也不再是当年的13人团队能够负担的了。
张小龙在近期的一次分享上透露出，微信事业部已经有1500多人了，增加了100倍。
如果早期微信只有一位产品经理，那现在是不是应该有100人的产品团队了？当然，这样推算是不科学的，但我们可以肯定的是，微信的产品团队至少扩大了数十倍。
“产品套娃”其实是一种讨巧的说法，我没有想好用什么样的名字称呼这种产品的“包含属性”，但他与套娃，惊人的一致。
这需要你充分认识 “产品化思维”，在你的眼里呈现出来的“产品” ，他不应该是一个app， 也不应该是一个网站，甚至不应该有所“形”与“名”，否则你就无法去解释刚才的问题。
你知道的，微信支付必然是由一位乃至数位产品经理独立完成的“产品”，但他“无形”，你无法判断朋友圈的用户数。你不能说他有5亿用户，因为这是微信的用户数。同样的，你更加无法判断微信通讯系统这款产品是否收到用户的喜爱，毕竟用户不会告诉你“用这个聊天太方便了” 因为这只是一个“基础功能”。
当一个产品发展到一定的阶段，当你所处的企业环境，有了多位产品经理，也许你们都在创造某一款产品，但我想请你清楚的明白一件事情，你们并不是在做一个相同的产品
“产品套娃的定义”
这样抽象出来是不是很像俄罗斯套娃呢？
我们在实际过程中所设计的产品，就正如图中绘制的套娃，一层包含一层，举个例子：
在最外围，是我们的企业定位，真正的产品经理，并不是一位伪CEO，而是一位专业的产品经理。
我们不会去思考与企业定位不相符的产品，比如，京东的产品经理，不会去思考朋友圈的设计方法以及市场需求。
这是因为我们的产品定位隶属于企业定位，两者之间存在明确的“包含关系”。
而我们业务模块的产品经理，与主要模块的产品经理也都有各自的思考倾向，一旦出现跨越式的联系，我想，这会产生两个结果，如果不是你即将主动或被动离职，那就是企业战略出现倾斜，也是表明团队出现了分歧。
我们来借用“俄罗斯套娃”的特性，来分析一下“产品套娃”吧。
“形状” 是 “差不多”的
你能想象微信从阿里体系诞生的样子吗？ 我怕是无法想象了，尽管阿里非常努力想做社交，但这并不等同于微信。
这当然和我们经常提到的团队基因有关，但我想从另一个角度来试着分析一下。
在套娃原理里，形状是差不多的是为了更好的利用内部的空间，我们可以理解成更充分的利用已有资源。
如果阿里企图打造一款微信产品，这就像是在椭圆形的套娃里，装了一个正方形的套娃，一方面受限于椭圆的横向空间，一方面又浪费了套娃的纵向空间。
并不是阿里不能做微信，而是不应该做微信。
而一旦我们要最大化的去利用企业的资源，就必然产生“差不多”的概念，因为只有形状相同，才能保证我们最大化的去利用资源，利用空间。
最典型的一种应用，也是现在最普遍的现象，许多的创业团队在初期，基本依赖创始人的资源，如果创始人手上有酒店的资源，那基本上必然会做一个酒店相关的产品，如果创始人有更多的教育资源，我相信也一定会选择一款教育性质的产品。
“尺寸”是“不一样”的
从大方面讲，一个企业在发展过程中，一定会出现多款产品同步运营的状况，也许你现在所在的公司，就有这样的多款产品，我相信，在这些产品里，一定有优先级关系，一定有一款产品是最核心的，然后有几款是相对核心的。
而在同一款产品里，这种尺寸也体现的淋漓尽致，我在前文提到了这样一句话，我想再强调一下
也许你们都在创造某一款产品，但我实际上，你们并不是在做一个相同的产品。
即使是在一款产品里，也会有“尺寸”的差异，你知道微信最核心的产品模块是什么吗？是通讯能力，而朋友圈是最接近通讯的产品模块，但在尺寸上任然是略小于通讯模块。
需求的优先级，你一定非常熟悉，不如换个角度思考一下，在需求优先级之上，产品其实还存在一个“模块”的优先级。
一旦出现“二选一”的情况，我们势必会选择相对更重要的模块进行维护和迭代。
如果你所处的团队，有多位产品经理，且你们都有明确的任务分工，我相信你一定有所感触：在研发，运营，设计，测试等等资源的分配上，永远是优先考虑主要模块的需求，只有在主要模块不紧急的情况，才会选择性的将资源倾斜给你。
而如果你是在独立负责一个完整的产品，那我希望你能更加深刻的意识到这个问题，MVP原则里强调了最简化开发的原理，本质上也属于对产品模块的资源倾斜，将你的精力，集中到最优先，最核心的模块，将其完善，过程中的碎片时间再去考虑衍生出来的模块。
每个娃娃都是独立且完整的
前段时间，和一位在某知名音乐产品就职的朋友探讨一个娱乐版块的玩法设计，她似乎一直在寻找好玩的“玩法”，希望这个玩法能够留住用户，也能够带来新的用户。
正巧，我正在研究“套娃原理” 这让我有很大的触动。
答案是否定的，当然是否定的，这就好比你不能说某产品日活高，是因为用户资料这个模块做的非常出色，你也无法说某产品日活低，是因为系统设置这个模块做的糟糕。
在一个产品里，每一个模块都是完整的，这个完整体现在使命，方向，用户体验，数据目标等多个维度。
我们基本可以在任意一个产品模块里，找到一款独立的app所必须具备的“完整条件”
当然，这些条件所对应的内容是不一样的。
为了更好的说明这种性质，我们来简单的拆解一款比较有代表性的产品“爱奇艺”。
作为一款app层次的产品，爱奇艺的品牌理念为“悦享品质”，为用户提供流畅的观影体验，高清的视觉效果，贴心的分享感受，满足用户的高品质生活追求。当然他需要追寻用户数，日活数，播放数等一系列的数据目标。
播放器是爱奇艺的主要模块，这是因为产品定位于“为用户提供流畅的观影体验”这是一个性能上的要求，对于播放器而言，毫无疑问，他将要承担观影体验、观影质量的任务，同时，播放器所需要追求的数据目标，则在于较低的跳出率，
再来看看导航呢？
导航是一个很典型的业务模块，用户不可能为了导航而是用某一款产品，但是，在设计导航时，也有他自身的“完整条件”
作为导航而言，他所需要追求的核心数据目标是转化能力，导航无法促进产品的日活与新增，但他能够加强往指定板块的导流能力。当用户已经进入到导航页面了，那就将其视为用户基数，在这个基数下面，有多少比例的用户会进入到分类页，这完全取决于导航的设计。
这是想象中的，两款导航方案的数据对比，两款方案都有1000人通过首页或其他的入口，进入到了导航页。
A方案有500人从导航页跳出来了，有500人通过导航，进入到了分类页，
B方案则是有100人跳出，有900人通过导航，进入了分类页。
数据层面，我们很容易判断B方案优于A方案，因为其更体现出导航页的存在使命，因此，我们判断这个导航方案是成功的。
当然，我们并不需要根据爱奇艺的用户数或者日活来判断他的导航是否成功，要知道这些数据和导航页没有任何关系。爱奇艺的日活并不等同于导航的指向数据。
