Then, once you have sorted out your own opinions, go read up on what everyone else does. Learn from it and modify your worldview based on what you learn. Learn how the non-tech aspects of the job play into the role of PM, and read books and take courses on those things. And again, synthesize it into your own ideal.
The thing is that PMs who read books, blogs, listen to podcasts and do what they all say are a dime a dozen. But PMs who truly understand the creation of software and are willing to break out of the mold to create their own world... not only do we need more of such people, but startups in particular need someone with the personality to buck the system and do what is actually needed.
Going through that exercise is also good practice for the role. PMs need to hear a plethora of opinions, sort out which ones make sense, which ones do not, and devise solutions that meet diverse needs in the best way. Being overloaded with info and sifting the good from the bad is the key skill to do all that. So practice exactly that as you learn.
yes yes yes
> on how to build an ideal workflow
no no no. Workflow and process is the least important part by far.
> what your ideal team/org/process structure looks like.
no no no. waste of time.
> PMs who truly understand the creation of software
We're solving customer problems, the creation of software is a side effect for engineering to worry about, this is the 'how', your effort must be focused on the 'why' and the 'what'.
It's pretty shocking you don't mention understanding customers once in this advice.
It is not your job to sweat this stuff. The best PMs are adaptable to the business, and develop a thesis based on customer discovery, about how your business can add value to customers. Then you convince the business to build what your think can give value, aligned with your product vision and product strategy.
Hopefully those opinions you have are about your customers and the problems they have.
The ingredients of good PM are not processes and workflows, but product sense, design taste, and customer empathy.
Product discovery is the single most important activity you can do as a PM (that others do not do or don't want to do).
Remember that my answer was not "How to be a PM", it was "how to transition from dev to PM". We are talking about a dev wanting to make a change. You lose all the value of past experience if you tell them to just go be the standard PM. That is my bigger point - not to ignore the customer, but to use their existing knowledge to do it all, and to do it better. To be someone whom the customer will trust and whom the team will follow. To make the experience of building the product as important as the experience of using the product, resulting in the mythical "high-performing team" who is able to deliver the product vision that yes, you also will come up with.
Both sides matter. Neither can exist without the other. And someone who has 15 years of building experience can be amazing at the side that most PMs neglect, driving their delivery teams into the dystopian scrum-hell with which we all are too familiar. So while your points do have merit, they miss the uncommon opportunity of an engineer's skills being applied to the whole picture.
Think less about what they will be in 10 years, and more about what they can be great at in 10 weeks. That is why I focused on what I did.
The people hit hardest by the contractions in tech tend to be PMs. While the best PMs can be incredibly helpful the average PM, in my experience, takes away from a projects probability of success.
If you want to be doing more product work, simply be more proactive in discussions involving product. If you have good product sense you'll naturally find that you spend more and more time making product decisions (most engineers don't want to do this anyway).
Another path to go is founding engineer. If you happen to be employee 1-3 and you choose to aggressively be involved in product decisions you'll find you quickly climb the ladder in small orgs and get a say in product decision. As the company grows you'll naturally find yourself in a role that has a lot of say in the way product is developed.
