My Experience As A Microsoft Product Manager: A Deep Dive

Disclosure: This post might contain affiliate links. If you click through and make a purchase, I’ll earn a commission, at no additional cost to you. Read my full disclosure here.

Embarking on a journey as a Microsoft Product Manager has been a transformative experience, full of challenges, learning, and immense personal and professional growth. Over the course of many years, I navigated through diverse roles within the company, contributing to the evolution of flagship products like Windows, Azure, and Skype. Each of these roles offered unique insights, learning opportunities, and the chance to impact millions of users worldwide.

In this blog post, I aim to provide a deep dive into my experiences, sharing the nuances of working as a Product Manager at one of the world’s leading tech giants. Whether you’re an aspiring product manager, a seasoned professional, or simply curious about the world of product management at Microsoft, this post is crafted to give you an insider’s perspective.

If you are interested in following my career path, then you can also look at my other posts:

• My Experience As A Microsoft Software Engineer: A Deep Dive
• My Experience As An Amazon Product Manager: A Deep Dive
• My Experience As A Google Technical Program Manager: Full Story
• Google vs Amazon vs Microsoft PM Roles: A Deep Dive
• Inside the Culture of the Top Tech Companies
• Salaries for Software Engineers are On FIRE!

History of the PM Role at Microsoft

Microsoft was the first company that introduced the PM role in 1984 when Office for Mac was being developed. At the time, Microsoft, as well as all other software companies, employed developers, testers, and marketers. Developers would build software, testers would test it and marketers were responsible for generating demand for the product. However, there was a crucial role missing, which was the input from the customer. That’s why Microsoft created the PM role, which was called Program Manager at the time.

Based on the book One Strategy: Organization, Planning and Decision Making by Steven Sinofsky, the first PM at Microsoft was a college hire named Jabe. He initially worked as a designer for Excel for Macintosh and then transitioned into Program Management. The goal of his new role was to be the link between users and the engineering team. He would partner with the development team and work through the entire product cycle as the advocate for end-users and customers. They needed to have both technical acumen and to understand the product in depth.

As time went by, Microsoft found lots of value in this new role and hired more Program Managers. Other companies also saw the trend and made the role and industry standard. However, as the role became more mature, several other companies figured out that it encompasses 2 very different functions:

• The business owner of the product, i.e. making the business case, understanding customer needs, defining how customers will use the product, etc. This eventually became the role of the Product Manager
• The person responsible for the execution, i.e. developing the project plan, communicating with stakeholders, tracking risks and dependencies, etc. This eventually became the role of the Technical Program Manager

If you are interested in learning more about the Product Manager (PM) and the Technical Program Manager (TPM) roles, as well as their differences, take a look at my post What are the differences between Product Managers, Program Managers, Engineering Managers and Marketing Managers?

Several other companies, such as Google, Facebook, and Amazon decided to have these 2 roles. However, for many years Microsoft insisted on having one role: the Program Manager. As a result, Microsoft Program Managers would have to work on both tasks. Depending on the type and maturity of the product that they were working on, the stage in the development cycle, and the needs of their team, Microsoft Program Managers would sometimes be working more closely as Product Managers and sometimes more closely as Technical Program Managers.

In mid-2023, Microsoft decided to align the Microsoft Program Manager role with the rest of the industry. The existing Program Managers were split into 2 new tracks: Product Managers and Technical Program Managers. In most teams, it was up to the Director to determine which people on their team would be assigned to each new track, based on their strengths and job functionality. Sometimes, individuals also had a say in this switch.

At this point, this split is official and there are different positions, as well as career paths for both roles. Most employee titles have been switched, but not everybody has. New open positions are being tagged based on the functionality. The goal is to complete the transition soon so that Microsoft aligns with the rest of the industry.

The Microsoft Product Manager Interview

I’ve done multiple interviews for Microsoft PM positions:

• As an external candidate when I transferred from Amazon to Microsoft
• As an internal candidate, when I transferred from Windows to Azure and Skype
• As an interviewer

In this section, I will try to provide an overview of the interview from the perspective of the candidate. I have a section further below, where I provide my insights as an interviewer.

