> Voila: you've re-invented product management.
This is a names vs. structure thing. For a moment, taboo the term product manager.
What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
The conventional wisdom (bad meme) is going to the labor market with a search term for people who claim to know what the users want, any user, any problem, doesn't matter. These people are usually incompetent and have never written software. Then hiring 1 and potentially more of the people that respond to the shibboleth.
If you want the first case, then you can't say "product manager" because people will automatically do the second case.
> What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
It doesn't have to be the most socially competent engineer to gather feedback. Having the engineering team sit with the target users gives so much insight into how the product is being used.
I once worked on an administrative tool at a financial institution. There were lots of pain points, as it started as a dev tool that turned into a monstrosity for the support staff. We asked to have a meeting with some reps who were literally 2 floors below us. Having the reps talk as they worked with the tool in real time over 1 hour was worth more than a year's worth of feedback that trickled in. It's one thing to solicit feedback. It's another to see how idiosyncrasies shape how products get used.