前几天读到 Gergely Orosz 的一篇旧文，英文标题是 The Product-Minded Software Engineer。文章发表于 2019 年，2022 年还修订过一版。中文里能读到一篇公开译文，题为《如何成为一名具备产品思维的工程师》。核心就一句：具备产品思维的工程师，不只关心怎么实现，还会追问为什么要做、为谁而做、怎样才算做成了。
这不是让你改行当产品经理。Orosz 写得很清楚，它是在工程能力之上，再补一层产品判断。
一、功能写完，工作还没结束
按时把需求做完，是工程师的基本功，不能轻看。可如果长期只问「我做完了没有」，就很难解释这件事为什么值得做，上线之后也很少回头看：到底有没有人用，有没有带来预期的结果。
不妨用一个常见的后台需求来看。本文举例，不是原文里的案例：给对账页加一个「导出」按钮。实现并不难，字段、分页、权限对上就能交。可它要解决的问题，可能是运营拿去线下核对，也可能是财务要留存证据。这两种用法，对导出范围、格式和成功率的要求并不一样。如果上线两周几乎没人点，真正缺的也许不是按钮，而是列表里少了筛选、对比或异常定位。
Orosz 强调的是后半段：一次功能不能停在「已经发布」。他还要看用户怎么用、业务指标有没有变化。表现不如预期时，他会像查一个难复现的缺陷一样，去找计划和现实之间差在哪。
具备产品思维，先补的是判断，不是职位。
二、九个特质，可以收成三条
原文列了具备产品思维的工程师常见的九个特质。不必把它们背成清单，更值得记住的是三条工作习惯。
第一条，先想清楚再动手。他们不会拿到规格就开工，而会追问为什么先做这个、成功怎么衡量，也会去了解业务怎么运转、用户怎么使用、数据怎么说。提出的建议，不是凭空猜，而是从这些信息里来。
第二条，在实现里做取舍。他们能跟产品、设计、数据、客服把话聊清楚，也会同时看产品影响和工程成本。工程量大的时候，他们不只想把实现做小，还会提出另一个产品方案：效果接近，但投入小得多。边缘情况也是一样，先分清哪些必须在首版处理，哪些可以先用说明、重试或人工支持顶住，避免为了极少发生的场景把周期拉得很长。
第三条，对结果负责。功能还没完全做好时，他们就会找办法做小范围验证，比如给同事试用，或先给产品经理看半成品。发布之后，他们仍会跟进真实使用情况。一次项目走完，判断会准一点；多次之后，产品经理也会更早来问他们的意见。
九个特质是原文的观察，不是检查表，也不必一次做齐。
三、一个项目，怎样把判断练出来
Orosz 把一次典型项目写成一个学习闭环。翻译成研发同学能直接套用的步骤，大致是这样：
先把「为什么做」问清楚，再把可以权衡的方案放到桌面上，其中一部分会改进行动方案。接着尽快做出一版，边做边收集早期反馈。上线之后，主动回看它有没有达到预期。如果没有，就深挖原因，补上对真实使用的理解。
这个闭环的关键，不是把流程写得更完整，而是每次都把「我以为会怎样」和「实际发生了什么」对上。猜对了，可以强化判断；猜错了，更有价值，因为能看清楚自己高估了什么、低估了什么。
闭环来自原文对典型项目的描述，步骤是便于执行的归纳，不是必须按五步打卡。
四、后端同学可以从当前需求开始
你不一定要先转去做产品，也不必从一份全新的用户研究开始。如果正在做面向业务的系统，现在这项需求就够用。
可以先弄清几件很具体的事：公司或这套系统靠什么创造价值，你负责的模块在其中影响哪一环，这项需求要改变谁的什么行为，上线后看什么，才能判断它做成了。再和产品经理说清楚，你希望更多参与产品讨论，并请对方对你的建议给反馈。
有机会的时候，听一次用户访谈，或者看一组客服工单、运营反馈，比再读一篇方法论更有用。提出建议时，尽量同时给出产品影响和工程量，让它容易被排进计划。工程特别重时，主动给一个更小的产品方案，而不是只在实现路径上做压缩。
这些练习，Orosz 是写给面向用户的产品团队的。落到企业内部系统里，用户常常是业务、运营、财务或下游开发，判断方式仍然成立：先弄清他们卡在哪，再决定做什么，上线后再验证。
五、本周可以先做的一件事
下次评审需求，或自己动手做一页方案时，先写下四行：
-
服务谁 -
要改变什么行为 -
最小的验证是什么 -
上线后看哪个指标
发布后两周，对照一次真实使用情况。不必做完整的实验设计，只要把预测和结果写下来。这是原文里「端到端负责」最容易起步的一步，也是最接近日常工作的一步。
它是一个练习方法，不是已经验证过的增长技巧。没有回看，判断就不会被校准。
四问是根据原文实践建议整理的起步动作，不是原文逐字清单。
来源说明
本文改写评论所依据的原文，是 Gergely Orosz 的文章The Product-Minded Software Engineer
https://blog.pragmaticengineer.com/the-product-minded-engineer/