• 分解问题： 是灯泡问题？是开关问题？是线路问题？还是整个电路问题？

• 系统分析： 先检查灯泡是否拧紧，然后换个新灯泡试试。如果还不亮，就检查开关，看是否有烧焦的痕迹。接着，可能会用万用表测量线路电压，判断是否有断路。

• 精确验证： 每一步都基于可观察的现象和可测试的假设。

• 追求最优解： 最终找到导致灯不亮的根本原因，并用最有效、最可靠的方法解决它。

工程师往往沉浸在技术的海洋中，专注于参数、代码、算法、硬件指标，却可能忽视产品最终使用者——"人"的真实感受、日常行为、情感需求和非理性决策。他们可能觉得一个功能"技术上很完美"，却没意识到用户觉得"用起来很别扭"或"根本不需要"。

比如： 一个智能家居工程师，他设计了一个功能强大的智能门锁，但是，关门的时候很容易夹手（除非你是左撇子），见下图(本图为真实照片，非AI生成)

这种缺失在于未能从使用场景，以及用户行为、心理学和社会学的角度去理解产品与人之间的互动，过于强调"功能性"而忽略"体验感"和"情感性"。

工程师思维偏重技术可行性和内部逻辑，容易低估或忽略商业模式、市场竞争、供应链、运营维护、法律法规、以及用户教育成本等外部非技术因素对产品成败的影响。

例如： 某家AI创业公司研发出全球最先进的图像识别算法，能精准识别任何物体。然而，他们可能忽略了将这项技术商业化需要庞大的数据标注成本、高昂的云计算资源投入，以及如何在现有市场找到明确的应用场景和盈利模式。技术再强，如果不能解决真实商业问题，也难以存活。

这种缺失体现在创新边界界定不全，未能将商业价值链、市场动态和生态系统纳入考量，导致产品虽然技术领先，但商业化落地能力不足。

工程师思维习惯于在现有框架和已知解决方案中寻求最优解，或者线性优化现有技术。对于颠覆性的、没有先例的"无人区"创新，他们可能因为缺乏可量化的数据或清晰的技术路径而变得保守，甚至会用"不可能"来否定大胆设想。

例如： 某品牌手机的工程师在功能机时代无疑是顶尖的，他们能把键盘手机做到极致，信号稳定，续航超长。但当智能机兴起时，他们可能倾向于在原有基础上做优化（比如给功能机加触控），而不是从零开始思考"手机的未来形态"。因为全面转型意味着巨大的未知风险和对现有技术体系的颠覆。

这种缺失在于受限于归纳法和历史经验，缺乏演绎法和批判性思维，难以跳出"技术惯性"去重新定义问题和寻找"第一性原理"级别的解决方案。

工程师天生更擅长"How"（如何实现）和"What"（产品功能），却容易忽视最根本的"Why"（为什么要这么做？为了解决谁的什么问题？）。这种"为做而做"的心态可能导致资源浪费和方向偏离。

例如： 某团队开发"智能药盒"，工程师专注于添加蓝牙联网、用药提醒APP、药量监测传感器等功能，却未思考：用户为何需要智能药盒？

若用户核心需求是"避免漏服高血压药物"，一个设计醒目、带分格和物理提醒铃的普通药盒，可能比依赖手机APP的智能药盒更有效（尤其对老年人）。

这种缺失反映在对需求背景和用户价值主张（why）的理解不足，缺乏深层次思考和用户价值捕获能力，容易导致产品功能冗余、体验脱节。

研发工程师不再只关注技术可行性，而是主动走出舒适区，通过用户访谈、观察、共情地图等方式，深入了解真实用户是谁、他们的生活方式、他们的感受以及他们面临的真实问题。

例如： 你的团队在开发一款智能冰箱。拥有工程师思维的你可能会想到给冰箱加入各种传感器和复杂的AI算法。但通过设计思考的"同理"阶段，你可能会发现，用户最烦恼的不是冰箱不够"智能"，而是"食物经常过期浪费"，或者"总是忘记买什么菜"。

将"同理"阶段收集到的信息进行分析和综合，用以用户为中心的语言，清晰地定义出需要解决的核心问题（"我们如何帮助用户X做Y，以便Z？"）。这个定义应避免直接指向某个技术方案。

例如： 基于上述冰箱案例，你不会定义"如何开发一个最先进的冰箱AI系统"，而是定义"如何帮助用户减少食物浪费，并简化购物清单的创建？"这个定义引导团队关注用户价值，而不是技术复杂性。

鼓励团队进行发散性思维，提出尽可能多的解决方案，包括看似"疯狂"或非技术的想法。这个阶段的目标是数量而非质量，打破工程师固有的技术限制。

例如： 针对"减少食物浪费"的问题，除了智能冰箱，你可能还会构思出：一个食物管理App、一种新的食物储存包装、社区共享食物平台、或者一套食物保鲜知识普及课程。工程师思维会帮助评估这些方案的技术可行性，但设计思考则拓展了解决方案的广度。

不必等待完美的技术实现，而是通过低保真原型（如草图、纸质模型、线框图）或最小可行产品（MVP），快速将构思转化为可体验的形式，以便从用户那里获得早期反馈。

例如： 为了测试"减少食物浪费"的方案，你可以先用纸笔画出冰箱智能屏幕的交互流程，或者用Excel表格模拟App的食物过期提醒功能。这些原型不需要任何编程，但能帮助你快速验证用户对这些概念的接受度。

将原型或MVP交付给真实用户进行测试，收集他们的反馈意见。工程师需要放下"我设计的就是最好的"心态，积极倾听批评和建议，并根据反馈不断修改和完善产品。这个过程是迭代的，可能需要多次循环。

例如： 将你设计的"食物浪费减少App"的初步版本交给用户试用，他们可能会说："这个界面太复杂了"、"提醒不够及时"、"我希望可以和我的购物App关联"。这些反馈直接指导工程师优化产品功能和用户体验，使其更贴近用户需求。