I use “software engineer” and “product engineer” to describe two ways of working. The difference is not the technology or level of skill. It is how much product ambiguity someone is expected to resolve.
This is my own definition, not an attempt to set titles for the industry.
Software engineers
A software engineer turns a defined problem into working software. They do best when the goal, behavior, constraints, and design are clear.
For a login feature, they might receive:
- the required fields and flows
- finished designs
- security and performance requirements
- the expected technology
Their main responsibility is implementation. Asking for missing details is part of doing the job well.
Product engineers
A product engineer helps decide what should be built before deciding how to build it. They still write software, but they also work through questions that a product manager or designer might otherwise answer.
For the same login feature, they might receive a goal instead:
Make it easier for returning customers to sign in without weakening account security.
They are expected to study the current experience, question the proposed solution, work with design, and decide how to measure improvement.
Neither approach is better. They require different support and create different risks.
A strong product team may benefit from engineers who can execute detailed plans quickly. A small or ambiguous product team may need engineers who can help shape the plan. Problems start when a company hires for one style and manages for the other.
If you give a software engineer an unclear goal and no product support, they may feel blocked. If you give a product engineer a complete specification with no room to make decisions, they may feel wasted.
The title matters less than making the expected way of working clear.