Here are 5 things I learned while I was a Program Manager at Microsoft

During college I was given a choice when I was interviewing for an intern position at Microsoft; I could become a Program Manager or a Software Engineer. I had interned at Tumblr the summer before as a Software Engineer and so I decided to give Program Management a try before I switched back to engineering.

I messed up on those plans though because I fell in love with being a PM.

Fast forward a year and a half, and it’s been a wild ride since I joined Microsoft out of college. I co-founded a product from scratch, brought a team together and shipped a consumer iOS and Android app within 6 months (named Project CampusLink).

It led to traveling in Europe, meeting teams at other companies such as Nike and really understanding what it means to build and ship quickly. The work our team did started a movement within our organization to build in-house mobile apps and helped to build strength in our mobile engineering.

Now let’s get into five short lessons that I learned while being a Program Manager at Microsoft.

1. More relationships, less meetings

Stop having five sync up meetings everyday or four hour long meetings to go over 100 page documents. The reason for not doing that is the same reason why in engineering a push data model is more efficient than a pull data model. When asking for feedback after joining the team, one of our engineers told me “only take up my time and bandwidth if it’s important, if not, please leave me alone”.

I’ve found that teams have this problem when people don’t feel comfortable asking questions or there is confusion coming from multiple sources of truth. The ladder can be fixed with a single source of truth (in our case, a single Program Manager) for the feature strategy and the first issue can be resolved with trust (which I outline below).

2. Trust is at the center of everything

Trust is the most important glue that holds a team together and that trust needs to start with the Product Manager. The way I see a team is like a family; everyone has their powerful talents but they need to feel that there is a safety blanket for when they want to take a risk or might make a mistake. Those little risks sometimes turn into incredible ideas but the Product Manager needs to set that standard through their actions.

I found building that trust with our team was as simple as grabbing lunch, genuinely asking about their lives and letting people explain to you what makes them excited.

3. Don’t let titles define curiosity

This was one of the first things I pushed for when I joined the company; get the engineers to have design opinions and the designers to have engineer opinions.

Every morning I’d try to walk around and chat with people on our team asking what they thought about what other people were working on, showed them examples of things outside of their title and tried to get them curious.

This resulted in better questions being asked at meetings, more passion for our users and empathy for other people on the team which ties back to the theme of having a family level of trust.

4. For every yes, there should be a thousand no’s

When we were planning out what features would be in the first version of the app, the small team at the time had thousands of ideas and other teams also chimed in with theirs. The issue was that we had to ship in 6 months to prove our worth as well as learn from our users. I had to make a ton of tough calls and say no to a lot of great ideas.

You have to have the courage to standup, trust your gut, give a shit about something and not be afraid to make people unhappy.

In the end, we shipped after a thousand no’s, but it was the yes’s that allowed us to get there and have thousands of people really like our product even though it wasn’t perfect.

5. Market within your company as much as you market out

One huge mistake I made was being too focused on users and our metrics that I didn’t market to our internal leadership. I assumed they knew how well we were doing because our dashboards were meeting our goals. Looking back, I was too heads down in execution that I didn’t see other things moving around above me.

It untimely led to other strategies being marketed to leadership which stalled our deployment, limited my ability to make some big product decisions and created some ambiguity which led to churn. We got over the road bump, but it was a painful lesson that I learned for six months.

Do you have advice or feedback? Are you a Product Manager or looking to get into the field? Just want to get coffee in the Seattle area? Let’s connect on LinkedIn!