原文地址: https://blog.pragmaticengineer.com/the-product-minded-engineer/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

by Gergely Orosz

产品思维的工程师是指对产品本身非常感兴趣的开发人员。他们对如何做决定，用户如何使用产品感兴趣，并且他们喜欢参与产品决策。他们如果放弃开发的话，可以成为优秀的产品经理。我曾和许多优秀的产品思维工程师共事过，并且我自己也想成为这种开发。在公司构建的全球级的产品，产品思维的工程师更是占据更高的影响力。

Sherif Mansour，Atlassian的项目经理，写过一个关于开发工程师的不错的文章，提到了产品经理如何区分开发，并且和他们友好共事。SM的结论也是类似的：

在我最近十年的产品管理经历中，我总结出来的经验是，产品开发人员是构建成功产品的是关键因素，并且还能让你进步，让你成为一个好的产品经理。

他还引用Shopify的首席工程师 Jean-Michel Lemieux 的话：

一旦你拥有了产品基础，你就需要积极地对“为啥”感兴趣的开发人员。对使用技术解决用户问题有渴望的开发工程师。他们带着同理心去探索有魔力的体验。这也是我的书中对产品开发人员的定义。如果斩断所有的疑虑那也不好。好的 产品开发知道哪怕很小的精巧产品都需要在构建时恰到好处的考虑设计。

产品思维工程师会在努力搞面向用户的特性，喜欢和产品经理合作的团队有更大的影响力。他们经常成为关键贡献人员，也会成为产品经理，更多的机会成为团队领导。所以什么样的特质，怎么工作才能成为产品思维的开发呢？本文会提供我观察到的9个小的特质，或者说是我对想培养产品思维的开发的建议：

1. Proactive with product ideas/opinions 对产品有积极主动的观点

产品思维工程师不是接受了规格说明书就跳进去实现它。他们会考虑其他的想法，和产品经理讨论这些想法。他们经常挑战现有的规格说明，提供可能更好的可选方案。

2. Interest in the business, user behavior and data on this 对业务，用户行为和数据感兴趣

产品思维工程师不会凭空获得新的想法，他们会花时间理解业务怎么运转，什么样的产品更合适，目标到底是啥。他们对产品给与用户的使用感受和使用收获具有同理心。他们经常深挖业务数据。他们也许是直接获取数据，或者是和产品经理或数据科学家交流获取类似信息。这是好奇的天性。

3. Curiosity and a keen interest in "why?" 好奇心和对“为啥”的兴趣

产品思维工程师喜欢了解“为什么”背后的所有事情。为啥产品要新建这个特性，是必须且不可代替的么？为啥在第一个里程碑实现这个，不能选其他功能么？有比这个简单的许多特性可以做啊？这些抉择是怎么度量的呢？有更加彻底的方法去度量么？

他自有办法找到答案。他们会想产品经理或者其他业务人员求助这些产品相关的问题。虽然他们会经常问许多的问题，但是经理不会烦他们，并且他们之间的关系还会更加紧密。

4. Strong communicators and great relationships with non-engineers 沟通能力强且和非开发人员关系很好

产品思维工程师喜欢和开发以外的人沟通，学习他们所做的事以及为什么要做。他们很好沟通，清楚地表明他们有兴趣了解其他学科是如何工作的。我经常看他们和非开发人员一起喝咖啡，吃午饭或者在走廊闲聊。

5. Offering product/engineering tradeoffs upfront 取得产品和工程的平衡

一方面他们对产品有一些独到的见解，另一方面他们对工程实践也很清楚，所以他们能带来其他人没有的建议。比如，当大家努力构建一个产品，创建关键特性在工程上的努力是很大的。很多开发会开始寻找方法去降低一下付出，并且尝试去搞清楚降低付出对特性本身的影响。

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.

产品思维开发会从两个角度解决这种事：从工程成本和产品影响两个方面都能行。他们开始做产品的折中，评估工程影响。他们会回到产品经理那里，给一个更完全不同的特性的建议，新的特性在产品功能上很类似，但是工程成本显著降低。

兼顾产品和工程两方面的权衡以及两者的影响，是产品思维工程师所具有的独特优势。他们可以快速在硬币的两个面上转换：产品特性和工程成本。他们脑子里两者都有，所以他们评估结论会很快。

6. Pragmatic handling of edge cases 特殊案例的实际处理经验