The structure of the Microsoft Product Manager interview is similar to that of the Microsoft Software Engineer interview:

• Number of interviews
  • For external candidates: The first round is a phone screen with the recruiter. If you pass this round, then you come onsite to Redmond for the second round. The first interview is again a behavioral interview with a recruiter. The loop consists of 5 additional interviews. At the beginning of the loop, you only know the contact information of your first 3 interviewers and if you perform well enough, you proceed to the remaining interviews.
  • For internal candidates: There are no interviews with the recruiter. There are 3-4 interviews, all of which take place on campus. It’s important to note that in order to change teams at Microsoft, you still have to go through a full interview loop and that the hiring bar is similar to that of external candidates.
• Interviewers exchange information with each other, as they pass the candidate to the next person. That’s why it’s important to have a great first interview
• The last interviewer is called the As Appropriate (aka AA). They are the ones, who make the final decision for the offer. They are above the Hiring Manager in the org hierarchy. For example, they might be a Senior Director, whereas the Hiring Manager could be a PM Manager.
• Apart from the AA, the remaining 3-4 interviewers are Product Managers and Software Engineers
  • Technical Interviews: Software Engineers test technical ability. They might ask the candidate to write code, test it, or even design a feature. Microsoft is one of the few remaining companies, which has a technical interview for Product Managers.
  • Product/Program Interviews: Product Managers will ask both Product Manager questions (e.g. Product Sense, Metrics, etc), as well as Program Manager questions (e.g. create the project plan, make tradeoffs during execution, etc). This is very different than all other companies, where the Product Manager candidates only go through Product Manager questions
• For example, a typical loop for a Microsoft Product Manager position could consist of the following:
  • A Software Engineer asking coding or system design questions
  • A Product Manager asking Product Sense questions
  • A Product Manager asking Project Management questions
  • A Product Manager asking behavioral questions
  • The AA asking specific probing questions, in order to address feedback from the previous interviews

For more information about preparation for the Microsoft Product Manager interview, take a look at my blog posts How to Prepare for Product Manager (PM) Interviews and How to Prepare for Technical Program Manager (TPM) Interviews.

What Does A Microsoft Product Manager Do?

When I was transferred from an Amazon Product Manager position to a Microsoft Product Manager position, I was initially confused by my role. My title at the time was “Program Manager”, but I was asked mostly asked to do Product Management tasks. On top of that, there were a lot of project management tasks, which were handled by the Technical Program Manager at Amazon.

What helped me clarify everything was a short internal document titled “Zen of PM”. It was succinct, and clear and gave me lots of value. Fortunately, this valuable document is still available online via the Internet Archive. So, in the section below, I will try to summarize it and give some additional color, based on my own experiences. However, I do recommend that you read the whole text. It is definitely worth it.

Without further delay: The Zen of PM!

The Zen Of PM

Crafting and Upholding the Product’s Core Value

A Microsoft PM is essentially the custodian of the product’s value proposition. This role demands a profound understanding of customer needs, market dynamics, technological advancements, and the strategic priorities of the business. The PM serves as the compass, guiding the team with clarity and precision, ensuring that every decision and action aligns with the product’s intrinsic value.

• Customer Advocacy: The PM stands in the shoes of the customer, relentlessly advocating for their needs and expectations. They are the voice of the customer within the team, ensuring that the product not only meets but anticipates customer requirements.
• Strategic Alignment: The PM ensures that the product’s trajectory is in sync with the broader business strategy and objectives. They navigate through complexities, making strategic choices that balance short-term gains with long-term vision.

Bridging the Gap: From Vision to Reality

The PM plays a critical role in transforming the product vision into a tangible reality. This journey is marked by meticulous planning, thoughtful design, and rigorous execution.

• Planning: The PM sifts through vast amounts of information, identifying what is crucial and what can be set aside. They set the stage, defining clear objectives and laying out a roadmap for the product’s journey.
• Design: In this phase, the PM takes charge of defining the solution. They engage in iterative design processes, ensuring that every design decision is well-considered and aligns with the product’s value proposition.
• Execution: The PM’s role becomes even more hands-on, as they ensure that the product being developed aligns with the set objectives and meets customer expectations. They validate the product with customers, adjust plans based on feedback, and make critical decisions under pressure.

