​

​

​

​

Step 1

收集需求

首先需要针对需求的来源进行分析，不同渠道收集到的需求会有差异：
1 来自于用户的后台反馈，这部分用户基本上是留存高，粘性大的用户，反馈权重高
2 来自于公司运营同事的反馈，这部分需求主要从运营业务的角度出发，需要甄别需求覆盖面积，从而判断开发价值
3 来自于你的老板，分析建议和高效执行，都很重要
4 来自于数据分析，这部分的需求主要是从数据分析中发现的，一般大多是优化类需求（比如发现注册率低，如何简化注册流程；发现新用户留存低，如何通过给新用户发放礼包、引导用户创建内容，来提高新用户的留存）

下表是对后台收集到的用户反馈，做初步处理：

 

 

 

 

 

 

 

​
 

​

​

​

 

Step 2

需求挖掘、明确

对于需求，有一点很重要，用户并不一定真的知道他想要什么，公司同事也一样，因此这就需要和反馈的用户沟通，多问问题，了解他具体遇到了什么问题？你为什么希望增加这个功能？你平时的使用习惯是怎样的？这里引用经典的福特需求挖掘案例：
福特：“您需要一个什么样的、更好的交通工具？”
用户：“一匹更快的马”
福特：“你为什么需要一匹更快的马？”
用户：“因为它跑的快”
福特：“你为什么需要跑的更快呢？”
用户：“因为这样的话，我就可以更早地到达目的地。”
福特：“所以，你需要一匹更快的马真正的用意是?”
用户：“用更短的时间、更快地到达目的地！”

用户的真实需求并不是”一匹更快的马“而是”更早到达目的地“。前者是用户表达出来的表意需求，后者才是有价值的底层需求。

所以无论是哪个渠道来源，都可以以这三个维度去理解用户，从而发掘底层需求,即：行为、环境、用户角色。
 

​

 

 

 

 

 

 

 

 

​

 

在人性欲望（更快、更好）的驱使下，不同用户因行为不同、环境不同，会产生多样的用户动机，借用上面的例子可以解读为：在更快的人性欲望驱使下，在没有汽车的环境中，用户想要一匹更快的马，能让他更快地到达某地。
我们把这种用户动机，解读为需求：更快到达某地。
产品需求则指具体的实现路径，我可以培育品种更好的马匹，也可以投入研发新型带轮子的机器。

​

​

Step 3

需求评估

任何事情，都是讲究ROI（投入产出比）的。通过上面的方法，我们会收到很多各式各样的需求，我们本可以都做，但遗憾的是，公司的时间资源和开发资源往往是有限的，因此我们需要筛选出价值最大、影响面最广、正收益最大的需求来实现，这就要对需求进行优先级排列。
评估需求优先级的维度如下:
1 影响人数
影响人数可以借助神策或后台统计遇到类似问题或拥有类似需求的用户数量、日活占比、用户价值（普通用户还是深度用户）
2 增值价值
分析增值价值，需要按照具体需求来看了，大体可以区分为：新增功能模块（如：新增想法Tab，用户可以分享交流想法）、优化功能（如：多步骤流程，通过预填写抓取字段来降低用户的输入成本）、完善功能点（如: 为用户的收藏夹提供分类标签的功能，以便于用户管理数量较大的收藏内容）
3 开发成本
有些需求是可以单纯客户端、前端就可以完成的，实现陈本一般较低，灵活度低（需要发版）例如：将图片的尺寸放大、缓存记录用户的近期输入数据等；还有一些是需要服务端与前端配合，不需要发版，这种需求相对来说实现陈本中等，灵活度适中，例如想要在原生App内嵌套的H5页面进行优化，不需要发版本，相对灵活，但可能需要服务端的配合；还有一些内容是全端配合，服务端甚至要开单独的表来写入读取数据，这种就需求开发成本大，灵活度低。

因此需要对不同类型的需求功能进行科学的安排，从而提高工作协同效率。

​

​

Step 4

小步快跑实现需求，最小可用性模型MVP（Minimum Viable Product）

在确定好需求后，面对一些开发成本较大，收效却不确定的需求，可以采用最小可用性模型（Minimum Viable Product），小步快跑，边做边看数据。下面这张图，很好的说明了什么是最小可用性模型。

​

​

​

​

​

 

​

​

​

​

​

​

​

​

 

不过应用到实际产品设计中，就不是那么容易区分了。
比如团队计划优化信息流内的内容cell样式，从原有的单图模式改为三图模式，我们的做法是：借助原有的信息流广告系统，通过设计讲单图伪装成三图模式，然后观察调整后的三图内容cell CTR的变化，结果发现：在同标题情况下，三图模式要比单图模式点击率高一倍。后来我们花了一个版本的时间，在信息流内新增了一个三图type。
回顾来看，这里的MVP是：用户视野中的三图，而非经过完整开发，彻底从数据结构上实现的三图。 熟练运用这种方法，能够帮主开发团队把试错成本降到最低。