The Microsoft Program Manager role doesn't know what it wants to be

I have now been a Program Manager in two pretty different parts of Windows, and I am still not totally sure what a Microsoft PM is supposed to be. I started in WDG under Storage and Filesystems, working on Consumer Storage, and later moved to Universal Store where I work on in-OS user acquisition through things like the lock screen, Start menu, and Action Center. Same title, very different job.

The easiest way I can describe the role is half product manager, half technical program manager, with a little engineering sprinkled in. The problem is that the percentages change depending on where you sit. In Storage and Filesystems, being technically credible mattered a lot because the product was technical by definition. I spent a lot of time understanding system behavior, working through requirements and dependencies with engineers, writing specs, and trying to make sure we were solving the right thing without accidentally creating a mess somewhere else in Windows. I was not an engineer on the team, but it would have been pretty hard to do the job well while treating the implementation as a black box.

Universal Store feels much closer to what other companies might call product management. A lot of the work is about user behavior, surfaces, acquisition, UX, experiments, and figuring out how to get people to discover something inside Windows without making the OS obnoxious. There is still a big execution and coordination component, and you still need to understand what engineering can actually build, but the questions are much more about the user and the outcome than about the underlying system.

I actually like that the role is broad. It is probably one of the reasons I wanted to do it in the first place. You can move between deeply technical work and product work without changing job families, and you get to learn a ridiculous amount because PMs sit in the middle of engineering, design, business, and whatever partner teams happen to be involved. The weird part is that I don't think Microsoft has a particularly consistent answer for how to tell whether someone is good at it.

On one team, success can look like shipping a complicated program across several dependencies without surprises. On another, it can mean moving an adoption metric. Somewhere else it might be writing unusually good specs, finding the right customer problem, keeping a giant cross-team effort moving, or being technical enough to challenge an engineering plan. All of those are reasonable things to value, but they are not the same skill.

That makes career development kind of confusing, especially when you are junior. If I ask, "what should I get much better at over the next two years?" the answer depends a lot on who my manager is and what team I happen to be on. One manager can care a lot about execution and detail. Another can care more about product instinct. Another might put a lot of weight on technical depth or how well you influence partner teams. You can be called a Program Manager in all three cases.

It also makes the title almost useless outside Microsoft. "Program Manager" usually sounds like someone who runs schedules and dependencies. "Product Manager" sounds like someone who owns a product direction and its outcomes. A TPM is expected to be technical and execution-heavy. Microsoft PMs can be all of those people, sometimes in the same week, which is interesting until you try to explain your job to anyone else.

I don't think the answer is to make every PM job identical. Consumer Storage and in-OS user acquisition obviously should not require the exact same strengths. But I do think a profession needs a clearer center of gravity than "whatever this particular team needs the PM to do." There should be a reasonably consistent answer to what excellent looks like, even if the domain changes.

Maybe the Microsoft version of Program Manager is really just a home for generalists who are comfortable moving between product, engineering, and execution. If that is the idea, I actually like it. I just wish we were more explicit about it, because right now the role seems to have an identity crisis and everyone mostly learns what being a PM means from the team they happen to land on.