Debunking Common Misconceptions

It is imperative to clear up some common misconceptions about the PM role at Microsoft. PMs are not just facilitators or coordinators; they are integral members of the product development team. They play a key role in shaping the software, advocating for the customer, and ensuring that the product delivers on its value proposition.

• More Than a Facilitator: PMs are not just there to schedule meetings or take notes. They are involved in the nitty-gritty of product development, from conceptualization to delivery.
• Beyond Evangelism: While PMs do play a role in evangelizing the product, their responsibilities extend far beyond. They are involved in design, planning, execution, and validation of the product.

In conclusion, the role of a Microsoft Product Manager is intricate, challenging, and immensely rewarding. It requires a unique blend of skills, a deep understanding of the product and the customer, and the ability to navigate through various phases of product development. The PM is a champion of the value proposition, a bridge between vision and reality, and a guardian of the product’s integrity, ensuring that it delivers on its promises and exceeds customer expectations.

Microsoft vs Amazon vs Google Product Management Experience

The role of a Product Manager (PM) varies significantly across the tech giants, each bringing its unique culture, expectations, and operational dynamics to the table. Having worked at Google, Amazon, and Microsoft, I would like to provide a quick firsthand comparison of the PM roles at these companies, focusing on responsibilities, culture, and compensation. For a deep dive into the differences between the Product Manager role in these companies, you can read my post titled Google vs Amazon vs Microsoft PM Roles: A Deep Dive

Google: The Engineer’s Playground

At Google, the PM role is deeply intertwined with engineering. PMs need to have strong technical backgrounds and the ability to advocate their vision to the engineering team, as engineers hold significant sway in decision-making. The culture is vibrant, with numerous perks and the total compensation is generous, though not the highest in the industry. Work-life balance is decent on average but can vary depending on the project. The hiring process at Google leans more towards technical evaluation compared to Amazon.

Amazon: The Customer-Centric Dynamo

Amazon PMs operate in a top-down, PM-driven environment, with a strong emphasis on data and customer insights. Every product decision is backed by rigorous data analysis, and PMs are expected to present data-backed narratives and KPI evaluations in weekly business reviews. The environment is high-pressure, with heightened expectations and a notable presence of Performance Improvement Plans (PIPs). However, this also means there are rapid growth opportunities for those who can navigate the system effectively. The relationship with one’s manager plays a significant role in a PM’s journey at Amazon.

Microsoft: The Hybrid Landscape

The PM role at Microsoft is a blend of a Product Manager and a Technical Program Manager, involving a variety of tasks from strategizing product direction to handling technical issues. The balance of responsibilities varies depending on the team and product. Microsoft is known for its work-life balance and has embraced a culture of innovation, inclusivity, and collaboration under Satya Nadella’s leadership. While the compensation might be lower compared to other tech giants, the average working hours are also less.

Comparative Overview

• Compensation: Google offers the highest total compensation, followed by Amazon and Microsoft.
• Work-life Balance: Google and Microsoft score high, while Amazon, has a much more demanding environment.
• Culture: Google and Microsoft have more collaborative and inclusive cultures, while Amazon has a data-driven and high-pressure environment.
• Product Lifecycle and Scope: Microsoft tends to have longer product lifecycles with a focus on comprehensive solutions and integration across products. Amazon prefers quicker iterations and rapid product evolution, while Google balances between long-term innovative projects and iterative development.
• Resource Allocation and Autonomy: Product Managers at Microsoft enjoy substantial resources and structured product development, while Amazon focuses on frugality, expecting PMs to act as mini-CEOs of their products. Google provides a balance, with access to extensive technical resources and a culture that encourages innovation.
• Learning and Development: All three companies are deeply invested in employee development but offer different paths. Microsoft has a wealth of training and mentorship programs. Amazon has no training or mentorship, as the fast-paced environment is well-suited for learning-by-doing. Google offers the chance to work on cutting-edge technologies and innovative projects.
• Decision-Making and Risk-Taking: Amazon’s bias for action encourages rapid decision-making, while Microsoft’s collaborative environment might involve more stakeholders in the decision-making process. Google, with its emphasis on innovation, encourages risk-taking and exploring uncharted territories.

