Apologies. I did a poor job of explaining myself. I completely agree that they are different disciplines. Yikes.
I'll try one more time. I guess if this were easy to explain it wouldn't be done so poorly everywhere.
By looking at the Product Manager's role in terms of componentizing responsibilities, duties, and skills -- which both the original author and the commenter did -- there is an underlying assumption that is false. That assumption is that these things you're supposed to understand and manage are discrete items. There's a factory metaphor, whether either author realizes that or not. Ideas come in from the users, bug system, and other places. The Product Manager assembles and works these ideas, identifying a MVP, breaking them down into smaller features, and so forth.
Perhaps this could be restated as such: There is a discrete set of information and processing that must be done to translate external stimulus into items ready for work (And yes, I think everybody agrees that this information changes over time, but the assumption is that you fix it in place at least long enough to go through a release cycle)
This assumption is not true. Yes, there is a discrete set of ideas that need processing, and the result looks the same -- but not only does the information change as time moves on, the developers concept of the world the user lives in changes the more they intimately interact. Now in a small team you join the team at the hip with some users and it works out. As you scale up, however, that's not an option, and it's much easier for a developer working as a Product Manager to spot where the world changed than a person trained only in management. (A developer who has no product experience in this particular startup would the same problem, by the way. You're looking to identify business model impedance mistmatches, places where we were coding for one universe we thought existed when in fact we were mistaken.)
That's not something you can somehow document or think your way out of, since so much of "the universe we thought existed" exists as invisible, implied assumptions. All you can do as an external manager is manage those things you can identify and record. When you're doing value discovery, the most important value ideas you'll find start subconsciously and then become visible.
We have this same problem in project management -- conflation of what I can see, record, and optimize with what the actual work is. In both cases, the underlying assumption of physicality and how we deal with physical problems comes into conflict with fluid, fluffy, and ephemeral way that humans actually think about and work through problems. This is not a problem in a ton of other areas where there actually is physicality, like hardware-only product development, where the cycle times are long. (Or at least not in the same way). But it is when you're doing traditional software-heavy product management.
Hope that helps. It was on-topic. It's just a difficult thing to write about in a simple way. Thanks for the feedback.
ADD: One of the things that makes this so difficult is the amount of invisible and many times unacknowledged work that happens. So you could ask a successful founder/Product Manager what their job and responsibilities were, and you'd get a list just like the one provided. Go out and try to execute on that list, though, and you'd screw it up.