Developer Instincts as a Product Manager

I've been a product manager/owner/leader in various forms over the course of my career. Sometimes I've had to code the product itself as part of my job, but not always. My more recent roles have had less coding and as someone who trained as a developer, it's been odd to not create a development environment locally as my first task in a new job - but I still do it anyway!

Being able to intuitively understand code and the difficulty of developing any particular feature as a product manager is a real gift - a gut instinct knowledge of whether a new feature will take a week, a month, or a year to develop is hard to emulate.

However, it can be very hard to focus at a high-level on product, strategy, marketing, and then jump down into a particular method in your codebase and decide whether to use a hashtable or a dictionary. In a startup, this is pretty normal (necessary?) and I feel is one of the reasons (as well as all the other financial/mental/emotional challenges) why startups are hard - you need to know a bit of everything which can get tiring after a while. On the other hand, if you want 5 years experience in just 2, join a startup!

So as I don't really code as much in my day job anymore, I am interested in keeping my skills sharp, or at least keeping my developer gut instinct intact. So a few things that I do to help with this include:

Installing the code base locally: I generally don't need to install any code locally, but I do anyway - I learned some new technologies and it also gave me a better idea of what our engineers need to do to modify the codebase. It also means I can suggest opportunities for improvements at the code or infrastructure level, based on what I've seen/used before.
Looking at the PRs/Branches: As well as reviewing a change/improvement in dev/QA environments, I also try and review the relevant code branches/PRs - not to offer suggestions but to understand the code base more. I don't want to interfere with the engineering process but it helps me with estimations of time and exposes me to good code from good engineers.
Fixing/Doing things myself: There are so many dev tools out there that it is impossible for a single engineer to know them all - so occasionally I know how to fix an issue or how to get information that engineering might not know about. Sometimes the team will do it, but sometimes I will do this myself but show the engineers while I'm doing it, which allows me to...
Mentoring (Junior) Staff - I think it's been hard for junior engineers working remotely as they may not get as much exposure to learn as before, so I make a point of doing video calls as often of them as possible when fixing issues - they get to learn and I keep my skills sharp. It can work the other way too, I'll join a call on some technology I don't know about and just listen!
Coding as a side project: This is a bit more specific to me, but I like making things, so I keep coding a little bit in my spare time.

If you're not a developer and are wondering how to develop these skills, I think that is a different/longer post, but even learning to code a little or installing your code locally to play around with could help you develop that instinct - I'll think about it some more before writing about it!