Full stack engineers are generalist engineers who are motivated by technical problems. Product engineers are motivated by building impactful tools. They learnt programming somewhere along the way as a necessity to show the world their ideas.
Product engineers generally pick mainstream languages and tools. They talk about users, strategy and product.
That's an interesting way to distinguish them, though I've seen people change from one to another. Motivations can change in a person.
I'm currently in the process of teaching one of the agency devs we hired on contract how to think with the end-user in mind. At the same time, I've tried to teach other how to reason through things from a purely technical perspective.
"Product engineers generally pick mainstream languages and tools." <-- going by that characterization, a "product engineer" will miss out some strategic advantages that comes from learning non-mainstream languages and tools. This is coming from the idea that, say, there are powerful abstractions and concepts that can be applied broadly, including UX.
For example: Promise Theory is a formal language for describing intentions and a powerful framework for creating cooperating agents in the context of uncertainty. It is typically applied to configuration management, infrastructure and microservices, but it can be applied broadly to human-to-human and human-to-machine interfaces -- literally, UX. For example, knowing that humans will typically assess trust in an iterative way, you can pick apart the entire user flow in terms of the perceived (implied or explicit) promises (user expectations) the product makes. It starts from the advertising (signaling), through user signup, through onboarding, and any useful impact that product makes. It extends through into support and infrastructure scaling, and back to the user signaling to other users that, hey, this is a useful too.
Another huge aspect that conception of the product engineer misses is strategic thinking. Strategic thinking is the art of making decisions in face of uncertainty. Engineers typically don't think strategically, usually thinking in terms of relative advantages instead of strategic advantages.
What differentiates a "product engineer" from an entrepreneur†? Lack of ambition?
Insofar as I fit all the criteria you're listing, those traits are all things that push me to want to work on a small, independent product where I can dictate the vision for it. If I'm willing to "learn programming somewhere along the way as a necessity" to express that vision, there's no reason I won't also decide to learn how to start and run a business "along the way, as a necessity."
To put it another way: in the games industry, the "product engineers" there are called "game designers." Game designers don't generally work as freelance consultants, or put themselves on the market as employees for companies like EA or Sony to snatch up. Instead, if you have the actual vision required to come up with a decent game, you'll make it—and sell it—yourself, either as a one-man show, or by starting your own small games company.
The only game designers working for the big games companies are the ones that grew into that role from whatever they got hired to do (usually either programming or art)—and, even then, only embraced their roles once the company decided to start letting them come up with products "from scratch" that they could basically run as their own little ventures, rather than just stewarding along some existing product of the company's.
---
† I say "entrepreneur", but not in the typical HN meaning of the term. Most "startup founders" I ever hear about seem to be either pure-engineering types who just think about cool tech all day, or pure-business types who think about what'll be profitable all day and follow trends. Entrepreneurialism seems to actually be much more common outside Silicon Valley in regular-old small businesses, where someone with a "product vision" like "feeding people really weird pizza" will get a loan and set up a pizza place to fulfill that vision.)
Product engineers are entrepreneurs in waiting who have yet to find product-market fit with an idea of their own. They've typically tried a few times, but haven't yet won at the startup roulette.
Product engineers and entrepreneurs get along so well because they're the same breed of people. Great entrepreneurs are often product engineers.
And what of those who are motivated by technical problems and by user needs and business strategy? Is it impossible to learn programming because of an interest in computer science or in the challenge of programming for its own sake, but learn product and strategy as a way to put those skills to impactful use?
I don't like this sort of pigeon-holing; most developers I know straddle this divide.
"Full-stack engineer" describes a person's technical knowledge: comfortable doing front-end or server work, maybe comfortable designing whole things from scratch.
"Product engineer" describes a person's motivations: primarily interested in writing code as a means to making a product, or improving a product.
Lots of engineers are primarily motivated by writing high quality code, or very performant code, or prefer to write tools (libraries/frameworks) over writing products using those tools.
You're begging the question. What does "engineering the product" mean? Software engineers are not civil engineers, there are not professional standards for what this means.
Fair point, there's no formal or widely accepted definition for Product Engineer.
In Roman languages, the word "engineer" derives from the word for "wit" (e.g. "Ingeniero" <- "Ingenio" in Spanish); hence there's a mental connection to identify an engineer as someone who uses her wit to solve problems. The Product Engineer hence uses her wit to solve Product issues, that could range from technical issues to manufacturing, materials, distribution or even marketing issues. She has to have a more holistic and less deep view of multiple areas, a la Project Manager.
Now you'll tell me that I'm talking about a Product Manager and I'll have to agree. In my opinion, a Product Engineer is a different name for a Product Manager. Product Management is a really broad area and I think some people more inclined to technical stuff and especially software development would feel more at home being called Product Engineer than Product Manager.
So here's my problem with this. There is no bricklaying in software. If something is really repetitive and mind-numbing it should be automated. That is the difference between software engineering and engineering/construction—the computer does all the rote work.
I get that there are amazing semi-technical managers and UX people who add outsize value even though they don't code—I don't subscribe to the SV worship of "hard skills". However, SV is also full of jackass wantrepreneurs who think they don't need to learn how to code because their singular vision is so valuable. These "idea guys" are the antithesis of what it takes to build a successful startup, and I worry that defining Product Engineer this way just gives them another place to hang their hat and further their own preciousness.
"Engineer" should be reserved for someone who codes or at least administers technical systems hands on. I'm well aware that traditional engineering disciplines look down their nose at programmers for declaring themselves engineers with such informal practices, but nevertheless software engineering is a thing with its own challenges (in many ways more difficult than physical engineering due to the breadth of scale and lack of constraints). Why do we need to water it down when we already have terms like Product Manager or UX Designer?
Product engineers generally pick mainstream languages and tools. They talk about users, strategy and product.