In conclusion, the PM roles at Google, Amazon, and Microsoft each have their unique characteristics, shaped by the companies’ cultures and business philosophies. Aspiring PMs should consider these nuances when contemplating a career move or seeking to understand the PM landscape in these tech giants. The key is to find the fit that aligns with one’s career aspirations, work-life balance preferences, and individual strengths.

Windows vs Azure vs Skype Product Management Experience

During my tenure at Microsoft, I had the unique opportunity to work as a Product Manager across three different divisions: Windows, Azure, and Skype. Each of these departments offered a different flavor of product management, shaped by their respective product nature, market positioning, and internal culture.

Windows: Legacy, Integration, and Broad User Base

Working on Windows was akin to steering a giant ship. With its long-standing legacy, broad user base, and deep integration into the Microsoft ecosystem, product management here required a keen understanding of diverse user needs and a meticulous approach to feature integration. The pace was steady, with a strong emphasis on stability, security, and user experience consistency. Innovation had to be balanced with maintaining the reliability that millions of users had come to expect.

Azure: Fast-Paced, Technical, and Enterprise-Focused

Transitioning to Azure presented a different set of challenges and pace. The cloud computing realm is fast-evolving, and Azure was at the forefront, competing neck-and-neck with other cloud giants. Product management in Azure demanded a strong technical acumen, as I was working on products and services catering to developers and enterprises. The pace was rapid, with a continuous stream of new features and improvements being rolled out. The focus was on innovation, scalability, and ensuring robustness to handle the demands of enterprise clients.

Skype: Communication, Consumer-Centric, and Innovation-Driven

Skype, being a consumer-centric communication tool, offered a different product management experience. The focus was on user experience, ease of use, and introducing innovative features that stood out in the competitive communication tools market. The pace was fast, and agility was key, as we aimed to quickly iterate on features based on user feedback and market trends. There was a strong emphasis on cross-platform consistency and ensuring a seamless communication experience for users globally.

Comparative Analysis

User Base and Market Positioning

• Windows catered to a vast and diverse user base, requiring a balanced and stable product management approach
• Azure targeted developers and enterprises, demanding technical depth and a focus on scalability
• Skype, with its consumer focus, required agility and constant innovation to stay competitive.

Pace and Innovation

• Windows had a steady and calculated pace. The team focused on stability and integration.
• Azure and Skype demanded rapid iterations and a quick response to market changes. Innovation was a key driver.

Technical Depth and Cross-Functionality

• Windows demanded a holistic view of the ecosystem and integration points.
• Azure required the deepest technical understanding, given its developer and enterprise focus.
• Skype required a strong focus on user experience and cross-platform functionality.

Memorable Moments

In this section, I will present some of my memorable moments while working in Windows, Azure, and Skype, in order to give you a better idea of the Microsoft Product Manager role.

Windows

Having An Amazing Manager

Most of my managers have been good or great (although there are some notable exceptions). However, I was really fortunate to have an amazing manager, when I joined Windows as a Product Manager. My manager had very high emotional intelligence (EQ), cared for her team, and knew the product very well. She was very well respected by her manager, the partner teams, and her peers. She was always helping the team bond. And we, her team, would have more fun with her present, than with her absent. I could go on and on, but I am very grateful for the experience of having an amazing manager.

I realized that she would be a different manager than my previous ones during my interview process for her team. At the end of the interview, I asked one of my favorite questions, which is “What type of people are you looking to hire?”. At that time I was really used to hearing something along the lines of Amazon’s Leadership Principles, e.g. someone that has a bias for action or thinks big or pays attention to detail, etc. However, her answer surprised me. She answered, “I want to hire people that I can happily work with”. And in hindsight, that’s what she did. She hired people, who would make a great team.

