英语学习篇一《The Product-Minded Software Engineer》

date
Feb 21, 2023
slug
eg-1
author
status
Public
tags
学英语
summary
type
Post
thumbnail
category
updatedAt
Mar 20, 2023 09:04 AM

The Product-Minded Software Engineer

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.
软件工程师的产品思维
注重产品的工程师是对产品本身非常感兴趣的开发人员。他们会想要了解如何做出决策让用户使用产品,
也想要切身参与到决策中去。如果他们决定放弃工程的乐趣,他们很可能会成为一名优秀的产品经理,我也曾
和许多具有很棒产品思维的工程师一起工作过并且考虑成为这种工程师。在制造世界级产品的公司,具有产品
思维的工程师会将团队提升到一个新的水平

陌生词汇:impact

n. 影响;撞击;强大作用;冲撞;冲击力
v. 冲击;撞击;(对某事物)有影响
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:
Atlassian 的产品经理写了一篇关于产品工程师以及产品经理如何辨认他们并和
他们创良好的合作的优秀文章,他的总结如下:

在我过去十年的产品管理经验中,我总结出来产品工程师是帮助你创造一个优秀产品
的关键因素,同时也能提升自己成为一个更优秀的产品经理

陌生词汇:

critical
adj. 批评的;关键的;批判性的;挑剔的;极重要的;至关紧要的;严重的;不稳定的;
可能有危险的;有判断力的;根据评论家的评论

ingredient 
n.(混合物的)组成部分,成分;(尤指烹饪)原料,配料;(构成)要素,因素
adj.
构成组成部分的
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.
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对产品工程师的定义:
一旦你有了产品基础,你就需要那些积极面对“为什么”的开发人员。并且渴望利用技术跨越人类/用户问题的
工程师。那些有同理心的人会获得神奇的体验。这就是我在书中对产品工程师的定义。糟糕的产品会偷工减料。
优秀的产品工程师知道,在构建阶段,小而美的产品需要考虑到合适的深度。
 
陌生词汇:

quotes
v.引用;引述;举例说明;开价;出价;报价
n.引用

devs
n.开发者

engage with
交战;面对;适应;参与

leapfrog
n.跳背游戏(游戏者轮流从其他弯背人身上跳过)
v.越级提升


empathy 
n.移情;同情;共鸣;同感

cut too many corners
偷工减料
 
 
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个特点,并提出了对于任何工程师成长产品导向性的建议。

observed
观察到

1. 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.
1. 积极的产品想法/意见

产品思维的工程师不会勉强接受现有的规范和立即去实施,他们会考虑其他的想法并提供给产品经理,他们
经常挑战现有规范,提出更好的替代现有规范的产品方法

陌生词汇

settle for 
勉强接受

specification
规范;规格;说明书

jumping to 
立即;匆匆

implement
实现;实施;使生效

approach
n.方式,方法

alternative
可替代的

2. 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 benifit 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.
2. 对业务、用户行为感兴趣并建立数据体系

当他们带着想法来的时候,这些想法并不是产品思维的工程师从空气中得来的,他们花时间去了解业务的运作
模式,产品怎么是适配业务、业务的目标是什么。他们也会站在用户的角度思考产品带给用户怎样的体验,用
户从使用产品中得到了那些好处,他们经常直接钻研业务和用户指标数据,并尽其所能获取这些数据。如果可
能的话,他们可能会直接访问数据,或者向产品经理或数据科学家寻求此类信息。他们这样做是因为他们好奇
的天性。这是我观察到的下一个特点。

dive straight
钻研、下潜、直入主题

hands on
抓在手上;实习的;亲自动手的

approach sb (about/for sth)
接洽;建议;要求

例句:she approached the bank for loan
她向银行申请贷款

curious 
好奇心

nature
自然;天性;天理;类型

3. 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.
Subscribe to my weekly newsletter for advice, observations and inspiration across the software engineering industry. It's the #1 technology newsletter on Substack with over 120,000 readers.

Newsletter

 
3. 好奇心和对“为什么”的强烈兴趣

