What does a product manager do? 

If a product’s job is to solve a problem, what are the main responsibilities of a PM?

👋 Hi, I'm Jaryd. Welcome to this weeks Slice— the free weekly newsletter about product, startups, growth and working with people.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice

I surprisingly hear this question a lot, either directly or indirectly.

If you’re a product manager — you know what you do already, and this weeks read hopefully sums that up nicely and can help with a clear and comprehensive answer the next time someone asks you what is it you do.

If you’re a founder — understanding the PMs role can help you when you’re wearing that hat, and also when hiring and working with PMs.

If you work with a PM — this will give you more insight into what we do.


What does a product manager do?

If a product’s job is to solve a problem, the main responsibilities of a product manager are to

  • Identify customer problems that are worth solving;

  • Identify business opportunities;

  • Effectively communicate those to the right people;

  • Drive the strategic vision;

  • And work with a team to bring that vision to market. 

Product management involves balancing, prioritization and trade-offs, as, broadly speaking, we sit at the intersection of user experience, business, and technology. Below is a useful illustration of where the PMs responsibilities fall. 

User-Experience (UX):

The product manager is the voice of the customer, and you need to have a deep understanding of who they are and what their needs and motivations are, and how those are changing. This means speaking to the people who use your product, actively creating feedback loops, and listening with empathy.  When you’re working on a solution with designers or engineers, or speaking with stakeholders, you need to be the person who advocates for that customer -- you have to be able to speak on their behalf across the business and represent them.

A big part of this means being passionate about their experience using your product, and being in sync with your design team and ensuring they always have as much context and information as possible for them to make informed design decisions.

Speaking of user-experience: 

“I know this feature sounds exciting, but having spoken to a bunch of customers recently, this isn’t actually something that they care about, because....” 

“This design looks great, but before passing onto engineering we should prototype it with some users to get feedback and make sure it’s as easy and intuitive for them as we think!” 


Product management is a business function, and while you have to maximize value for the customer using the product and advocate for them, you also have to balance their needs with maximizing the business/commercial value of the product for your company. This means you have to have a deep understanding of the business, the market, the business model, company vision and your company's strategic goals and objectives. Fortunately, as you get more and more responsibility as a PM in your organization, especially at a startup or smaller business, you’ll very likely be working with executives in driving those things. 

Speaking of business: 

“Research shows that while there is a clear customer problem, there isn’t a big enough market of potential customers for our effort to have a worthwhile return on investment, and my recommendation is....” 

“One of the company’s primary objectives this quarter is to improve customer retention, and this projects main goal is to increase monthly subscriber retention from 10% to 12% in 60 days”


A big part of the product manager’s job is working to define what should be built to solve a particular problem. This takes into account customer and business needs.

Once you know what is being built, you have to have an understanding of how it will be built. Unlike your intersecting-roles within UX and Business, this doesn’t require you to have a deep understanding of the code. However, you should have a solid understanding of your product's technology-stack, and most importantly, you should understand how complex a certain solution will be to build and what an estimated level of effort is. This means knowing how to speak to the developers on your team, being able to ask them the right questions, and knowing when is the right time to get engineering involved.

It’s critical that you know, at least ball-park, what the level-of-effort (LOE) for something you want to build is. This is so you can communicate opportunities appropriately, make informed decisions, and be able to prioritize and allocate resources reliably. 

Speaking of technology: 

“Over the last 2 weeks we spoke to 15 customers to gather feedback after the release of our new payment feature, and based on that, we are thinking of making the following changes as per this design concept. Do you have some time before Tuesday to help with a rough LOE on this?” 

“We’re going to be building the following feature, and we expect it should take a 1 front end and 1 backend engineer a week to build it”

“We’re meeting today to decide on what project we should prioritize. We’ll discuss the problem being solved, opportunities, and goals for each, as well as the LOE”    

The voice of the customer, the company, and your team

A big part of the product manager's role is to be able to represent the customer when they are not in the room, as well as the company, or your team of designers and engineers.

