a recent spike in popularity
Recently, I’ve noticed a spike in usage and reference of the term “Product Engineer” in and around Twitter, LinkedIn…etc.
Checking Google Search Trends, since 2017, we can observe a near doubling of searches for the term.
It feels like a bucket-term for many different roles:
- the non-technical builder,
- the Product/Project Manager using low-code tools,
- the Software Engineer who talks to users,
- the AI engineer who uses Cursor,
- anyone using a prompt-to-app tool
- the catch-all: engineer with product sense
- …etc.
I feel like the definition of a Product Engineer isn’t the clearest at the moment, and I’d like to offer my take.
why I resonate with being a Product Engineer
Like many of us, I have had a unique path in determining my calling. I pursued and explored:
- traditional electrical engineering with process, instrumental & control systems for large physical assets
- medical tech hardware entrepreneurship
- military service (at the end of my service, I seriously considered signing on)
- management consulting
- autonomous vehicles research: machine learning, robotics, computer vision
- hackathons: a lot
- software engineering, backend, data science engineering (read more at Connecting the Dots)
In 2022, early in my career – I wasn’t clear about what I wanted to do. One key reason I work hard, is so I can do work I find meaningful.
And yet, I wasn’t exactly feeling it at the time – especially as I was designing and building large data pipelines. I couldn’t appreciate the user impact from a “this makes me excited to get out of bed today” vibe. Noting that enterprise products are often harder to appreciate compared to consumer products (as we are all experienced consumers).
Thankfully, I always managed to get my product and creative expression fix from doing hackathons.
During that time, I came across a Why become a product engineer? webinar by Y-Combinator. Their event blurb read:
An interesting role that’s often overlooked is a Product Engineer — a software engineer who codes every day and also cares deeply about what the customer wants.
I was like “T-that’s me??“
at hackathons:
I’d usually lead the ideation, product management scope, talk to the most users, validate the idea, bring feedback back to the team, do multiple-demos, nail the user stories & narrative, consider the angles and future features – while building as many features as I could.
at work:
I’d create concise “Problem, Use Case, Solution, Business Value, Implementation” one-pagers or even slides if needed – to try to get buy-in from leaders to support my initiative. E.g.
- Improve our engineers’ flow state: by balancing our AWS auto-sign out & security risk with the existing permissions management system
- Enable “Google Side-projects”: at work in the graduate program through problem discovery and hacking solutions quickly (I was told I couldn’t both run the initiative and take part in it 🥲 because that would be too much work)
- Passively reduce food wastage: through simple IoT visuals at the company’s dining hall
- MaaS (model as a service): pretty much Replicate, leveraging the unique models we had
- Zapier for AI agents: MCP nails this much better. However, the need was clear, and I pushed for this in early 2024.
my definition of a Product Engineer
A Product Engineer pursues truth. The truth of their users, the problem, the solution, and even themselves – and uses that truth to get us closer to product-market fit. For any problem, there is a fog of war that must be explored to solve it. A Product Engineer delves into it and does whatever it takes to clarify the path through.
That’s my definition when trying to distill the essence of a Product Engineer. I can slam and list the methodologies, frameworks, and responsibilities – but it’s more useful to understand the core of a Product Engineer’s identity.
In pursuing truth, Product Engineers seek to answer:
- What’s the problem? Is it valid? Is this a downstream or upstream issue? Why does it exist?
- Does that use case exist? To what extent? To whom?
- How does that translate into our solution? What are the key features needed?
- Will the user understand this? What’s their unmet need? Primary, secondary, tertiary?
- Why isn’t this solved yet?
- What is our solution? What are the problems in our solution we need to solve?
- How can we use our resources most effectively?
- What intangibles are there? In our team’s morale? How we communicate?
- How are we determining the truth?
- and many more.
At the core of these questions is the Product. Tied to the product are our users, our solution, our methodologies, etc. Each with its own area in the larger fog of war – and we cannot always see clearly through as it continuously evolves and changes.
A Product Engineer cannot only develop features or talk to users – as the truth obtained from solely each scope is only a part of the full picture. Often, I only appreciated the complexity behind what we were building when I worked on the features myself (e.g. trying to put hand models in VR is not always a 15 minute YouTube tutorial). Often, only after talking to users did I realise our existing features were missing the mark.
The Product Engineer is trying to chart the best course through the fog of war by seeking the truth.
The main difference I see between Product Engineers and any other kind of engineer – is that we have an obsession over these questions to a greater extent than any other.
Other roles and scopes often focus on their area’s questions (as they should). While the Product Engineer should continue to bring their latest uncovered truths to each of them, while appreciating the truths from them – to derive a more complete truth.