产品思维的工程师喜欢去思考所有事物背后的“为什么”,为什么构建这个产品功能?为什么不是另外一个
功能?为什么要发布第一个里程碑而不是另外一个?构建这个里程碑要简单的多。如何衡量事物,为什么
不选择一种更彻底的方式来衡量事物

他们能够自主寻找答案,他们会向产品经理和其他业务人员询问关于产品的问题。即使询问了他们很多问题,
并且经常这样做,但他们还是设法不惹恼人们,因为他们之间建立了牢固的关系。

thorough
adj.彻底的;充分的

autonomous
adj.自主的;自治的;有自治权的;

turn to
向.. 求助

4. 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.
4. 强大的沟通能力和与非工程师的良好关系

产品思维的工程师喜欢跟人们讨论工程之外的问题,学习他们做什么和为什么他们会这样做。他们善于沟通,明确表示他们有兴趣更多地了解其他学科的运作方式。我经常会看到他们与非工程师在和咖啡,吃午饭,或者在走廊里聊天

smooth communicators
善于沟通

disciplines
n.(尤指大学或学院设立的)专业

grabbing coffee
喝咖啡

5. 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.
5. 预先提供产品/工程权衡

因为他们对产品的“为什么”以及工程方便有深刻的理解,所以他们能够提出很少人能提出的建议。举个例子,在确定构建产品的工作范围时,构建关键功能的工程工作可能很重要。许多工程师会开始寻找减少工作量的方法,并试图弄清楚减少工作量对功能本身的影响。

具有产品意识的工程师从两个角度解决这个问题:寻找工程权衡和产品影响。他们还开始权衡产品,评估工程影响。他们经常回到产品经理那里,建议构建一个完全不同的功能,因为产品影响是相似的,但工程工作量要小得多。

兼顾产品和工程的权衡以及两者的影响是具有产品意识的工程师所具有的独特优势。他们可以在同一枚硬币的两面来回切换:产品功能和工程计划的权衡。因为他们在可以在脑海中做这些,用他们的工程与产品视角,他们可以很快的得出有价值的结论

upfront
adj.坦率的;诚实的;直爽的;预付的;预交的
adv.预付地,先期支付地

significant
adj.重要的, 有重大意义的;显著的, 值得注意的;<>显著的, 有效的;别有含义的, 意味深长的;(语言上)区别性的;(词缀等)有意义的;相当数量的;不可忽略的, 值得注意的
n.<>有意义的事物;标志, 象征

vastly
amv. 非常;很

Juggling both
两者兼有之

back-and-forth
来回

remarkably
adv.非常;极为;格外;出乎意料地

6. 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?
6. 边缘案例的务实处理

边缘案例是个有趣的东西,在一个极端上,工程师经常忘记其中的很多问题,在得到测试产品的人或者最终用户的反馈后,不得不重新解决这些问题。另一个方面,处理新产品中所有可能的边缘情况可能需要花费大量的时间。

具有产品意识的工程师会快速规划边缘案例并想办法减少对它们的工作:通常会带来不需要工程工作的解决方案。他们专注于“小而美的产品理念”并且评估出边缘案例的影响和需要花费多少精力去处理它们。他们提出了很好的中间立场建议:在发布甚至是早期版本之前,找出大多数可能出错的地方,并就需要解决哪些边缘情况提出建议。

举个例子,如果千分之一的用户可能会受到错误的影响,他们会考虑如何修复错误,并考虑如果什么都不做会发生什么。在这种情况下,客户支持能否在验证期间帮助此人?用户下次可以重试并成功吗?产品是否可以稍微修改一下,这样就不会出现这种边缘情况?

pragmatic
务实

map out
规划

middle-ground 
中间立场

shipping
n. 船舶;航运;海运
v. 船运;运输;运送;上市;把…推向市场;舷侧进水

7. 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?"

8. 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.

9. Strong product instincts through repeated cycles of learning

A typical project for a product-minded engineer usually goes like this:
  1. They ask a lot of questions to understand exactly why the product feature is being built.
  1. They bring suggestions and tradeoffs to the table, some of which are included in the revised spec.
  1. They build the feature quickly, getting early feedback, as they do.
  1. After shipping the feature, they actively follow up to understand if the feature lives up to the expectation.
  1. 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.