看到这个标题，难免有人会问：“为什么要探索客户需求？我们不是要写产品技术文档吗？跟需求有什么关系”，且听我道来。
试想，客户拿到一本技术文档翻阅，什么内容才能吸引他看下去呢？当然是文档介绍的东西满足他的需求。只有客户看到你说的东西的内容能够满足他需求时，他才会想去知道如何去做（操作）才能满足需求，进一步他才会想知道为什么这么做（技术原理）才能满足（高级用户、技术专家）。
这就是为什么要探索用户需求，因为需要把这些写到文档（Short Description）中。
那到底如何去探索客户需求呢？
让我们先来辩识下这几个概念。
原始需求
客户希望解决自己问题而提出需求（此处的问题泛指提出人的愿望、要求或困境），是提出需求的根本出发点。
- 不要将问题和解决方案混为一谈，多数人过于关注解决方案，描述需求时往往直接描述自己拟好的解决方案，以解决方案代替需求，是导致需求失真的只要原因
- 原始需求只需完全记录客户的话，不要加入自己的理解
需求背景
包含两方面：
- 客户提出原始需求所处的情境
- 我们目前的实际情况（例如产品的状况、手册的状况）
有了原始需求和需求背景的对比，你就有可能知道客户为什么提出这样的“愿望 要求 或困境”，进而有可能分析出完全真实的客户目标。
客户需求
客户真正的目标
- 并非客户提出的问题本身，而是问题背后的故事，是客户真正的目标
- 与产品\系统无关
- 是做正确的事情
系统需求
在众多解决方法中最终确定的“解决方案”
- 系统需求的目标是为了满足客户需求
- 与产品\系统相关
- 是正确的做事
从这些概念中我们可以看出，最重要的是分析出真实的客户目标做正确的事情（客户需求），其次才是解决方案正确的做事（系统需求）。那么如何去分析呢？最常用的就是三步思考法了。
三步思考法
- 从解决问题的角度出发 -- 这个功能/特性能够解决用户什么问题
- 从客户价值角度看思考--当上一步局限在解决技术问题而看不出价值时，或回答过于泛泛时，需要思考这个步骤
- 从客户的客户的价值这个角度出发
回答完这三个问题，基本上客户需求就明朗了，接下要做的就是用SCQA的方式把客户需求、系统需求写到特性描述、特性配置。