Many roles in an organization are more siloed, however to be an effective PM that (1) brings products to market that solve worthwhile problems, (2) contributes meaningfully to the company that cuts your pay check, and (3) has credibility with your design and engineering partners -- you have to always balance the needs of the customer, company, and your team and their time. 

Being overly customer-centric at the expense of the company or your team, can lead to great solutions shipping to customers, but that have no commercial viability, and/or waste too many development hours (a very precious commodity). 

There is no science or predefined framework unfortunately about what the perfect balance looks like, however, whenever you're making a product decision, be sure to always have those stakeholders in mind and consider the cost-benefits to each of them.    


The Why, What, Who, When and How 

A PMs role is knowledge, insight and communication.

You’ll be in countless situations where you’re working to get buy-in from stakeholders, sharing updates with other team members, or providing context on a project to designers, engineers or people from other teams.

If you’re working on a specific initiative, you are the go-to-person that’s expected to be able to address any questions and drive the vision and direction for that project. The more you know and understand, and the better you’re able to effectively communicate that, the more alignment you’ll be able to achieve which is vital to your success as a PM.  

If you’re asking engineers to work on a project, but can’t explain the purpose of it and why it’s worth their time -- you’re going to lose a lot of credibility with your engineering partners which will make your job a lot more difficult. It’s about demonstrating trust. 

These are 5 questions you should know on deck and be able to speak to: 

  1. Why: The problem and the opportunity, and how this fits into the strategic direction of the company. Know the goals, which should be clear and ladder up to higher level strategic objectives, and have a hypothesis. This is where driving the vision, painting the big picture, and getting buy in really happens. The WHY is the most important question, and before you are confident with it, you shouldn’t be presenting anything to anyone and trying to get work done. If you don’t know WHY, then you’re still in the discovery phase (more in Section X), and you’re not ready to scope anything. The WHY is most important, because what you end up doing to address it can easily change. Always know and advocate for WHY, it's your secret weapon as a PM to align people. ]

  1. What: The solution to solving and addressing the WHY. This is what’s in scope, and essentially reads as “We’ve identified [the why], and we’re going to build [the what]. This can change, and often the initial WHAT is a recommendation, and based on feedback from other internal stakeholders, this solution -- in it’s idea phase -- iterates. 
    An important skill as a PM here, is to (1) be able to present the recommended WHAT persuasively, and (2) be able to talk about the alternatives and tradeoffs to this solution. This demonstrates your understanding and consideration as a PM.

  1. Who: The end user or customer for this product. Every product or feature has a target audience, and you need to be able to convey who that is, what their needs and motivations are, and in what context they have a specific problem that your solution will address. The more specific you can be about WHO this is for (even if that’s a very large segment of people), the more successful the product will likely be.

  1. When: The timing and priority of the project. You should be able to speak to where this fits into the roadmap, if there are any dependencies that need to happen before you can work on this project, as well as what the priority is (more on this in Section X). This information doesn’t just come from you, and involves getting feedback and collaborating with other partners on your team, but you need to know it, at least ball-bark. For instance, if you show up to a meeting with designers, and they ask you “What is the timeline for this, and when do we need to as a group review high-fidelity designs by?”, and you don’t know, that is poor project management and can lead to designers losing confidence in you.

  1. How: The technical implementation to solve the problem and build the product. Even if you have a technical background - this isn't your job to define. It’s very important not only to the success of the product, but also to your relationships with engineers at the company, to have them involved in scoping out the engineering solution to the problem and helping you with the HOW. You don’t have to understand exactly what the code means and get into the weeds of it, but you should know, high-level, what architectural changes are happening, if there any implications on data models, how much work is needed on the Front-End (FE) and Backend (BE), and the complexity of the work do be done. Your engineering partner is essential here.

Have any thoughts, questions or feedback? 👇

Leave a comment

Every week, I write about product, startups, growth, working with people, and anything else that I’ve found helps me have a happier and more meaningful career in product management

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