The simplest example of this: as a programmer, when your boss says to code a feature, you code it. But as a PM, you have to get a team to make it.
A PM's job is to figure out what the feature really is, and how complex or configurable it should be, and what the target audience is, and how you'll measure success. It also involves making sure that you feature works well with other features, and that your team is moving in the same direction as the rest of your company.
Be prepared, BTW, for the constant assumption that you became a PM because you couldn't hack it :-)
When talking about a feature, am I doing basically high level system design? Similar to what a senior engineer does (aka this should be a cache, it’s best to change this to streaming so let’s remove the audit db, etc) or is it even more high level than that?
Also lol at the last line, never heard that but I can see why people might make the assumption.
No, you aren't doing that kind of high-level design. For example, I was the PM for the "connect to Wi-Fi via a QR code" feature in Windows (you're welcome!). As PM, my job was to :
- demonstrate that this was "thing" people would want to do - demonstrate that it slotted into the existing feature set (the existing Windows camera already reads QR codes, so we just had to use their existing hoooks) - do a quick evaluation of the WIFI: protocol (which, BTW, sucks; it's one of the worst standards I've ever seen) - do an evaluation of the overall market (like, what do other operating systems do)
There was also some discussions with the Windows Wi-Fi team for how to store the connection data since it wasn't a perfect fit for the our existing connection store, plus a security evaluation. You won't do anything about caches or streaming except that they will naturally fall out of your spec.
You'll learn a ton about writing convincing documents, how to find users and partners, tracking schedules, and stuff
I think technical PMs are well suited to absorb this. Ideally, they're already comfortable with specifying software, communicating about requirements, recognizing and avoiding failure modes, etc. So that's one route, but not one that particularly appeals to me.
The things that I find interesting largely haven't changed. I'm interested in complex systems, distributed or not. I'm interested in organizational dynamics. I'm interested in game theory and mechanism design. I'm interested in simulations, machine learning, and GOFAI. I'm hoping that I can find a way to turn these interests into a new career. I can continue learning and growing, I can challenge myself, I can expand at whatever speed I can manage, and I can develop and deliver working software at a greater pace than I've previously been able to manage.
I'm definitely afraid. I don't know how to just create a career from a vague collection of things I like thinking about, to just go out there and make money and support my family. I don't know how to "operationalize" these ideas. But that's what I'm trying to do, FWIW.
At least, that's what we PMs were told when Microsoft Windows rejiggered their PM roles