这是产品问答的第二篇，探讨对用户需求的深入挖掘。

问：在挖掘用户需求时？如何深刻的挖到用户的需求？
答：用户需求，字面意思就是用户的需求。
用户的需求，有这么几个特点：
1）强烈的个人倾向。某个用户提出的需求，往往是其在使用产品遇到问题所产生的。每个用户的使用习惯、认知等都不相同，可能他遇到的问题，其他用户并不是问题。
曾经有一个客户提出，他每次进入到邮箱，都想可以直接编写新邮件，而不是非要去点击“新邮件”这个按钮，这就是个人倾向比较明显的需求。并不是所有邮箱用户，都认为编写新邮件是最重要的需求。
2）提出的是浅层希望。用户提出需求不会进行深入思考，而是被触动当下的浅层希望。
很多产品经理耳熟能详的故事-“更快的马车和发明汽车”，商人浅层希望直接表达为希望马车可以跑的更快，而其深层需求是更快的速度。那么发明汽车提供比马车更快更持久的速度，才是对其真实需求的最佳满足。
3）提出现成的功能。很多时候用户提出的，是直接了当的功能。
在做互联网医疗项目时，曾有一位患者，对我们的不良反应反馈功能（癌症患者在手术后的治疗过程中，每进行一个疗程都要反馈自己身体的不适，包括头晕、恶心、呕吐、疼痛等等。这些信息会辅助医生来决策，当前方案是否合适，是否要进行调整），提出这么一个需求：“我每次都要一项项输入这些信息，我想你们能在这个页面地下放个按钮，我按住以后就像微信聊天一样说话，医生到时候直接听就可以了”。
4）只从单个或片面的角度考虑。用户提出的需求，可能是客观情况中的单个角度。
还是前面提高的互联网医疗项目，我们服务的一家医院科室，提出一个需求：“我们这次要增加一个功能，患者预约了手术，我们的医生审核确认之后，患者就不能再取消预约。”
这个需求一定是这个科室从自身业务或利益角度考量决定的，但并不是所有科室都会这么考虑。实际也证明我们服务的其他科室，很多都允许患者在要求时间之前提交取消申请。
5）只考虑自身利益，忽视可能对其他人造成困扰。
同样还是前一个例子，科室提出不允许患者取消，并没有考虑到患者可能出现的情况。如果患者确实无法进行手术，而功能上却不支持这样的操作，最终伤害的是利益相关的双方。

实际情况是，用户提出的需求，同时包含多种特点。对用户需求的特点进行识别，再针对性处理，是最高效的方法。

1）个人倾向的需求。
这类需求，要拓展到更大的需求框架中进行对比和思考。
还是用邮箱产品的例子。
我们判断这个用户提出这样的需求，是因为他使用邮箱时，更频繁的是发送新邮件。假设有一群这样的用户，我们定义其为“邮件发起者”。那么我们就可以通过问卷调研来搜集，现有用户中（或者所有邮箱使用者中）“邮件发起者”的比例有多少，他们对于这种直接发送邮件功能的需求程度，以及他们是否还有其他更好的想法。
同时，我们还可以根据邮箱的主要功能，再假设几个用户群出来，如：“邮件审阅者”、“邮件转发者”、“邮件回复者”等。那他们是否也有类似的需求，将某个常用功能排序到操作的第一步。我们的这些推测可以通过问卷调研一次性搜集。
假设通过分析，验证了如上猜测，那我们就可以总结：
邮箱用户可以根据使用邮箱的主要目的，分为：“邮件发起者”、“邮件审阅者”、“邮件转发者”、“邮件回复者”等几种类型。每种类型的用户都有将其主要使用步骤前置的需求。那么我们就可以考虑如何去满足这类需求。比如：开发一个选择用户类型的功能，方便每个类型的用户直接将主要功能前置，而如果用户没有需求，则仍保持传统邮箱功能序列。

