What is a product engineer?

Hello. You're getting this email you signed up for productengineered.com. I hope you enjoy.

I landed my first job in tech in 2018. At the time, companies hired 'frontend engineers' (if you liked Redux), 'JavaScript developers' (if you thought ES6 was cool) or just 'software engineers'. But today, I'm not really any of those things. I'm a product engineer.

I started productengineered.com because I noticed two things:

I think product engineering is the way to build startups in the 2020s. Yet the methodology is not as widespread as it deserves to be. This newsletter is my attempt to fix that through sharing what I learned about the discipline and providing a space where we can collectively work out how to do it better.

To begin this journey, I want to discuss what a product engineer really is.

Product engineering doesn’t conform to a simple definition. If I tried, it would be something like ‘software engineer who works on a customer-facing product’. But this description doesn’t do the term justice. Product engineering is a detailed approach with many sub-components.

First, the obvious part: product. More specifically, I'd describe a product engineer as expressing product taste.

What do I mean by taste? It's your ability to notice and evaluate the details of your work. It's your ability to distinguish between good and bad, elegant and crude, quality and slop.

Product taste is an aesthetic quality. It's knowing what looks right (even if you're not working directly on UI).

I'd state that excellent product engineers exercise taste beyond just product. They have technical and business taste. They can size up problems. They know the right and wrong way of doing things in product, code and design.

How do you acquire this taste? You care. You pay attention. You surround yourself with other tasteful individuals, and evaluate their work and your own. It’s nebulous, but this caring is one of the core skills of a product engineer.

A product engineer has to work with customers directly. Building a great product means building a great product for someone.

Any well-crafted product is the accumulation of a thousand small details. As a product engineer, you will constantly be making the decisions to power those small details. Unless you understand who you are building for, what they want and how to give it to them, you will make the wrong decisions.

You need to be speaking to customers. That means time on customer calls and in Intercom. When a customer reports a bug in a system you built, it should hurt a little; you should feel compelled to fix their problems.

Another way to work effectively with customers is to become one yourself, i.e. dogfood. You can be creative here: create a fictional business to test with, use your day job’s product for your side project, find internal users elsewhere within the company.

More than anything else, the thing I feel defines product engineering is that your goal is to solve product problems rather operating in a clearly defined domain.

This means that companies that hire product engineers tend to hire stack-fluid individuals. The exact interpretation of this differs from company to company, but it ranges from 'everyone must be full-stack' to 'most people skew backend/frontend but shouldn't be afraid to jump across boundaries if it means getting the job done'.

Part of the reason for stack fluidity is that AI has reduced the cost from switching from frontend to backend or vice versa. If you know how to code and just need to add that little frontend specific knowledge on top, Cursor/ChatGPT/Claude make that easy.

Mobile seems to be a little more isolated due to the deep tooling and environment knowledge that is still required, but this boundary is also fuzzy. Someone even mentioned to me the idea of being a 'client engineer' where you focused on client-agnostic building across web and mobile.

In asking around at other companies, I identified some common trends in who is not classed as a product engineer.

The core roles that still seem to be segmented out of the product engineer core are:

Although there are some very technical roles on this list, you should not, by any means, think that product engineers are non-technical. Solving product problems means solving technical problems.

Indeed, it is often deep technical knowledge that allows product engineers to provide new and valuable product input. Sometimes, detailed product behaviour is very technical. I see this all the time when coming across questions of data validation, UI optimism and error handling.

Technical ambition and acumen also make whole new levels of product excellence possible. Outcompeting your rivals technically, means you can make a smoother, more powerful product.

Although product engineers don't do everything, they certainly do more than a traditional software engineer. This leaves us with the question of what the teams that surround product engineers look like.

The first thing I've observed is that these teams tend to be smaller than the canonical 'two pizza team' of 6-10 people. It varies, but product engineering teams are typically half that size.

This is for a few reasons:

I've heard of extreme versions of product engineer minification. For example, PostHog employs >100 people but has one product designer and only a handful of PMs. Some teams consist of a single product engineer.

In addition to working in smaller teams, I've seen the boundaries between teams blur. When your job is to solve problems directly, "That's not our responsibility" doesn't cut it. Product engineers will often provision their own infra, and work in codebases without formal ownership boundaries.

Naively, you might think the product engineer displaces the product manager. It is certainly the case companies can go longer before hiring their first PM.

But the primary difference in how PMs operate in product engineered companies is that the role shifts from a manager of the team towards expert product consultant. Product managers have the space to go deeper than product engineers, particularly on product/customer research and feedback. They focus on gathering and synthesising knowledge which the rest of the team can then use.

Call me biased, but I think this way of working with software will inevitably win. Smaller, well-equipped teams are simply better. They have tight feedback loops and learn faster. They are less blocked by process and more focused on building.

But most of all, the core trait that the product engineer archetype possess is that they give a shit. And how can you compete with that?

Thank you to Jonathan, Alex, Dan, Oleh and Kacper for their input on this post.

Looking for a product engineering job? We're hiring at Attio. Reply to this email for more.