Welcome to the first post of my newsletter for Product-Minded Software Engineers.
Product-Minded Coders is a newsletter about the skills, traits and careers of software engineers that has a holistic approach to product development.
Product-minded coders go by many names: product-oriented, product-focused or simply product engineers. These names are used interchangeably throughout this post and the newsletter.
Product engineers are a specialisation of software engineers. In other words, all product engineers are software engineers, but not all software engineers are product engineers.
Great software engineers focus on writing high-quality code and building robust systems that unfortunately not always adequately solve real user problems. Great product engineers focus on solving the right problems to build useful products with or without code.
Key Characteristics
Since product engineers are software engineers, they possess many of the same traits including systematic thinking and being detail oriented. Let’s now look at other characteristics that set them apart.
Value Add
The number one characteristic that distinguishes a product engineer from other software engineers is their meticulous focus on “value add” for users and ultimately the business. Every action they take is driven by what they believe will push the needle forward the most. Because of this, they have an uncanny ability to brutally prioritise their own efforts to focus on high-impact (high ROI) tasks.
To understand what will add the most value, they take every available opportunity to receive high-quality feedback (affirming or constructive) directly from users or indirectly via studying usage data and overlaying that with the business objectives.
You will often find product-oriented engineers talking with colleagues in other areas of the company to grow their business sense and understanding.
Because of their keen insight and understanding of the users and business they’ve built up over the lifetime of the product, they are also remarkably quick at estimating or identifying the impact of a service degradation or incident in production.
Pragmatism over Idealism
Even though good product engineers are also highly skilled in coding, since it is still their primary role, they are more quick to settle for tradeoffs if the tradeoff means they can add real value sooner rather than later.
Where many software engineers feel an attachment to their own creations, product engineers are not married to any specific implementation and can easily sunset a feature or replace their own code with something else that is better for the product. In that sense, they are more pragmatic than idealistic. They are comfortable shipping a solution with known edge cases and then iterating over it until it matures or is replaced. They realise that perfection can stop the product momentum which is crucial for early-stage startups in particular.
Data-Directed Decision Making
Data plays a fundamental role in the day-to-day work of a product engineer. First of all, understanding which metrics are the key metrics for the product and business guides them in their decision-making to optimise for maximum “value add”.
Product engineers routinely take qualitative feedback data from users in an outside-in approach and reverse-engineer new feature ideas. They come up with hypotheses for these ideas, which they pitch proactively to product managers and other members of the team to get buy-in for implementation. Often they will use prototypes alongside the data to strengthen their pitches, which could end up being implemented as an A/B test. Product engineers do not stop there. They follow up features after rollout to either confirm or disprove any hypothesis and to further strengthen their product intuition.
It is important to note that though product engineers are data literate, they do not necessarily have comparable data analytical skills to that of data scientists. Most often, they will work in collaboration with analysts or data scientists to get the data they want.
Entrepreneurial
Naturally, product engineers are often entrepreneurial by nature, which is proven by a long history of side projects or failed products. Even though they might be dreaming of building and running their own product in the future, their product obsession envelops them so that they take full responsibility and ownership of the product they’re currently working on as if it is their own.
Working with Product Managers
On their mission to understand products better, product engineers can come up with lots of questions and pushback on the direction of the product or features on the roadmap. This can lead to conflict with inexperienced or less mature product managers if they feel threatened or personally questioned. Great PMs embrace this and foster an almost Batman and Robin-like relationship where product engineers are their greatest allies freeing them to focus externally to cast longer-term vision and stakeholder management.
Since product engineers act as the voice of the customer, their digging questions can help product managers clarify and distil their product vision and how it is communicated outside and within the product interface.
A product engineer can never fulfil the role of a great PM while being involved in the technical details of the product. The sweet spot is when a healthy relationship exists between both roles.
Natural Habitat
More often than not, you will find product engineers fulfilling the role of a frontend-focused or full-stack software engineer. This is by no means a requirement, but an observation. The product-oriented engineers that fulfil traditional backend roles tend to not “stay in their lanes” and you will see them often approach product managers or other frontend teams with UI/UX questions and improvements.
Regardless of where they sit in an org chart, product-minded engineers flourish in environments with individual autonomy and ownership, therefore, they are particularly valuable in early-stage startups or mature feature teams at larger companies where ICs (Individual Contributors) have an equal say around the product table.
Nurture vs Nature
Undoubtedly, some people naturally gravitate towards and excel at the product engineer role, but it does not mean that all or most of the mentioned skills can’t be learned and cultivated with intentional effort. One exception might arguably be a natural curiosity about “why” businesses and products work the way they do. Then again, often passion comes along the journey, and not always upfront. I’ve discovered numerous times in myself that I acquire a new interest after an initial phase of slogging past the first seemingly uninteresting layer of a topic I don’t know much about, like Formula 1.
Drawbacks and Growth Areas
Even though I would argue that product engineers are crucial to the success and longevity of any product, they are definitely not flawless unicorns. They can easily fall into the trap of only ever producing prototype-grade or other rudimentary technical solutions in their pursuit to experiment or add valuable features fast. Also, because of their relentless pursuit of doing only the work with the highest ROI, product engineers aren’t always good at doing the mundane 90% of the work that is required for any product. Furthermore, product engineers can get distracted and end up only working on things that are not part of their primary role, software engineering. This is mostly an issue if the product engineer is part of a team in which it is not generally understood (either explicitly communicated or implicitly implied) that they will not do the same amount of actual coding or code reviews as other engineers on the team. This is another reason why I would not advocate for all engineers in a team to be product engineers primarily.
All of these drawbacks can be overcome by growing their awareness of serving the team along with the end users and maturing in their professionalism as software engineers.
The ideal situation for a product engineer would be in a team where they can be mentored, challenged and kept accountable by both a great product manager as well as a strong experienced technical lead.
Final Words
If you enjoyed this post and know of someone else who would benefit from it, please share it by clicking the button below.
If you identify as a product-minded engineer or feel an attraction to grow the necessary skills to become one, you are the person I want to write this newsletter for.
Great stuff JP enjoyed hearing your thoughts