My Microsoft PM Internship Experience
I recently wrapped up my 12-week summer Program Manager internship with Microsoft’s Azure Frameworks team and wanted to write a bit about my experience and the lessons I’ve learned to help new PMs, Microsoft or not, navigate their new role.
As a disclaimer, my PM experience may vary from others. The PM role differs from company to company (a Microsoft “Program Manager” is like a combination of a “Technical Program Manager” and a “Product Manager”) and from team to team (in my team, I was able to drive product direction like a Product Manager and interact with engineers like a Technical Program Manager, but other teams might lean more into one or the other).
So, what does a PM do?
If you’ve religiously read through “Cracking the PM Interview” and you’re still not sure exactly what a PM does…well that was me as well. I came from a software engineering internship, where all my tasks were defined for me and I just had to hit my milestones. That was not the case starting out my PM internship because, in a sense, I had to define my own milestones.
My project this summer was to redesign a product, and I spent my first two weeks trying to figure out my job. Someone would give me one suggestion that I would follow, and then someone else would give me another suggestion that drove me in the opposite direction. And then someone would give me a suggestion I didn’t even like, and I’d go along with it! I felt like a hamster on a wheel going nowhere.
So what does a PM do? I like to describe the PM role the way my manager described it to me at the end of my first two weeks stumbling around:
A PM’s job is to make decisions and execute them.
That’s when I began to learn that people have different opinions on different things and it’s very hard to get unanimous support behind a decision — but you don’t need unanimous support. The job of a PM is to drive the project forward by making decisions as long as she has supporting evidence for why a decision is being made. This isn’t to say that you shouldn’t take input from others; just know why you are taking the input.
Design
Let’s get into what I did. Since I was redesigning a product, I had to think first about how I wanted to redesign it. I talked to team members to get some input on what they would find helpful on the product and read through some past user research studies on similar products to see what things users found helpful.
I had a designer who I directly worked with on the project, but before my meetings with her, I would usually try to sketch out some of my ideas on Figma myself just so she has a better idea of what I’m talking about. Two reasons for this: one, I personally love designing and had a lot of fun playing around with Figma, and two, this made our meetings much more efficient so we could discuss specifics on certain details or try alternate ideas before she turned my Figmas into mocks that adhere to design standards.
Prototype + Iterate on User Research Feedback
With our Figma designs, we moved to turn them into interactive prototypes. This is because we wanted to conduct some user research on the usability of our product concept and make the necessary fixes before developing it. I worked simultaneously with the design engineer and the researcher: I regularly checked in with the progress of the prototypes and worked through edge cases with the design engineer while also working with the researcher to come up with tasks we wanted users to do to test the usability of the prototypes.
The user research studies were super cool to sit through! Seeing a third party interact with the prototype gave me great insights into what we could improve on to make the experience more user-friendly, and it’s always a good ego boost hearing people compliment the product. 😊 Post-research study, we summarized the results from the studies and decided which features we wanted to incorporate into the next design iteration.
The Launch Process
Because my internship was only 12 weeks, we didn’t have time to ship the entire product. However, we did have time to develop a basic version of the product that was already a significant improvement from the existing product (I was really lucky that we were able to get to this stage — because internships are short, many PM interns don’t actually get into the production stage).
The most important takeaways here were creating the A/B test and defining the metrics I wanted to measure for success. To make an A/B test, it’s important to understand the company’s roadmap to production — it might be a good idea to first test the product on an internal platform before changing the experience for external users. I worked with my mentor and data scientists to write out queries to measure success metrics and attached these to the scorecard that my A/B experiment had.
Soft Skill Takeaways
Probably the most important part of this writeup saved for last! I mentioned that I developed a lot of soft skills this summer, so here’s a summary of some important ones.
· Ask “why”: Don’t take things with a grain of salt. This is something that set me back at the start of my internship, and this is something that I am still working on. As a PM, you’re responsible for the entire product, and that means understanding what’s going on with the product in and out. There were two times this summer where, after diving into enough “why’s” with developers, I was able to redirect the project direction.
· Communication: People communicate in different ways and part of your job is learning how to communicate effectively with the people you work with. Some people communicate better over messaging, whereas some prefer to hash things out over call. And some people you need to follow through with a couple of times to get what you want.
· Disagreements: Disagreements are natural and are not something to be afraid of. Respectfully disagreeing with someone (even if it’s a senior team member) and having strong backup data is how we can ensure that the best decisions are being made for a product. In fact, one of the most important decisions I made this summer that changed the course of my project came from disagreeing with the direction some developers wanted to head into.
So there you have it! A summary of 12 great weeks at Microsoft. I hope this helps you get a better sense of what the PM role entails, and best of luck on your PM journey!
