link
【1】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.
【2】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:
【3】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.
【4】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.
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.
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.
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.
Newsletter
Enjoying this article? Subscribe to my newsletter to get issues like this in your inbox. It's a good read and the #1 technology newsletter on Substack.
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.
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.
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.
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?
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?"
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.
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. 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 tech newsletter on Substack.
【1】产品思维的工程师是对产品本身有浓厚兴趣的开发人员。他们想要理解 决策的原因、用户如何使用产品，并且喜欢参与产品决策。他们如果放弃工程师的乐趣，可能会成为出色的产品经理。我与许多优秀的产品思维工程师共事过，并认为自己也是这种类型的开发者。在打造世界级产品的公司里，产品思维的工程师能够让团队的影响力提升到一个新的高度。
【2】Atlassian的产品经理Sherif Mansour写了一篇关于产品工程师的优秀文章，介绍了产品经理如何识别这些人并与他们良好合作。他的结论类似：
【3】在过去十年的产品管理中，我得出的结论是，产品工程师是帮助你构建成功产品、扩展自己并成为更好的产品经理的关键因素。
他还引用了Shopify工程主管Jean-Michel Lemieux的定义：
【4】一旦你有了产品基础，你需要积极参与“为什么”的开发人员。那些渴望利用技术来超越人类/用户问题的工程师。那些有同理心去追求神奇体验的人。这就是我书中定义的产品工程师。糟糕的工程师会偷工减料。优秀的产品工程师知道，最少可爱的产品在构建阶段需要考虑到适当的深度。
在从事面向用户的功能并与产品经理合作的团队中，产品思维的工程师可以产生巨大的影响。他们往往成为关键贡献者、产品经理的首选对象，并经常晋升为团队领导。
那么，产品思维工程师的关键特质是什么，如何才能变得更具产品思维？本文总结了我观察到的这类人共有的9个特质，并给出了任何工程师如何培养产品思维的建议。
产品思维的工程师不会仅仅满足于拿到规格说明然后直接实现。他们会考虑其他想法并向产品经理提出这些想法。他们经常挑战现有的规格说明，提出可能效果更好的替代产品方案。
在提出想法时，产品思维的工程师不会凭空得出这些想法。他们会花时间了解业务的运作方式，产品的定位及其目标。他们还对产品给用户带来的感受以及用户从中受益的方式充满同理心。他们经常深入研究业务和用户指标数据，尽可能获取这些数据。他们可能直接访问这些数据（如果可能的话），或者找产品经理或数据科学家获取这些信息。他们这样做是因为他们天生好奇。这是我观察到的下一个特质。
产品思维的工程师喜欢理解所有事情背后的“为什么”。为什么要为产品构建这个功能，而不是另一个功能？为什么要发布这个里程碑，而不是选择另一个更简单的里程碑？如何测量这些东西——为什么不选择更彻底的测量方式？
他们会自发地寻找自己能找到的答案。他们会向产品经理和业务中的其他人询问与产品相关的问题。尽管他们问了很多问题，但他们通过与他人建立的强大关系，避免了让人感到烦扰。
产品思维的工程师喜欢与工程师以外的人交流，了解他们做什么以及为什么做。他们是出色的沟通者，能够明确表达他们对学习其他学科如何运作的兴趣。我经常看到他们与非工程师一起喝咖啡、吃午饭或在走廊聊天。
由于他们对产品“为什么”以及工程方面的事情有深入理解，他们能够提出其他人很少能提出的建议。例如，在评估构建产品的工作量时，构建关键功能的工程工作量可能很大。许多工程师会开始寻找减少工作量的方法，并试图弄清楚减少工作量对功能本身的影响。
产品思维的工程师从两个角度解决这个问题：既寻找工程权衡，又考虑产品的影响。他们还会开始做出产品权衡，评估工程影响。他们经常回到产品经理那里，建议构建一个完全不同的功能，因为产品影响相似，但工程工作量大大减少。
在处理产品和工程权衡及其影响方面，产品思维的工程师具备独特的优势。他们能够在产品功能和工程工作量及权衡之间快速切换。因为他们在脑海中利用工程和产品见解进行思考，他们能够非常迅速地得出有价值的结论。
边缘情况是一个有趣的问题。在一个极端，工程师经常忘记许多边缘情况，在收到测试人员或最终用户的反馈后才回来处理它们。另一方面，在一个新产品或功能中处理所有可能的边缘情况可能需要大量时间。
产品思维的工程师会迅速绘制出边缘情况，并考虑减少工作量的方法：通常提出不需要工程工作的解决方案。他们专注于“最少可爱产品概念”，评估边缘情况的影响和处理它的工作量。他们提出好的中间建议：绘制出大多数可能出错的情况，并提出哪些边缘情况需要在发布早期版本之前处理。
例如，如果每一千个用户中有一个可能遇到错误，他们会考虑修复它的工作量，并思考如果不做任何事情会发生什么。客户支持能在验证期间帮助这个用户吗？用户可以重试并成功吗？产品可以稍作修改，以避免出现这种边缘情况吗？
即使他们正在工作的功能还没有准备好投产，产品思维的工程师也会找到创意的方式获得早期反馈。这可能是与同事进行走廊测试、向产品经理展示正在进行的功能、组织团队对测试版本进行bug bash等。他们不断思考：“我们如何验证人们会按照我们设想的方式使用这个功能？”
大多数有经验的工程师都会端到端地掌握他们的工作：从获得规格说明，到实现它，再到发布并验证其正确性。产品思维的工程师通常会更进一步。
他们认为自己的工作只有在获得用户行为和业务指标的结果后才算完成。在发布后，他们仍然积极与产品经理、数据科学家和客户支持渠道互动，了解功能在现实世界中的使用情况。可能需要几周时间才能获得足够可靠的数据以得出结论。即使他们可能在处理一个新项目，他们也会将检查结果作为首要任务之一。这不是一项耗时的活动，但需要额外的坚持，想要知道：“我的工作到底表现如何？”
当一个功能表现不如预期时，他们会好奇地了解不匹配的原因。他们对找到产品计划和现实结果之间的根本原因同样感兴趣，就像调试代码库中难以重现的bug一样。他们经常会花大量时间与产品经理和数据科学家讨论假设和学到的知识。
对于产品思维的工程师来说，一个典型的项目通常是这样的：
他们问很多问题，以准确理解为什么要构建这个产品功能。 他们提出建议和权衡，其中一些会被纳入修订后的规格说明中。 他们快速构建功能，同时获得早期反馈。 在发布功能后，他们积极跟进，了解功能是否达到了预期。 当功能未达到预期时，他们深入探究，了解原因，并学习到一些关于产品在现实世界中使用的新知识。
在每个项目之后，他们对产品的理解都会加深，并开始培养越来越好的产品直觉。下次，他们会提出更相关的建议。随着时间的推移，他们成为产品经理的首选对象，他们的建议在项目启动之前就被寻求。他们在团队外建立了强大的声誉，为他们的职业发展打开了更多的门。
成为更具产品思维的工程师的建议
如果你在从事面向用户的产品，这里有一些我看到的有效建议，可以帮助你培养产品思维的能力。
了解你的公司如何以及为什么成功。商业模式是什么？钱怎么赚来的？哪些部分最有利可图，公司哪些部分在快速扩展？为什么？你的团队在这其中扮演什么角色？ 与产品经理建立良好的关系。大多数产品经理都会抓住机会指导工程师。工程师对产品感兴趣意味着他们可以更好地扩展自己。在提出大量产品问题之前，花时间建立这种关系，并向产品经理明确表示，你希望更多地参与产品话题。 参与用户研究、客户支持和其他活动，了解产品的运作方式。与设计师、用户体验人员、数据科学家、运营人员等经常与用户互动的人配对。 提出有依据的产品建议。在你对业务、产品和利益相关者有了良好理解之后，主动提出建议。你可以为正在进行的项目提出小建议，也可以建议一个更大的努力，概述工程和产品的工作量，使其易于在待办事项中进行优先排序。 为你工作的项目提供产品/工程权衡。考虑不仅为团队构建的产品功能做出工程权衡，还提出减少工程工作量的产品权衡。对他人的反馈持开放态度。 向产品经理寻求频繁的反馈。成为一名优秀的产品思维工程师意味着你在现有工程技能的基础上构建了良好的产品技能。最适合给你反馈你在产品技能方面表现的人是你的产品经理。寻求他们对你产品建议的价值的反馈，并询问进一步成长的领域。
订阅我的每周通讯，将这样的文章直接发送到你的收件箱。这是一个很不错的阅读材料，也是Substack上排名第一的技术通讯。