The life of a Microsoft PM: PowerPoint, Patents and Tea Time

On Friday, July 8, 2016 I wrapped up my last day as a Microsoft employee. After 3 (amazing) years on the Windows team, I’m stepping away for a bit to help our government get better at technology and design. I thought it would be fitting to go through some of the data I collected about my time at the company to help illustrate what it was really like to be a PM on the Windows Shell.


In my 34 months at Microsoft, I worked on 3 different teams. Pretty much my entire career was focused on digital pen and ink, which was particularly exciting because there was so little happening in the space when I signed on. When I joined the Surface team had only launched one pen device and we didn’t yet have a cohesive story about what it meant to use a pen on a computer. This meant that my collaborators and I got the unique opportunity of setting the vision for an entire hardware category!


I also got to help make a lot of product demos and even join the marketing team at a few video shoots. My favorite part of all this is that many of the Windows Ink GIFs shared out by Microsoft feature my handwriting.

Email is king

As a PM, a lot of my work revolved around communicating with other people to build and share ideas. At a company like Microsoft that translates to lots and lots of email. I received more than 36,000 emails (that’s more than 1,000 a month) and sent more than 4,500 of my own messages (an average of 6 emails a day). And that’s just the emails I kept!


As it turns out, a lot of this email came from mailing lists - before I resigned, I was on 39 different distribution lists. Luckily, most of them were reserved for important announcements, and didn’t distract me from my day-to-day. I managed just 4 mailing lists: 2 for features I was working on, 1 alumni list for my grad school, and 1 list for sharing pictures of cute animals (scoring is one of my prouder accomplishments).

The meeting life

There is a stereotype that PMs spend all their time in meetings talking. Driving consensus between teams is a major part of the job, which means getting people face to face, so it’s not unreasonable to expect lots of meetings. My favorites were the small group working meetings where I got together with a few other folks to hash out design problems, review concepts, and strategize about product direction.


I did a pretty good job living up to the meeting loving stereotype about PMs. I had more than 2,000 work meetings on my calendar, which added up to 2,136 hours and 25 minutes (the median meeting time was an even 60 minutes - not surprising given that Outlook’s default meeting length is one hour). Unsurprisingly, given that I worked on digital pen experiences, 462 of these meetings involved the word “pen” and 448 involved the word “ink”. I organized 620 of them, for a total of 659 hours and 20 minutes, which is about 30% of the total. This does make me curious to see how much time folks in other disciplines (like software development) spend in meetings, and how many meetings they organize. Hopefully their numbers are a little lower!


Fortunately, I didn’t spend all of my time in conference rooms - there were also 54 morale events and 191 social events on my calendar. 110 of these had the word “lunch” in them (20 titled “Lunch!” and one titled “Lunch!!”), as well as one meeting featuring “lønsj” (from my Norwegian teammate). I also had a meeting with fellow Olin alum Kate titled “Fifteen dollars!” that involved eating lunch. Eating together is an important part of workplace culture, after all.


A column chart breakdown of the events on my calendar.


One of my favorite team activities was tea time, which almost never involved a calendar invite. Instead, my teammates and I would message each other in a shared WhatsApp room - or just go door to door pulling people out of their offices. Tea time was a chance to take a break, grab a mid afternoon snack, and catch up with everyone about how things were going. I have it on good authority that shared breaks improve communication and productivity, so I’d say it was a good investment!

What do PMs make?

Being a PM is not really a generative role; at the end of the day our work is to forward ideas, not to produce specific artifacts like our developer and designer counterparts. An interesting side effect of the fact that PMs work more on ideas than execution, is that PMs often submit a large number of ideas to be patented - I left Microsoft with 5 patent applications in the pipeline, and I had colleagues with dozens of patent cubes in their offices.


This isn’t to say that PMs don’t ever make things. As part of our role as communicators, PMs often put together sketches, documents, and slide decks to help others understand what the plan is. I had more than a gigabyte of data in my OneDrive, including more than 90 slide decks. As it turns out, PowerPoint is an amazing tool for PM work, and I used it in a way that was a little different from what most people expect. The stereotypical PowerPoint presentation is bland, wordy, and, well, ugly. It’s essentially a Word document turned into bullet points and projected onto a screen.


