A product engineer is the person responsible for making your digital product work and solve what your business needs, not just for writing the code you asked for. They decide what the first version should do and what can wait, build it, launch it and keep it running. A programmer, in the most common sense of the word, receives a task someone else defined and executes it well. Both roles are legitimate and both write code; the difference is who makes the decisions and who answers for the result. I am writing this because it is the question founders ask me most before hiring, and because picking the wrong role costs more than picking the wrong technology.
TL;DR
- A programmer executes tasks someone else defined. A product engineer defines what gets built, builds it, launches it and answers for the result.
- If nobody in your company decides what goes into the first version and what does not, you will end up doing that job yourself, without the experience, or nobody will. That is where a product engineer pays off.
- If you already have a CTO or a technical lead who decides, what you need is a good programmer. Over-hiring is a mistake too.
What a product engineer does
The shortest way to put it: a product engineer answers for the product, not for the tickets. When a client hands me their mobile app, their website or platform, or their AI chatbot, what they get in return is one person responsible for making that thing exist, work and keep working. That covers work normally split across four profiles: understanding the business, defining the scope, designing how it gets solved, writing the code, launching it and watching what happens next.
What defines the role is not the list of tasks but where the responsibility starts and ends. It starts before a task exists, in the conversation where you decide what is worth building. And it ends after the code is written, when the product has been in real users' hands for months and someone has to decide what gets fixed, what gets measured and what comes next.
In my case I have worked this way since 2019, as an independent contractor, for founders and teams without a technical lead in-house. Before that I worked inside teams with the traditional structure, and that experience is exactly what makes me value the programmer role when the structure exists.
What a programmer does, and why that is not a criticism
A programmer receives a specification, a task or a design and turns it into working software. It is hard work, and there are excellent programmers who do not want to decide what gets built and should not have to. In a team with a product manager, a designer and a technical lead, that split is the right one: each person decides in their own area and the programmer can focus on doing the most technical part well.
The problem shows up when you hire a programmer and have nobody to do the rest. The decisions do not disappear; someone makes them anyway. If there is nobody to make them with judgment, one of two things happens:
- You make them, and you know your business but not what is expensive to build, what is fragile or what will hurt in six months.
- The programmer makes them implicitly, task by task, without seeing the whole and without anyone having asked them to.
Neither is the programmer's fault. You asked them to execute and they executed. The gap was in the role nobody filled.
The difference in one table
| Programmer | Product engineer | |
|---|---|---|
| What they receive | A task defined by someone else | A business problem |
| What they deliver | Code that completes the task | A launched product in use |
| Who decides the scope | Someone else | They do, with you |
| What happens if the task was framed wrong | They build it anyway, or ask | They question it before starting |
| What happens when something breaks in production | Depends on who notices | Noticing it is their job |
| How their work is measured | Tasks completed | Product outcomes |
| Who talks to you | Often an intermediary | The same person writing the code |
The row that matters most is the third one. Defining the scope of the first version is where a project's money is won or lost, and it is precisely the part a programmer, by definition of the role, does not do.
Keep reading
That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:
Read the full post on ramonchancay.me →
Originally published at www.ramonchancay.me/blog/what-is-a-product-engineer.
Top comments (0)