The way I see it, to be a specific type of developer (e.g. product or really technical), you have to learn multiple factions within the whole development.
A really technical developer can be a tech lead or CTO and help other developers grow with complex material.
Product developers may find it a bit more difficult when helping mid/sen developers with complex technical solutions, but they would be an awesome fit for product owner roles.
I think this article is a great example on how to mix "being a pure developer" with other parts of the whole process.
I think this is a false dichotomy. There is no easily definable difference between solving a complex problem and creating a product. What I think this article is actually about is startup and small contractor culture.
OP immediately draws a distinction between having and pursuing a deep understanding of programming and building stuff. These two things are not mutually exclusive. There is nothing that says a programmer has to sacrifice product focus for technical ability, or vice versa. What I think the OP is actually experiencing is the result of contracting across disciplines, which happens often in the "we wear many hats" culture of the modern startup or when one operates as a solo or small team contractor.
Front end applications, whether web or native, have become increasingly complex. Much of the business logic that used to live on a server is now living in the front end. This means that to be a solo front end programmer one must have knowledge of ui design, ux concerns, web/os standards, and the more traditional computer science skills. To me, being a "Product Developer" reads as being more concerned with the front of the front-end. This is not at all a bad thing, as there is a real difference between ui design and ui programming and both of these fields are rich with history and best practices, but an individual can have experience across the whole stack.
That said, the problem of delivering a cohesive product, imo, has more to do with having the process down for defining what the product is and how it's intended to work than the individual skills of a programmer. I've worked on many products with stacked teams of talented engineers and ui designers that failed to deliver even simple products because the vision for the product was not defined. When there is only one or two people working on a product this seems to happen less, but as the size and scope of a product grows (along with its resource allocation) the cracks in a bad process become more apparent.
This reminds me of something I read a long time ago that has stuck with me: If a good process (read: well defined) leads to a good outcome then the process works. If a bad process (read: ill defined) leads to a good outcome then it was luck, not the process. That is to say, if you're a developer that isn't detail oriented and precise with your process but you deliver a good product then you got lucky. If you're a developer that is detail oriented and precise and you deliver a bad product, then you can probably look to your process to find out what happened and fix it. The point of being detail oriented and precise is not to constantly over-optimize and waste time on problems with low roi, it's to write good software that's maintainable.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.