Field Notes · Act 1 — Define · 02 of 13
What Is a Product Engineer?
Observe
What people who do the work sayThis article draws on 15 public sources, re-read in October 2026: definitions, first-person accounts, hiring posts, and how teams say they work. I kept only sources that show an engineer doing something beyond the familiar software engineering scope; where the title only renames the usual job, the source is left out. Quotes are verbatim and linked. Grouping them into patterns is my own reading, done with an AI assistant and not yet checked by a second reader.
Last time, I ended with a signal from one company and six questions for the series. This article takes on the first three: what the people who do this work say it is, what repeats across them, and a more personal one, whether that connects with the way I've been working for years.
THE QUESTIONS IN THIS ARTICLE
What do the people who do this work say it is?
Before counting anything, listen to practitioners and teams describe the role in their own words.Chapter 1 ↓What patterns repeat across them?
Which practices keep coming up, from understanding the user to learning after shipping.Chapters 2–4 ↓Do those patterns connect with the view I've been building in my career?
I've worked across design, business and technology for years, and that combination was always hard to explain while teams were organised in silos.Chapters 5–6 ↓This is the qualitative research behind the series. Instead of starting from job postings, I started from what people say about the work in their own words: companies that define the role, engineers who hold the title and write about their days, people hiring for it, and teams describing how their engineers are expected to work. I read 15 public sources, pulled out 74 short verbatim excerpts, each one something the engineer actually does, and grouped them by practice.
The goal is not to measure how common the role is. It is to understand what the work involves, see which practices repeat across very different voices, and arrive at a working definition.
THE 15 VOICES
Each card opens the excerpts I used and the source. The same cards come back through the article next to each quote, so you can always see who is speaking.
What the people who use the title say
PostHog, a company that hires explicitly for this title and writes publicly about it, lists what a product engineer does:
Makes and owns product decisions. Talks to users and cares deeply about their needs. Cares more about outcomes than shipping perfect code. Is opinionated about what they should be building. And can back that up with persuasive arguments. Understands how their work impacts the business. Tests in production and iterates with real users. Thrives when given autonomy to engineer every element of the product.
Michael Matloka, who worked as a product engineer at PostHog, reduces it to three beliefs on his own about page:
understanding the user, building the right solution for their problem, productizing that solution
Antonio Alegria, hiring at DOJO AI, describes the person he is looking for:
Someone who can sit with a customer and actually understand the problem, then go build the solution end to end, front end, backend, the agent logic, all of it.
The people doing the job describe it in the same direction. Eric Roby, who changed his own title, starts every task with two questions. Ian Carey, writing about Intercom, says what the role asks of engineering knowledge. And Edd Sowden, three months into the role at incident.io, describes how much of a project was his:
Who is this feature really for?
Is this the most valuable thing I can build right now?
you are tasked with using your engineering knowledge to inform the design
I was given a couple of sentences as to what we thought we wanted but after that I owned everything.
Some teams write it down as how they expect engineers to work: Intercom in its product principles, Amplitude in how it builds product-oriented teams, Ashby in its engineering levels.
Start by deeply understanding the problem we're solving.
talk to customers
Lead the research, product decisions, design (both UX and technical), and implementation of new products
Reflect
The patterns that repeatOne path keeps coming back
Read side by side, the 15 sources keep describing the same path, in roughly the same order: get close to the user, their problem and their journey (10 of the 15 sources); decide what's worth building (11); build it, often small first (10); and learn after shipping (9).
These four steps are how I grouped the practices I found in the excerpts. Each step brings together the practices that do the same job on the way from a user's problem to what happened after shipping; three practices don't belong to one step, because they support the whole path.
THE PATH: FOUR STEPS, ELEVEN PRACTICES
Intercom and Roby put the last step plainly:
Shipping is the beginning, not the end
I monitor the rollout and talk to real users.
WHERE THE DECISION STARTS
Two things stand out. The first is how thin one step is: plenty of sources talk about getting close to users, but only 3 talk about stating the user's problem itself. The second is that building, on its own, is not what the sources are pointing at. Every engineer builds. What they describe is building as one step in a path that starts with someone's problem and ends with learning what happened.
THE PRACTICES BEHIND THE PATH
Who says what: every practice × every voice ▾
Hover or focus a lit cell to read what that source says.
These counts show where these voices repeat. They are not a measure of the market.
Ownership is the whole path, not one more skill
"Ownership" shows up everywhere in how people talk about the role, and it is easy to read it as one more trait on the list. The sources describe something else: the same person carrying a piece of work along that path. Sowden's project is the clearest example: from a couple of sentences
to defining how it would work, getting the UI designed, building it, turning it on, and telling the customers who had asked for it.
That is the same path from One path keeps coming back, carried by one person. The panel lines up the four steps with each voice. How to read it:
- A lit step: the voice describes that step.
- A ✱: the voice says outright that the engineer owns the work.
- Lit steps and a ✱ together: describing every step is not the same as one person doing all of them. Only the ✱ voices say that one person does.
ONE PERSON, THE WHOLE PATH · THE FOUR STEPS, VOICE BY VOICE
Where the voices say it outright
The same sources are also clear about the limits. That ownership sits inside a scope, and it comes with help. Sowden had support where he wanted it. At incident.io, Macey Baker started with work the team had prepared. At Ashby, an engineer leading a project noticed early in a prototype that it would eat much of the roadmap and flagged it; the decision to reprioritise was the team's.
I was given plenty of help and support where I wanted it!
the team had put effort into picking out digestible, yet high-impact pieces of work that I could tackle
The Engineer had the right sense of urgency to flag this as a potential issue
So ownership end to end is not the absence of anyone else. It is carrying the work from the problem to what happened after shipping, inside a scope, with the help you need.
So is this just a good engineer?
That objection deserves a straight answer. The top-voted reply in the largest discussion thread I found on this was three words:
Good developers always were.
I think that's mostly right. The path isn't new behavior; what's new is a title that names it, and a market starting to ask for it. Even so, the voices pull in different directions on how it works in practice:
WHERE THE VOICES DISAGREE
Make
A definition where the findings meetWhere this meets my own path
Back to the third question from the top: do those patterns connect with the view I've been building in my career? What these sources describe is a combination I kept practising across roles long before I had a name for it, and I recognise it step by step. Here is my own path read against the same four steps; the dates, numbers and projects are on adilsonchicoria.net.
MY PATH, STEP BY STEP
- Get close to the user, their problem and journey
- 2007–2011 · PotereFounding my own company: a pharmaceutical product pushed me from a quality-driven mindset to customer development, to find product-market fit.
- 2016–2019 · IBMRequirements for the IoT Automation Console came from remote design thinking workshops, over three sprints.
- Since 2023 · Guarda-Costas ImobiliárioA home-buying due-diligence product I used in my own purchase: six months, more than 40 apartments visited.
- Decide what's worth building
- 2016–2019 · IBMPlayed the Scrum Product Owner: storyboards, journeys and needs broken into epics and stories, prototypes validated with users and stakeholders before building.
- 2020–2023 · OutSystemsA new onboarding for the IDE, designed so a prospective user perceives value within five minutes.
- Build it, often small first
- 2005–2007 · CpqDCore components of a telecom and utilities billing product, test-first, across the whole RUP lifecycle.
- 2016–2019 · IBMThe Automation Console itself: React front end, Java APIs, microservices on Kubernetes, and a team of three to seven front-end engineers.
- Since 2023 · soloConceiving, building, launching and automating my own digital products with AI agent pipelines.
- Learn after shipping
- Since 2023 · sales funnelsServer-side tracking from first touch to purchase. In one campaign, sending a new ad to the page section that continued its message raised click-to-conversion by 70%.
Across the whole path: 2015 set up IBM Studios São Paulo inside IBM Brazil's Software Lab · 2014–2019 more than 30 Enterprise Design Thinking workshops · 2015–2019 the Design Thinking track I created at The Developer's Conference, 14 editions and more than 1,200 people in the room · 2018 innovation labs with Saint Paul Business School and Fundação Dom Cabral.
Lined up this way, the first three steps have been part of my work for a long time. Learn, measuring what happened after shipping, came last: only when I started running my own products did I own what happened after launch.
The job titles rarely said any of this. Here is how the work in each role split between tech, design and business:
MY ROLES · HOW THE WORK SPLIT
TechDesignBusiness (product and founder work)
The split I state for each role, reviewed in October 2026. Back end, front end, desktop and engineering count as Tech; UX, research and collaboration as Design; product and business work, including founder work, as Business. Source: adilsonchicoria.net.
The mix was there from the start, but it came and went with the job. When I worked for myself or founded something, design and business took most of the work. In most engineering jobs they shrank to a quarter or less, and much of that work happened around the role instead: the studio, the workshops, the conference track. That is the silo problem in practice, and it is why the title Product Engineer caught my attention.
The sources ask for that same mix. Tag each excerpt by the knowledge it draws on, and almost every practice needs more than one of design, product and technology:
DESIGN · PRODUCT · TECH, PRACTICE BY PRACTICE
My definition of a Product Engineer
Putting the patterns and that experience together, this is my definition: the one The Product Engineer works from. It is built from the sources above and from my own path, and it stays open for discussion.
THE PRODUCT ENGINEER · MY DEFINITION · v0.5
A Product Engineer is a software engineer who takes part in understanding real users' problems, deciding what is worth building, and turning those decisions into usable solutions. They bring technology, design and product judgment together, carry the solution along the whole path — from the user's problem to the decision, the build and what they learn after shipping — within their scope and with the help they need, working with other disciplines.
The research behind this definition is open: the 15 sources, the 74 excerpts word for word, and how they group into practices along the path, in The Product Engineer Mental Model.
So what distinguishes a Product Engineer from a strong Software Engineer? Not the title, and not the tech stack. It's whether you take part in the whole path: understanding a real user's problem, a decision you helped make, something you built, and what you learned after it shipped. If you already work that way, the title is catching up with what you do. If you don't yet, look at which step is missing: that's where to start.
Which leaves the other side of the question. When companies hire under this title, how much of the path do they actually ask for: the whole path, or a full-stack job with a new name?
Fifteen people who do this work describe the same four steps. Most job ads ask for only part of them.
The Field Notes newsletter follows The Product Engineer Path from practitioners to job postings. Subscribe and get each new note by email.
Enable JavaScript to subscribe, or get in touch by email.