產品「套娃原理」 （上）

你知道俄羅斯套娃嗎，咱們國家也有相似的傳統工藝品，就是那個盒子裝盒子的，只是似乎沒有準確的名稱，所以今天，我借用一下「俄羅斯套娃」來給大家分享一下，產品的「包含」性質。

正文

先給大家科普一下，什麼是「俄羅斯套娃」， 簡單的來說，就是一個娃娃肚子里，裝了另一個娃娃，並且一直循環下去，可以裝很多個娃娃。當然了，這有幾個特殊的 「性質」。

1. 這些娃娃的形狀 ：形狀差別越大，浪費的空間就越大，這樣就裝不了太多的娃娃了
2. 這些娃娃的尺寸一定是不一樣的：我們沒有辦法讓兩個相同尺寸的娃娃，產生「包含關係」
3. 每個娃娃都是獨立且完整的：這表示，即使我們不小心弄丟了，弄壞了，都不會影響整體的套娃，而每一個套娃 單獨拿來，都是一個工藝品，所以你買了一套俄羅斯套娃，就等於買了若干個不一樣的娃娃

當然，我並沒與在代購「套娃」，所以我們帶著這四個特性，來說說「產品套娃」吧

「產品套娃」

一款產品的誕生到產生極大的價值，他還是一款產品，但卻又不是一款產品。

微信這款產品誕生於2011年，到現在有6年了，你意識到一個問題了嗎？

產品在生長過程中，發生的一個小小的變化，大概就像細胞裂變一樣的微小變化。

2016年的微信，不再是當年的13人團隊能夠負擔的了。

張小龍在近期的一次分享上透露出，微信事業部已經有1500多人了，增加了100倍。

如果早期微信只有一位產品經理，那現在是不是應該有100人的產品團隊了？

當然，這樣推算是不科學的，但我們可以肯定的是，微信的產品團隊至少擴大了數十倍。

一位產品經理，在做一款產品，那麼一群產品經理 在做什麼呢？

「產品套娃」其實是一種討巧的說法，我沒有想好用什麼樣的名字稱呼這種產品的「包含屬性」，但他與套娃，驚人的一致。

這需要你充分認識 「產品化思維」，在你的眼裡呈現出來的「產品」 ，他不應該是一個app， 也不應該是一個網站，甚至不應該有所「形」與「名」，否則你就無法去解釋剛才的問題，

你知道的，微信支付必然是由一位乃至數位產品經理獨立完成的「產品」

但他「無形」，你無法判斷朋友圈的用戶數，你不能說他有5億用戶，因為這是微信的用戶數。

同樣的，你更加無法判斷微信通訊系統這款產品是否收到用戶的喜愛，畢竟用戶不會告訴你「用這個聊天太方便了」 因為這只是一個「基礎功能」。

當一個產品發展到一定的階段，當你所處的企業環境，有了多位產品經理，也許你們都在創造某一款產品，但我想請你清楚的明白一件事情，你們並不是在做一個相同的產品

「產品套娃的定義」

是不是和俄羅斯套娃很像？我們在實際過程中所設計的產品，就正如套娃，一層包含一層。

例如：

在最外圍，是我們的企業定位，真正的產品經理，並不是一位偽CEO，而是一位專業的產品經理。

我們不會去思考與企業定位不相符的產品，比如，京東的產品經理，不會去思考朋友圈的設計方法以及市場需求。

這是因為我們的產品定位隸屬於企業定位，兩者之間存在明確的「包含關係」。

而我們業務模塊的產品經理，與主要模塊的產品經理也都有各自的思考傾向，一旦出現跨越式的聯繫，我想，這會產生兩個結果。

如果不是你即將主動或被動離職，那就是企業戰略出現傾斜，也是表明團隊出現了分歧。

我們來借用「俄羅斯套娃」的特性，來分析一下「產品套娃」。「形狀」 是 「差不多」的

你能想像微信是從阿里誕生的時代嗎？ 我怕是無法想像了，儘管阿里非常努力想做社交，但這並不等同於微信。這當然和我們經常提到的團隊基因有關，但我想從另一個角度來試著分析一下。

在套娃原理 里，形狀是差不多的是為了更好的利用內部的空間，我們可以理解成更充分的利用已有資源。

如果阿里企圖打造一款微信產品，這就像是在橢圓形的套娃里，裝了一個正方形的套娃，一方面受限於橢圓的橫向空間，一方面又浪費了套娃的縱向空間。

並不是阿里不能做微信，而是不應該做微信

而一旦我們要最大化的去利用企業的資源，就必然產生「差不多」的概念，因為只有形狀相同，才能保證我們最大化的去利用資源，利用空間。

最典型的一種應用，也是現在最普遍的現象，許多的創業團隊在初期，基本依賴創始人的資源。

如果創始人手上有酒店的資源，那基本上必然會做一個酒店相關的產品。如果創始人有更多的教育資源，我相信也一定會選擇一款教育性質的產品。

「尺寸」是「不一樣」的

我們從大的講，一個企業在發展過程中，一定會出現多款產品同步運營的狀況，也許你現在所在的公司，就有這樣的多款產品。

我相信，在這些產品里，一定有優先順序關係，一定有一款產品是最核心的，然後有幾款是相對核心的。

而在同一款產品里，這種尺寸也體現的淋漓盡致，我在前文提到了這樣一句話，我想再強調一下，也許你們都在創造某一款產品，但我實際上，你們並不是在做一個相同的產品。即使是在一款產品里，也會有「尺寸」的差異，你知道微信最核心的產品模塊是什麼嗎？

是通訊能力，而朋友圈是最接近通訊的產品模塊，但在尺寸上任然是略小於通訊模塊。

需求的優先順序，你一定非常熟悉，不如換個角度思考一下，在需求優先順序之上，產品其實還存在一個「模塊」的優先順序。

一旦出現「二選一」的情況，我們勢必會選擇相對更重要的模塊進行維護和迭代。

如果你所處的團隊，有多位產品經理，且你們都有明確的任務分工，我相信你一定有所感觸。

在研發，運營，設計，測試等等資源的分配上，永遠是優先考慮主要模塊的需求，只有在主要模塊不緊急的情況，才會選擇性的將資源傾斜給你。

而如果你是在獨立負責一個完整的產品，那我希望你能更加深刻的意識到這個問題。

MVP原則里強調了最簡化開發的原理，本質上也屬於對產品模塊的資源傾斜，將你的精力，集中到最優先，最核心的模塊，將其完善，過程中的碎片時間再去考慮衍生出來的模塊。

未完待續

下周一將會為大家分享 產品 「套娃原理」的下半場，「每個娃娃都是獨立且完整的」

微信公眾號：枯葉咖啡館

QQ群：591918885

等你來哦~

推薦閱讀：