以切入点考虑产品架构

产品如何通过最初的几个版本迭代做好从0到1？

在互联网历史上有很多失败的产品。在产品发展过程中大改产品架构，从而扭转局面的少之又少。可以说在快速发展的环境中，每个产品只有一两次机会。尽管我们通过种种分析找到了产品切入点，弄清了产品定位，但也不意味着我们就能设计出一款好产品，从而赢得用户的喜爱。在整个设计过程中，产品经理对于其核心——产品架构的把控，是至关重要的。它就像是骨架，支撑起整个产品的发展。

我们从产品切入点出发，在设计最初的产品架构时，需要考虑以下方面。

l 产品瞄准的细分市场。

l 产品的发展方向。

l 产品的核心功能。

l 信息架构。

需要注意的是，产品架构并不只是用一张脑图画出的产品导航结构图，产品导航结构图只是产品架构的一部分。产品经理很容易忽略的是，用户在产品上的主要行为路径，这一点往往决定了我们头脑中设想的产品亮点能否真正成为产品的发力点。

在做了多年网易云音乐之后，我总结了一些做产品架构上的经验与方法。下面就以网易云音乐最初的产品架构为例，介绍整个思考过程。从产品切入点出发，网易云音乐决心选择比较资深的音乐爱好者作为细分市场，从满足发现音乐的痛点开始，以UGC（用户原创内容，在网易云音乐中就是歌单）、个性化推荐、社交互动作为产品的发展方向。我们面临的第一个问题就是，如何选择产品初期主打的核心功能点。

人们都能畅想出产品发展到100时备受用户欢迎的场面，但在产品从0到1的时候究竟以什么为核心，是一个非常难的问题。因此下面来看看在选择核心功能点时，产品经理应该考虑什么。

产品经理应该思考核心功能点有哪些待选项，即研究能实现产品成功切入市场的可能路径有哪些。在满足比较资深的音乐爱好者发现音乐的需求上，我们面临的可选方式有：UGC（歌单）、标签、电台（与豆瓣FM、Songza类似的形态）、MV（音悦台的形态）、音频直播聊天室（虾米音乐Loop的形态）。经过调研，我们首先排除了如下方式。

音频直播聊天室：产品受众太小，用户门槛过高。

l MV：市场体量不如音乐，并非用户的刚性需求，适合产品迭代之后做。

l 电台：当时用户的刚性需求仍偏点播、下载，如果上来就以豆瓣FM的方式切入市场，难以撬动大众用户。适合产品迭代之后做。

然后我们需要在歌单、标签方式中选择。这时可以用如下的权衡利弊的方法来思考。

l 歌单的好处：用户间可以围绕歌单进行互动，形成关系，进而打造社区。

l 歌单的坏处：会有类似、重复的歌单，无法多维度交叉，不能形成网状结构，不如标签灵活。

l 标签的好处：网状结构，有更多交叉探索的可能性，更加灵活，同时也能作为轴心串起整个产品（像Stack Overflow那样，将标签用到了极致）。

l 标签的坏处：如果直接用标签做音乐的发现与分享，UGC的行为会弱化，用户之间的互动会减弱。

总的来说，歌单包含了更多的用户创造的成分，更符合打造UGC社区的长远目标。它存在弊端，但影响不是很大（类似、重复的歌单可以通过技术手段降权；网状结构也并不是必需品）。相对来说，它的好处对产品的发展更有利，更何况用户本来就习惯以歌单的形式听音乐，只不过之前大家称其为“播放列表”。

因此，我们决定以歌单作为核心功能来设计产品架构。在设计的过程，需要考虑下面这些重点。

l 核心功能突出，用户上手简单，使用户马上能感受到产品的优点。对于一款新产品，用户对它的认知越清晰越好，因此产品也就不能有过多的功能。为了在产品架构上突出歌单，我们在初期的网易云音乐App版本中砍掉了排行榜、新歌、歌曲分类等常见的音乐发现功能，除了搜索外，整个产品发现音乐的途径只有UGC。这样，当新用户打开App时，接收到的信息是，这是一款以歌单为主的音乐产品。当然，这样一定会对用户产生影响，因为大部分用户习惯一个有排行榜、新歌、歌曲分类等功能的产品。但在一个竞争十分激烈的市场中，一个新产品拥有自己的特色相比于看上去与其他音乐产品差不多，前者应该更重要。

l 核心功能与整体产品的架构布局。一图胜千言，图5-8可以阐释网易云音乐以歌单为核心功能演化整个产品架构布局的思路。很重要的一点是，产品架构上没有断层，而且重要模块间是可以互相借力、协同发展的。例如，UGC可以积累数据，促进算法发展，而算法发展起来后又可以有效地区分人群、促进社区互动、减少“噪声”（音乐口味不同而带来的冲突）；社区氛围越来越好，则又反哺UGC系统，不断地产生高质量的歌单。

图5-8 网易云音乐的产品架构布局

l 产品架构逐步完善的顺序和节奏（UGC、个性化推荐、社区/社交三步骤）。在这个架构中，由于歌单是一个用户本身既有的高频需求（用户都是以列表方式来听歌的，歌曲消费很快，因而歌单消费也很高频），它是适合在这三个核心功能中首先发力的部分，这点尤为关键，选取正确的发力点往往能事半功倍。如果顺序反了，在基础支撑的核心功能没有做好之前，先做了一个依赖基础方能更好发展的核心功能，那么产品的运营过程就会很吃力，事倍功半，这就好比没有学会加减乘除就直接学习微积分一样。

需要注意的是，这个架构并不一定适合其他产品。每个产品都有自身的特性、所处环境，切忌直接套用在其他产品上。网络上有很多产品模式，真正实践做产品的人都知道，模式只能参考，或者成为引发思考的起因，真正的困难在于深入研究，直抵关键核心。

本节讲述了从切入点出发，探索产品架构方面的方法与经验，并没有具体涉及复杂产品架构的方法。复杂产品的架构能力属于产品负责人的能力范畴，会在后面的章节中给大家介绍。