“需求分析”的过程到底是什么？如何将搜集到的用户需求转化为产品需求、再映射到产品功能中去呢？
苏杰先生在《人人都是产品经理》中提到了“Y理论”，将需求分析的过程形象化为“Y”，如图1所示。
图1 需求分析的“Y理论"
暂不考虑从“2-产品需求”追溯到“4-马斯洛需求”的过程，那么“需求分析”的过程实际上就是经历图中的“1用户需求–> 2产品需求—>3产品功能”。 1–>2，通过问“Why”，逐步归纳；2–>3，通过问“How”，逐步演绎。
本文基于某企业级IM产品，从消息提示相关的需求场景出发，根据“Y理论”进行归纳和演绎，提出了产品功能方案。
一、场景与用户需求
场景一：
用户在手机客户端收到一条消息，阅读后暂时没空处理该消息，并且确定在未来的某个时间有空，TA担心有空时会忘记处理这条消息。
场景二：
用户在手机客户端收到一条消息，阅读后发现该消息的处理需要借助于电脑，而目前用户并不在电脑前，TA担心回到电脑前时会忘记处理这条消息。
场景三：
用户在手机客户端收到一条消息，阅读后暂时没空处理该消息，但不确定什么时候有空，TA担心有空时会忘记处理这条消息。
二、产品需求
在场景一中：
为什么用户担心有空时会忘记处理这条消息？（why）
——因为TA有空时可能想不起来处理该消息。
因此，用户实际上是希望在TA有空时（确定在未来的某个时间有空），我们的IM产品能帮助TA想起某条重要而不紧急的消息，使TA不忘记处理，这就是产品需求。
在场景二中：
为什么用户担心回到电脑前时会忘记处理这条消息？（why）
——因为TA回到电脑前时可能想不起来处理该消息。
因此，用户实际上是希望在TA回到电脑前时，我们的IM产品能帮助TA想起某条重要而不紧急的消息，使TA不忘记处理，这就是产品需求。
在场景三中：
为什么用户担心有空时会忘记处理这条消息？（why）
——因为TA有空时可能想不起来处理该消息。
因此，用户实际上是希望在TA有空时（什么时候有空并不确定），我们的IM产品能帮助TA想起某条重要而不紧急的消息，使TA不忘记处理，这就是产品需求。
三、产品功能
针对场景一的产品方案：
如何帮助用户在有空时想起来处理这条消息？（how）
——在用户有空时，也就是未来某个确定的时间，提醒用户。
如何在未来某个确定的时间提醒用户？（how）
——产品方案一：在用户长按消息弹出的操作列表中提供“消息定时提醒”的功能
在“消息定时提醒”中，可以提供“稍后提醒”“明天提醒”“选择时间提醒”的选项，满足用户对于提醒时间的不同需求。
当用户设定的时间到了的时候，可以通过push或系统闹钟的方式提醒用户。如果是push方式，那么用户点击push进入会话窗口后，应能直达设置提醒的具体消息。
——产品方案二：将消息与产品已有的日程功能打通，在用户长按消息弹出的操作列表中提供“转日程”的选项
用户选择“转日程”后，自动进入“新建日程”页面，同时该消息自动作为日程内容填入，用户本人被自动添加为日程的参与人。用户只需将计划处理该消息的时间设置为日程的开始时间，再点击“提交”即可发起日程。
借助于日程的提醒机制，用户能在计划处理该消息的时间点收到提醒并处理消息。
——方案对比：
方案一通过开发新功能满足了用户需求，而方案二是利用已有的日程功能满足了用户需求。两种方案都能满足用户的需求，但方案二的实现成本更低。
针对场景二的产品方案：
如何帮助用户在回到电脑前时想起来处理这条消息？（how）
——在用户回到电脑前时，提醒用户。
如何在用户回到电脑前时提醒用户？（how）
——产品方案一：在用户长按消息弹出的操作列表中提供“PC端再次提醒”的功能
用户选中“PC端再次提醒”后，再回到PC端时，包含已标记“PC端再次提醒”消息的会话窗口为未读状态。并且，当用户点击并打开该会话窗口后，会话自动回滚到标记“PC端再次提醒”的具体消息附近，且该消息被高亮显示，从而达到提醒用户并定位具体消息的目的。
——产品方案二：基于产品已有的消息转发功能，在长按消息弹出的操作列表中提供“转发给我的电脑”的快捷入口
用户选择“转发给我的电脑”后，再回到PC端后，转发的消息在PC端作为新消息对待，会有未读提示，用户点开即可查看。由于转发给我的电脑的消息一般不多，因此不存在消息定位困难的问题。
——方案对比：
方案一通过开发新功能功能满足了用户需求，而方案二则通过改进已有的消息转发功能满足了用户需求。两种方案都能满足用户的需求，但方案二的实现成本更低。
针对场景三的产品方案：
如何帮助用户在有空时想起来处理这条消息？（how）
——在用户有空时，提醒用户。
但是用户不确定什么时候有空，那么如何能在恰当的时机提醒TA呢？（how）
——IM手机客户端是在工作中使用频率很高的工具，用户会时不时查看。如果在用户查看时该消息所在会话显示未读，那么每当TA打开app时都会注意到，直到TA有空时再次点开会话并处理了该消息为止。（这一做法与电子邮箱中广泛采用的邮件标记未读功能是异曲同工的）
——产品方案：在用户长按消息弹出的操作列表中提供“标记未读”的功能
用户将消息“标记未读”后，该消息所在的会话会变成未读状态，在消息页面有未读红点提示，从而在用户每次打开消息主页面时引起TA的注意。
当用户再次点击进入会话后，会话自动回滚到“标记未读”的具体消息附近，且该消息被高亮显示，用户据此可知未被处理的具体消息。
四、总结：
虽然上述场景中用户的困境比较明显，产品的功能方案比较容易得到，why和how的思考层级也就比较浅，但通过这些例子不难看出：从用户需求过渡到产品需求，再到提出解决方案，需要经过先问why再问how的过程，而不是“用户提了什么需求就去做什么功能”。