First-Time Product Manager? This Will Help You Be A Great One.

Nicole Zhao
Photo by Matthew Henry from Burst

The product management job is still fairly new, fairly mysterious, and fairly confusing. If you’re not sure what the heck PMs actually do all day, you’re not alone. What purpose do they serve in the company? Sure they decide where the product roadmap is headed, but what does that really mean?

I recently began my second co-op term in product management at Top Hat and I wanted to give my two cents about my learnings from mistakes I made and things I wish I knew when I started. For anyone interested in learning more about the craft, or new product managers wondering what to expect from the job, I hope this lowers your eyebrows.

So what do PMs actually do?

A product manager can make or break a product because in short, they are responsible for the direction of the product. That’s a lot of pressure on your shoulders, but worry not, you have your whole team to assist you in every decision you make. Talk to them. They are experts and they want to help make the company better.

At a high level…

Product managers make decisions about what to build. This means balancing the needs of customers with the wants of each team in the company. Here’s a sense of what that can be like: Sales could want something that customers are requesting in order to close a deal. Marketing could want a shiny new feature that will drive new enterprise value. Support could want you to fix a bug that’s creating a lot of noise. Legal could be asking you to migrate databases between servers in different countries because of new data privacy laws. And the whole time, engineering could be asking for more resources because they already don’t have enough people to maintain the existing architecture. It’s your job to decide which to choose… if any.

At a granular level…

Day to day tasks vary for PMs between different companies or even within the same company. For the most part, I’ve found tasks to revolve around communication, prioritization, definition, and alignment. I won’t dive too deep into this part, but let’s just say, it involves a lot of meetings.

Here are a few things I’ve learned

Actively listen

From your first day of on-boarding, you will be bombarded with information like who’s who, current projects, re-structuring of the company (I’ve gone through 2 of those so far), tools to use, business strategy, customer personas, and how the coffee machines work. You get the idea, anything goes. Get used to it because it’s no accident. You are the bearer of all information (except for that last one maybe). A great starting point is to listen actively during every meeting. At any given point, there are a thousand moving parts in the company and any small piece of information you picked up during a meeting could be an important one. Ideally, PMs have both full breadth and depth in knowledge of all things in the company that is updated in real time. Obviously, that’s not possible, but by actively listening in every conversation, we’re able to get as close as we can.

There is always more you can do

Product managers create their own schedules and make up their own work. At any time you could stop and have done enough to enable your team to function okay. But there’s always more work that could be done, whether that’s looking back at your work, talking to more people, writing up documentation, internalizing learnings from the day, reviewing the roadmap, automating SQL queries, or reading through Jira tickets to gain more technical knowledge. The list goes on. Point is, you will never be done all your work because there is always more that could be done.

Your common sense is not enough to back your decisions

You probably gathered from earlier that a large part of product management is making the tough calls. Although it may seem like common sense to you to make one decision over another, your common sense is only built from the information you know. And that’s almost never enough. Decisions and prioritization should always be backed up with sound qualitative and quantitative reasoning. A good place to start is the triad of product: customer viability, business viability, and technological feasibility. You’ve probably heard some version of that before, but to make it useful, use it to ask yourself questions like:

  • How do we know customers actually want this? Data? User research?
  • Does it align with the company’s strategic objectives for the current period? Is it an interruption to current projects/roadmap? Is that fine?
  • Do we have the resources to make this happen? In time?

Use these guiding questions and other decision-making/prioritization frameworks like RICE and SWOT, because the obvious right choice to you may not actually be the right choice for the product or the company.

End every interaction with next steps

We’ve all been in meetings that get heated in discussion and everyone has an opinion and is pressed for time before the next meeting. It seems like you’re leaving more confused than when you came in. It’s important for a product manager to be able to steer the conversation in the right direction while not suppressing any opinions or new facts. And after everyone has expressed their opinions and thoughts it’s your job to outline actionable next steps. Did you figure out everything you needed to? If yes, do you need to document it? Can you proceed with engineering estimates for the project? Do you need to get it approved by other product people? If no, are there further conversations you need to have and with who? Should you be running tests or research to help you make a decision? Everyone should leave your meeting with a clear summary of what has happened and what they need to action on moving forward. This applies for any informal conversations as well; don’t end any encounter in confusion.

Think back to strategy

You can think about strategy like a tree. There’s one company level objective, perhaps to grow a specific product line, penetrate a new market, or perfect a business model. That can be broken down further into team level objectives, maybe one for each step in the funnel. Those are perhaps then split into project level objectives. In this generalized and simplified model of objectives in a company, you may be responsible for a project at any point in the tree of objectives. It can be easy to get caught up in the day-to-day and lose sight of the North Star company level objective/mission that each task should ultimately align with.

Write things down

Every day is filled with learning opportunities, and sometimes you experience problems and learnings you may not experience again for a long time. Write down your ideas, learnings, and notes from meetings, then take time at the end of the day to reflect on and internalize them. I’ve found it incredibly helpful to remember takeaways from each day and consciously reflecting on learnings.


Of course, all I’ve said should be taken with a grain of salt. Product management is still an elusive craft and each great PM is great for a different (but clear) reason. I’m still trying to find ways to highlight my strengths and compensate for my weaknesses. I look forward to learning every day on this ever-challenging and ever-rewarding journey.


Thank you to Top Hat for giving me opportunities to grow and learn, and for trusting me to take the reins.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade