Unit 1: What product management actually is (and isn't)

Learning objectives

By the end of this unit, you should be able to explain what a product manager does in clear terms, distinguish product management from project management and program management, and understand why the PM role exists in the first place.

Video script

Reading material

The real job

Product management sits at the intersection of business, technology, and user experience. This is a common framing, and it's roughly accurate, but it can make the role sound more balanced than it actually is. In practice, most PM work leans heavily toward one of these areas depending on the company, the product, and the stage.

At an early-stage startup, the PM (often the founder) is mostly focused on user problems. The business model is uncertain, the technology is evolving, and the most important question is "are we building something people want?"

At a growth-stage company, the PM is balancing user needs with business goals. There are revenue targets, market positioning decisions, and competitive dynamics to consider alongside what users need.

At a large enterprise, the PM is often navigating internal complexity as much as external user problems. There are multiple stakeholders, legacy systems, platform considerations, and organizational politics that shape what's possible.

None of these contexts is "right." They're just different, and understanding which context you're in helps you focus on the right things.

What a PM is not

A PM is not a CEO of the product, despite a famous essay claiming otherwise. You don't have authority over anyone. You influence through persuasion, not through a reporting line. This is both the hardest and most rewarding part of the job.

A PM is not a feature factory operator. If your job consists of taking requests from stakeholders and turning them into Jira tickets, you're doing project management with a product title. This is common, and it's worth recognizing so you can work to change it.

A PM is not a data scientist who also writes requirements. You should be data-informed, not data-driven. Data tells you what happened. Judgment tells you what it means and what to do about it.

The PM in an AI world

AI is changing the execution speed of product development, but the fundamental PM responsibilities remain: understand the customer, define the strategy, prioritize ruthlessly, and align the organization. What's changing is the pace at which these responsibilities cycle. When you can prototype and test ideas faster, the discovery-decide-build-learn loop tightens, and the PM needs to keep up.

The PMs who will do well in an AI-augmented world are the ones who use the speed gains to learn faster, not just to ship faster. We'll explore this in much more detail in units 10-12.

Practical exercise

Exercise: PM role audit

Find three product manager job postings for companies you find interesting. Read them carefully and categorize the responsibilities into four buckets:

1. Discovery work (understanding users, researching problems)
2. Strategy work (prioritization, roadmapping, vision)
3. Execution work (writing specs, managing backlogs, tracking delivery)
4. Alignment work (stakeholder communication, cross-team coordination)

Notice the balance. Which bucket dominates? What does that tell you about how that company thinks about the PM role? Would you want to work there?

Write a short reflection (200-300 words) on what you found and which type of PM work appeals to you most.