我们还是继续分析“用户需要一匹马”的这个需求，用户是为了快速、舒服的前往某地。在此基础之上，我们探究其与价值观的联系，可能会由以下三部分构成：

生理：骑马相较步行而言，会更舒服、不那么累人，而没有人会不喜欢轻松舒服的完成目标

社交：在出行路上，可能会遇到徒步顺路的旅行者，如果你愿意，可以载他们一同前往，也免得这一路太孤单，这时社交属性也融入其中

尊重：和步行相比，骑马出行的人的生活层次、消费水平都会更高，资产背景条件都会更好。所以大多数情况下，会得到别人的尊重和认可

4、产品功能

在剖析了用户的价值观后，我们就需要把用户需求从一个抽象的概念转化为一个实体的功能，这其实非常考验一个产品经理的设计功底是否雄厚

我们要尽可能简单的设计产品功能，而不是一开始就把一个功能设计的尽善尽美，这需要用到MVP原则——最小可用性功能集合，这个会在后续有关项目把控的文章中着重展开

而在这里，我们要明白的是，一个功能拥有一条完整的主流程，可以满足用户需求即可。而许多分支冗杂的附加功能，并不是在设计之初就加上的，而是要在功能得到用户认可后，起到锦上添花作用的

我们需要做的是快速迭代：快速验证产品方向是否正确，快速确定产品功能是否满足需求。而如果把功能设计的过于复杂，增加不必要的资源浪费，那么带来的负面影响是难以衡量的

这也就是为什么，福特公司面对用户对马有需求时是造的汽车，而不是飞机；为什么最早的汽车连车顶都没有，只有方向盘、车轮等必需组件

下面讲一个有关我之前工作中出现的需求转化实例：

我之前的一家公司是从事驾考类app服务的，对标竞品为驾考宝典、元贝学车等。app中的底部导航栏对应4个模块：驾校报名、理论学习、上路陪练以及个人中心

在工作中就遇到了一个用户共性需求，由于产品本身是驾考工具类型的，所以只有当用户需要填报课程、预约练车、学习理论知识的时候才有启动app的动机，当然还有少部分用户即使去学车也不使用app。而这样的后果就是用户活跃度低、留存率低、唤起app间隔时间长

后来我们专门去了驾校进行实地访谈，和学员们沟通交流产品体验。经过深入的研究，我们决定采用另一种“从始至终”陪伴学车全程的模式。我们是这样做的，多加了一个功能性需求和一个非功能性需求：

功能需求：增加学车进度功能，为用户实时展示已学天数、预估还有多少天拿本、超过多少同期学车的用户等

非功能需求：判断用户当前所属状态，然后针对不同状态，分类固定不同页面为首页。比如没有登录或者没有报名的用户，首页固定在驾校报名页；已经报名的用户，首页则固定为理论学习等

在版本迭代上线之后，DAU、留存率等各项指标均有了大幅度提升，并且用户学车积极性也有所高涨