I remember a particular example where I had an email exchange with a lead from a different team. She was on the thread. At some point, she called me to her office and told me that I was making the other person nervous with my responses. She was reading between the lines, much further than I could. And she pointed out specific points in my responses and his responses that showed that she was right. She asked me to talk to the other manager in person. I followed her advice, we sorted things out and then that person gave feedback to my manager saying how astute and sharp I was. Little did he know that I owed this great feedback to my manager.

On another occasion, we were together in a meeting. I had a feeling that the presenter could have prepared better. At the end of the meeting, she asked me what I thought. After that, she told me that the meeting had gone really horribly for the presenter, based on the reactions of the leadership team in the room. She gave me specific examples about how she would read the audience after some main points of the presentation. Getting this type of mentoring from such an exceptional manager is always a learning point.

Building Technical Credibility

As a former Software Engineer, I am a very technical person. I enjoy working on complicated technical issues and this helps me be close with the engineering team. I have found that it is very helpful in my collaboration with the Software Engineers to prove my technical credibility early, in order to establish a closer bond with them.

When I joined the team, I asked the Architect to give me a detailed overview of the system design. We used the whiteboard, where he created architectural diagrams. I kept notes and asked detailed questions. Moving on, I observed that he would have to repeat this process anytime that we had to discuss the design of the system. Then it hit me that the architecture was not documented. Speaking with the Software Engineers in the team, they all knew their area in depth, but not how it connected with the rest of the system. The Architect was the only one, who knew the overall design, but he also had areas, where his knowledge was not very detailed.

So, I decided to create a very detailed architectural diagram. I sat down with the architect and we created the first high-level draft. Then I went to each engineer and we dived deep into their component. I made sure to clarify any open questions about how each module communicated with the others, as well as the main interfaces. After several days and multiple iterations, I created a really detailed architectural diagram that surprised even the architect. Many engineers congratulated me because it was the first time that they had such a detailed view of the whole system. And I felt so nice when I saw that almost all of them had printed copies of my diagram and referred to it very often.

At that time, I became the go-to person for every system design question in the team. It felt a little strange, but apart from the architect, I was the only one who had such a holistic detailed understanding. Since then, when I join a new team I try to do something similar, in order not only to understand the design of the system but also to gain technical credibility with the engineering team.

Collaborating With External Partners

One of my favorite experiences from my role in Windows was my close collaboration with many of the top H/W and S/W partners, such as Intel, AMD, Qualcomm, Dell, HP, etc. I got an inside view of the different levels of support that are provided to each partner, learned the key players and navigated the Windows Ecosystem.

I remember one time, where we were close to releasing a new version of Windows, but one vendor was still having lots of issues. This affected performance in my area. Communication was too slow, so I invited them to Redmond. We worked closely for several days and managed to fix their bugs. In the end, based on different reliability tests they managed to score much higher than any other vendor.

Azure

Creating Azure’s Online Training Programs

In my role at Azure, I recognized a crucial need to modernize our approach to training partners and developers. Traditionally reliant on in-person presentations, I initiated a shift towards online classes, aiming for a more scalable and accessible learning experience. I meticulously collaborated with a group of internal and external partners to design a series of user-friendly online classes, covering a broad spectrum of topics to cater to diverse learning needs.

A cornerstone of this project was the collaborative class where all the Product Managers on our team contributed, each presenting their specific area of expertise. This approach not only enriched the content but also showcased the collective knowledge and skills of our team, fostering a sense of community and shared purpose.

In addition to leveraging internal resources, I also engaged with external vendors to create multiple classes, further diversifying the learning materials available. These collaborations were instrumental in bringing in fresh perspectives and expertise, ensuring that our online classes were not just a replication of our in-person training, but a significant enhancement. Through this innovative project, we successfully transformed the way we trained and supported our partners and developers

Organizing a Hackathon

During a significant Microsoft conference, I took on the exciting challenge of organizing an Azure Hackathon, bringing together 100 developers for a day of creativity and collaboration. Partnering with a specific vendor, we provided extensive training materials, ensuring all participants were well-prepared to harness the full potential of Azure’s technology. The training was a combination of learning and excitement, setting the stage for the innovation to come.

