Why the titles multiplied
Software teams can move from an idea to a working version faster than they used to. That changes where teams feel the bottleneck: less time waiting for a handoff, more pressure to choose a useful problem and learn whether the solution helped.
New role titles are attempts to describe that shift. They are not a universal taxonomy. The same title can mean different things at different companies, so read the work behind the label.
Two questions make the map
Start with two questions: where do you start, and who do you serve? One axis is your home discipline—engineering, or product and design. The other is your working context—many users of one product, or one customer at a time.
Owns a product for many users, from user call to shipped metric.
The map is a guide to the work, not a scorecard. Roles overlap, and a job description may sit between quadrants.
Four builder roles
Product engineer
A product engineer starts from an engineering foundation and works across the product loop for many users. The job is to understand a need, shape a solution with the team, build it, and learn from the result.
Some teams have a product manager alongside the engineer. In that model, the PM may own strategy and prioritisation while the engineer takes a larger role in discovery, scoping, specifications, trade-offs, and success measures. In a smaller team without a PM, those responsibilities are shared or carried by the engineer as well.
Forward-deployed engineer
A forward-deployed engineer starts from engineering and works close to a particular customer or customer team. The engineer builds and adapts production software in the environment where it will be used, then brings what they learn back to the product team.
The customer context is the defining difference. The work may become part of a reusable product, but the immediate problem belongs to a specific deployment.
Product builder
A product builder starts closer to product or design and uses code and other tools to move from an idea to a working change for many users. The label is broad; the useful question is how much technical depth, product judgment, and ongoing ownership the role actually expects.
Solutions and implementation roles
These roles also work close to customers. Their center of gravity may be helping a customer evaluate, configure, integrate, or adopt a product. Some include substantial software development; others focus more on solution design and enablement. Ask what you will ship, who will use it, and who owns it after handoff.
With a PM, and without one
Working with a PM is a realistic first step into product engineering. The PM can bring strategy, research, and prioritisation; the engineer can help understand the user’s workflow, shape the solution, write a short spec, define a success signal, and make technical trade-offs visible.
When there is no PM, the team still needs those activities. The work does not disappear—it moves between people. An engineer may take on more prioritisation and roadmap decisions, usually in close partnership with a founder, designer, or team lead.
Which path fits you?
Think about the work you want to own. Do you want to improve one product for many users, or solve a specific customer’s problem in their environment? Do you want to start from engineering, or bring product judgment and code together from another discipline?
Try the five-question self-check for a first read. Treat the answer as a prompt for reflection, not a verdict. If product engineering is the direction you want to explore, the 90-day plan gives you a practical place to begin.
What the roles share
All four roles reduce the distance between a real need and a useful result. They ask builders to make decisions, collaborate across disciplines, and pay attention to what happens after something ships.
The differences are the starting point, the customer context, and how broadly a solution needs to work. That is the map. The work is learning when to cross its boundaries.
