I think you're confusing product and engineering. I get that programmers are smart so we just assume we can do every job, but it's a waste of your time and salary to talk extensively to customers and create product requirements. Let the PM's run the user research sessions, you can find more productive things to do.

However, where we agree, is that there is more to engineering than writing code. It's problem solving. Even if the product team, the c-suite, the board, the investors, et al, are all in on a product that they believe customers want, doesn't mean the real problem of bringing that idea to life at scale has been solved.

Product should, definitely, run user research along with Product Design. But what I find is that people in either have a problem imagining a solution that's a couple of orders of magnitude easier to build, but also much easier for our customers (usually boils down to making the right choices for customers — the savings are not in the common "choose good defaults", but in actually removing flexibility that's needed only in 1% of cases).

Thus, I insist on engineering being involved early to put real world constraints on wild ideation ("it would take 3 months for 5 engineers" quickly changes what's a must-have :)) — sometimes, a curious, critical mind can expose things like these without having to do the research or user testing themselves.

Now, throughout my 20 year career, it's been very rare to find a product person who will both understand customers deeply, tie their needs to business value, and be able to formalize the intersection of these in a form of good requirements for design and engineering to eventually build!

So I really believe an engineer's (and design) role there is to serve as a sanity check as they dive into actual building — does this really make sense? If they do not, they run the risk of a project completely failing or perhaps not even shipping once someone else questions the value of continuing to invest in this 3 month project 9 months in. ;-)