不是每个人都能当产品经理，但每个人都该有产品思维
最近和不少技术圈的朋友聊天，发现一个有意思的现象。
无论是在拓竹、大疆，还是字节、阿里的朋友，只要聊到“产品经理”这个话题，那些工程师们，往往会给出一个一模一样的结论：
“我们公司的产品经理是SB。”
吐槽归吐槽，但痛快之后，我们不妨静下心来，用第一性原理的思维，把审视的目光转回自己身上：
如果在产品经理眼中，用户是上帝；那么在我们工程师眼中，谁才是我们的“上帝”？我们打造的“产品”又究竟是什么？
用第一性原理来剖析技术工作的本质，你会发现：每个技术决策，其实都是在做产品设计；每次学习新知识，都是在进行自我迭代。
马斯克常提的第一性原理，强调的是回归事物本质。对技术工作而言，本质不在于“用了多炫的框架”，而在于**“以多高的成本，解决了什么问题，最终创造了多少价值”**。
这就是技术人员的产品思维。
缺乏这种思维，工程师很容易陷入**“技术自嗨”**：见到新技术就想追，看到老代码就想推翻重写，却很少算一笔经济账——这笔投入到底值不值。
举一个我亲身经历的例子。之前在一家传统行业公司，我发现产品里用了迪文品牌的串口屏，负责单片机和屏交互的核心代码，是一个巨大的switch结构，里面塞了2700多个case。第一反应是震惊，接着就涌起一股强烈的重构冲动——这代码实在不优雅，也不好维护。
但当我向leader提出重构想法时，却被直接拦了下来：“这代码已经稳定运行好几年了，目前没必要动它。”
这件事点醒了我：代码的“优雅”不是最终目的，稳定可靠地解决问题才是。如果现有方案已经能以较低成本满足需求，那么纯粹为了“更漂亮”而推倒重来，从产品角度看，就是一笔亏本买卖。
产品思维不仅能用在工作中，更应该用来指引个人成长。
今天C++，明天Rust，学个zephyr，搞个nuttx…很多工程师患上了**“知识焦虑”**：生怕不学就跟不上了，于是屯了一堆课、收藏无数文章，结果真正消化吸收的却没多少。
怎么破局？产品思维能帮上忙。
产品经理决定是否开发一个功能，看的是用户有没有真实需求。我们学习技术，也应该由真实的问题或需求来牵引。
学一套新东西的时候不妨问一下自己：
“学这个有助于我的个人技术成长吗？有助于提高我的技术能力，让我能做出更好的产品吗？“
“目前嵌入式在从传统的从0搭建，向zephyr，向Nuttx的生态转变，我需要学这个提高我未来的技术力”这显然是充足的理由。
当你带着具体问题去学，学习过程就有了应用场景，也有了效果反馈，知识留存率和转化率自然最高。
分清“核心能力”与“外围技能”
做产品要聚焦核心功能，个人成长也要把握重点。
- 核心能力：计算机底层原理、算法、系统架构设计能力，以及沟通协作、文档编写等软技能。这些是你的“护城河”，属于长效资产，值得持续投入。
- 外围技能：某个框架的具体API、某个工具的配置技巧。这些更新换代快，属于“易耗品”，应该在用的时候再学。
具备产品思维的工程师，会把主要精力投入到“核心能力”的夯实上。 因为API可能会过时，但对系统设计的深刻理解，永远都有价值。
写在最后
回到开头那句话。我们不一定都要转行做产品经理，去画原型、写PRD。
但我们在写下每一行代码、决定学习下一项技术之前，都应该具备产品思维：
- 这次投入的性价比如何？
- 这项技术真的能解决我面临的问题吗？
- 我做这个决定，是出于实际需要，还是仅仅为了满足技术虚荣心？
技术是工具，不是目标。
当你学会用产品思维去审视你的代码、规划你的成长，你就不再是一个被动的执行者，而成为自己职业发展的“掌舵人”。