写了6年代码，我才懂好软件≠好产品

▲ 好软件、好产品、好商品，是三道各自独立的门槛

干嵌入式的第6年，我发现一件挺扎心的事。

我，以及我身边绝大多数同行，都是"把东西做对"的高手，却很少有人是"把东西做好"的高手。

寄存器配得一丝不苟，中断优先级排得明明白白，看门狗喂得比自家猫还准时，设备连跑三个月不复位。然后产品经理拿着客户反馈过来了，说："客户嫌这玩意儿用起来太麻烦。"

我们一脸茫然：麻烦？它明明能跑啊，一个 Bug 都没有啊。

对，问题就出在这儿。

所以今天只聊一件事：一个优秀的软件工程师，为什么一定要具备产品思维。

开篇先立三句话，它们是全文的地基：

• 一个好的软件，不一定是一个好的产品；
• 一个好的产品，不一定是一个好的商品；
• 而一个只会写好软件的工程师，很可能一辈子只值一份"好软件"的价钱。

一、不是我们不想做好，是"做对"已经把人榨干了

软件工程师是有思维的，而且是很硬的思维——系统思维。

我们脑子里常年装着时序图、状态机、内存分布、通信协议、异常分支。给一个需求过来，我们的第一反应从来不是"用户会怎么用它"，而是"这个上 RTOS 还是裸跑""状态机得拆几个态""掉电了数据怎么保""这个 Flash 擦写寿命够不够"。

这套思维极其宝贵，它保证了东西能用、不崩、不出事。尤其在嵌入式领域，我们做的东西经常没有"重启一下试试"的机会。

但它有个天然盲区：它对"人"不敏感。

系统思维关心的是：这条路，走得通吗？ 产品思维关心的是：这条路，人走着累不累？

这两件事之间，隔着一整个太平洋。

▲ 同一个需求，两种看法

而且说句公道话，我们真不是不想做好，是真的没劲儿了。

软件开发本身就是一件极度耗费心神的事情。而一个好的设计，比写代码更耗心神——它要求工程师带上自己的同理心，把自己塞进使用者的身体里，把整套流程真真切切地走一遍，再一处一处地把那些"用着别扭"的地方揪出来。

问题是，同理心这玩意儿，是要拿精力去换的。

当你已经连续三天在追一个偶发的 I2C 死锁，第四天你身上仅存的那点同理心，只会留给你自己。

于是流程就变成了：需求实现了 → 测试过了 → 提交 → 下一个需求。至于"用起来顺不顺手"，那是产品的事，那是 UI 的事，那是别人的事。

这不是懒，这是心力破产后的本能自保。

二、无处不在的二八定则，在这里格外残忍

二八定则在这个话题上同样成立，而且成立得特别不讲情面：

那 20% 让产品真正变好用的优化，往往要吃掉你 80% 的心神。

前 80% 的工作量，换来的是"能用"；剩下 20% 的工作量，换来的才是"好用"。

前者写在需求文档里，后者只写在用户心里——以及差评里。

更要命的是，这 20% 通常不体现在你的 KPI 上，不体现在代码行数上，也不体现在周报上。

你熬了两个通宵，把一个操作流程从 7 步压到 3 步，周报上是一行字："优化交互流程"。 隔壁同事新增了一个模块，周报上是十行字，外加一张架构图。

年底评优，你猜谁的材料更好看？

▲ 交付的那 20%，吃掉心神的 80%

所以对大多数人来说，不做那 20%，才是理性选择。

这也解释了一个现象：市面上"能用"的产品遍地都是，"好用"的产品凤毛麟角。稀缺的从来不是技术，而是那份愿意为最后 20% 买单的心力。

顺便说一句，你我作为消费者天天在骂的那些反人类设计——空调遥控器上十个你从没按过的键、需要连按五次才能进的设置菜单、报警起来能把人吓出心脏病的蜂鸣器——背后大概率也不是坏人，而是一群和你我一样、在 deadline 前已经心力破产的工程师。

三、产品思维怎么练？一条快路，一条慢路

好消息是，产品思维不是天赋，是可以练的。练法有两条，一快一慢。

快的那条：抄……啊不，竞品分析

竞品分析是所有行业的通用手段，不丢人，反而是基本功。

去看同行怎么做，尤其去看行业第一名怎么做。人家的急停按钮为什么放在那个位置，人家的报警为什么非要分三级，人家的菜单为什么死活只肯做两层，人家的默认参数为什么是那个数——这些设计背后，往往都躺着几百条用户投诉的尸体。

前人已经用脑门试出来的坑深，你没必要再试一遍。

这条路见效最快，缺点是天花板也明确：你最多做到和同行一样好，很难做到比同行更懂用户。

慢的那条：把自己泡进行业里

想突破天花板，只有一个办法：深入行业，理解这个行业到底在痛什么。

这条路没有捷径，慢，但它带来的东西别人抄不走。

