What a product manager actually does

Ask ten companies what their product manager does and you will get ten answers. In one firm the product manager writes tickets all day. In another they set strategy and barely touch the backlog. In a third they are a project manager with a nicer title. The confusion is understandable, because the role sits between business, design and engineering and borrows a little from each.

This guide sets out what the job is, the two kinds of work it contains (discovery and delivery), how it differs from nearby roles, and what a sensible week looks like. It is written for founders hiring their first product person, managers inheriting a product team, and analysts thinking about moving into the role.

The job in one paragraph

Wikipedia’s entry on the product manager describes someone responsible for developing an organisation’s products who owns product strategy, specifies functional requirements and manages feature releases. They coordinate engineering, design and data people and are accountable for product outcomes. Most product managers have no direct reports, so they lead through influence rather than authority.

The important word there is outcomes. A product manager is judged on whether the product gets better at solving a customer problem in a way that also works for the business. Everything else in the job is a means to that end.

Four risks the product manager has to answer for

Marty Cagan of Silicon Valley Product Group gives a useful way to split the work. In his article on the four big risks he says every product idea carries four risks, and assigns an owner to each:

• Value risk (product manager): will customers buy it, or users choose to use it?
• Usability risk (product designer): can users figure out how to use it?
• Feasibility risk (lead engineer): can the team build it with the time, skills and technology available?
• Business viability risk (product manager): does it work for the rest of the business, including sales, finance, legal and brand?

Two of the four sit with the product manager. That is a good summary of the role: make sure the team is building something people want, and make sure the business can live with it. Design and engineering own the other two, but the product manager needs to understand them well enough to make trade-offs.

Discovery and delivery: two kinds of work

Product work splits into two streams that run at the same time.

Discovery is deciding what to build. Cagan, writing on product discovery, says it has two goals: to find out whether there are real users who want the product, and to find a solution that is usable, useful and feasible. He warns that teams who skip it end up “using the engineering organization to build a very, very expensive prototype”.

Delivery is building and shipping what discovery has justified, to a quality standard, on a predictable rhythm. This is where backlogs, sprints, acceptance criteria and release notes live.

Jeff Patton, who popularised the term dual-track development, makes two points worth repeating. First, discovery aims for fast learning while development aims for predictability and quality, so they need different habits. Second, the two tracks are two kinds of work, not two teams. He writes that “the most expensive way to test your idea is to build production quality software”, and that a team doing discovery well will “substantially change and kill lots of ideas”.

A product manager who only does delivery becomes a ticket writer. One who only does discovery produces research nobody builds on. The job is to keep both moving.

Product manager, product owner, project manager

These titles get mixed up, and the mix-up causes real friction.

In small companies one person often does the first two. That is fine, as long as the backlog work does not crowd out the discovery work. Wikipedia notes that a product owner’s focus is mainly on building the product rather than its long-term market success, and that the role may end with the project. A product manager’s does not.

What the week actually looks like

An example (illustration only). Priya is the only product manager at a 25-person software company that sells booking tools to physiotherapy clinics in the UK. A normal week for her might include:

• Two customer calls with clinic managers about how they handle cancellations (discovery).
• Reviewing last month’s numbers on how many new clinics take their first online booking within a week (outcomes).
• A one-hour session with the designer and lead engineer sketching three ways to reduce no-shows, then picking one to test with a clickable prototype (discovery).
• Backlog refinement and sprint planning with the team for the work already agreed (delivery).
• A conversation with the finance lead about whether SMS reminders would push costs above what the cheapest plan can carry (viability).
• A short written update to the founders on what the team learned and what it plans to try next.

Notice what is missing. Priya is not designing screens or writing code. She is not deciding alone. Her value is in asking the right questions, getting evidence and making sure the team works on the problem that matters most.

Common mistakes

• Acting as a feature broker. Collecting requests from sales and big customers and passing them to engineering without asking what problem sits behind them.
• Measuring output. Celebrating releases instead of checking whether a customer behaviour or business number moved.
• Doing discovery alone. Running interviews without the designer and engineer means they hear the findings second-hand and trust them less.
• Owning every decision. The product manager owns value and viability. Usability and feasibility belong with design and engineering, and overriding them wastes their expertise.
• Letting delivery eat the calendar. When sprints are busy, discovery is the first thing dropped. Protect a few hours a week for it.

When you need one, and when you do not

A founder with a handful of customers and two engineers usually is the product manager, and should be. Hiring one too early can put a layer between the founder and customers at the stage when that contact matters most.

The need grows when the founder can no longer talk to customers every week, when engineers are regularly building things nobody uses, or when several teams are pulling the product in different directions. At that point a product manager earns their salary by deciding what not to build as much as what to build.

If you are hiring, test for judgement, not tools. Ask candidates to talk through a product decision they got wrong, what evidence they had, and what they would do differently. Someone who can explain the value and viability risks in their own past work is likely to handle them in yours.