Product engineer vs software engineer: How are they different?

May 10, 2023

Software companies are changing. Where once product managers and software engineers dominated, now a new role is emerging: the product engineer.

Want proof? Look at this graph:

Online searches for product engineers have grown over 80% in the last year and are 3x greater now than just two years ago.

Product engineers are changing the way companies think about engineering. To help explain why, we’ll compare the role of product engineer with the traditional (and still very necessary) role of full-stack software engineer.

How are product and software engineers different?

Here's the TL;DR:

• Product engineers focus on building great products.
• Software engineers focus on building great software.
• But they both write and commit code.

Let's break those points down a bit more.

Product engineers – sometimes referred to as product-minded engineers – own the product, and are responsible for its successes and failures. They're empathetic towards users and care about solving their problems. They build with the user in mind, and create what users need for success.

In contrast, software engineers 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.

Product engineers are less focused on implementation, and focus more on solving the users’ problems. In this way, they are pragmatic. They are willing to build fast, iterate, or even from scratch if needed.

Software engineers are more idealistic. They look 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.

What about growth engineers? Growth engineers are a type of software engineer that focuses on projects that drive growth metrics like signups, subscriptions, and revenue. They share many characteristics with product engineers, but have a broader focus on growth across the company rather than a specific product.

How do they spend their time?

Product engineers still spend the majority of their time coding, but they have responsibilities outside of coding that software engineers don't.

Product engineers also spend their time talking to customers, digging into usage data, and researching the competitive landscape. They test other products, build prototypes, and brainstorm experiments to make their product better.

They spend time communicating with users, their team, and other members of the company. They communicate what they learned in research, why their work relates to that research, and how to prioritize what to work on next. They own the product roadmap, and this comes with a responsibility to communicate it.

Software engineers focus on writing code, testing it, and maintaining it. They look for ways to optimize code, improve scalability, and solve bugs. They are deeply focused on specific areas of technology, whether that is databases, data pipelines, backend APIs, or client-side app frameworks. This means researching and reading documentation, updates, and code.

Why is demand for product engineers growing?

There's no single reason, but typically it's motivated by a desire to ship product improvements faster. Product engineers are popular among startups and early-stage companies for this reason, even if they don’t say it. Many engineers behave like product engineers, even if it's not their job title.

At larger companies, product engineers are seen as a way to drive innovation, sometimes through the creation of smaller teams that have the freedom to ideate and execute product ideas. Software engineers and multidiscipline teams are still important, but product engineers can inject urgency where it's needed.

Elon Musk's Twitter is a good example of company that could benefit from product engineers, whether he's aware of it or not. Elon wants to make dramatic changes to the product, but in his opinion, the organization he inherited was too large and unwieldy to achieve this.

In other words, he doesn't need software engineers to maintain or optimize the existing codebase; he needs product engineers who can identify problems and opportunities, and execute solutions quickly and independently.

Is product engineering right for you?

Good product engineers need to:

• Be customer obsessed.
• Enjoy talking directly to users.
• Care deeply about outcomes and impact.
• Be flexible about exact implementation.

If this sounds like you, product engineering might be for you.

If, however, you want to focus on solving difficult technical problems, and optimizing existing technologies and processes, then more traditional software engineering roles are a better choice.

Just remember product engineering is more of a way of working, and thinking, than a defined, rigid role. Product engineers should be flexible enough to go deep on technical implementation when needed. Likewise, software engineers can choose to adopt a "product engineer" mindset whenever they like.

When should companies hire product engineers?

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 take a holistic view of the product, and the ability to move fast when the need arises. They're less effective for companies with large, technically complex products, like a data tool, or platforms for large enterprises.

Picking what's right is up to the company and its goals. If you're a small team focusing on building great products, multi-skilled product engineers who can talk to users are a great choice. If your larger product requires specialization to scale and maintain, software engineers are the better choice. Companies with both types of roles have succeeded, and more will continue to succeed.

Further reading

• What is a product engineer (and why they matter)
• Startups, stop treating engineers like a different species
• The really important job interview questions engineers should ask (but don't)