关于这一点，我讲个我自己的故事。

四、一个躺在病床上的工程师，看见了什么

我是做医疗器械的。同时，我还是一名克罗恩病患者。

这个组合有点黑色幽默：白天我给医院造设备，隔一段时间，我自己躺回医院，用同行造的设备。

复诊、打针，是我生活的一部分。也正因如此，我有机会以一种大多数工程师没有的视角去观察我们这个行业的产品——躺在病床上的视角。

治疗克罗恩病有一种生物制剂，叫"类克"。这个药有个特点：基于它的药代动力学和药效学特性，输注不能像普通药水那样，设一个速度从头滴到尾，而是必须分阶段变速——每隔一段时间往上调一档，一档一档走完，直到输注结束。

我第一次亲眼看到它是怎么被输进去的时候，作为一个软件工程师，我人有点麻。

流程是这样的：患者或家属自己盯着表记时间，到点了，喊护士；护士过来，手动把输液泵的速度改一档；然后接着盯表，接着等，接着喊，接着改。一次输注下来，这套动作要重复好几轮。

护士忙得脚不沾地，患者绷着神经，家属盯着手机计时器不敢眨眼，生怕漏掉一次。

站在软件工程师的立场上，我该怎么评价这台设备？

它能精准设定速率，能恒速输注，能气泡检测，能阻塞报警，能防回血。功能全部实现，指标全部达标，这活儿干得挑不出毛病。

可站在使用者的立场上再问一遍：这是一个好功能吗？

显然不是。

这是一套繁琐、易错、极度消耗人力，并且把出错风险转嫁给护士和患者的流程。设备完成了它的"任务"，却根本没有解决使用者的"问题"。

▲ 同一条速率曲线，两种产品

那么，解决它需要什么惊天动地的技术吗？

不需要。剥开来看，它本质上就是一个多阶段输注序列：把速率曲线做成预置模板，医生选中方案，设备自己按时间轴切换速率，切换前提醒、切换后留痕，全程可追溯。

对一个嵌入式工程师而言，这不过是：一个带时间轴的状态机 + 一张参数表 + 一套 UI。技术难度，说实话，还不如你上周调的那个 DMA 双缓冲。

难的从来不是实现。难的是，得先有人意识到这里有个问题。

而我能意识到这一点，靠的不是我 6 年的编程经验，靠的是我作为一个患者，在病床上盯了两个小时的表。

这就是"深入行业"的价值：你离用户越近，就越能看见那些藏在"功能一切正常"背后的真实痛点。

五、产品思维到底值几个钱

我知道有人会说：想那么多干嘛，我一个写代码的，把需求实现了不就完了？

那我从三个层次说说它值多少钱，而且是从功利，到更功利。

第一层：向上走的入场券。

说句实在话，在大多数公司的职级体系和话语权排序里，"产品经理"这个 title 确实比"软件工程师"更有诱惑力——不是因为它更高贵，而是因为它离决策更近。工程师回答"怎么做"，产品回答"做什么"。产品思维，就是你从"执行者"变成"定义者"的那张入场券。

第二层：为自己打工的可能性。

再往远看，只有具备产品思维的人，才有可能在未来的某一天不再给别人打工。

技术能让你活得体面，但技术本身很难让你变成老板。真正能让一个人跳出打工人身份的，往往是抓住了一次真实的市场需求。而需求这东西，只有具备产品思维的人才看得见——同样一个场景，多数人看到的是"这流程真麻烦"，你看到的是"这里有个机会"。

第三层，也是最现实的一层：让领导多看你一眼。

就算你既不想当 PM，也不想当老板，只想安安稳稳写代码到退休——产品思维依然值钱。

在产品启动会上，当所有人都在争论"这个功能用什么方案实现"的时候，你举手说了一句：

"我建议加一个多阶段输注模板。临床上有几类药物必须变速输注，现在全靠护士手动改速，费时费力还容易出错。"

这一句话的分量，抵得过你半年的加班。

因为在那间会议室里，能把事情做对的人很多，能说清楚"我们该做什么"的人，很少。

▲ 产品思维的三层价值：越现实，也越值钱

最后

回到开头那三句话。

好软件是"没有 Bug"，好产品是"用着舒服"，好商品是"有人愿意掏钱"。

它们之间不是包含关系，而是三道各自独立的门槛。你在第一道门里练到满级，不代表第二道门会自动为你打开。

而从工程师到产品思维之间的距离，也从来不是一门新技术、一个新框架、一颗新芯片。

它只是一次视角的切换：

从"我做的东西对不对"，切换到"用它的人，累不累"。

写了 6 年代码，我最大的收获不是学会了多少种协议栈、玩转了多少款 MCU，而是终于想明白了一件事——

代码是写给机器执行的，产品是写给人用的。

前者要求你严谨，后者要求你有心。

而"有心"这两个字，恰好是这个行业里最不值钱、也最值钱的东西。

共勉。