很多次在做产品的时候会遇到，明明是一个很简单的需求，在经过各方分析、拆解再重组之后突然就变成了一座大山或一座山脉，瞬间有种高山仰止操了狗的感觉。
结合最近频繁面试被问及为什么要这样设定产品功能，怎么处理产品功能的取舍，又是怎么定的产品目标，写下了这篇分析总结。
先设定我们要做一个解决用餐需要排队等候问题的产品，做一个需求的拆解重组
目标：不排队、最少排队时间
先从时间轴为两个层：排队前，排队中。
排队前的需求是这家店现在排队是什么情况，例如：搜索一家白鹿（西湖文化广场店）能立马知道这一刻这家店的排队情况。延伸的需求是西湖文化广场的餐厅排队情况，以及白鹿在全城的排队情况。然后就是可以在线预约排队
排队中的需求是减少上菜排队等候以及错过正确用餐时间点的问题，那么就是点菜，提醒
从上面的分解，直接能得到的产品功能：搜索/推荐/在线预约/点菜/提醒；
再来从用户使用进入场景分两个层：直接使用，到店使用
直接使用就是上述我们已经分析过，另一种到店使用，有可能用户在到店领取了纸质排队号子之后才使用，那么用户直接进入的就是时间轴的排队中状态，但怎么让用户从这种纸质的状态转化过来呢？
这里我们就又需要设立转化的桥梁，将用户线下实体领取的号子转化到自身的产品中来，直接能看到的产品功能点就是：扫码排队
上述分析完，发现只是解决了帮助用户减少排队等候时间，和实体排队等候的问题。还是不能根本的解决用户可直接用餐而不排队。
针对这个问题我们再来分析，为什么不能解决用户可直接用餐？
1.餐厅不会平白无故一直空桌等待；
2.上一波用餐用户的时间不确定
这样来看，又会衍生出至少三点产品功能：用餐时间的预约/担保预定/买断预定，即：用户在预约排队时事先支付一笔担保金或直接该笔订单的餐费；公司单向买断餐厅个别餐桌供产品用户使用
这样下来一个单线程的产品逻辑貌似差不多，但继续深挖会发现还有其他的需求，但不在次进行分析。
接下来我们试着把盘子放大来看，把只解决用餐排队的问题改为用餐来看，又会发现新的很多需求，例如：团购/评价/美食社区...
到现在拆解下来的产品功能可能足以让人头大了，那么问题来了，怎么重组，怎么取舍？个人的观点是根据公司的目标，阶段业务线的目标，最终定格到产品功能的目标，这样听起来可能有点虚。
用刚才的解决用餐排队的案例来分析，如果只做到想让用户知道餐厅预约排队的实施情况可能我们只需要做一个基于采集了实体餐厅取号机器数据的公众号就可以了；这样的一个偏工具类的功能单一产品不管从投入成本，项目开发进度都相对比较低，需要达到的目标也能实现。
但如果想做以解决排队为切入点的下一个美团，一个公众号明显就不能满足了。
总结一下，做产品想要想大而全，深而透，实际操刀去做一定是点到面