When the training finished, we set the developers free to put their new skills to the test. For an entire day, they worked tirelessly, brainstorming and coding to create a variety of solutions using Azure. As a judge, I was immersed in this hive of activity, marveling at the creativity and dedication on display.

The Hackathon culminated in a showcase of impressive projects, each demonstrating the unique talents and ingenuity of the developers. In just 24 hours, they had transformed their ideas into reality, utilizing Azure in ways that were both inspiring and innovative. This experience was not only a highlight of my time at Azure but also a powerful reminder of the incredible potential that lies in collaboration and the application of technology.

Knowing Your Customer

At Azure, we prioritize connecting with our high-profile clients through an exclusive program. Here, executives from global corporations visit our Redmond campus to explore Azure’s technological offerings. Product Managers, representing each Azure product, lead these sessions, showcasing our capabilities and addressing executive queries. The aim is to illuminate the benefits of Azure and inspire its potential integration into their businesses.

One standout session involved my manager presenting to the CTO of a leading retail company. He brought me along for this invaluable experience. Instead of relying on our standard deck, my manager adeptly tailored the presentation to the retailer’s unique needs. He seamlessly translated Azure’s technical features into strategic opportunities for the company, exhibiting unmatched executive presence and communication finesse. The executives were really impressed by the level of thought in his deck.

This experience was a profound lesson for me. It emphasized not just product knowledge but also the art of customizing communication for the audience. Azure’s commitment to going beyond generic pitches and forging meaningful connections was evident, setting a benchmark for client engagement excellence.

Skype

Collaborating With a H/W partner

My main project while working at Skype was to launch Skype on a specific H/W. This was a very different project than anything that the Skype team had done before, as Microsoft did not own the H/W or the User Experience in that platform. Instead, the H/W partner owned the interaction with the user, defined the programming model, and provided information about the H/W. This partner is the leading vendor in the particular H/W space, so this project was high priority.

I got a first-hand view of how these inter-company collaborations work. In this case, each company was very adamant about keeping control of its own data. Microsoft did not want to share more information than was needed about Skype, whereas the other company did not want to share anything with Microsoft. Yet, we had to make things work. In the end, we defined a communication endpoint between the two architectures. Each company would own the call up to that endpoint. And no data would be passed to the other side. So, each company would have to debug the Skype calls only from their own subset of data. This made things tricky, however in the end we managed to make it work.

However, apart from the technical challenges in this interaction, we also had business challenges to solve. Each company had different priorities, so we had to create a contract. Everything that we cared for, such as timelines, data sharing and usage, privacy information, etc would have to be clearly written in the contract. If something was not in the contract, then it meant that we gave permission to the other party to do as they wanted. As you can imagine, it took several weeks to finalize the contract. We had lengthy discussions for days over each line of the contract. Lots of pressure and compromises from both sides. It was such a relief when we finally signed the contract and moved on.

Working As A Startup Inside Microsoft

One of the unique advantages of my role at Skype was that since my main project was to integrate Skype on a particular H/W platform, we were independent from the rest of the Skype development. We were working with the H/W partner to build a new Skype client for their platform, which meant that we did not need to make any changes to the existing Skype clients for Windows, Android and iOS. Instead, we needed to make sure that we allow interoperability, i.e. Skype calls between a Windows client and the H/W client.

This difference meant that we were free to operate as a team and to define our own timelines and processes, separate from the rest of Skype. In essence, we were a small startup inside the big Skype org. Of course, we had to share our goals and timelines with the rest of the Skype team, but we had much more independence than any other team within Skype.

The downside to the above is that some members of the leadership team felt that we were allowed to be too lose and we needed to be controlled more. I remember a particular review meeting, where one such member wanted to make the point to the rest of the team that we had not been following a particular process and therefore, we had to change things going forward. As we were getting hammered during the meeting, my manager asked if the rest of the teams were all following this process. Immediately the pressure shifted, as they admitted that this is not a very common process that is followed within Skype. And just like that, we were free again!

Unlocking Knowledge By Being An Interviewer

