上一次分享了产品结构创建的流程以及结合思维导图提高效率的思路，今天我们就要解释另一个问题，就是产品功能创建以后，制定产品结构的决策是怎么定的。
产品的决策难点
上文提过产品要经过前期的调研、分析，才进入规划的阶段，即构建产品框架的阶段。而构建产品框架从功能起步，再到定义产品的信息和具体结构。
它们三者都是结合前期调研、分析后做出的决策。比如电话亭产品功能中的课程模块，包含了直播课、免费课、系统课、训练营四个大类，都是根据业务上的需求得出，是比较直接的转换，对我们决策的负担并不重。
但只从业务角度出发制定功能，往往是不够完整的。一方面常规产品都会包含一些基础的通用功能，如账户系统、三方登录、推送通知、应用设置等，产品经理需要考虑添加他们的必要性。
另一方面，产品经理自己或者团队、用户都会提出一系列对产品发展或用户体验有益的功能点，我们统一称它们为主观想法，产品经理就需要考虑是否采纳他们。
并且，一个大的功能点，必然是由若干小功能点组成的，
而这在前期调研分析中很难完整覆盖。
比如一个直播功能，直播前有几种预约形式，预约怎么通知，直播中要不要包含聊天、礼物、截图、连麦等功能。这些功能点做不做，都要看产品经理如何决策。
再到信息地图，一个对象可以添加的数据字段，那可就太多了。
比如产品用户，从他们的基础信息、生辰八字，到在应用内产生的各项数据，都是产品经理可以制定的字段，随便想都可以想出百八十个出来。
想出来不难，但这些信息显然不会全部用上（数据冗余和开发成本），那应该保留哪些，就是选择困难症的噩梦，也是产品经理必须要做的决策。
功能和信息内容的制定，都是在前期调研分析基础上展开的独立决策。而进入产品地图阶段，则要同时结合调研分析和功能、信息的要素做决策。
比如电话亭应用中，核心的功能模块包含课程、社区、知识库三个，直接把它们放在底部导航上加上用户组成四个选项，这河狸嘛？
虽然能用，但明显感觉不太对劲对吧？这和传统应用的做法差异很大，而且每个页面下级要放什么内容，其它基础页面（如首页、探索等）、功能服务（如通知、日程等）要不要放，放哪里也成为问题。
作为产品经理，在这个阶段就要组织页面结构框架，将所有的功能合理分配到不同的页面中去，并为它们填入前面制定好的有效信息。
一方面产品地图的决策数量远高于前两者，另一方面每个决策都要有对应的理由，这就导致产品地图创建过程的难度直线上升。
之所以困难，是因为产品决策解决的不是1+1=2 这种有推导逻辑和标准答案的问题，而是充满了不确定性和没有标准答案的问题，产品得在一堆可选项中做出最终决策。
想想每天午饭/晚饭叫外卖的纠结，现在每规划一个模块，就要面对几十上百个这样的抉择……
产品决策的依据
决策很困难，就是因为每个决策的结果都存在大量的不确定性，近的包括需求评审阶段能不能通过，远的包括上线后的实际效果，产品经理都需要对这些决策负责。
上线的结果怎么样另说，产品首先要面对的是评审的压力，也就是你要用拿没有标准答案的决策成果，去说服其他人认同你的方案。
而想要别人认可你的方案，就需要对每个决策给出充分的理由，也就是建立因为…所以的逻辑推导过程。而这个过程并不只是用来应付其他人的，得是你自己也形成这种思考逻辑，用他们思考问题，最终结果才有说服力。
而接下来，我们就要针对每个决策形成的过程，做进一步的拆解。
还是以上面的案例为例，我定义的产品结构大致如下所示：
其中，登录后底部导航的选项有四个，分别是首页、课程、消息、我的。
首页是个聚合页，展示推荐内容，以及可以通过快速入口进入不同课程分类，以及社区、知识库下级页面中。下方则是课程推荐和聚合信息的瀑布流，用户在进入主页后可以直接向下划查看感兴趣的内容。
导航第二个选项是课程，有个独立频道页面，而另外两个主要功能社区和知识库，却只能从首页进入。这种分配当然是不平衡的，而这种不平衡也是考虑后的结果。
虽然主要功能模块有三个，但是我对课程权重的定义是更高的，是我认为用户使用这个产品的核心价值点，而知识库、社区只是辅助功能。且在前期阶段，产品中不会有那么多知识库内容以及社区内容，进去也没多少东西能看，那它们就更没有在 Tab 中露出的必要。
而第三个选项使用消息，是因为正在看的课程、直播课、知识库如果更新，需要尽可能让用户能感知，以及用户上的系列课/直播课时在临近上课前也需要有通知和记录。
在框架的定义中，决策的依据各不相同，且每个决策也有各自的优缺点。这就要进一步探讨，决策的形成过程，用一个简单的图形做拆解如下所示：
关注重点，就是解决问题的依据。比如导航底部放不放功能模块这个问题，我主要关注的重点是功能的权重，是由产品阶段目标决定的。
而应对方案就是把第二个选项放课程，其它模块入口从首页进入。做这样的方案必然会产生优点和缺点，优点就是课程模块更显眼更容易被发现，缺点是三个主要功能模块有落差，社区、知识库太深不好找，很难有人主动去点。
形成最终决策的考量，就是基于关注重点对优点和缺点做出比较，当优点大于缺点的时候，那么这个决策就有做的价值。当缺点远远大于优点时，那就应该考虑别的方案了。
关注重点是这个体系中最重要的因素，不同项目、场景、功能关注的重点可能截然不同。比如上方我关注的问题重点是产品发展目标（让用户多关注课程模块），但也可以是别的因素，如：
