The Product-Minded Software Engineer: 9 Traits and How to Grow Them
The author breaks "product-minded" down into observable behaviors: these engineers do not take a spec and start coding, they ask why first, challenge requirements, and evaluate product and engineering tradeoffs together. Nine traits are listed, including digging into business and user data, building relationships with non-engineers, applying a minimum-lovable-product lens to edge cases, and following user behavior metrics for weeks after launch before drawing conclusions. Product instinct, the author argues, compounds across repeated project cycles of questioning, proposing, validating fast, and debriefing gaps. Written for engineers on user-facing teams who work with PMs; it closes with six concrete habits to build the muscle.
Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. I've worked with many great product-minded engineers and consider myself to be this kind of developer. At companies building world-class products, product-minded engineers take teams to a new level of impact.
产品思维工程师是对产品本身充满兴趣的开发者。他们想弄明白每个决策为什么这样做、用户如何使用产品，并且乐于参与产品决策。如果哪天他们决定放弃工程带来的乐趣，多半也能成为优秀的产品经理。我共事过许多出色的产品思维工程师，也自认属于这类开发者。在打造世界级产品的公司里，这类工程师能把团队的影响力带到新高度。
Sherif Mansour, PM at Atlassian wrote an excellent article on product engineers, and how product managers can identify these people and work well with them. His takeaway is similar:
Over my last ten years of product management, I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager.
Atlassian 的产品经理 Sherif Mansour 写过一篇很棒的文章，谈产品工程师，以及产品经理如何识别这类人并与他们高效合作。他的结论也类似：
在从事产品管理的过去十年里，我逐渐得出结论：产品工程师是帮你打造成功产品、放大自身能力、成为更优秀产品经理的关键要素。
He also quotes Jean-Michel Lemieux, head of engineering at Shopify who defines product engineers like this:
Once you have the product foundations, you need devs who engage with the 'why', actively. Engineers who have the thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books. Bad ones cut too many corners. Great product engineers know that minimum lovable products need the right depth to be considered during the build phase.
他还引用了 Shopify 工程负责人 Jean-Michel Lemieux 对产品工程师的定义：
有了产品基础之后，你需要的是主动参与“为什么”的开发者。他们渴望用技术跨越人与用户的问题。他们带着同理心去追求神奇体验。在我眼里，这才叫产品工程师。差的工程师会偷太多工减太多料。优秀的产品工程师知道，最小可爱产品也需要在构建阶段考虑足够的深度。
Teams who are working on user-facing features, collaborating with product managers are environments where product-minded engineers can have a huge impact. They often become key contributors, the goto people for product managers and frequently advance to being team leads.
在面向用户功能、与产品经理协作的团队里，产品思维工程师能产生巨大影响。他们常常成为关键贡献者，是产品经理随时会找的人，也经常晋升为团队负责人。
So, what are the key traits of product-minded engineers, and how can you work on becoming more product-minded? This article summarizes 9 traits I've observed these kinds of people share, and my suggestions for any engineer to grow their product-minded muscle.
那么，产品思维工程师的关键特质是什么？你又该如何让自己更有产品思维？本文总结了我观察到的这类人共有的 9 个特质，以及任何工程师都能用来锻炼产品思维的建议。
- Proactive with product ideas/opinions
Product-minded engineers don’t settle for getting a specification and jumping to implement it. They think about other ideas and approach the product manager with these. They often challenge existing specifications, suggesting alternative product approaches, that might work better.
- 主动提出产品想法/意见
产品思维工程师不会拿到规格就埋头实现。他们会思考其他方案，并主动找产品经理聊。他们还常常挑战现有规格，提出可能更好的替代产品思路。
- Interest in the business, user behavior and data on this
When coming with ideas, product-minded engineers don't just get these from thin air. They take the time to understand how the business works, how the product fits in, and what its goals are. They are also empathetic about how the product makes users feel and how those users benefit from using this product. They often dive straight to data about business and user metrics, getting their hands on this data however they can. They might access it directly - if this is possible - or approach the product manager or data scientists to get this kind of information. They do this because of their curious nature. This is the next trait I've observed.
- 对业务、用户行为及相关数据感兴趣
提想法时，产品思维工程师不是凭空拍脑袋。他们会花时间理解业务如何运转、产品处在什么位置、目标是什么。他们也能共情产品带给用户的感受，以及用户如何从中获益。他们常常直接扎进业务和用户指标数据里，想尽办法拿到这些数据。如果可以直接访问，他们就自己看；否则就找产品经理或数据科学家要。之所以这样做，是因为他们天生好奇。这就引出了下一个特质。
- Curiosity and a keen interest in "why?"
Product-minded engineers like to understand the "why?" behind all things. Why build this feature for the product, why not the other one? Why ship this first milestone, instead of choosing another one, that's a lot simpler to build? How will things be measured - why don't we choose a more thorough way to measure things?
They are autonomous in finding answers they can, by themselves. They turn to the product manager and other people in the business for other, product-related questions. Even though they ask many questions, doing this frequently, they manage not to annoy people, as they've built up strong relationships with them.
- 好奇，且对“为什么？”有强烈兴趣
产品思维工程师喜欢弄懂一切事物背后的“为什么”。为什么要给产品做这个功能，而不是另一个？为什么先发布这个里程碑，而不是选择一个实现起来简单得多的？结果会如何衡量——为什么不选一种更彻底的衡量方式？
能自己找到答案时，他们会自主去找。遇到其他与产品相关的问题，他们会转向产品经理和业务侧的人。虽然问题多、问得也频繁，但他们不会惹人烦，因为他们已经和这些人建立了牢固的关系。
- Strong communicators and great relationships with non-engineers
Product-minded engineers like talking with people outside engineering, learning about what and why they do. They are smooth communicators, making it clear they're interested in learning more about how other disciplines work. I frequently see them grabbing coffee, lunch, or doing a hallway chat with non-engineers.
- 沟通能力强，与非工程师关系好
产品思维工程师喜欢和工程之外的人聊天，了解他们在做什么、为什么这么做。他们沟通顺畅，会明确表现出对不同职能如何运作的兴趣。我经常看到他们和非工程师一起喝咖啡、吃午饭，或在走廊里闲聊。
- Offering product/engineering tradeoffs upfront
Because they have a strong understanding of the product "why," as well as the engineering side of things, they can bring suggestions that few other people can. For example, when scoping the effort to build the product, the engineering effort to build a key feature might be significant. Many engineers would start to look for ways to reduce the effort and try to figure out what the impact of the reduced effort would mean for the feature itself.
- 主动给出产品/工程取舍
因为他们既深刻理解产品的“为什么”，也懂工程，所以能提出别人很难提出的建议。比如，在评估构建产品的工作量时，某个关键功能可能需要投入大量工程资源。许多工程师会开始想办法减少工作量，并推演减少投入会对功能本身造成什么影响。
Product-minded engineers attack this problem from both angles: both looking for engineering tradeoffs and what the product impact is. They also start making product tradeoffs, evaluating the engineering impact. They often go back to the product manager, suggesting a completely different feature to be built, given the product impact would be similar, but the engineering effort vastly smaller.
Juggling both the product and engineering tradeoffs and the impact of each is a unique strength product-minded engineers have. They can quickly go back-and-forth between the two sides of the same coin: product features and engineering effort and tradeoffs. Because they do it all in their head, using their engineering and product insights, they get to valuable conclusions remarkably quickly.
产品思维工程师会从两个角度同时进攻：既寻找工程取舍，也判断产品影响。他们还会开始做产品取舍，并评估其对工程的影响。他们常常回头找产品经理，建议改做一个完全不同的功能——如果产品影响相近，但工程投入小得多。
同时权衡产品与工程两边的取舍及其影响，是产品思维工程师独有的强项。他们能在同一枚硬币的两面——产品功能与工程投入/取舍——之间快速来回切换。因为他们在脑子里同时用工程洞察和产品洞察推演，所以能极快地得出有价值的结论。
- Pragmatic handling of edge cases
Edge cases are a funny thing. On one extreme, engineers often forget about many of these, having to come back to addressing them, after getting feedback from people testing the product or end users. On the other hand, handling all possible edge cases in a new product or feature can take a lot of time.
- 务实处理边界情况
边界情况很有意思。一个极端是，工程师常常忘记许多边界情况，等测试人员或最终用户反馈后，才回头处理。另一个极端是，在新产品或新功能里处理所有可能的边界情况，会耗费大量时间。
Product-minded engineers quickly map out edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work. They are focused on the "minimum lovable product concept" and evaluate the impact of an edge case and the effort of handling it. They come with good middle-ground suggestions: mapping out most things that can go wrong and bring suggestions on what edge cases need to be addressed, before shipping even an early version.
For example, if one in a thousand users might be hit by an error, they will consider the effort to fix it and think about what happens if they don't do anything. Can customer support help the person in this case, during validation? Can the user just retry and succeed the next time? Can the product be slightly modified, so this edge case won't occur?
产品思维工程师会快速梳理边界情况，并想办法减少处理它们的工作量：常常给出无需工程投入的解决方案。他们聚焦“最小可爱产品”理念，评估某个边界情况的影响以及处理它所需的工作量。他们会提出很好的折中建议：列出大多数可能出错的地方，并给出哪些边界情况需要在发布早期版本前解决。
例如，如果一千个用户里可能有一个会遇到某种错误，他们会考虑修复它的成本，并思考如果什么都不做会怎样。在验证阶段，客服能否帮助这个人？用户能不能直接重试，下次就成功？产品能不能稍微改一下，让这个边界情况不再发生？
- Quick product validation cycles
Even before the feature they are working on is production-ready, product-minded engineers find creative ways to get early feedback. This could be doing hallway testing with colleagues, showing the work-in-progress feature to the product manager, organizing a team bug bash on the beta build, and many other, creative ways. They are continuously thinking:"how can we validate that people will use this feature, the way we think they will?"
- 快速的产品验证循环
甚至在他们负责的功能还没达到生产可用之前，产品思维工程师就会用创造性的方式获取早期反馈。比如找同事做走廊测试、把半成品功能演示给产品经理、在 beta 版本上组织团队 bug bash，以及许多其他有创意的做法。他们一直在想：“我们怎么验证用户会像我们以为的那样使用这个功能？”
- End-to-end product feature ownership
Most experienced engineers own their work end-to-end: from getting the specification, through implementing it, all the way to rolling it out and validating that it works correctly. Product-minded engineers often go a step beyond this.
They consider their work done only after getting results on user behavior and business metrics. After rollout, they still actively engage with product managers, data scientists, and customer support channels, to learn how the feature is being used in the real world. It can take weeks to get enough reliable data to draw conclusions. Even though they might be working on a new project, they make checking on the results one of their top priorities. It's not a time-consuming activity, but it needs that additional persistence from someone wanting to know: how is my work really doing?
- 端到端负责产品功能
大多数资深工程师会端到端负责自己的工作：从拿到规格、实现，一直到上线并验证功能正常。产品思维工程师往往还会多走一步。
只有当用户行为和业务指标出结果后，他们才认为工作完成。上线后，他们仍会主动与产品经理、数据科学家和客服渠道保持互动，了解功能在真实世界里如何使用。要获得足够可靠的数据来下结论，可能需要好几周。即便他们可能已经在做新项目，也会把查看结果列为最高优先级之一。这件事并不耗时，但需要额外的坚持——一种想知道“我的工作到底表现如何”的劲头。
When a feature performs worse than expected, they are curious to understand where the mismatch was. They are just as interested in finding the root cause between the product plan and the real world result, as they are to debug a hard-to-reproduce bug in the codebase. They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists.
当功能表现不及预期时，他们会好奇差异出在哪里。他们像调试代码库里难以复现的 bug 一样，热衷于找出产品计划与现实结果之间的根因。他们还常常花大量时间和产品经理、数据科学家争论各种假设和学到的东西。
- Strong product instincts through repeated cycles of learning
A typical project for a product-minded engineer usually goes like this:
They ask a lot of questions to understand exactly why the product feature is being built.
They bring suggestions and tradeoffs to the table, some of which are included in the revised spec.
They build the feature quickly, getting early feedback, as they do.
After shipping the feature, they actively follow up to understand if the feature lives up to the expectation.
When it does not, they dig deep, to understand why it did not and learn something new about product usage in the real world.
- 通过反复学习形成强大的产品直觉
产品思维工程师的典型项目通常是这样推进的：
他们会问很多问题，弄清这个产品功能到底为什么要做。
他们带着建议和取舍上桌，其中一些会被写进修订后的规格。
他们快速构建功能，同时像往常一样获取早期反馈。
功能上线后，他们会主动跟进，了解它是否达到预期。
如果没有达到，他们会深挖原因，并从真实世界的产品使用中学到新东西。
After each project, their product understanding deepens, and they start to develop better and better product instincts. The next time, they'll bring even more relevant suggestions to the table. Over time, they become a goto person for product managers, their advice being sought well before projects are kicked off. They build a strong reputation outside the team, opening more doors for their continued career growth.
每做完一个项目，他们对产品的理解都会加深，产品直觉也越来越好。下一次，他们会带来更切题的建议。随着时间推移，他们会成为产品经理随时会找的人，甚至项目还没启动，建议就已经被征询。他们在团队之外也建立起良好声誉，为持续的职业发展打开更多门。
Tips to become a more product-minded engineer
If you work on a user-facing product, here are a few tips I've seen work well, to growing your product-minded muscle.
Understand how and why your company is successful. What is the business model? How is money made? What parts are most profitable, what parts of the company are expanding the most? Why? How does your team fit into all of this?
成为更有产品思维的工程师的建议
如果你在做面向用户的产品，下面这些方法是我见过能有效锻炼产品思维的建议。
理解你的公司为什么成功、如何成功。商业模式是什么？钱从哪里来？哪些部分最赚钱？公司哪些部分扩张最快？为什么？你的团队在其中处于什么位置？
Build a strong relationship with your product manager. Most product managers jump at the opportunity to mentor engineers. Having engineers be interested in product means they can scale themselves more. Before coming in, asking a lot of product questions, take time to build this relationship and make it clear to your product manager, that you'd like to get more involved in product topics.
和你的产品经理建立牢固的关系。大多数产品经理都很愿意指导工程师。工程师对产品感兴趣，意味着他们能更好地放大自己。在冲进去问一大堆产品问题之前，先花时间建立这段关系，并让产品经理清楚知道：你想更多地参与产品话题。
Engage in user research, customer support, and other activities, where you can learn more about how the product works. Pair with designers, UX people, data scientists, operations people and others, who frequently interact with users.
参与用户研究、客服以及其他活动，在这些场合你能更了解产品如何运作。和设计师、UX 人员、数据科学家、运营人员等经常与用户互动的人结对合作。
Bring well-backed product suggestions to the table. After you have a good understanding of the business, the product and stakeholders: take initiative. You could bring small suggestions to a project you are working on. Or you could suggest a larger effort, outlining the engineering effort and the product effort, making this easy to prioritize in the backlog.
提出有充分依据的产品建议。在你对业务、产品和利益相关者有较好理解之后：主动出手。你可以对自己正在做的项目提出小建议；也可以提议更大的项目，写清工程投入和产品投入，让它在待办列表里更容易被排优先级。
Offer product/engineering tradeoffs for the projects you work on. Think of not only making engineering tradeoffs for the product feature your team is building but suggest product tradeoffs that result in less engineering effort. Be open to the feedback on these from others.
在你参与的项目中主动给出产品/工程取舍。不仅考虑为团队正在构建的产品功能做工程取舍，也提出能减少工程投入的产品取舍。同时，对别人给出的反馈保持开放。
Ask for frequent feedback from your product manager. Being a great product-minded engineer means you have built up good product skills, on top of your existing engineering skillset. The best person to give you feedback on how you're doing on the product skillset is your product manager. Reach out for feedback on how valuable they see your product suggestions and ask for thoughts on areas for further growth.
经常向产品经理要反馈。成为出色的产品思维工程师，意味着你在原有工程技能之上，还建立了不错的产品技能。能就你的产品技能给你最好反馈的人，就是你的产品经理。主动询问他们如何看待你的产品建议的价值，并请他们谈谈你还有哪些方面可以继续成长。
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 software engineering newsletter on Substack.
订阅我的每周通讯，把这样的文章直接送到你的收件箱。它相当值得一读——也是 Substack 上排名第一的软件工程通讯。