I can't think of a worse time to transition to being a PM. In the old days most engineering teams PM'd their own work, and the role of PM grew into prominence as companies started hiring without care as part of a general strategy of growth (combined with a desire to reduce the power of engineering teams).

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.

As someone who did make that transition, I wouldn't recommend consuming any content to start. You have been a dev. If you want to be a PM, you should already have opinions on how to build an ideal workflow, what kind of information the devs need, and what your ideal setup would be. Go write up your own PM manifesto of what your ideal team/org/process structure looks like.

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.

The easiest way to jump into product is to be a very product focused engineer and make an internal transfer. I’ve been offered such a transfer because stakeholders knew me and that I was thinking about these things in depth. This overcomes challenges around trust and credentials you have cold applying with no prior experience in the role.

I’d recommend listening to Lenny’s podcast.