Five things I learned during my first month as a product manager
Time really flies by! I looked at my calendar this week and realized it’s officially been one month since I’ve joined Microsoft. With that in mind, I wanted to take some time to reflect on some of the key lessons I’ve learned, in hopes that I will retain these learnings going forward and help improve the experiences of new hires to come.
For me, one of the biggest adjustments from college to full-time work was that there were no longer explicit assignments to complete. Sure, you may have specific deliverables like a framing deck or spec to present, but the way you go about those things is completely up to you. And on top of that, there’s no one-size-fits-all formula for how to do it! I’m still working on finding the best method that works for me, and below are several actions I found helpful towards identifying some strategies:
EDIT: It’s been a few months since I wrote this document, and I had the good fortune of getting some great feedback from Dan Parish, the Principal GPM of NUI (Natural User Interface) here at Microsoft. You can see his comments in the addendum sections throughout this article!
1. Ask members of your team if you can “shadow” their daily PM tasks (e.g. spec reviews, framing meetings, flash feedback sessions)
A shout out to my onboarding buddy, Abid, for this nifty tip!
Attending meetings from some of the more senior people on the team can give you more guidance on what it means to be a PM. A few types of meetings that would be helpful to observe include framing meetings, flash feedback sessions, and spec reviews.
Another benefit of shadowing: it’s also a great opportunity to explore different working styles between people on your team. Especially in the field of product management, there’s different ways to drive alignment amongst your team — whether that’s using customer feedback, analyzing telemetry, or looking at growing trends. While attending these types of meetings, make sure to observe what types of evidence the PM uses to guide their decision and how others respond to it. This can help you later on in developing your own approach or pinpointing the right person to ask a specific question.
2. Ask lots of questions
I used to spend hours searching in our internal database to learn the material; then I realized there’s no one that knows the material better than the people who wrote the material. Plus, they might have even more useful information to share! Nowadays, when I feel like I’m spending copious amounts of time trying to research or answer a certain question, I’ll see if I can connect with someone who might know where to find that information or, better yet, be able to answer the question.
When it comes to getting niche questions answered, I’ve found there’s a lot of value in thinking in terms of breadth first and depth first search — using BFS to “traverse” all the core members of your team for their knowledge, then using DFS by asking each of these people who they might recommend talking to for more detailed questions.
ADDENDUM:
I 100% agree with this premise, but I think there are actually three distinct issues new hires hit and they have different ideal paths to resolution:
Not asking ‘What is X’ questions: These are the basic “I don’t know what this acronym means” or “what is GitHub” type questions. The tried and true solution here is to write these things down and follow up on them later either with your mentor or by searching, and that’s fine. That’s what 99% of new hires do. But you should also not be afraid to ask these questions in meetings. I as a GPM ask these types of questions all the time. The reality is I do that because I may feel more comfortable in my role than someone new, but the expectation from everyone around is exactly the opposite. People expect someone new to not know everything and just to ask. Worst case it’s too complex and someone will follow up with you after, but even that is good to know.
Not asking ‘Why is X’ questions: These are questions like “why don’t we do X” or “why did we build X like that”? These types of questions you should almost always ask in real-time in the meeting. What generally happens is people who have been on a team for a while gloss over things that don’t make sense because they’ve gotten used to them. You as a new hire are in a unique position to see things with fresh eyes and identify opportunities to improve the team, the code, or the customer experience. There’s only two outcomes to asking this type of question:
1. You’ll learn a bunch of context usually from multiple people and be way better off than you were before
2. You’ll cause people to think, reevaluate, and hopefully drive change
Both of those outcomes are super valuable! Tons of great improvements to our teams, build systems, and external-facing features have come from people just asking why?
Not getting unstuck: This is when you’re trying to figure out the solution to a coding problem, or how to write a spec, etc. and you haven’t made progress for a while. This is the major type of problem you were referring to in your post, but I actually think here you were too cautious in your advice. The rule I give new hires is this: If you are stuck on something for one hour, ask someone. Your time is valuable too, and we don’t want people to be stuck researching things that someone can probably answer in 30 seconds. No one will be upset with you asking questions, and your mentor won’t be upset if you’re asking for help. You are right that doing some research beforehand is good, hence the 1h rule, but anything more than that is just inefficient which is bad for everyone.
3. Collaborate with all kinds of people, even outside of your team
I’ve found the best work can sometimes come from borrowing ideas from others, especially other product teams — which may come as a surprise, especially since the PM is often described as the one driving innovation on the team. However, learning from other product areas is a great way to see what challenges and learnings came out of teams with similar features or problem spaces. The best part is that you can save time on your feature by avoiding making the same mistakes while gaining new friends to collaborate with!
The product areas are most similar to yours may not be immediately obvious — it could be worth brainstorming the unique challenges and problem spaces you feel are related to your project and asking your manager for the contact information of teams or people who have faced similar experiences.
ADDENDUM:
Yes! The only thing I wanted to call out here is don’t just look for ways to increase your individual contributions, also look for opportunities to leverage the work/ideas from other teams or find ways to contribute to them. Even if you worked 24h a day, you can only accomplish so much. But if you leverage others or contribute to others your impact can be far larger.
4. Seek out mentors with varying levels of experience at the company
I’ve found it’s extremely useful to have two different kinds of mentors: one who has spent around 2–3 years at the company, and another one has a more senior level of experience. The reason for this comes down to perspective: people who have joined more recently may have more insight on what it’s like to start out at the company, whereas people with senior experience can provide helpful insights on how to maximize your impact and grow as a leader within the company.
Finding these mentors can be anything from signing up for an explicit mentorship program within your company, to serendipitously meeting someone that you just know you want to learn more from. Having been both a mentee and mentor, I’ve found there’s no “right” recipe for what a mentor/mentee relationship might look like — it might look like a regular sync, or it might be an ad hoc “what are you up to?” meeting every so often. In my opinion, the best thing to do is to proactively seek ways to learn from all kinds of people and surround yourself with people who are rooting for your success.
5. Be kind.
I’m absolutely convinced that nothing can underscore the importance of being kind. This can come in many forms — whether it’s paying forward by mentoring others or taking the time to send thank you notes, the most important contributor towards your success is being kind to the people you work with.
I couldn’t have written this article without the help of my friends, colleagues, and mentors — huge shout out to Dan, Christina, Ariel, Katherine, Neehar, Sarah, Chenying, Abid, Sumedha and Sander for giving feedback and unfiltered opinions! This is my first ever Medium article and I intend to write more, so feel free to leave your own comments on what content you’d like to see more of in the future. Thanks for reading and please leave a clap if you found this useful!
