[ThalesX]

All the startups I have worked with in the recent years have had a product person. It was a full time job that was mostly focused on the customers and how to deliver value within the constraints given by engineering and business.

Product development should be done on process I think, not on superstar product engineers.

I think the role is new, misunderstood, but I believe throwing bullet points is maybe not the way.

What I’m arguing against mostly is this focus on the person instead of the process and the push that someone can be a master of all those domains of knowledge (as in this article).

I wrote some (mean) thoughts as I was going through the article which I will answer now to the OP post where he answers my question if you are curious to check it out.

[Hermitian909]

I'm currently a product/engineer person on a team that has a fulltime product person. The split works well and I don't think it requires me to be a superstar in any way.

I sit in on a lot of meetings, talk to users, etc. and I program enough to know the ins and outs of our codebase. This means when wireframes are being put together I can say "well, that one will take 3 months longer" before anyone can get invested, clarify ambiguity I know the programmers will struggle with, and better translate user requirements to technical ones.

At a high level I'd say I'm sort of a liaison between two very different groups of people with very different realms of expertise. There's a lot of "translation" that necessary for that but anyone who's middling in both fields should be able to perform in the role.

[andreigheorghe]

You expect a (good) product manager to be reasonably technically competent so that they can carry a conversation with business/customers without having to go back to engineering every time to ask "Is this possible?".

Similarly, you can expect a software engineer to be somewhat product competent so they can push back on bad ideas, proactively suggest better ways of doing things, and even connect the business dots and propose entire classes of new features that the PM maybe didn't even realise were possible / within reach.

It's not two roles in one, it's not working 16 hours / day, it's just having the right mix of experience and intuition such that you're still primarily an engineer but you help guide the product.