2）浅层希望的需求。
停留在浅层希望的需求，可以通过复原场景的方式来获得更深层信息。
这方面的产品文章有很多，大家感兴趣就能找到，我还是从最经典的“更快的马车和发明汽车”来简单阐述。
商人提出需要更快的马车，我们应该去和他聊聊，通过沟通复原他提出需求的场景。问他这些问题，可能会有帮助：
a、你使用马车是用来做什么？
b、你对速度的要求，是基于什么样的考虑？
c、你在载重量、时间持久、使用成本有什么要求么？
d、在上面这些因素里面，速度真的是你最优先的要求么？
e、上面这些因素里，有哪些对你造成过困扰？
…
这些问题得到的答案，往往可以引申出新的问题，直到你觉得你已经深度复原了需求提出的场景。相信那时候，你对真正的需求也有了完整的认知。
提问方法，可以参照“5W1H分析法”。

3）体现为功能的需求。
提出是已经成为功能的需求，可以围绕功能的每一步进行访谈。
同样用举过的例子来说明。患者的需求描述是：“我每次都要一项项输入这些信息，我想你们能在这个页面底下放个按钮，我按住以后就像微信聊天一样说话，医生到时候直接听就可以了”。
可以提出这些问题：
a、您每次输入不良反应，大概会输入多少项内容？
b、输入的内容量有多少，哪些是您觉得比较犯错或容易出错的？
c、假设现在我们已经在这个页面增加了按钮，您现在按住它，模拟一下您现在要说的内容。
d、现在您讲完了，页面提示您已经增加了一段录音，您是否需要回放一下？您是否可能需要删掉这条，在重新录音？
e、您是否想知道医生有没有听完您的录音，您希望医生听完以后给您什么反馈么？
通过一系列的问题，就可以建立一个完整的围绕功能的需求逻辑。

4）角度片面的需求。
角度片面，表示提出来的需求，可能只是完整业务流程的其中一条路径。这时应该先去梳理出完整的业务流程图，建立对需求可能性的完整认识。
A医院的科室提出，要取消患者对已预约成功手术的取消机制。我们就应该先从A医院开始，询问他们提出这个需求时，所基于的实际业务情况。这里需要运营一些业务调研访谈的方法论，也需要培养自己的对于业务的理解和梳理能力。（如要展开说又要讲半天，我尽量以后有机会再详细阐述。）最好的结果就是，可以把A医院围绕这个功能的业务情况，梳理成业务流程图。你可能会发现，原来提出的需求并不能覆盖他们实际的业务，那就需要在满足需求时，整体考虑业务情况。
我们之前是一款Saas产品，满足对一家医院的业务覆盖，是不能作为标准功能去迭代的。所以还要以一家医院的业务流程图为基础，去广泛调研访谈更多的医院科室。最终把所有医院的业务情况整合成一个更加全面完整的业务流程，才能考虑如何在迭代中即满足某些业务特例，又不会对其他正常业务造成影响。

5）只考虑自身利益的需求。
这类需求是一种利益博弈，对待博弈最好的办法就是寻找利益的临界点或最优解。需要才双方或多方的角度各自出发，寻找最终可以被广泛接受的方案。
通过深入沟通，我们了解到科室提出该需求的考虑为：“经常有患者因为误操作或者说不清楚的原因，取消了手术预约。而科室已经为准备手术付出了很多成本，甚至于已经取消的患者会出现在住院部要求继续进行手术。导致医院床位、人员、手术室的资源浪费。”
同时问到科室：“如果真的患者有必要的情况无法手术，你们要如何处理？”科室回复：“需要患者联系医生，医生确认后就会取消手术”。
所以我们了解到：
a、科室并非不能接受患者的取消，而是因为患者误操作或其他原因，导致手术安排混乱；
b、科室可以接受患者想医生提出取消申请，医生来确认的业务路径。
后来我们设计的功能是：患者线下联系医生后，医生会在系统内将患者的手术取消掉。
也许你会问：
a、为什么不设计成，患者申请医生审核呢？
设计成患者申请，患者依旧会产生误操作，医生要继续为误操作投入时间成本；
b、为什么一定要医生在系统中取消呢？
因为后续手术的预约一定是建立在没有进行中手术的前提上，不限制会造成更多问题。

当我们对用户的需求理解比较完整，就可以进行下一步工作，将用户需求转化为产品需求。

用户需求了解完整，并不代表我们一定要去规划并开发。我们需要使用之前说过的产品战略对产品的指导，来筛选最终要去实现的需求。
而所有最终抉择后留下来的待开发需求，也正因为我们的深入挖掘，能够对最终形成的产品需求，作出更全面的指引。