Software Architect in general implies a high-level (in terms of abstraction) technical position within an engineering team. This person is usually in charge of the design of the software, as in "use a queue here instead of a database", "this data should not go to the UI, but instead be requested on demand", "here's what the API should be for these 2 components to interact". You wouldn't expect a software architect to be particularly knowledgeable about business needs and users.
UX positions are usually design centric (people in these positions usually hold HCI or Design degrees). These people usually lack the engineering knowledge to be able to quickly assess the viability and cost of the solutions they propose, and therefore work very frequently with people that have complementary skills.
I am one of those types with a mixed business/engineering skillset and work in Product Management these days.
The "Product Engineer" as described in the article seems like a great position for a small company, or for a small team within a company. It's what a founding CTO would usually do at the early stages of a company.
In my experience, as companies grow, it's hard to know both the customers, the users, and the technical details in intimate detail, so the position seems slightly doomed unless the product is very technical (say, mostly an API).
That being said, broad skillsets can be a blessing when things need to move rapidly.
It's a lot of things. "Product Developer" captures it quite well. You're going from 0 to ShipIt with minimal bottlenecks.
"Isn't that just an architect?" Except you're not a silo'd backseat driver–ahem! Architecture Review Committee Member–meddling with various teams.
"UX guy?" No, you're building the API, deploying the infrastructure, setting up the DB, and then consuming all of that on the front-end.
"A full-stack developer?" Except full-stack developers are usually weighted heavily to one side, or they get pigeon-holed on Day 1 wherever the team is lacking (usually Ops. Sigh).
But "Sr. Actually-Full-Stack Developer" would be an alternate job title to "Product Developer." You need a lot of discipline (and experience) to not over-engineer a new product to death.
UX positions are usually design centric (people in these positions usually hold HCI or Design degrees). These people usually lack the engineering knowledge to be able to quickly assess the viability and cost of the solutions they propose, and therefore work very frequently with people that have complementary skills.
I am one of those types with a mixed business/engineering skillset and work in Product Management these days.
The "Product Engineer" as described in the article seems like a great position for a small company, or for a small team within a company. It's what a founding CTO would usually do at the early stages of a company.
In my experience, as companies grow, it's hard to know both the customers, the users, and the technical details in intimate detail, so the position seems slightly doomed unless the product is very technical (say, mostly an API).
That being said, broad skillsets can be a blessing when things need to move rapidly.