Career FAQs: Product Management

This post is part of a series of posts answering the questions that people on LinkedIn most commonly ask about my career. Other posts in this series cover working at Google, accessibility, and generative AI. Each post covers what it’s like working in that area and tips on how to get into it yourself.

What’s it like being a product manager?

What I love about product management is how broad and varied the role is. I work with people in all sorts of roles and all levels of seniority. I spend a lot of time connecting with people in meetings, yet also have time for deep work. I do big-picture strategy and still weigh in on the details. I work on multiple features in different stages of development, so I might be working on defining one feature while validating another and shipping a third. The work pushes me to grow in all sorts of ways.

Product management also has its share of challenges. As the person setting the vision, I have to guess and shape the future. It takes a strong mix of confidence and humility to put forward a nascent vision and see if people buy it. Even when the team gets excited about a vision, often we run into obstacles or the circumstances change. Then I have to revise the vision and bring the team along with the new plan.

Another challenge is context switching. With such a varied role, I’m constantly jumping from one task to another. I have to be intentional about prioritizing requests and carving out time to focus.

To give a more concrete picture of the role, here’s how my day might go (and below that, advice on how to get into product management).

9 AM: Product design

I hop on the walking desk and try to get in some deep work before the day gets hectic. I start a PRD to define how the next feature should work and why. I had already made a long list of brainstorming notes, so it was time to try to pull it together into a coherent plan.

After an hour, I had the basics down, but the PRD was still feeling a little fuzzy. I tried writing down several different ways users might behave and grouped them into categories. Then I cross-checked the categories with some UX research. Thinking about the user journeys by category helped me identify some details I could clarify and increased my confidence in the design. I send the draft PRD to my design lead for feedback.

11 AM: Email

Time to dig out some email. A junior designer has left a comment in Figma that some new mocks are ready for review. The mocks look good, but a few states are missing. I respond, how does the user save their creation if they want to share it later?

I also read an email from one of my engineers: she wants to know if she can use a certain dataset. I shoot off an email to Legal and Privacy for confirmation. I make sure to include context about how we plan to use the data to help them make an informed decision and minimize back-and-forth.

12 PM: Lunch

Yum.

1 PM: Team meeting

California is online now, so it’s meeting time. I have a team meeting where we share status on several projects. I make a point to thank a few individuals for particularly good work; I care about making people feel seen and appreciated.

I reinforce which projects are highest priority and confirm that we’re still on track to run the upcoming user study. The prototype is built, we have mocks ready for the pieces we haven’t implemented yet, and the participants are scheduled. I make a note to retest the flows myself, to try to catch any major issues before the study.

2 PM: One-on-one meetings

I meet with an engineer who has been collaborating with me on analyzing some log data. When I have a hunch, he pulls a data slice into a spreadsheet to make it easy for me to dig in. It’s silly how much I enjoy color-coding spreadsheets. It’s satisfying to format the data with color scales and watch the patterns pop. Anyway, one of the patterns I found seems pretty improbable, so we talk it over. Seems like the data might include some cases that we should be filtering out. I’ve come to learn that data is nothing without context on how it was collected and defined, so it’s great that this engineer can provide that context.

I also meet with my program manager, who is in charge of the project timelines. I decide which marketing event we’re targeting and he fills in the intermediate milestones like reviews, internal testing, and QA to make sure we launch on time. He manages the team’s project tracker and keeps it up to date. I’ve done this kind of work myself on other teams, but it’s really nice to get to collaborate with a program manager. Having him do the tracking frees up my time for bigger picture vision and strategy work.

3 PM: Gen AI

I’m feeling a little afternoon slump, so I switch to a lighter task. On one of my Gen AI projects, we recently tested a new prompt on our eval dataset. We have the model output, but we don’t know if it’s good. We haven’t built an auto-rater yet, so I score a few dozen results by hand. It’s a little tedious, but it’s important for giving me a nuanced understanding of what the model does and does not do well.

I notice that some of the outputs are too long, so I add Concise to our rubric with some examples. This should help us prompt an auto-rater model to understand how to classify results correctly.

Then I jump to another 1:1 meeting, this time with an engineer to talk about implementing our gen AI safety policy.

4 PM: Presentation prep

I have an exec review coming up, so I open up the slide deck I’ve been working on. In these reviews, I try to leave plenty of time for discussion and feedback, so I move some nonessential slides to the appendix. I also clean up the formatting a bit. The slides don’t need to be super slick, but I want to make sure the layout guides the VP to focus on the most important content.

5 PM: Review for Marketing

One of my projects is about to launch, so before I head out, I check on all the pre-launch work: blog post draft, press info sheet, help center article. I quickly make some edits to the info sheet and send it back to Marketing.

Then I hop on my bike and head home.

How can I get a job as a product manager?

The first question most people have when thinking about getting into product management is, how is product management different than program management or engineering management? Here’s how I see it:

• Product managers are responsible for the vision and strategy, based on what benefits users and the business. They decide what to build and why. If you think big-picture, empathize with people, and are a compelling communicator, this might be the role for you.
• Program managers are responsible for the timeline, including tracking projects, writing status updates, and coordinating multi-team efforts. They focus on when. If you’re super organized, always follow up, and love planning the details, this might be the role for you.
• Engineering managers are responsible for the engineering and the engineers. They decide how to build the product and who should build it, accounting for each engineer’s skills, preferences, and career trajectory. If you’re highly technical and care about helping individuals succeed, this might be the role for you.

People get into product management from all sorts of roles. I had been working as a software engineer, a much more specialized and solitary role which was a terrible fit for my personality but a solid foundation for getting into product. Other common career paths are from design, marketing, user research, business, program management, and data analytics. Product managers need a bit of all these skills, so any is a fine starting point. The key is develop basic proficiency in all the other roles.

If you’ve decided that product management is the role for you, I suggest watching lots of mock interviews on youtube.com/@tryexponent. These videos give a good sense of how product managers are expected to think and will prepare you for interviewing. I watched so many of these before my PM interviews.

If you want a more tangible sense of what product management is like, or you’re having trouble getting your foot in the door, try designing a product yourself. You don’t have to have a million-dollar idea. Just pick a problem that you’re interested in solving. Identify who has this problem and focus in on a narrow segment. Then brainstorm a bunch of solutions and justify which seems most promising. Make a prototype and do some user testing to validate it. Write down your ideas and decisions as you go. Turn that into a blog post about what you tried and learned. Even if you never build out a solution, going through these steps will give you a more concrete sense of what it’s like to do this work. Talking about your project in interviews will demonstrate your credibility and hustle.

Best of luck!