如果你是工程师，有没有过这样的经历，当用户/客户以及项目端提出一个功能需求的时候，我们的第一反应就是怎么去实现它，然后立马就去按照自己的想法去实施了。这属于开发人员的思维：考虑怎么干。因为我原来的角色是AI算法工程师，所以这是我原来处理问题的惯性思路。
但现在作为产品经理，面对一个用户/客户以及项目端提出来的功能需求，需要先考虑的是why，再考虑how。
先考虑Why
比如:我们接到一个需求是：将扫码获取的信息保存在C盘，以天进行保存(0-24)小时，文件夹命名为UPI。我们需要识别到这个“需求”可能只是用户/客户提出的满足他们真需求的其中一种实现方式。
那我们需要与客户沟通，询问做这个独立信息保存的目的和用途是什么。(提问方式也需要注意,直接问为什么容易带着质疑的气氛，我们尽量避免让客户产生以为你是不想做而质疑他，找他扯皮等其他负面的感觉，而是让客户感受到你是真诚地在考虑如何更好地满足他的需求)
询问得知：之所以要做信息独立保存，是需要被外部软件读取，用来监控UPI对应板件的在生产全流程的路径信息，以及以此信息来统计生产员工的工分。
在Why 这个阶段考虑和搞清楚的是这个“需求”的场景，来源，动机和意图，从而去发现真需求。
再考虑how
在上面的案例中，客户真正的需求是监控生产流程的路径信息和统计员工工分，而真需求在另外一个软件产品B中实现的。只是需要检测软件扫码获取的信息可以被外部读取，而信息可供外部读取这个子需求可以考虑的实现方式就可以有很多种。围绕客户的目的我们知道，这个功能会影响员工的工分(和绩效挂钩)，因此它的重要程度也就提高了，采用保存在软件外部的方式存在被误删的风险，一旦出问题就会影响员工的切身利益，产生利益矛盾。这时候就需要给客户提示风险，提出其他解决方案看是否更加合适。
扩展：一个需求的处理全流程
