In the past couple of months, folks asked me how I got into product management. While everyone probably wants to hear an overly romanticized story about how this was my passion from an early age, the reality is much funnier - it was an accident. I never had any plan to be in product management, and yet, this is how I built my career. This essay is a story of how I got to be in the role I am today.
Last week I mentioned that after six year at Microsoft I was leaving the company to pursue a new adventure that would push my growth and skills to new levels. To me, learning can only be done if I constantly push myself outside my comfort zone - I think today’s decision does this. I am happy to announce that starting today I will be joining Amazon Web Services as a Senior Product Manager, Technical on the Amazon EventBridge team, making serverless and event-driven infrastructure more accessible and developer-friendly.
Jeff Sandquist, CVP of Developer Relations at Microsoft, once said that “change invigorates the soul”. Working with Jeff’s organization was one of the highlights of my career - collaborating with some of the smartest folks in the industry, shipping things that have an impact (also known as docs.microsoft.com) and being very closely aligned with developer needs. I’ve been at Microsoft for close to six years, and I always felt like I am never the smartest person in the room - the sheer caliber of individuals that I had the honor of working with speaks volumes for the kinds of organizations that exist within the company.
Yes, you read that right - my good friend Courtny and I launched a podcast, dubbed “The Work Item”, where we talk about everything that comes to mind in the product development and design space. We even have a mascot, named “Peppy the Post-It” (Courtny is the creative mastermind behind the art and the mascot name, by the way). Two episodes of this podcast are already out - the first one being on remote work (check it out on YouTube), and the second covering our career paths (also on YouTube).
In several conversations with individuals that I help mentor, the same question seems to be coming up more often than others - what are the skills necessary to be a good product manager? This seemed like a great opportunity to provide a more persistent outline that can be referenced by others in the future, hence this post. I should mention that this list is, of course, not comprehensive - depending on the company, responsibilities and the product one is working on, additional skills might be necessary (or even the same skills, but in a different context).
Here’s a statement that covers an often overlooked reality - as a product manager, you are in sales. Now, you might be wondering - you’re not putting together sales plans, you are not knocking door-to-door to sell a product, you’re not even part of your marketing department. How is that you’re in sales? In this article, stop focusing on the idea of sales being an exchange of goods for money, and instead, focus on the following definition:
I am all about numbers when it comes to driving decisions. That’s the most accurate and tested way in ensuring that you are pursuing the right thing. Not to say that we should not focus on things like customer development, but numbers certainly can shed a lot of light on whether the product is on the right track. There are certain approaches to analyzing product data that universally apply to all projects, and can yield some interesting insights given that you put some time in it.
The other day I had a conversation with my skip-level manager about what it means to be a leader in an independent contributor role, that prompted me to sit down and write this out. I’ve always been fascinated about ways in which I can multiply my impact, so this seemed like an important conversation to have. A lot of times product managers assume that just because they are in an Individual Contributor (IC) role, that means they need to focus only on their immediate areas - things that yield positive outcomes in projects and initiatives that are directly related to one’s line of work.
I’ve recently had a chat with my team on metrics - one of the key topics a PM needs to be well-versed in. Metrics are at the core of helping you define what you’re truly after. Having a deep understanding of what you are measuring is the only way to make sure that in the long-run, you’re able to build a product that truly satisfies customer needs. Consider this post a basic intro in just that - getting a grasp on quantifiable measures of the performance of your product.
I am big on figuring out ways in which I can spend time more meaningfully. Part of this is a strategy to automate as many of the routine tasks as possible, to make sure that I can focus on the big picture - building products that deliver value to customers. I should also preface this post with some context - I am a remote employee. Sometimes it’s hard to communicate what you’re doing and how you’re approaching the stack of tasks while hundreds of miles away from your team.
Ideas are an interesting beast - we tend to get attached to them as if they are the lifeblood of what we’re doing. It’s especially common in the world of product management - way too often PMs tend to think that the most important part of the job is to come up with great ideas, implement them, and see the product shine. I thought so too when I was first starting out - the onus was on me to come up with the right solution as the driver behind a feature or product segment.
What is the purpose of a 1:1 with your manager? I wanted to do a write-up to dispel a common misconception around what that meeting with your manager is, and how you can channel it into a much more productive use of time. Status Whenever I talk to new hires, and they set up 1:1s with me or their new manager, one thing becomes very obvious - a lot of people consider 1:1 meetings to be a forum to discuss everything they’ve done in the past week/month/quarter.
When things go wrong, it’s human instinct to jump to the nearest possible solution and execute. The goal is to rectify the problem as soon as possible, to ensure that it either never happens again, or the chances of it happening again are slim. This hasty response, however, more often than not leads to suboptimal solutions that merely put a band-aid on the problem and do not address the underlying root causes.
If you are a product person, you’ve probably heard this numerous times - “fail fast, fail often”. To many, this often might sound like an invitation to just ship whatever comes to mind, test it and then assume that there is some “learning” happening afterwards that is going to help one come up with a better solution to a user problem. Photo by Quino Al on Unsplash. Let’s say that we take this scenario outside the product world.
As a PM, one of the most important skills that I learned in the past couple of years is the ability to collect, query and analyze data. No, really - data is fascinating to me almost more than any other part of the product. Data can inform any future decisions and either validate or invalidate your hypotheses around the direction of your work. Before joining Microsoft, I always thought that working with data is something that only data scientists and analysts do - a PM sets out the path for the product, the data science team provides the numbers and insights, and then engineering drives the implementation.
This question probably came up for anyone that ever worked as a PM - when should I use quantitative metrics, and when should I rely on qualitative metrics? It’s an important aspect of ensuring that the right data is used for the right aspect of product planning. Let’s start by distilling the terms. Quantitative data is data that is heavily grounded in numbers - how many users, what percentage of them are happy, what is the ratio of converted vs.
Last year, I decided to be more proactive about working on becoming a better product manager - I acutally carved out some time to learn about the skills that would allow me to have a bigger positive impact on the customers of projects that I am building. I’ve spent a significant amount of time reading through various books that tackled topics from customer empathy, innovation to practices on improving collaboration with my team and partners.