During my tenure at Microsoft, I offered to do a lot of interviews. I wanted to do this both in order to help Microsoft find better candidates and also to understand what differentiates the candidates who get the offer and those who don’t. Fortunately, my manager at Skype liked my interviewing style, so he assigned me a lot of interviews, which gave me lots of valuable lessons.

I really enjoyed asking Product Sense questions, so I got my expertise in that area. My main question was a very simple one: “How would you improve Skype?”. Skype as a product is definitely not perfect, so there was a lot of room for experienced candidates to shine. Based on the answers that I got, I would like to share the following tips:

• Know the product: I think that it goes without saying that if you are interviewing for a particular product, you need to know how to use it. This way you can answer any related questions that come up. You can’t imagine my surprise when some candidates told me that they don’t use Skype. Almost impossible to get an offer this way
• Structure your answer: Many candidates, after hearing the question, would just start listing solutions without thinking if they would move the needle at Skype or whether Skype customers would be interested in using it. Not having a framework for Product Sense questions makes the interviewer think that you wouldn’t know how to improve a real product as a Product Manager. Which leads to an easy rejection.
• Be creative: If a candidate was using Skype and had a structured way to phrase their answer, they would really differentiate themselves from the pack. To be honest, I considered this to be a low bar. I am not sure, if this was due to the candidates at Skype or whether this is universal. The only remaining question in my mind, in order to mark them as “Hire” was whether their final solution would be creative. For example, would they just suggest that we integrate Skype with another product? Or that we build something completely new that would amaze users? I would definitely vote for the candidates, who strive to amaze users.

If you want to understand more about how to properly answer Product Sense questions, take a look at my post Differentiate Your Answers to Product Sense Interview Questions

Compensation and Career Progression

Career Progression for a Microsoft Product Manager

As I wrote above, Microsoft’s PM role initially stood for Program Manager. However, in 2023 the role was aligned with aligned with industry standards by being split into Product Manager and Technical Program Manager. Program Manager Directors in each org decided which track their Program Manager teams would get into. Both roles have the same compensation bands, so there is no compensation difference between the two

The following matrix shows the career progression, focusing on levels and titles.

LEVEL	OLD TITLE	PRODUCT MANAGER TRACK	TECHNICAL PROGRAM MANAGER TRACK
59	Program Manager	Product Manager	Technical Program Manager
60	Program Manager	Product Manager	Technical Program Manager
61	Program Manager 2	Product Manager 2	Technical Program Manager 2
62	Program Manager 2	Product Manager 2	Technical Program Manager 2
63	Senior Program Manager	Senior Product Manager	Senior Technical Program Manager
64	Senior Program Manager	Senior Software Engineer	Senior Technical Program Manager
65	Principal Program Manager	Principal Product Manager	Principal Technical Program Manager
66	Principal Program Manager	Principal Product Manager	Principal Technical Program Manager
67	Principal Program Manager	Principal Product Manager	Principal Technical Program Manager
68	Partner Program Manager	Partner Product Manager	Partner Technical Program Manager
69	Partner Program Manager	Partner Product Manager	Partner Technical Program Manager

At Microsoft, a promotion goes from one level to the next one, e.g. from level 61 to level 62. Based on the above matrix, it is obvious that a promotion might not correspond to a title change.

Salary of a Microsoft Product Manager

The best public database for salaries in high-tech companies is provided by Levels.fyi. This website uses data from actual job offers, in order to publicize the compensation across different levels for lots of high-tech companies.

Here is a screenshot of their data for Microsoft Product Manager Engineer salaries, as of 10/31/2023.

Salary of a Microsoft Technical Program Manager

Just for reference, here is the data from Levels.fyi for the Microsoft Technical Program Manager salaries, as of 10/31/2023. The data is close enough and within range of the Microsoft Product Manager salaries.

Performance Review Process

As I wrote in my previous post My Experience As A Microsoft Software Engineer: A Deep Dive, this is the summary of Microsoft’s performance review process:

• Calibrations happen twice per year (each period ends in March or September)
• Different segments, based on the rewards that the engineer will receive:
  • 0% of target rewards -> Corresponds to a Performance Improvement Plan in other companies
  • 60% -> All team transitions are blocked
  • 80%
  • 100% -> This is the actual target that most Microsoft Software Engineers will be bucketed in
  • 120%
  • 140%
  • 160%
  • 180%
  • 200% -> Max rewards
  • E.g. If the target rewards for a particular level is $X, then someone bucketed at 100% will receive $X, someone bucketed at 160% will receive 1.6*$X and someone bucketed at 80% will receive 0.8*$X
• Promotions can happen either in March or in September, but the vast majority happen in September
• Annual increases and bonuses are given in September

The most important part of this calibration process at Microsoft (both previously and now) is that your manager and your skip-level manager (i.e. the manager of your manager) play a really really important role in your promotion and performance results. As long as both of them agree that you are ready for a promotion, then there is a really high chance that you will get it. Of course, they need to provide a business justification and have the budget for it, but in most cases, they manage to figure it out.

Downsides of working as a Microsoft Product Manager

The Legacy of Program Management

Unlike other tech giants that have distinct and separate roles for Product and Program Managers, Microsoft has historically combined these responsibilities under the title of Program Manager. Despite the recent shift to include Product Managers, the essence of the role remains a hybrid, demanding a skill set that spans both domains. Many Microsoft Product Managers find themselves juggling the responsibilities of both Product and Program Management.

On one hand, having a hybrid role allows for a holistic view of the product lifecycle, providing valuable insights into both the strategic and execution phases. On the other hand, it can lead to role ambiguity and an overwhelming set of expectations. Product Managers at other companies can dedicate their time to understanding user needs, analyzing market trends, and refining product strategy, while their counterparts at Microsoft are often also navigating timelines, resources, and cross-functional coordination.

Compensation is lower than other tech giants

One of the more prominent challenges at Microsoft is the compensation package. While the company offers competitive salaries, there is a noticeable disparity when compared to some of its peers in the tech industry, such as Google, Facebook, or Netflix. Software Engineers, particularly those at the entry and mid-levels, might find that their counterparts at other leading tech companies receive higher compensation for similar roles.

My rule of thumb is that Microsoft is paying the Product Managers at level N, similar compensation to level N-1 at these other tech giants, e.g. a Senior Product Manager at Microsoft is getting paid a similar amount as a Product Manager 2 (or L4) at Google/Facebook. This discrepancy can be a significant factor, especially for professionals who are evaluating multiple job offers.

Slow Career Progression

Microsoft is known for its well-structured hierarchy and clear career progression paths. However, the existence of multiple levels within each job role can lead to a slower career trajectory for Microsoft Product Managers. Promotions and advancements may not come as swiftly as one might hope, and the journey from one level to the next can be lengthy and complex.

This slow pace of career progression can be a source of frustration, especially for ambitious individuals eager to climb the corporate ladder. It requires a considerable amount of patience, consistent performance, and strategic career planning to navigate through the various levels and achieve career advancement.

Conclusion

As I reflect on my journey as a Product Manager at Microsoft, working at Windows, Azure, and Skype, I recognize the unique and multifaceted nature of this role within the tech giant. The combination of product and program management at Microsoft has offered a holistic view of the product lifecycle, from ideation to execution, providing invaluable lessons and a diverse skill set.

The dual responsibilities have certainly posed challenges, especially when compared with the more specialized roles of Product Managers at other leading tech companies. The expectation to manage not just the product vision and user engagement, but also the project timelines and cross-functional collaboration, has been both a test and a testament to the resilience and versatility required in this role.

Comparisons with my experiences at other tech giants, such as Amazon and Google, have highlighted the unique aspects of Microsoft’s approach to product management. Each environment has its strengths and nuances, contributing to a well-rounded perspective on how product management can be shaped and influenced by corporate culture, market positioning, and historical legacies.

In conclusion, my tenure as a Microsoft Product Manager has been a journey of growth, learning, and adaptation. The blend of product and program management has enriched my professional experience. While there have been challenges and moments of role ambiguity, the overall experience has been rewarding, offering a comprehensive insight into the art and science of bringing products to life.