🧭What is Product Management

The classic Marty Cagan definition

The clearest framing comes from Marty Cagan: a product manager is responsible for discovering a product that is valuable, usable, and feasible. Three words doing a lot of work:

• Valuable — customers will buy it, use it, or recommend it (depending on your business model). This is the PM's primary territory, in close partnership with design (the usability side) and engineering (the feasibility side).
• Usable — your customers can actually figure out how to use it. Designers lead here, but the PM owns whether the team is solving the right user problem at all.
• Feasible — engineering can build it within constraints. Engineering leads, but the PM has to understand enough about technical feasibility to scope ambitions correctly.

What the role is not

• Not a project manager. A project manager runs schedules, dependencies, and status. A PM cares about all of that as needed, but their primary job is judgment about what to build, not logistics.
• Not a feature factory worker. If your job is to take feature requests from sales/executives and hand them to engineering, you're not really doing product management — you're doing requirements coordination. Real PMs push back on what's being asked, validate that the underlying problem is real, and reshape the solution.
• Not the "CEO of the product." This old cliché does damage. PMs almost always lead through influence, not authority. You don't have the unilateral decision rights of a CEO — you have to earn buy-in.
• Not the spec writer. Writing the PRD is one output. Many great PMs write very few documents because the company has a strong design or engineering culture and most decisions happen in conversation.

What the PM actually does, day-to-day

The PM's calendar usually has six categories of work:

1. Discovery — customer interviews, data analysis, prototypes, competitive teardowns. The point: figure out what's worth building next.
2. Definition — translating discovery into the briefs / PRDs / scope decisions that let engineering and design execute.
3. Delivery — unblocking the team. Answering questions, making trade-off calls, removing dependencies.
4. Measurement — instrumenting features, watching the metrics post-launch, deciding whether the experiment was a win or to roll back.
5. Stakeholder communication — keeping leadership, sales, support, marketing, and other product teams informed enough to do their jobs.
6. Strategy — every few months, lifting up to think about where the product is going, what bets to make, and how to allocate the team's attention.

How the role changes by company stage

The job at Google is not the job at a Series B startup. Roughly:

• Pre-product-market-fit (seed → Series A): the PM is often the founder, or barely a separate role. Job is to find the customer and find the problem. Heavy on discovery, light on process.
• Scaling (Series B → D): PMs are hired, processes start to form. Job is to take a working product and find more growth — new segments, new features, new geographies.
• Big tech / enterprise: layers of PMs, deep specialization (growth, platform, ML, infra), longer decision cycles, much higher stakeholder load. Job is often as much about navigating the org as it is about the product.

What hiring managers actually filter on

Across thousands of PM interviews, the things that get people hired in roughly this order:

1. Product sense — you have opinions about products, you can articulate why a design choice is good or bad, you can spot the problem a feature solves.
2. Execution — you can take an ambiguous goal and turn it into a shipped result.
3. Analytical rigor — you reach for data and frameworks instead of vibes.
4. Communication — you can write clearly and speak persuasively to engineers, executives, and customers.
5. Leadership — you can rally a team without authority.

Everything else (technical depth, domain expertise, MBA, etc.) is a tiebreaker, not a primary filter. Internalize this and you'll spend your prep time correctly.