边缘案例是一件很有意思的事情。工程师经常忘记特殊极端的场景，所以不得不在测试或者用户使用后回顾修补。另一方面，处理所以场景会浪费许多的时间。

产品思维工程师能快速列出边缘案例，考虑降低这些情况的处理办法，结果会带来一些不需要工程上特殊处理的建议。他们聚焦于最小最优雅的产品概念，评估边缘案例的影响，并努力解决这些案例。他们提出一个好的中间立场的建议：在早期版本中就列出所有的错误场景，在需要解决的边缘案例上提出解决建议。

例如，如果几千个人里面有一个错误，他们会考虑修复，如果不不修复的话会怎么样。客服会在这种场景给用户失败时提供支持么？用户是简单重试并且立刻成功么？还是产品简单修改一下，这种错误就不会发生了？

7. Quick product validation cycles 快的产品验证周期

在产品设计准备产品特性时，产品思维工程师会找到有创造力的方式获取早期反馈。这有可能是和同事在走廊闲聊，展示正在做的新特性时，或者在测试版本做bug梳理时，或者很多其他的方式。他们老是在想：怎么验证确保用户会向我们预计的那样使用新特性呢？

8. End-to-end product feature ownership 拥有端到端产品特性

绝大多数有经验的开发会有自己的点到点：从拿到规格说明书到实现他们，尝试所有办法弄出来并验证成功正确性。产品思维工程师会更进一步。

他们会在工作完成后考虑获取到用户行为和业务指标。首次展示上线后，他们会和产品经理，数据科学家，客户支持沟通，了解新特性在真是环境是如何被使用的。这会花费几个星期去分析数据，得出结论。虽然他们可能正在做一个新的项目，但是还是会把获取结论作为高优先级的事。不是简单地花费时间，是一个人持续的想知道：我的工作做得到底怎么样？They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists.

当一个特性表现得比预期的糟糕，他们会好奇失误是怎么发生的。他们只对根本原因感兴趣。就像他们在代码中找不能复现的bug一样。他们会经常花大量的和 产品经理，数据科学家辩论推测。

9. Strong product instincts through repeated cycles of learning 不断学习的强烈产品本能

对产品思维工程师来说一个典型的项目会如下推进：

1. 他们会问许多为啥产品特性要这么设计的问题。
2. 他们有许多建议和权衡，其中有些会在改进后的规格书中找到。
3. 他们能快速构建新需求，并快速获得反馈。
4. 功能上线后，他们会积极跟踪新功能是否有达到预期。
5. 当不及预期，他们会深挖为什么，并且会在真实世界的产品用途上有新的收获。

当项目结束，他们对产品的理解很深了，也能开发的更好了，也有更好的产品理念了。下次他们会带来更好的建议。随着时间的流逝，他们成为预备产品经理，大家在项目开始时就寻求他们的建议。他们也有了一个更好的个人声誉，事业上也有更多选择了。

Tips to become a more product-minded engineer 成功一个具备产品思维的小建议

如果你做的是直面用户的产品，那这是几个有用的小建议，可以用于增加你的产品思维：

• 弄清楚你的公司为啥能成功
• 商业模式是什么样的？怎么把钱给赚的？哪些方面是最赚钱的，哪些方面是浪费最多的，为啥会这样？你的团队和这一切融洽么？
• 和你的产品经理搞好关系
• 大多数产品经理乐于指导开发。有开发对产品感兴趣意味着产品的管理规模更大。在问产品问题之前，你花时间了解清楚你的产品经理，会让你更多的参与到产品话题中去。
• 去从事用户调查，客户支持的工作，这会学习到更多产品是如何运作的。和设计师，用户体验工程师，数据专家，实施工程师等等能经常和用户沟通的人交流。
• 开会的时候提出一些好好准备的产品建议。
• 在你有对业务有好的理解之后，产品和利息相关者会主动找你。你可以在你从事的项目上提一些小建议了，或者你陈述工程成本和产品效应，让优先级更容易确定。
• 权衡你正在做的项目的产品和工程。不仅要考虑为您的团队正在构建的产品特性进行工程权衡，还要考虑建议可以减少工程工作量的产品权衡。接受别人的反馈。
• 经常找产品经理寻求反馈。
• 拥有好的产品思维意味着你在好的工程能力之外，还有构建好产品的能力。最能告诉你应该怎么做的人就是你的产品经理。弄清他们在他见到你的产品之后的反应，并问问哪里还能更好。