7 skills to become a successful project manager
Recently I’ve been conducting quite a few mock product manager (PM) interviews at Google, to help Googlers who are preparing for their final interviews before being approved to transfer into the PM job family.
It still amazes me that when assessing a candidate for a PM role, we have to do so with only five or six 45-minute interviews since there are so many distinct skill sets required for the job.
When I first became a PM, my strength was execution and delivery given my software engineering background. It took me some time to understand the other dimensions and grow into those skills. Here’s my take on the skill sets required to be a successful PM.
You probably have heard the phrase “eat your own dogfood”, which means you need to use your own product before you expect other people to use it and pay for it. I remember being an avid Amazon shopper while I worked at Amazon and I just assumed that I knew what it was like to be a customer. It wasn’t until I actually read customer support emails and listened in on real support calls that I realized I was not the typical customer. At the time, I was the PM responsible for Amazon’s shoes and handbag website. There was a customer who called support and wanted a particular shoe size. The website showed that the size was not available and she asked the customer support agent if they could “look in the back”. The agent was a total professional and told the customer that no, the website was up to date with the latest inventory information and we didn’t have the size she wanted since the customer clearly didn’t quite understand how online inventory is managed.
Knowing your customer is the first step, and product intuition is the next step of understanding their needs and motivations so that they will actually use your product. One of the past products I worked on allowed customers, who were advertising agencies or marketing departments, to be more efficient with their ad buying. However, the benefit of my product only allowed them to be marginally more efficient with their ad spend. Because marketers tend to be incentivized to spend all of their ad budgets so that they can ask for more budget the next year, what our product did wasn’t a game changer for them. So it wasn’t sticky for them. These are the types of intuitions that you naturally develop once you’ve worked on a variety of products. That experience gives you the spidey senses you need to go beyond the obvious, and dive deep into understanding what your users do, and how they think and feel. Those intuitions are the ones that will guide you towards coming up with the right product solutions.
This might be the most practical and useful day-to-day skill as a PM. The PM role is cross-functional by nature. At a minimum, you’ll work with engineers, user experience (UX) designers, marketers, salespersons, executives, and customers. You will most likely have no authority over these colleagues thus you must rely on your ability to influence to get them to do what you need. When you start out, you might not even understand the role of your colleague and you will have no idea how to work with them. I recall an early experience in my career working with sales. I listened in on one of our salespersons on a call with a customer. The customer raised concerns about the throughput of our product. She responded without hesitation, “our product has 30% more throughput than our competitors”. After the call, she said, “what’s throughput?” I was flabbergasted. But it shocked me into realizing that our sales team is strongly incentivized to simply close the deal. They also have very different backgrounds than those of us in product and engineering. When you need to work with colleagues who have incentives that are at odds with your own, sometimes it can get really daunting and frustrating. Why does the sales team keep selling features that your product doesn’t yet have? Instead of fighting this, you need to earn their trust by listening to their pain points and add value for them. Is there a way to educate your sales team about all the capabilities of your product, so that when a customer asks for something your product doesn’t do, the sales team is equipped to handle that by offering a solution or a workaround that your product can provide? Your sales team talks to your customers a lot more than you do as a PM. You need to figure out how to turn them into your allies and your ears on the ground.
When I first contemplated moving to a PM role, I had high expectations that now I was going to be super strategic in my ivory tower and I no longer would have to worry about tactics and delivery. However, my mentor at the time told me something else. She was a very senior product and business leader who owned an entire product category at Amazon. She said that every PM role has an execution component and PMs are measured against outcomes. Amazon is a company highly focused on outcomes. In fact, one of the sacred Leadership Principles is “Deliver Results”, which is described as “Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.” So regardless of whether you’re a PM, an engineer, or a marketer, you’re held accountable to the results you deliver. Strategy without execution doesn’t yield results. As a PM, since you often don’t have authority over those who are doing the work, it takes additional finesse to organize and motivate those who are doing the hands-on work to execute. I find that once I’ve defined a product direction, my focus turns to remove obstacles for the UX designers and the engineers, i.e. those that are building the product. I make sure that the team understands the priorities and I’m here to clarify things when questions come up or help simplify a product requirement to avoid unnecessary work. I find it valuable to have 1:1 meetings with engineering leads which can uncover unstated assumptions. Once the engineering lead on a project told me that it was hard to track the exact user interactions for the web version of our product because of how a component on the page behaved. I told him that we will not plan to make any investments in the web version of the product in the next year, so you just need to get to a close approximation and that was good enough. He was relieved because it was going to save a lot of time and complexity. As a PM, even though you’re not writing the code, being close during the execution phase of the project can make a big difference if you lookout for ways to help your team be more efficient and work on the most important things first.
At the core of the job, the PM is responsible for making decisions, both big and small. Should we launch the product globally or in the US first? Should we fix this bug or leave it as is? Those who are affected by your decisions expect you to be decisive and your rationale to be sound. Most of the time, you have to make timely decisions with imperfect data. You must first get the data that is available, and then take calculated risks due to the data you don’t have. As PMs, we run into this situation every year when we build a product roadmap, which is a series of projects that we plan to work on in a given year (or half-year/quarter) for the purpose of meeting an agreed-upon goal. When you need to plan for the year, you never have perfect metrics to tell you where you are now. You also don’t know how long each project will actually take. Once the project is complete, you don’t know whether it will help you meet 100% of your goal or 50%. There are lots of variables and you’re supposed to order these projects in sequence. It can feel like a daunting and impossible task. A phrase we often used at Amazon was creating “two-way doors”. It means that we’ll make the best decisions we have with the data we currently have on hand. Once we have new data, we adjust. The key is not to create “one-way doors” such that your decisions are hard to reverse in case you’re wrong. And you will be wrong. Instead, you make sure you create flexibility in your plan so you can adjust when you learn more.
Once the hard part of decision-making is done, you also need to be able to explain how you made these decisions to your team, stakeholders and executives. One thing I remind myself of is that the people who are relying on my decisions often don’t have better data than I do. So they can only judge my decision based on the decision-making framework I used to arrive at these conclusions, and the alternatives I considered.
During my first summer break at university, I worked at a women’s clothing store. We were required to sell the store loyalty card to every single customer who was making a purchase. There was a leaderboard showing how many cards each employee sold each day. This was my first sales job. I felt really uncomfortable trying to convince a total stranger to part with their money in the short time that they’re checking out to buy something else. But by the end of the summer, I had long gotten over my fear and embarrassment. I felt a jolt of energy when I made a sale. As a PM, you must be the cheerleader and spokesperson of your product because you likely have to sell your product on a weekly basis. By that I mean you need to sell your product vision to your UX design and engineering team. These are top-notch folks who need to feel excited about bringing your vision to reality else they might very well move to a different team within the company. You need to sell your product to another team within the company that you need to work from in order to bring your product to market. Why should they work on your project when there are other teams also asking them to do work? You need to sell your product strategy to your leaders and executives so that you can get additional funding and headcount for your team. Not to mention you need to work with your marketing team to sell your product to your users. Whether you like it or not, there’s a lot of selling in this job.
I already talked about the fact that Amazon prefers the narrative format whereas Google tends to use slides in a previous post. You must learn and adapt to the communication style of your organization. I recall once writing a status email to my leadership team and my manager told me to take the last sentence in the email and put it in the beginning, i.e. start with the TL;DR. When he pointed that out to me, I realized how obvious my mistake was. I was starting with the details, here’s all the stuff we’re doing, and leaving the punchline at the end. Leaders are busy. They want to know, are you on track, behind, or stuck? What decision, if any, do you need them to make? I took that manager’s advice to heart and started to make my writing more scannable, such as prefacing each paragraph with a bolded phrase or headline. We used to call these “Blackberry emails” because your emails need to be readable by an exec on a Blackberry device before the days of rich text and iPhones. As a PM, you must master how to land your message with your team, your cross-functional colleagues, your stakeholders, your executives and your customers. These audiences can wildly differ which makes this quite a challenge. When you do this well, you will be that much more effective as a PM.
I majored in computer science in university and I was a software engineer for five years at the start of my career. This gave me the experience and confidence I needed to feel very comfortable working with software engineers day today. I remember how anxiety-inducing it was to have to carry a pager on the weekend when I was on call. I know how unruly and difficult it is to maintain your codebase if you continuously take shortcuts to make a deadline. I also know that sometimes, as an engineer, you want to design something that is elegant and can scale over time, even though you don’t yet know what the product needs will be in a few years. In short, I have a lot of empathy for engineers. At the same time, because I have worked on multiple large-scale software projects over the course of my career, I have a foundational understanding of how internet applications work, and I have developed a strong intuition for how software projects tend to run. So far, I’ve personally participated in four large-scale migration projects at three different companies. They all look something like this: we have a product that’s in use running on an aging architecture. We need to migrate the existing functionality to a new technology stack which will allow the product to run better, be easier to maintain, and faster to add new features. How long will this migration take? Six to nine months the engineering lead says. How long does the project actually take? Three to four years. When you’ve worked on many software projects, you sometimes realize that you’ve seen this movie before. My experience better prepares me to know what questions to ask my engineering team. When I come up with two different product ideas, which one is better aligned with how the current software system is designed? Which one requires brand new systems, or is demanding the current system to do something that it’s never done before? Understanding how your proposed product change affects your current software system early in the product development process could prevent you from spending valuable product management and UX design resources on an idea that you can’t bring to market in a reasonable time frame. I don’t think you need to know how to write code to be an effective PM in the software industry. It’s more important to understand how software systems work. I like the home renovation analogy for software development projects. You intuitively understand that painting is cosmetic and it’s easy, quick, and low risk. If you want to add a new floor or an extension to the house, then you probably need to update your roof and that starts to be more invasive. Since it’s an existing house, you won’t know exactly how things are going to go until you start working on the project and taking apart walls. You might uncover shotty wiring or termites that could cause a massive delay and budget increases. I’m no expert in how houses are built. So if my contractor comes to me and says, hey I need to replace the gutters and fix x, y, and z. I wouldn’t have a clue as to whether this work is really needed and worthwhile. But on software projects, I have enough knowledge and experience to know the right questions to ask. What happens if we don’t do this? If we make this change now, does it mean we need to redo it in 6 months when this other system changes? Understanding how your product is architected, knowing its technical limitations, and being able to effectively leverage your engineering counterpart’s technical expertise are the critical skills for a PM when it comes to technical competency, not coding.
I was a software engineer and a technical program manager before becoming a PM. I was very used to thinking about how to build the product, rather than the “why” and “what” of the product. I’ve had no formal business training and I don’t have an MBA. As a result, being able to “think big” is the skill that took the longest for me to develop. Someone once said to me that being the PM is to be able to “see the future”. There’s a lot captured in that phrase and I’ll do my best to explain it. You need to have a curiosity for what’s going on in the world and be able to see the trends that are going to shape the future. Blockbuster ignored the rise of Netflix. Kodak dragged their feet with digital photography. The downfall of these companies is obvious in hindsight, but as the PM, you need to see these things before they happen.
I love this visual above that shows we’re only implementing the ideas from 10 years ago today, while the old economies are trying to survive disruptions by ideas from 20 years ago. When I was a software engineer intern at Amazon in the summer of 2000, there were only a few dozen of us in our cohort. Jeff Bezos, the founder, and CEO, personally joined one of our intern lunches. Wearing his signature blue button-down shirt and khakis at the time, he showed us the things he carried in his pocket every day: a Blackberry, a cell phone, and a digital camera. He held them up and told us that soon, all these devices will be merged into one. He was right. He was also right to invest in the Kindle and Prime video streaming because he knew that although Amazon started by selling physical books, and later expanded to music CDs and movie DVDs, eventually these things would all be digital with the rise of high bandwidth internet. He also knew consumers wanted free shipping from online shopping so he aggressively drove down the order size needed to qualify for shipping and later introduced 2-day free shipping with Amazon Prime. Now consumers expect free shipping when they shop online. He’s very good at seeing the future in technology trends, consumer behavior and industry trends, and the competitive landscape. It took me some time to understand and learn this skill. I also find that the most visionary product leaders have a healthy disregard for the impossible. A UX designer I used to work with once said to me, “pretend technology is magic”, when we were working on a product. I love that phrase because it frees me from my normal, day-to-day practical thinking, and allows me to truly focus on the needs of the users. What would be a magical, delightful experience? I think part of the reason why this is so hard is that #3 above, execution and delivery. And when you can master both thinking big and strategically, and executing well, you will thrive as a PM.