A stereotypical PowerPoint slide - long-winded and hard to process.


I’ve always thought of PowerPoint as a fast, dynamic communication tool, but I never dug into its other capabilities before working at Microsoft. Specifically, PowerPoint is a great way to do high level design work. Putting together rough wireframe images is very quick, and the transitions and animations the app offers give you a way to quickly add motion - something that is increasingly important in modern interaction design. This was especially important on my team, because digital pen experiences involve gestures, input modality switching, and actions both on and off screen. Communicating how users might select content with their pen or automatically convert their handwriting into typed text is much easier when you can step through an animated sequence with your team.



PowerPoint is a great tool for showing simple UI animations, like this simple drag and drop example I made in about 5 minutes.


In addition to all those slide decks, I also had just north of 200 images (largely references clipped from other sources) and 20 documents in my OneDrive. There were also a handful of videos, 3 PDFs, 2 spreadsheets, and 1 interactive web prototype that I built (HTML/CSS/js). Many of the documents in my folder were related to user research - because our team’s user researcher was often overloaded, I put my graduate degree (after Olin, I got a Master’s in HCI at the University of Washington) to good use and did a fair amount of preliminary usability testing on features by myself.


I sent a lot of collaborators this drawing of Han Solo and Chewbacca high fiving.

Shipping quality

One of the less discussed parts of being a PM is testing your features to make sure that they work the way they should. Sometimes this means running through formal test passes (I worked with our Quality Lead to write a framework for turning user scenarios into test cases), and sometimes it means just using the product as much as possible.


While it’s sometimes frustrating to use software that doesn’t always work the way it should, you also get to see all the cool new features months before the rest of the world. You also get to have a very noticeable impact on what you’re building. During the last Windows development cycle, I filed more than 90 bugs, many of which got fixed in the final product.


I also got to sit on the other side of the table and run triage for my team - which means that I got together with our Dev Lead every morning to look at all of the new bugs people reported, remove any duplicates of known issues, and decide whether or not to fix the remaining items. In our last development cycle, I triaged more than 650 bugs!

At the end of the day

Microsoft was a great place to build up my core PM skills, like writing specs and triaging bugs. I also got an accelerated education on shipping at scale, something Microsoft has been doing for decades. Building within such a large, global company shaped my thinking in several key ways:


  • Thinking globally. Shipping a feature in just English is a rarity - Windows 10 has support for well over 100 languages. This changes how you think about building features, because you have to account for such a diverse audience. A design might look great in American English, but does it still work when the strings are in German? What about in a right-to-left language like Arabic?


  • Thinking inclusively. Microsoft must meet the accessibility standards outlined by the US government, but the company is pushing for a design process that goes beyond compliance. I’ve spent many hours in meetings with design and accessibility experts discussing what it means to make handwriting and digital pen accessible, and how we can give people unexpected superpowers with this technology. Conversations have ranged from wholly practical (“How do we make this UI work with a touch when a screenreader is running?”) to forward looking (at least one discussion led to a patent submission).


  • Working within a large organization. When I first got to Microsoft, I heard a lot of people throwing around the phrase “managing up”. It’s generally used negatively - the implication is that you have to manage your boss, because they’re not a good enough manager to be left unsupervised. Over the last few years, my perspective on this has changed: managing up is really about collaborating across hierarchical levels. Managers naturally have less insight into detailed feature areas, and more insight into organizational dynamics. They’re the right people to go to for organizational problems and broader context, and they know that their employees are the right people to go to for design and implementation details. Making this work means that both people have a good sense of when the other person will be able to make more progress on an issue, and be comfortable saying so. In a good relationship, managing up means going to your manager and saying things like “I need some extra firepower in this debate, can you step in?” or “This team seems resistant to our proposal, do you know what other pressures they’re under?”.


While I could have learned these things at any organization, I believe that working at Microsoft gave me better roles models and helped me learn more quickly. I’m extremely proud of what my team is shipping this summer and excited to bring everything I learned to my next job.

Posted in: Alumni Speak