Scratching the Surface of Product Development & the Workplace

I’ve outlined a brief summary of things I’ve learned so far working as a Product Manager into two parts– General Work Lessons & Product Development Lessons.

General Work:

These are lessons geared towards starting life as a new hire in this “new normal”. 

When I first started on projects I wasn’t entirely sure of how to begin scoping or understanding the problem I needed to solve. I was encouraged to ask as many questions as possible (especially if you’ve been stuck for more than 30 min), and this helped answer many of my questions.

It’s okay to make mistakes (I accidentally deleted months worth of data that someone else needed) & when that happened, I won’t lie, I started panicking so much. I took a deep breath and reached out to anyone I knew and other teams as well in order to restore the data. It stands that you show your best character when taking full responsibility when it’s much easier to hide under your bed.

Write in order of priority the night before the top three things that I need to accomplish the next day. Now that we’re online, it makes it much easier for others to leave messages & emails that allow them to own my time 24/7. Outlining the absolutely must get done things helps me take back ownership of my time.

Ask my coworkers that I work with regularly if they suggest I connect or speak with someone on my team or outside my team. I spent a lot of time asking other folks to directly connect me, but working from home has made folks 10x more overwhelmed and busy so it’s best for me to take action too. Cold emailing might feel super scary in the moment, but it can turn out to be really worth it.

Finally, treat everything as a small “win”. Every little step I take or my team takes, I take a moment to celebrate. It creates a much greater sense of community and brings people closer together. Any sort of connection is much harder to forge right now so people tend to remember you and speak in favor of you if you leave a positive impression.

Product Development Lessons:

Now, I’d like to pivot and discuss engineering & feature development.

Typically, as a PM I, my manager will assign a feature to me that can either be as complicated as a complete revamp of a major user workflow or as simple as adding a new version of an existing icon. Funnily enough I’ve learned that the latter requires just as much work as the former. As a first step, I find it helpful to speak with other PMs & Designers in order to understand how the feature came to be, why are we implementing it now, what’s the business impact. From there I can determine what is necessary to make the feature (i.e. user testing, telemetry, etc.). The best knowledge is built upon other people’s knowledge. I think sometimes at Microsoft there’s a perception that PMs work in individual silos on their own features, but I’ve seen the most successful PMs collaborating and reaching out across disciplines. Alongside this, it’s important to look at the existing telemetry or user data that I have available in order to understand what is important to users. The most critical question to try to answer– do people even want what I’m creating? That’s all a great starting point to get the ball rolling & give me an idea of how far to scope the feature. That just scratches the surface of large scale feature development, the rest can be for another time😅.

Next up, TESTING! Everyone’s favorite part… I learned here from watching other features that it makes a massive difference to do accessibility testing and consider accessibility while creating my features. It’s very important to me to take the time to create products accessible to everyone because that’s truly when the best products are made. I may be biased here, but not only does creating universal designs making the product overall better, but also saves a huge amount of time when going to ship. I’ve seen situations where features will be behind for weeks to months because they don’t meet Microsoft Accessibility Standards. At such a large company, the timeline for when a feature ships is incredibly important and a part of how the business impact of an individual contributor is measured. So when it comes to my features I do testing as I go along, iteratively, maximizing efficiency. This is a lesson that applies to both PMs & Software Engineers.