转自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. 浅谈 Java集合

    Java 集合 集合是对象的容器,定义了多个对象进行操作的常用方法,可实现数组的功能. Java集合类库所处位置:java.util.*. 与现代的数据结构类库的常见做法一样,Java集合类库也将接口 ...

  2. vue拼图动画Demo

    这是一个基于vue的Demo,可以实现拼图动画,但是具体的没有写拼图成功的逻辑,鼠标悬停移动.周期刷新 我把它放到的我的博客园界面上了.刷新界面可以看到. 演示地址 :https://liruilon ...

  3. 通过VNC远程连接Linux实例

    无法使用Workbench和远程连接软件(例如PuTTY.Xshell.SecureCRT等)连接Linux实例时,您可以通过控制台的VNC远程连接实例,查看云服务器操作界面的实时状态. 前提条件 已 ...

  4. 多测师讲解selenium__论坛验证码_处理方法_ 高级讲师肖sir

    1.登录我们搭建的论坛环境 2. 3. 4.

  5. CS61A Homework: Church Numerals

    Church Numerals Nagging 南大的 SICP 实际上是 Berkeley CS61A 的 clone ,所以我有幸做到了这个 Homework02. 此外要感谢选课系统,让我一个工 ...

  6. go http爬虫

    1 package main import ( "fmt" "io/ioutil" "net/http" ) func main() { r ...

  7. centos8平台基于iftop监控网络流量

    一,iftop的作用: 基于ip统计外部机器与本机之间的网络流量, 可以方便的查看各客户端是否有非正常的到本机的访问 说明:刘宏缔的架构森林是一个专注架构的博客,地址:https://www.cnbl ...

  8. centos8平台使用nethogs基于进程监控网络流量

    一,nethogs的作用: 按进程或程序实时统计网络带宽使用率 我们查看流量的占用时,知道来源的ip.访问的端口,还不足以帮我们确认到进程, 而nethogs则可以让我们查看每个进程所占用的流量带宽 ...

  9. 第七章 HTTP协议原理

    一.HTTP协议概述 1.什么是HTTP? HTTP 全称:Hyper Text Transfer Protocol 中文名:超文本传输协议 http就是将用户的请求发送到服务器,将服务器请求到的内容 ...

  10. FDDB人脸检测数据集 生成ROC曲线

    看了好多博客,踩了很多坑,终于把FDDB数据集的ROC曲线绘制出来了.记录一下. 环境:ubuntu18.04 1.数据集准备 去FDDB官网:http://vis-www.cs.umass.edu/ ...