What is a Product Engineer, and How Do They Differ from Software Engineers?

The world of software has always moved quickly, and one silent trend slowly gaining steam that not many people outside of the industry have heard of is the rise of the Product Engineer. Today I want to explore what exactly is this mythical new type of engineer and what makes them different from your standard software engineer, a related yet distant role. The title has been used for a years in classical manufacturing, but let us see what exactly it means to be one when building software or... products!

Shifting Focus

A product engineer, at its most basic, is a software engineer building products. They do similar work to software engineers: writing code and shipping features. Usually, they write fullstack code with a focus on the frontend. This is where the confusion starts as previously anyone writing any type of code was deemed a software engineer and the story ended there.

They are customer-focused, full-stack engineers who blur the lines between product and engineering roles. Generalists who can take an ambiguous problem, define a solution to it, and design, implement, and deliver that solution.

They might not be experts in any of those fields, but their expertise lies in building and shipping the product itself.

Recent Trends

Online searches for product engineers have grown by 80% since 2021 as startups started to prioritize engineers who are customer obsessed, talk to them directly, and comfortable working autonomously.

The reason for this can be distilled down to the very essence of a company: Building products that many people want and will pay to get them. For any startup that dreams big but cannot afford to hire separate product, engineering, marketing, sales, design teams, the rise of the product engineer was inevitable and has existed long before it got its current name.

What should a Product Engineer have?

What makes them unique is the focus on creating a product for users. It's about building a solution to problems that provides value to users. They must be empathetic to users, and this means caring about user feedback and usage data, coupled with a responsibility for the overall product they are working on.

Let's dive deeper into the main characteristics.

Customer Obsession

This was the key to Amazon becoming the giant it is today. There are countless shareholder letters from Bezos where he talks about the importance of customer obsession, but for me their process of validating and building products speaks the loudest.

The so called Working Backwards process, where we start from the final product once it has been built, the experience it will provide and the problem it will solve. Write your product's press release and any FAQs people might have, and start building from there.

Analysis

Together with ownership of the product, comes the responsibility to always keep an eye on the competitive landscape, following usage data and watching session replays.

Understanding where your product fits in your field, who is using it and your competition is a must. By knowing what makes you different, you can focus all your attention on expanding this gap and solidifying your position.

Prototyping

Briefs, mockups, written reports, and presentations are not a great product. Prototyping, shipping, and experimenting are closer.

Every product or feature can only be validated by only one thing: the users. If your ideas never leave the meeting room, you will never know if they are worth implementing. The value of a product engineer is willing to put his unfiltered ideas into the world and let them live or die by the sword, quickly reacting to their failure or success and learning from them.

Automation

Being responsible for the entire life of a product requires time and your attention. Product engineers get this time by relying on dev tools and automation. This means spending as little time as possible on tasks such as testing, infrastructure, and deployment.

Product vs Software Engineer

I've talked a little about the difference between the traditional SWE and the newly rising Product engineer, let us paint a clear picture by going through the major differences.

Product Engineer

Focus on building great products
Own the product, and are responsible for its successes and failures
They are empathetic towards users and care about solving their problems
Build with the user in mind
Willing to build fast, iterate, or even from scratch if needed
Pragmatic
Less focused on implementation
Spend time researching the competition, talking to users and digging into usage data
Take ownership and responsibility over the roadmap

Software Engineer

Focus on building great software
Own the code they write
They care more about solving technical problems, optimizing systems, and writing clean, secure code
They have flexibility with implementation, but they aren’t making product decisions
Idealistic
Looking for the best solution to the problem in front of them, focus on best practices, and build off prior work
Security, risk, and scaling weigh heavier in their minds
Deeply focused on specific areas of technology, whether that is databases, data pipelines, backend APIs, or client-side app frameworks.

When do you need one?

Product engineers are ideal for startups, and companies that want to be agile and move fast, such as B2B SaaS or consumer subscription service.

They're less effective for companies with large, technically complex products, like a data tool, or platforms for large enterprises.

The classic downside of being a jack of all trades is that you are a master of none, and if your users expect an extremely stable, secure and performant product, you need an idealist software engineer that will dig deep for a 1% performance improvement. For most startups and emerging products, performance and security is not the highest priority, and that is when you need a product engineer to pilot it into the sky.

Why should an engineer care about product success

A question I am sure many software engineers have asked themselves while reading this article.

A successful product results in a successful company. A successful company results in rising wages as the value increase is the result of your work.

At the top of Maslow's hierarchy of needs lies Self-Actualization. What is more self affirming than seeing something you poured your effort into go into the world and come back successful?

Case study

In my last blog Good Data ADD LINK I went more in depth about our journey with product analytics and Rate Game, but I would like to go through a short version of it here as an example of where a product engineer shines and got the job done where a traditional structure would have required 2 or more people working on it.

Rate Game: Setting up rock solid Analytics

Rate Game is an app for sports fans to rate games and leave their takes. As a social app, the bulk of its value its comes from our users and tracking their behaviour is key in figuring our the right features to build.

How we turned the lights on:

AARRR Funnel: We identified that our focus should be on the first 3 sections and built our tracking around them.
Separate Responsibility: Set up a doc where we identified the correct tool for each metric.
Clear Definition: Defined each metric clearly. An example is a session length of 5 or more seconds for DAU/MAU.
Posthog: Transitioned from Mixpanel to Posthog due to their cutting edge Session Replay feature for React Native.
Lean Events: Followed best practices and cut down our events list from 110 to 35 events.
Appsflyer: Rate Game relies on creators bringing in users through their platforms. Tracking installs and conversions from each of these creators is key.
Custom Dashboard: Built a dashboard on the web where we track general app stats as an overview.

While there were 2 attempts to bring in a freelancer to set up our product analytics, it took a product engineer willing to step into new territory to make this happen.

The Future

It is not a coincidence that job listings and searches for the "product engineer" title have risen so much, and we are only at the beginning of its rise. I believe it has to do with the following 3 trends:

More With Less
- Companies of all sizes want to do more with less, as amply evidenced by massive tech layoffs over the past few years.
The golden age of DevTools
- The landscape of tools available today for software engineers to quickly design and develop new products is staggering compared to what existed ten years ago. The SaaS renaissance is happening now, use it.
The Rise of LLMs
- Specialists are valued due to their expertise of a specific tool or field which could be hard to get into it. LLMs remove this barrier to entry and make it easier to get the job done.

With the newly announced o3 and o3mini coding and technical knowledge will be needed less and less, similar to manual labor being replaced by machines in the industrial revolution.

We are on the verge of another revolution with a similar or bigger impact, and there are 2 directions you can go into. Specialize in building products, or wait for a model good and cheap enough to replace you hit the market.

How To Become One

Due to the many fields where you need at least surface level knowledge in order to be useful, the key to become one is to go out of your your way to learn as much as you possibly can. The best way to do this is to work in a fast paced environment with loosely defined roles and the freedom to take on any hat you think would serve the product.

Most startups will provide this environment for you, as this is where product engineers are forged. If there is a chance for you to do work in a field outside of your expertise, have the courage to try and fail.