转自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.

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.

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.

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.

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

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.

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.

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.

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?

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:

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

朋友们可以关注下我的公众号,获得最及时的更新:

The Product-Minded Software Engineer的更多相关文章

  1. Software Engineer Title Ladder

    http://changelog.ca/log/2013/08/09/software_engineer_title_ladder Within the software engineering pr ...

  2. Sr Software Engineer - Big Data Team

    Sr Software Engineer - Big Data Team   About UberWe’re changing the way people think about transport ...

  3. 微软职位内部推荐-Software Engineer

    微软近期Open的职位: Job Title: Software Engineer Work Location: Suzhou, China This is a once in a lifetime ...

  4. 微软职位内部推荐-Software Engineer II_VS

    微软近期Open的职位: Job Title: Software Engineer II Division: Visual Studio China – Developer Division Work ...

  5. 微软职位内部推荐-Software Engineer II_HPC

    微软近期Open的职位: Job Title: Software Engineer II_HPC Location: Shanghai, China Are you passionate about ...

  6. software engineer's resume(帮助你写程序员简历)

    关键词 参考 简历模板 参考 下面开始是正文(关键词原文) 介绍 本项目由海外兔 (https://osjobs.net) 维护,海外兔团队由一线互联网面试官组成,提供海内外公司一对一入职套餐以及算法 ...

  7. (转载)The One Sign You Will Be Rich-(by Brian de Haaff Founder and CEO Aha! -- world's #1 product roadmap software)

    When I was studying Philosophy at Berkeley, a friend told me that she could tell who was going to be ...

  8. Software Engineer

    1, 软件工程师 软件工程师英文是Software Engineer,是从事软件职业的人员的一种职业能力的认证,通过它说明具备了工程师的资格.软件工程师是从事软件开发相关工作的人员的统称. 它是一个广 ...

  9. 微软职位内部推荐-Software Engineer II-Web app

    微软近期Open的职位: The Office App Services team is working on the powerful Office Web Apps including Word ...

随机推荐

  1. np.random.multivariate_normal方法浅析

    从多元正态分布中抽取随机样本. 多元正态分布,多正态分布或高斯分布是一维正态分布向更高维度的推广.这种分布由其均值和协方差矩阵来确定.这些参数类似于一维正态分布的平均值(平均值或"中心&qu ...

  2. 关于ptype_all和pypte_base中的pt_prev的说明[转]

    不知道原帖,我是从这里看到了,解决了迷惑我很久的疑问,抄过来. 看见noble_shi兄弟"关于net_rx_action函数的若干问题"贴中关于pt_prev的问题, 本来想在论 ...

  3. 2016年 实验四  B2B模拟实验

    实验四  B2B模拟实验 [实验目的] ⑴.掌握B2B中供应商的供求信息发布.阿里商铺开设和订单交易等过程. ⑵.掌握B2B中采购商的采购信息的发布.交易洽谈.网上支付和收货等过程. [实验条件] ⑴ ...

  4. Docker-V 详解

      1. 作用 挂载宿主机的一个目录. 2. 案例 譬如我要启动一个centos容器,宿主机的/test目录挂载到容器的/soft目录,可通过以下方式指定:   # docker run -it -v ...

  5. css选择器 兄弟选择器 相邻兄弟选择器 子元素选择器

    1.兄弟选择器: ~ 该选择器会选择当前元素之后的所有相邻指定元素(具有相同父元素的兄弟元素): .p ~ li{ color: blue; } <div> <p class=&qu ...

  6. 某次burp抓包出错的解决办法

    前些日子同事发微信问我一个问题 没听懂他说的没回显是啥意思,于是叫他把站发给我. 浏览器不挂burp代理能正常打开,挂上burp代理以后浏览器显示连接超时 首先测试burp能抓其他的包应不是这个原因 ...

  7. 【API管理 APIM】APIM中对后端API服务的DNS域名缓存问题

    问题描述 在使用API Management来进行API管理时,当我们后端的API DNS IP地址发生改变或者是API的域名发生改变后,通过APIM请求访问的还是是旧的域名或者IP地址,这是因API ...

  8. 第六章 类(Class) 和对象(Object)

    一.笔记导图 二.实例代码: public class PrintCarStatus{ public static void main(String[] args){ int speed; Strin ...

  9. Learning Attention-based Embeddings for Relation Prediction in Knowledge Graphs

    这篇论文试图将GAT应用于KG任务中,但是问题是知识图谱中实体与实体之间关系并不相同,因此结构信息不再是简单的节点与节点之间的相邻关系.这里进行了一些小的trick进行改进,即在将实体特征拼接在一起的 ...

  10. day73:drf:drf视图相关类&路由Routers&创建虚拟环境

    目录 1.APIView 2.GenericAPIView:通用视图类 3.5个视图扩展类:ListModelMixin,CreateModelMixin,RetrieveModelMixin,Upd ...