The Product-Minded Software Engineer
转自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的更多相关文章
- Software Engineer Title Ladder
http://changelog.ca/log/2013/08/09/software_engineer_title_ladder Within the software engineering pr ...
- Sr Software Engineer - Big Data Team
Sr Software Engineer - Big Data Team About UberWe’re changing the way people think about transport ...
- 微软职位内部推荐-Software Engineer
微软近期Open的职位: Job Title: Software Engineer Work Location: Suzhou, China This is a once in a lifetime ...
- 微软职位内部推荐-Software Engineer II_VS
微软近期Open的职位: Job Title: Software Engineer II Division: Visual Studio China – Developer Division Work ...
- 微软职位内部推荐-Software Engineer II_HPC
微软近期Open的职位: Job Title: Software Engineer II_HPC Location: Shanghai, China Are you passionate about ...
- software engineer's resume(帮助你写程序员简历)
关键词 参考 简历模板 参考 下面开始是正文(关键词原文) 介绍 本项目由海外兔 (https://osjobs.net) 维护,海外兔团队由一线互联网面试官组成,提供海内外公司一对一入职套餐以及算法 ...
- (转载)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 ...
- Software Engineer
1, 软件工程师 软件工程师英文是Software Engineer,是从事软件职业的人员的一种职业能力的认证,通过它说明具备了工程师的资格.软件工程师是从事软件开发相关工作的人员的统称. 它是一个广 ...
- 微软职位内部推荐-Software Engineer II-Web app
微软近期Open的职位: The Office App Services team is working on the powerful Office Web Apps including Word ...
随机推荐
- Visual C++中各种文件的作用(详细)
参考:http://blog.sina.com.cn/s/blog_6975d67c0100r3kx.html DSW:全称是Developer Studio Workspace,最高级别的配置文件, ...
- 9.23 T1 tree
题意描述: 给你一个长度为 \(n\) 的序列,让你从中选出 \(k\) 个数组成一个集合,定义这个集合的极限高度为\(a_i...a_k\) 的最大值. 让你求所有的集合极限高度 之和对 \(100 ...
- NOI 2011 【阿狸的打字机】
之前讲了[AC自动姬],今天我终于把这题给刚下来了...嗯,来给大家讲一讲. 题目描述: 打字机上只有28个按键,分别印有26个小写英文字母和'B'.'P'两个字母.经阿狸研究发现,这个打字机是这样工 ...
- 用C写一个简单的推箱子游戏(一)
我现在在读大二,我们有一门课程叫<操作系统>,课程考查要求我们可以写一段程序或者写Windows.iOS.Mac的发展历程.后面我结合网上的资料参考,就想用自己之前简单学过的C写一关的推箱 ...
- day48 Pyhton 数据库Mysql 05
一内容回顾 insert insert into 表名 (字段名) values (值) insert into 表名 values (有多少个字段写多少个值) insert into 表名 val ...
- 比特币PoW
比特币区块头结构 字段 大小(Byte) 说明 nVersion 4 区块版本号,表示本区块遵守的验证规则 hashPrevBlock 32 前一区块的哈希值,使用SHA256(SHA256(父区块头 ...
- vi/vim系统编辑命令使用技巧
01前言 在Linux系统中会有很多的文件信息,这些文件的内容如果需要编辑,就必须借助vi或vim编辑命令. vi是Linux命令行界面下的重要文字编辑器.vim是vi命令的增强版. [语法格式] v ...
- LeCun自曝使用C语言23年之久,2年前才上手Python,还曾短暂尝试Lua!
程序员圈子的流行风潮,过几年就怀旧风走一波. 这不,最近Twitter上刮起了一阵编程语言使用历史的风潮. 连图灵奖得主.CNN之父-- Yann LeCun 也参与进来了. 他自曝使用C语言时间最长 ...
- 【应用服务 App Service】当使用EntityFrameWorkCore访问Sql Server数据库时,在Azure App Service会出现Cannot create a DbSet for ** because this type is not included in the model for the context的错误
问题情形 使用EF Core访问数据库,在本地运行正常,发布到App Service后,偶尔出现了Cannot create a DbSet for ** because this type is n ...
- dubbo配置加载优先级
优先级从高到低: JVM 启动 -D 参数优先,这样可以使用户在部署和启动时进行参数重写,比如在启动时需改变协议的端口: XML 次之,如果在 XML 中有配置,则 dubbo.properties ...