Things that PMs Do

Attend meetings, take notes, create tickets, document stuff, scribble on whiteboards, crawl on Medium/Quora/Product Hunt, gawk over new apps, fill my home with every gadget I could afford…

If you asked me what I do as product manager, that’s how I would ramble on.

The truth is that product management is a type of general management. At the end of the day, I’m accountable for the success of a product line or business unit, not completing a specific set of tasks.

Over the past year, I’ve talked to a number of companies about what their PM roles look like. I’ve also scoured Quora and Medium to look for the best PM role definition and the most succinct one I found is from this post: help teams ship the right product.

To me that definition breaks down into 3 responsibilities:

  1. Choosing the right problems to solve
  2. Coming up with the best solutions
  3. Ship the solutions

I’ll describe how each responsibility maps to day-to-day tasks for a software product manager.

Choosing the right problems to solve

PMs identify the most impactful problems to solve for the business within the domain of their ownership.

market research

PMs look for the unfilled needs in the market. What do the competitors offer and how can we be better? For example, Amazon offers two-day shipping, can we do same-day shipping? At a large company, this task can be split amongst PMs, product marketing, business development, business analysts and upper management.

customer research

PMs identify the pain points of existing customers. They spend a lot time reading over institutional and industry customer research and assisting with research planning or actually conducting interviews.

measure every part of the product

PMs know where their product is broken through quantitative metrics. If the product is a series of actions (funnel) that a customer completes, like a checkout experience, the PM knows where the biggest drop-offs are.

estimating the opportunity

Once PMs have a list of problems that could be solved, they prioritize that list based on opportunity, which is typically measured in terms of a business Key Performance Indicator (KPI), like conversion or revenue. For example, if we solve this problem, how much additional revenue would we bring to the business?

Coming up with the best solutions

After identifying the right problems to address, PMs must decide on the best solution for each problem.

competitive analysis

PMs intimately know their competitors and the solutions their competitors provide for customers. They know when to copy and when to innovate. See Instagram Stories vs Snapchat.

keeping up with trends

PMs are tapped into the pulse of the industry and technology trends. They read articles, subscribe to newsletters and attend conferences and meet-ups. They look for possible solutions from integrating with a new technology or jumping early onto a consumer trend.

solicit ideas and input

PMs know the best ideas often don’t come from themselves. They solicit ideas from their team and stakeholders because PMs are often not the domain expert or the most experienced and people closest to the problem tend to have the best solutions.

building a roadmap

After all the best solutions have been collected, PMs prioritize them into a product roadmap. Prioritization is a deep topic that deserves its Medium post, but at a high-level, PMs weigh the estimated impact (ability to address the KPI opportunity of the original problem) against cost (design, eng, operations, financial) and risk (likelihood to achieve impact)

Ship the solutions

For each prioritized product solution on the roadmap, PMs lead their team to ship the solution to their customers.


PMs break-down a given solution into functional requirements — units of customer experience that a designer can turn into designs, which can be then turned into code by an engineer.

project management

The process of building each solution is a project that PMs lead from start to finish. In software development, PMs usually use either Agile or Waterfall methodology (there are shelves of books written on each so I won’t go into details here).

stakeholder buy-in

PMs often need to get buy-in from cross-functional stakeholders like Legal, Customer Support, Risk Operations before launching a solution that could impact the jobs of those stakeholders. After the initial buy-in, PMs also have to keep the same stakeholders up-to-date on any changes in the plan or new decisions. I’ve personally done demo presentations, status emails and recurring check-in meetings.

quality assurance

PMs make the final call on whether the solution is ready to ship to customers. They must feel confident in the quality of the work before putting it into customer hands which means they must personally test all the sunny-day flows and edge cases. Bad PMs tend to skip this step and rely on the judgement of their QA staff or engineers and ends-up shipping a lower quality product.

early validation

PMs seek early validation on a solution before shipping it to the entire customer base. They tend to validate through a beta program, conducting customer research using prototypes or running an AB test. If the user feedback or test results are negative, PMs must decide whether to shut down the project completely or pivot and iterate based on new insights. Good PMs keep product solutions in this stage until the original problem is addressed with measurable success.

launch communication

When a solution is validated and ready to launch to all customers, PMs are responsible for communicating the launch to their stakeholders and customers. They are responsible for clearly articulating the impact and values of the launch for both the customers and the business. PMs typically work with their public relations, product marketing and customer support teams to craft blog posts, help content and press releases and also conduct press interviews as necessary.

When is the job done?

Never. There are infinite problems to solve in any product domain, especially as technology and consumer behavior are always changing.

PMs don’t pat themselves on the back and retire when they’ve shipped everything on their roadmap…they repeat the entire process all over again for the next business cycle :).