案例解析：蚂蜂窝这一案例中的酒店预定、机票预定功能，如果订单数量很多，但终完成支付的很少，可以怎么解决?
　　1、 梳理下订单之后的各个环节，下单成功后，需要什么环节才能成功支付;
　　2、 分析各个环节的转化率，找到用户流失的关键步骤;
　　3、 从产品角度考虑产品功能优化，以降低用户流失。
　　现场简要分析，用户流失可能因为：1)登录注册繁琐;2)支付方式太少;3)页面跳转环节过多等等。针对这几个问题，从用户需求的角度来看，1)简化登录注册，好可以支持通用的如QQ、微博等社交类帐号;2)丰富支付方式，支持常用网银、支付宝等支付工具;3)简化非必要跳转页面。
　　市场、客服等合作部门的反馈，因为市场、客服人员是与一线用户直接接触的，对于用户对产品的反馈和建议是能够快速掌握的，有时可能是用户的一句抱怨，可能会给产品带来很大的价值，因此留意用户，接触用户也是非常关键的。

　　5、竞品分析所谓的竞品分析是找类似定位的产品，看别人的产品功能、设计，逆推用户需求，发现竞品的闪光点，拿来用在自己的产品上。 互联网的一些事
　　从领域、产品类型、未来规划的方向、相关功能等角度去找竞品;再从竞品的定位，具体功能，战略规划，运营推广等角度去分析。(ps：当今社会创新的成本太高，拿来主义式的微创新也是不错的选择)
　　如本篇案例中的蚂蜂窝，竞品分析可对途牛网、悠哉网，去哪儿，酷讯，到到网，驴评网，蝉游记等产品的产品定位、功能结构、产品规划等多维度分析，找到不同产品的优势，然后为我所用，基于此对蚂蜂窝进行优化改造。

　　6、用户模拟用户模拟的目的是在具备产品核心定位后，融入用户角色，再不断的对产品核心理念做修正的一个过程。有两种方式，一种是1S变小白，自己化身用户，思考如果你是用户，你想用这个产品在什么场景下做什么;另外一种方式，代入用户角色，走进目标用户群，去体验感受用户的所有感知。

　　需求评估
　　通过多种需求采集方法收集了大量的用户需求后，在进行产品设计前，会预先对需求进行评估。需求评估的目的在于，对所有需求做评估，做优先级判断，判断哪些需求是必须要满足的，哪些是可以延迟一点满足的，而哪些又是可以不用考虑的。
　　需求评估考虑的因素有：1)可行性(技术能否实现)、2)成本(人力成本、时间成本)、3)商业风险、4)是不是用户迫切的需求(紧急性与重要性)。
　　我们常用的需求评估方法有KANO模型、需求减法、专家评估式：
　　1、KANO模型KANO模型，是需求实现与用户满意度之间的关系模型图，把需求按照需求满足和满意度两个维度把需求划分为基本型需求、期望型需求和兴奋型需求三大类。同时用户的需求类型是随着时间变化的，也许期望型需求变成了基本型需求，兴奋型需求变成了期望型需求，需要重新挖掘用户的兴奋型需求。
　　对于必须完成的需求，在产品发布时需要完成;同时完成尽可能多的期望型需求;如果时间允许，至少应该确定少量的兴奋点需求优先级，进入研发和发布计划;后续及时跟进用户的需求状态和类型，不断挖掘用户新的兴奋型需求。
　　KANO模型分析可参见《如何解决“女生喜欢白马王子”的需求》。
　　2、需求减法有时候决定不做什么，比决定做什么更加重要。产品经理或多或少有一些”完美主义“情结，生怕缺少什么，增加不必要的功能。但是从成本、效率等多方面考虑，我们应该倾向于”轻产品“，根据一定的原则做需求减法，适当的砍掉一部分需求。
　　需求减法的核心要点依旧是产品定位，围绕产品定位，根据产品价值，定义需求边界，把握核心需求，砍掉需求边界外一些无关紧要的需求。
　　如阿里集团旗下的淘宝和阿里巴巴同为电商平台，为何阿里会搭建两个平台来开展电商业务?很清楚的定位，淘宝是2C，阿里巴巴是2B，两者所面向的用户群体不一样，对于不同的买家和卖家的需求都会不一样。
　　3、专家评估法专家评估法，顾名思义是组织产品专家一起评估产品需求，决定做还是不做，是否值得去做，运用群体智慧的力量来决策产品需求。专家可以是技术专家、市场、客服等。
　　尤其值得一提的是老板需求，老板作为一个特殊的客户，常常会对产品提出一些自己的设想，老板以他的经验、阅历及对市场的敏感度会做出一定的判断。针对老板需求在不影响整体产品逻辑的前提下可以适当考虑。如果偏离太远，可提供相应理由给老板定夺。
　　需求管理
　　在需求采集、需求评估的过程中，如何整体管理这些需求，在整个产品的生命周期里更好的跟踪把控需求进展。公司不同，个人习惯不同，对于需求管理的方法会有所不同，但是目的是一致的，实时把控跟踪需求。下面是几种使用较多的需求管理方式：
　　需求卡片：描述需求来源、需求内容及需求优先级的需求卡片，一般会用于市场、客服等相关合作部门提交需求所用。
　　需求矩阵：EXCEL表单的形式记录每条需求，追踪需求动向，包括相应提出人、需求描述、需求优先级、需求评审时间、开发时间、开发人员、测试人员等。 
　　需求文档：把整个产品拆成N个小功能模块，出具相应的需求文档，分阶段提供给开发、测试相关人员，在小公司小的产品中比较适用，但要求产品人员必须非常清楚产品的每个功能点，可以全盘考虑管理。
　　测试用例：测试用例一般以用户场景的形式描述，使用测试用例的形式来记录需求，管理需求也不失为一种很好的方法。
　　后提供两个群友们贡献的工具参考：Jira、FitNesse。

　　结束语：上述内容不一定全面，是我们在自己实际工作中的经验分享，经验有限，如有不同意见或补充，请在下方评论区留言，谢谢。