Why I chose to become a Product Engineer
When I started my career as a web developer, I believed my job was to solve as many tickets as possible with the best code possible. Whenever a task reached “Done”, I considered my work finished.
Then one day that changed.
I joined a healthcare startup and found a decisive factor: the user’s need. My code was no longer helping someone discover a service or buy a nice t-shirt. In healthcare, users arrive with an urgent concern. If the app fails, feels slow, or takes too much effort to understand, we add another problem to a vulnerable situation.
There are no second chances, no later, no tomorrow.
That is when I realized I liked problems more than solutions. Before opening my editor, I needed to understand why and for whom. I stopped being only a developer and became a Product Engineer.
Is this role for everyone?
The simple answer is no. It does not fit every context.
In a software factory, value often comes from maximizing delivery speed. In Big Tech, you are one part of a huge system, where technical specialization is usually the priority.
Product Engineers thrive in startups and scale-ups: uncertain environments, small teams, and a short distance between code and the end user. Engineers who understand the business can iterate quickly and discard ideas before spending energy on them.
Beyond code
The work starts long before the first line of code and ends long after a release. A Product Engineer takes part end to end:
- Discovery: understand the user’s problem.
- Planning: decide what to build, and what not to build.
- Implementation: write the technical solution.
- Measurement: check the impact of what we shipped.
It is an endless loop ruled by metrics. We may solve a problem while adding friction, solve it roughly, or misunderstand the need and make the product more complex.
Technology in service of the product
The biggest change is how decisions are made. I do not choose a technology because it is trendy or familiar; I choose it for its product impact.
- Feature flags enable progressive releases and reduce business risk.
- Local-first strategies remove latency and frustration when connectivity fails.
These are contextual decisions, not universal truths. Understanding the business makes you a better engineer: it expands your view to conversion, retention, sales, and support.
Closing
A Product Engineer is not a resource assigned to close tickets. It is a central role that understands business needs and turns them into reality through technical craft.
In the next articles I will explore the metrics product engineers should watch and how to communicate and negotiate with stakeholders.