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.
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:
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.
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.
You talk to customers, you collect data, you got buy-in from your internal stakeholders. You lined everything up for a successful feature launch. And then you run an experiment, and the reality showed you that the implementation that you expected to be the winning one is actually not what moves the needle for the larger product. Now you have a dilemma - you have the option to launch as is (after all, you did the due diligence - maybe the experiment timing was bad and in the real world, people will love what you did) or go back to the drawing board.
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.
You are getting started as a PM - what are some of the tools that can help you be productive, organized and just overall effective? That is a question that I asked myself when I first started as a program manager. There are so many things to stay on top of, and just no clear guidance as to what I should use to do so. In this post, I am outlining just some of them that helped me not lose track of the million and one things a PM needs to work on.
I remember the day when I got my first internship at Microsoft as a program manager. It was such a new concept to me at the time - months before my interview took place I was hastily doing my research, trying to figure out what does a PM do. One of my first explorations in that domain was through a post from Steven Sinofsky - PM at Microsoft. One part stood out:
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.
As a program manager (PM, for short), I had and continue to have the pleasure of working on a number of features across a range of products. The scope and feature direction can change fairly frequently, and it’s our (PM’s) core responsibility to re-adjust and make sure that we design and develop a solution that helps our customers be more productive, efficient, and successful. In Ben Horowitz’s 15 year old post, he states that good PMs are “mini-CEOs” of features and product segments.
You are a PM. You work for a big company or a startup. You are tasked with determining the direction for your product, so you enthusiastically embark on the journey to talk to as many customers (or potential customers) as possible to determine what their needs are and how your product can help them in the long-run. After months of painstakingly collecting feedback, you emerged victorious with a PowerPoint deck that says: “We need a bigger button in the toolbar to let people renew their subscription easier”.
Before going any further into this post, I should preface this by saying that anything and everything below is purely my subjective view on what makes a Program Manager a great Program Manager. I consider myself lucky enough to have experienced what it's like to be a PM on a product team, and currently - on a content team, and this blog post is a reflection of my experiences across the two completely different organizations.
In a world where everyone is trying to collect and analyze data about their product, it is easy to get excited about numbers. After all, getting hard numbers about what you shipped is, in a way, validating or invalidating the provided value.