做产品和做技术有着两种不同的思维方式，如果是从技术转岗到产品经理，如何完成思维上的转变呢？

有没有过这样的经历，当用户/客户以及项目端提出一个功能需求的时候，我们的第一反应就是怎么去实现它，然后立马就去按照自己的想法去实施了。这是技术开发人员的典型思维：直接考虑怎么干。

但作为产品经理，面对一个用户/客户以及项目端提出来的功能需求，需要先考虑的是why，再考虑how。

先考虑Why

举个例子：

我们接到一个需求是：将扫码获取的信息保存在C盘，以天进行保存（0-24）小时，文件夹命名为UPI。我们需要识别到这个“需求”可能只是用户/客户提出的满足他们真需求的其中一种实现方式。

那我们需要与客户沟通，询问做这个独立信息保存的目的和用途是什么。（提问方式也需要注意：直接问为什么容易带着质疑的气氛，我们尽量避免让客户产生以为你是不想做而质疑他，找他扯皮等其他负面的感觉，而是让客户感受到你是真诚地在考虑如何更好地满足他的需求）

询问得知：之所以要做信息独立保存，是需要被外部软件读取，用来监控UPI对应板件的在生产全流程的路径信息，以及以此信息来统计生产员工的工分。

在Why 这个阶段考虑和搞清楚的是这个“需求”的场景，来源，动机和意图。

再考虑how

在上面的案例中，客户真正的需求是监控生产流程的路径信息和统计员工工分，而真需求在另外一个软件产品B中实现的。只是需要检测软件扫码获取的信息可以被外部读取，而信息可供外部读取这个子需求可以考虑的实现方式就可以有很多种。

围绕客户的目的我们知道，这个功能会影响员工的工分（和绩效挂钩），因此它的重要程度也就提高了，采用保存在软件外部的方式存在被误删的风险，一旦出问题就会影响员工的切身利益，产生利益矛盾。这时候就需要给客户提示风险，提出其他解决方案看是否更加合适。

本文由 @宇宙一建原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

本站部分转载文章，皆来自互联网，仅供参考及分享，并不用于任何商业用途；版权归原作者所有，如涉及作品内容、版权和其他问题，请与本网联系，我们将在第一时间删除内容！

联系邮箱：1042463605@qq.com