前两天在知乎上有人邀请我回答这个问题，一开始觉得自己工作中经常碰到就尝试回答了下，但下笔后又发现又有点复杂。很多时候，用户的需求是一个问题、一个想法或者是一个吐槽，但是想要转换为产品需求，这中间的过程会有很多坑。下面拿一个例子就是之前我吐槽“百度地图的公交导航没有公交车的实时进度提示”，来说明如何将用户需求转换为产品需求，分为还原、抽象和设计这三个步骤。

    1、需求还原：需求是什么，是否真实、合理？

    这个需求在现实情况下，应该是这么被提出来的“哇靠，百度地图不行啊，公交车到哪了都不知道”、或者 “等了这么久，还说是最佳方案，结果公交车到现在都没来，方案不准吧”，然后用户可能把问题或者需求反馈给客服。一般产品经理接到手的需求可能是转过几手的，不一定是初始需求了，所以一定要做需求还原的工作，尽可能把用户的真实需求还原出来。

    1.1、谁有需求。在还原用户需求的时候需要明确需求的主语是谁，比如是老板、运营、客服还是市场等，并且尽可能详细的描述出来。这里不能直接写成是百度地图的用户，这样就无法区别是驾车导航的用户还是公交导航的用户，而驾车导航的用户根本就没有这个需求。很多时候，产品经理一头扎入需求的细节当中去，到最后却忘了给谁做的，所以做出来的产品也就有很多问题。

    1.2、什么场景下发生。还原需求发生的场景，需要站在用户的角度去思考，并且尽可能全面的描述出来有哪些场景。描述场景一般主要从时间、地点、人物、行为、心理这5个方面去描述（描述心理状况是最能看清楚是否真实的），目的是还原需求发生的场景，证明其存在的真实性，后面亦可用于指导需求的方案设计。这个需求的场景如下：

    1.3、解决什么问题。需求场景虽然真实存在，说明有一定的合理性；但此时再问一遍自己，这个需求到底解决什么问题。因为人们真正的需求，往往隐藏在表面问题之下，即问题是有层次的。比如开头的“等了这么久，还说是最佳方案，结果公交车到现在都没来，方案不准吧”这个问题，乍一看是说推荐方案不准确，其实仔细分析一下用户在抱怨“等了好久，公交车还没来”，问题也就是不知道公交车到哪了，但如果一开始就知道公交车还有好多站要等，是不是就不会抱怨了。

    一般描述问题可以写一个表面的用户问题，以及深层的问题（问题的本质）。不需要分层太多，分的太多说明没有了解问题的本质是什么。如下是这个需求要解决的问题：

以上，基本可以说明需求是什么，并且是否真实与合理。

    2、需求价值：要不要做，什么时候做？

    2.1、用户价值。主要说明这个需求对于用户来说，处于什么价值区间。可以用东京理工大学教授狩野纪昭提出的KANO来描述如下图（具体描述可以自己查下），分数代表用户体验增减。这个需求是可以落在期望需求之列，因为首先这个对导航工具来说不是必备功能，但是提供后可以提升用户体验；而用户在查看导航方案之后，是期望有一个公交车进度提示的（算不上兴奋，因为用户在具体的情景下是想得到的）。

    2.2、企业价值。可以从品牌增值与收入增值两个点分析，塑造品牌是企业长期价值所在，收入是更看得见的价值。对2C来说提升用户体验就相当于品牌增值，因为体验好就会黏性强，也就会吸引更多人使用，而流量就是收入。

    2.3、可行性与成本。产品经理可以不了解技术实现的细节，但必须要了解实现需求的可行性及其投入成本。这个需求其实百度的产品经理绝对是想到过的，并且也深入分析了，毕竟高德地图都做出来有一段时间了。为什么没做？因为要实现这个需求，必然需要知道每一辆公交车的实时到站数据，这里简单描述下可行性（没有深入研究过这里的可行性）：

    2.4、排定优先级。根据价值、可行性与成本的分析，对需求进行优先级的排序，比如优先级P几，跟着哪个版本研发。这个需求还是需要提案出来，进行商定的，需要做的前期准备较多。

    以上，需要确定需求的价值，即要不要做，什么时候做。

    3、需求设计：怎么实现？

关于需求设计这块，主要是讲如何把需求落地到可研发的产品需求，即业务流程、功能清单、原型设计等方面的详细描述。可以参考：《产品方法：需求处理的正确姿势》

   所以，深入的去分析一个用户需求，并将它转化为靠谱的产品需求，是一件可以做的很复杂的事情。稍微拔高下，相当于你有一个idea，打算把它当成是一个创业项目，去拉团队、拉VC，结果每一个人说你“想多了，怎么可能”。整个过程叫做如何将你的梦中Idea变成靠(苦)谱(逼)的创业项目。