2、产品思维的本质：从「怎么做」到「为什么做」

我记得刚转产品那会儿，有个老同事问我：「你现在每天在想什么？」

我说：「在想怎么把功能做出来啊。」

他笑了：「那你还是个工程师。」

这句话我记了很久。说实话，当时挺不服气的。但后来我明白了——产品思维和工程师思维最大的区别，就在于你关注的是「为什么做」，还是「怎么做」。

2.1 工程师的思维惯性：问题导向

做工程师的时候，我们每天面对的都是「问题」。

• 这个接口怎么设计？
• 那个算法怎么优化？
• 系统延迟怎么降下来？

你想想看，我们被训练成解决问题的高手。老板说「做个登录功能」，你马上开始想：用OAuth还是JWT？要不要做第三方登录？密码加密用什么算法？

这些都是「怎么做」的问题。而且做得越好，你越觉得自己厉害。

我在项目中遇到过一件事。有个同事花了三周时间，把某个模块的响应时间从200ms优化到了50ms。他特别兴奋，在周报里写了满满一页。结果产品经理看了一眼说：「用户根本感知不到这个变化，我们真正的问题是注册转化率太低了。」

嗯，这就是典型的「怎么做」和「为什么做」的冲突。

2.2 产品思维的起点：价值导向

产品思维不一样。它问的第一个问题永远是：「我们为什么要做这个？」

说白了，就是这件事有没有价值？对谁有价值？值不值得做？

我刚开始转型时，最痛苦的就是这个。老板让我做个新功能，我第一反应还是「怎么做」。后来我强迫自己，接到需求后先问三个问题：

1. 这个功能解决谁的什么问题？（用户是谁？痛点是什么？）
2. 不做会怎样？（优先级有多高？）
3. 有没有更简单的办法？（一定要用技术解决吗？）

你可能会觉得，这有什么难的？但真做起来，你会发现大部分需求都经不起这三问。

2.3 从「功能列表」到「用户故事」

工程师习惯写功能列表。比如：

版本1.0 功能清单：
- 用户注册/登录
- 商品浏览
- 购物车
- 订单管理
- 支付功能

这有什么问题吗？看起来挺清楚的。但产品经理看的是另一套东西：

用户故事：
- 作为新用户，我想快速注册，这样我就能开始购物了
- 作为购物者，我想把喜欢的商品加入购物车，这样我就能一次性结算
- 作为买家，我想查看订单状态，这样我就知道什么时候能收到货

看出区别了吗？功能列表关注的是「系统有什么」，用户故事关注的是「用户能达成什么目标」。

我个人习惯，做产品规划时永远用用户故事。它强迫你去想：用户为什么要用这个功能？他的使用场景是什么？他期望得到什么结果？

2.4 避坑指南：别把手段当目的

做产品时，一定要分清楚：

手段（怎么做）	目的（为什么做）
优化算法	提升用户体验
增加功能	解决用户问题
降低延迟	减少用户等待焦虑
提升并发	支撑业务增长

你想想看，很多技术人做产品失败，就是因为太沉迷于「手段」了。觉得技术牛逼就是产品牛逼，其实完全不是一回事。

2.5 思维转型的三个关键动作

从工程师到产品经理，思维上要做三个转变：

1. 从「解决问题」到「定义问题」

   工程师习惯拿到问题就开干。产品经理要先想：这个问题是真的吗？值得解决吗？有没有更好的问题可以解决？

2. 从「技术最优」到「方案最优」

   技术最优不一定是产品最优。有时候一个笨办法，但能快速验证想法，就比完美的技术方案更有价值。

3. 从「交付功能」到「交付价值」

   功能做完了不代表成功了。用户用了没？用得好不好？有没有解决他的问题？这才是衡量标准。

2.6 一个真实的案例

我之前带过一个团队，做一款企业协作工具。工程师们提了个需求：要做个「代码片段分享」功能，因为大家觉得程序员之间分享代码很方便。

我问：「为什么要做这个？」

他们说：「因为Slack有啊，我们也要有。」

我又问：「我们的用户是谁？」

「程序员啊。」

「那程序员现在怎么分享代码的？」

「用微信或者钉钉发代码截图。」

「所以问题是什么？」

「截图不能复制，而且格式乱了。」

「那我们要解决的是『分享代码』的问题，还是『代码格式不乱』的问题？」

他们想了想，说：「后者。」

最后我们只做了一个很小的功能：在聊天框里支持代码高亮显示。开发量从两周变成了两天。上线后用户反馈特别好。

你看，这就是「为什么做」的力量。想清楚了，很多事其实没那么复杂。

2.7 小结

产品思维的本质，说白了就是一句话：先想清楚「为什么」，再考虑「怎么做」。

这个转变不容易。我花了差不多一年时间才真正适应。但一旦你开始习惯性地问「为什么」，你会发现自己的视角完全不一样了。

下一章，我们会聊聊「用户思维」——怎么真正站在用户的角度想问题。嗯，这个比你想的要难得多。