So, what’s the deal with product management?
What exactly is it, what do PMs do, and is it worth the hype?
Becoming a product manager is all the rage. Once you got your first role, did it stack up to what you imagined it to be? Did you truly enjoy the ins and outs of being a product manager, or did you think the anticipation of becoming one and the sound of the job description is what actually made you more excited? Zooming out of the specific industry and product, curious to hear your honest take on the role itself.
I’ve been getting more and more messages like this recently from folks trying to better understand product management, and figure out if it’d be a fit for them. Honestly, I didn’t even know product management was a career option until a few years ago. And when I did learn about it, I discovered that it came with an expansive cottage industry built around helping people ‘break into’ product management. As soon as I started digging into it, I was immediately overwhelmed with information. Sorry, Marty who and do I really have to enroll in a $10K Product School course?!
So let me share what I wish someone had told me before I jumped headfirst into pursuing a role in product management: how I landed on my decision to pursue PM over other career paths, how I’d define this role, and a synopsis of a week in the life of a product manager as I know it.
Why did I choose product management?
One of my mentors recommended visualizing my career as an hour glass. At the base, which represents the beginning of your career, you’ll start off very broad: you have no skills! Just raw potential, cutie pie. As you rise through your first few entry-level roles, you amass more experience and credibility. You’re starting to specialize, and getting really good at your craft, at which point you get to the ‘waist’ of the hourglass (that’s probably not the technical term, don’t @ me). But when you switch over to a management track, you broaden back out, since you’ll be spending most of your time and energy making sure your direct reports have what they need to 1) do their job well, and 2) grow their career and meet their development goals. At that point, your role might not look too different from a people manager in any other department.
So roughly four years into my career, I had to choose what I wanted to develop my expertise in before going full-send on management. I had a couple options in mind:
Continue on my current track in Strategy & Operations
Double down on the Operations side of that role
Pivot to marketing, since that’s where I spent the bulk of my time in management consulting
Pivot to product management
The #1 thing I did to figure this out, and what I’d strongly recommend to those of you who are at similar junctions in their career, was to talk to real people. Have conversations with people who sit in roles you think are interesting and ask them to go into detail about what they do day-in and day-out, what annoys them about the job, what they wish they could do more or less of, etc. That’s the most effective way to understand what’s going to be a fit for you. Now, if you’re interested in PM, read on.
So what the hell is product management?
I’m happy to offer generalizations about the role, but the truth is, product management looks and can feel very different from company to company and from team to team. In fact, the experience will probably be dramatically different even if you belong to the same product org but the company evolves from Series A to Series D to public. So here’s my well-worn disclaimer that the following is rooted in my personal experiences, and what I know to be generally true of a PM role.
So many people have written much more eloquently and exhaustively than I on the topic of what PMs do and what makes for exceptional PMs. So before I dive in, I want to direct you to those tried and true resources:
Defining product management
Product Management—in 1 tweet. Role: Define the product & coordinate actions across the org to enable its success Success: User adoption Business impact Skills: Common sense Immense empathy Influential communication Traits: Low ego Deep care High agency Simple, but not easy.
I see PM core responsibilities as: 1) Represent the user 2) Champion business case 3) Make sure everyone around project is heard, bought in and happy 4) Help project converge on deadline Others can do this work, too! Ultimately, PM fills whatever team gaps exist to achieve (4)Question for y'all: Some of us at @figmadesign were having a conversation about the line between a product manager's role and a product designers role. What do you think? How have you seen it work in the past? How SHOULD it work ideally?
Sho Kuwamoto @skuwamotoWhat separates a good PM from a bad PM—by Ben Horowitz of a16z, considered widely to be part of the intro PM literature canon
So how would I define product management? I’d say that product managers gets alignment on what success looks like from both the user and business point of view, and then empowers their team to deliver the right feature into the hands of the user.
A couple things to unpack here: 1) success—you can hack any metric. If you decide that your metric is registrations, you can make it super annoying to not be signed in, making for a terrible user experience in the quest to achieve your objective. If your primary KPI is an engagement metric as broad as monthly active users (MAU), an industry standard, you might be motivated to do the bare minimum to get users onto the app (say, by lighting up the app icon with a badge notification that users want to clear) even if they don’t actually take any meaningful action within the app or get any value out of it. So having honest, tough love conversations about success at every level—the company-level, the product organization-level, the individual product team-level, and at the atomic project or task-level—is extremely important. You’re also counted on as a PM to balance what’s in the user’s best interest and what creates strategic value for the business. So this requires keeping a close pulse on what users are saying—what they love about your product, what they find obnoxious, how app store reviews are trending, what you can infer from the body language of interviewees in moderated testing, etc. And this also requires having a firm grasp on what’s going to move the needle for your business today, tomorrow, and a year+ down the line.
The 2) part of this statement is empowering your teams. Do I wish I knew how to code? Yes. Did I get the most liberal arts, touchy-feely undergrad degree possible (Medicine, Health & Society)? Also yes. To some, it might feel disenfranchising to not be able to get the work done yourself: you’re almost entirely at the mercy of your designers to breathe life into the vision, and your engineers to code that vision into existence. But I’d say this is part of what makes the PM role both challenging and fun. Since you can’t be the hands and feet on the ground, you’re working to constantly unblock those folks. If they’ve got a question—even if you don’t have the answer yourself, you’re out of your seat trying to get them the answer ASAP. If they present a set of choices or options—you’re getting the right people in the room to make an executive decision, or you’re weighing the right business and user outcomes to make that decision yourself. I’d say of all the cross-functional stakeholders I work with, I really care about getting my relationship right with my engineering and design partners—and making sure they’re feeling happy, motivated, empowered, and bought-in is a huge part of my job.
The last thing I’d highlight is delivering the right feature. Often, I see junior-level PMs take inventory of feature requests (or hate mail) from users and surface the most popular ones as items to insert directly onto the product roadmap. “16 people said they’d love us to build this new feature, we should build it!” A strong PM is able to peel back the onion, identify the root issue behind the feature request, figure out the best way to address that root issue, and then identify if/where it belongs on the product roadmap.
Let’s run through an example: say you’re a PM working on an app for an eCommerce brand. You get a lot of user feedback asking for the ability to virtually try on the clothing. Sure, that sounds cool and high-tech—you could bring it up to your team and see if there’s an out-of-the-box solution out there at a reasonable price point. But instead, you dig deeper and conduct some user research, upon which you have the epiphany that people are primarily asking for this feature because the brand’s sizing varies wildly, and it’s difficult to order the correct size. So the solutions you end up exploring are 1) figuring out ways to drive more consistency in sizing; 2) including models of different heights and body shapes in photography (e.g., the same SKU but size S is worn by a 5’8, athletic model and size L is worn by a 5’5, curvy model) and 3) experimenting with changes in the return / exchange policy.
Strong PMs are also always synthesizing new inputs, whether it’s a new user survey or external industry headwinds, into their roadmap, maintaining it as a living, breathing document. Product orgs will typically do quarterly planning and get together to ‘finalize’ a roadmap for the upcoming quarter, half or year—that’s a well-worn and important process, but it’s equally critical to not let that roadmap just become a stale artifact, against which teams just chug along oblivious to any new information that might warrant a change in priority or sequencing. Your roadmap should be outcomes-driven, and the source of truth for what’s most important to build as of today.
What does a week in the life of a PM look like?
I’ve now had PM experience at two very different companies. One was at a B2B2C mental health marketplace, where I owned a pretty vast, nebulous surface area that included payments, outcomes-based pricing, and the integration of our offerings with health insurance plans. My current role is at a B2C outdoor tech company, where I’m focused on enhancing the trail discovery experience for our users through search and personalization. But in general, here’s what an ‘average’ week might look like across both roles:
30% of the week = meeting with cross-functional partners such as my engineering and design counterparts, the marketing team, the data team, etc. including recurring touchpoints as well as project-specific check-ins. I devote a considerable amount of energy preparing for each of these meetings to make them a good use of people’s valuable time, so this includes evaluating whether we actually need to meet or not, thinking through a prioritized agenda given the desired outcomes of the meeting, reflecting on how to best socialize or get alignment on certain items, etc.
20% of the week = meeting with the Product team—including my weekly 1:1 with my manager, a touchpoint across the broader product team (inclusive of product managers, designers and researchers), and a smaller-group huddle just with other PMs to do a round table / solicit feedback on ongoing or planned work. This is a good time to calibrate on organizational priorities or share broader product management best practices
15% of the week = running or observing user research such as designing and administering a survey, sitting in on user interviews or moderated testing of the product, etc. Once user research is conducted, there’s also the work of synthesizing the key insights from the research and sharing it cross-functionally
10% of the week = writing tickets and running or attending sprint planning. This is another one that will really depend on the individual product org., but most operate in the ‘scrum’ style, which sets up 2-week cycles for engineering work, broken down into digestible ‘tickets’, to be completed. In my former role, I assumed the role of the product owner / scrum master, meaning that I was the one not only writing the tickets, but also assigning tickets to sprints and engineers and creating the sprints themselves. In my current role, I get to work with an awesome team of technical program managers who do most of that heavy-lifting and I get to focus on being crisp about communicating the why or the user value / business value behind what we’ve chosen to prioritize in a given sprint, and defining the tickets to include all the necessary context and information to empower an engineer to be able to run with it
15% of the week = creating and updating documentation including one-pagers (great perspective on the power of one-pagers here) and PRDs (product requirement documents) for use across the Product, Design, and Eng. teams
5% of the week = refining and continuously re-prioritizing the product roadmap by evaluating new inputs (e.g., new user pain points, ideas from a cross-functional product brainstorm, suggestions from the customer support team on the frontlines, etc)
5% of the week = holding space for informal coffee chats with folks and hosting team social events. I’ve unofficially assumed the role of social chair for every product team I’ve been on, so this is something I both enjoy and find to be valuable in creating relationships that are meaningful and don’t feel strictly transactional. Yes, I love icebreakers, sue me!
In sum: I love product management, and I’m super happy I chose to dive into this discipline. There’s nothing more motivating or exciting (okay, and at times a bit intimidating) to me than feeling like I have so much to learn. And for my consulting homies on this list, I can attest that it’s incredibly satisfying to be able to “ship” features vs. move boxes around slides. But wherever you are now, I’d encourage each of you to do some real soul-searching before investing too much time (and/or money) into barreling down the PM path just because it’s the hot job of the moment—and I hope this post helps. And you know what, read Inspired. It’s a classic.