“需求”、“用户需求”、“产品需求”、“特性”、“产品特性”、“功能”几乎每天都会被我们提到很多次，不管你是不是产品经理。虽然从未有人彻底解释和辨明这些相似的概念，但是并不妨碍聪明的我们完成工作。然而最基础的概念没有彻底明白，总会出问题。
在找寻根源的时候，我们永远也不会归结于概念不清。而通常是管理问题、沟通问题、审核问题、责任心问题……
“我们定位问题极限是我们认知边界，我们不可能找到我们自己都不知道的问题。”——艾老思
这句话有点绕，意思是我们不知道“我们不知道”。我们不知道我们概念不清，由此造成的问题，我们是无法识别出来的。
回到主题，我们来辨析一下这些词的差别，然后举例来说说我们应该如何使用。
概念澄清
用户需求（User Requirement)
用户需要的东西，产品或者服务。常常缩略为“需求”。
产品特性（Product Feature）
产品所拥有的特征、功能、品质、性质等。常常缩略为“特性”。
所谓特征，指产品的独特的形态、调性。
所谓功能，指产品提供的价值服务。
所谓品质，指产品的质量。
所谓性质，指产品的收费、公益等特殊属性。
两者关系
-
用户产生需求
-
需求应该被翻译为产品特性
-
产品是需求的解决方案
-
功能与服务的集合构成产品
-
特定的功能和服务的组合可以体现出特性
-
产品具有多种的特性
-
产品在使用过程中产生体验
-
体验被用户感知
举例说明
“我饿了”——用户需求
“一碗精品牛肉面”——产品
“双倍牛肉”——产品特性
这里可以很清楚的看出几个概念之间的差别。
但是放到互联网+产品中有时候就不容易分辨了。比如KTV O2O平台产品K米的一个特性“KTV包间预订”。
“KTV包间预订”是一个用户需求还是一个产品特性呢？
答案是：两个都是！
作为用户需求的表述是“作为一个要去KTV唱歌的用户，当我要约朋友一起唱歌的时候，我可以提前预订包间，以便我们能够顺利唱歌。”
作为产品特性的表述是“为用户和商家提供包间预订的全流程功能，具体包含KTV查询、包间报价、包间展示、预订下单、结果通知、冲突处理、过时取消等”。
两者都可以省略表述为“KTV包间预订”，但内涵确实完全不同，前者是在表达用户的需求，而后者是在表达产品如何解决用户的需求。
使用场景
我们可以用缩略语沟通，但绝不可以傻傻分不清楚，因为我们在不同的场景下所进行的沟通是不同。
我们在早期挖掘用户需求，讨论用户需求，验证用户需求的时候，是没有必要去考虑它的实现，然后很多程序员出身的产品经理会不自觉的陷入实现细节，这时就会非常容易忽略需求的真实性，最后做了没有人用的产品特性。
我们在设计产品，优化流程，改善体验的时候，我们讨论的是产品特性。但此刻我们仍旧需要紧盯用户需求，做每一个细节决策都来自一个真实的用户需求，只有这样才不会想当然，歪歪出一些没有人用的产品特性。
展现形式
用户需求应该用《用户需求说明书》来表达。其中必须包含四个要素：
-
用户
-
场景
-
需求
-
价值
举个反例
这是一个《日程安排需求说明书》的一部分，这里描述了用户定位，看起来做到了，但其实远没有。这里的用户分析是一个非常粗略的分析，而且可以很明显的看出是缺乏实际依据的，是自己臆想出来的用户群体和用户需求。
产品特性应该用《产品特性文档》来表达。其中必须包含七个要素：
-
用户需求说明
-
特性设计思路
-
核心业务逻辑
-
原型交互设计
-
验收通过条件
-
异常情况处理
-
运行数据指标
这是一个产品特性设计的例子，和大多数产品设计者一样，关注点集中在正常业务功能实现，缺失了异常情况、验收条件、数据指标等考虑。这样很容易产品做出来了，但却体验很糟，由于没有数据支撑，又不知道从何改起。
很多公司将两者合二为一了——《产品需求说明书》。
这两个都是传统的PRD，它们都是产品整体设计文档，而不是特性文档。它们背后的逻辑都是把产品当做一个整体进行研发设计，而不是基于特性迭代的。为什么要“基于特性迭代”进行产品研发？下次艾老思再来讲讲。
希望概念的明晰能够给你一个更加清晰的思维逻辑。
评论(0)