What Is Product Management?

Early in my career, someone asked me what a product manager does. I gave a ten-minute answer that involved strategy, roadmaps, customer research, cross-functional alignment, stakeholder management, and agile ceremonies. When I finished, they said, “So… you go to meetings?” I laughed, but the question stuck with me. If I could not explain my own job in a sentence, maybe I did not actually understand it yet.

It took me years to get to a simple answer. The core job of product management is to figure out the most important customer problem to solve — and then determine the best thing to build to solve it. That is it. Everything else — the roadmaps, the specs, the stakeholder updates — is scaffolding around that central act of judgment.

What Is Product Management?

Product management is the discipline of discovering what to build and why, so that engineering, design, and the rest of the organization can focus on building the right thing well.

The PM does not write the code. The PM does not design the screens. The PM does not sell the product. But the PM is responsible for making sure the thing that gets built is worth building in the first place.

Marty Cagan, in his book Inspired, frames this as the PM being responsible for ensuring that what gets built is valuable (customers want it), usable (they can figure it out), feasible (engineers can build it), and viable (the business can sustain it). Of those four, value and viability are squarely the PM’s territory.

Ken Norton, in his influential essay How to Hire a Product Manager, described the PM as someone who combines elements of engineering, design, marketing, and business — a leader who earns authority through judgment rather than title. I think that captures something essential: you are responsible for the outcome, but you control almost none of the inputs.

The Two Spaces

The simplest way I have found to explain what a PM does day-to-day is to split the work into two spaces.

The Problem Space

This is where you figure out what problem to solve. You talk to customers. You study the data. You map the market. You understand what people need, what frustrates them, and what they are trying to accomplish. Teresa Torres calls this continuous discovery — the habit of maintaining weekly touch points with customers so you always have fresh data when decisions need to be made.

The problem space is where most PMs underinvest. It is tempting to skip ahead to solutions because solutions feel productive. But a beautifully executed solution to the wrong problem is still a failure. Understanding who your customers actually are and what they struggle with is the foundation of everything that follows.

The Solution Space

This is where you figure out what to build. You write the spec. You work with design on the experience. You scope the work with engineering. You make trade-offs about what to include and what to cut.

The solution space is where most people think the PM job lives. And it does — partly. But the solution space only works if the problem space did its job first. The order matters: problem first, then solution. Always.

Cagan calls this “product discovery” — the process of testing whether your proposed solution actually solves the problem before you commit engineering resources to building it. The best PMs I have worked with spend at least half their time in the problem space, even when everyone around them is pressuring them to “just ship something.”

The Core Responsibilities

If the two spaces define what a PM thinks about, here is how they spend their time. Lenny Rachitsky, in his newsletter, breaks the PM role into three areas: shape the product, ship the product, and synchronize the people. I would frame it slightly differently.

Decide What to Build

This is the heart of the job. Given limited resources and unlimited possibilities, what should the team work on next? This requires understanding the customer, the business, the technology, and the competitive landscape — and then making a call. As Ben Horowitz wrote in his classic memo on product management, a good PM takes ownership of the product’s direction and makes decisions based on customer needs, not internal politics.

Prioritize and Sequence

Deciding what to build is hard. Deciding what to build first is harder. Every feature request sounds reasonable in isolation. The PM’s job is to see all of them together and choose the sequence that creates the most value fastest. This is where the Strategy Pyramid becomes essential — it gives you a framework to evaluate whether a given feature serves the strategy or just sounds like a good idea.

Align the Team

A PM who makes the right decision but cannot get the team to execute on it has accomplished nothing. You need engineering to understand why they are building this. You need design to understand the customer pain. You need leadership to understand the trade-offs. This is not about slides and status updates. It is about giving people enough context to make good decisions on their own.

A Concrete Example: ProjectFlow

To make the discussion more concrete, imagine a company called ProjectFlow that builds a project management tool for creative teams. They have 50 customers and a team of eight.

The PM at ProjectFlow gets a request from their biggest customer: “We need Gantt chart dependencies.” The sales team is excited. The customer is excited. It seems obvious.

But the PM steps back into the problem space. She asks: what problem are dependencies solving? After three customer interviews, she discovers the real issue is not dependencies — it is that team leads cannot see when one person’s delay will affect someone else’s deadline. The customer said “Gantt chart” because that is the tool they know. The problem is visibility into blockers.

Now in the solution space, the PM works with design on three options: full Gantt dependencies (six weeks of engineering), a simpler “blocked by” tag on tasks (two weeks), or an automated daily digest showing at-risk deadlines (one week). She evaluates each against ProjectFlow’s product vision — “every team ships with confidence” — and their strategy of simplicity over power.

She chooses the daily digest. It solves the real problem, ships in a week, and aligns with the strategy. The customer is happy. The sales team is happy. And the PM protected six weeks of engineering time that can now go toward the next most important problem.

That sequence — hear the request, dig into the real problem, explore multiple solutions, choose based on strategy — is product management in practice.

What Product Management Is Not

One of the most persistent confusions is between product management and project management. The names are similar. The work sometimes overlaps. But they are fundamentally different disciplines.

A project manager asks: How do we deliver this on time and on budget? A product manager asks: Should we be building this at all?

Project management is about execution. Product management is about direction. Both are valuable. But confusing them leads to PMs who spend all their time tracking tickets and running standups, and none of their time talking to customers or questioning whether the roadmap is right.

If you find yourself spending most of your week on timelines, status reports, and coordination — and almost none of it on customer problems and strategic choices — you might be doing project management with a product management title. That is not a judgment. It is a signal that the role might need to be redefined.

Why This Matters

Product management matters because someone has to own the “why.” Engineers own the “how.” Designers own the experience. Sales owns the revenue. But the PM owns the question that precedes all of those: why are we building this, and why now?

Without that function, teams drift toward building what is easy, what the loudest stakeholder wants, or what competitors already have. They ship features without conviction. They fill roadmaps without strategy. And they discover, months later, that nobody wanted what they built.

A good PM is the person who prevents that drift. Not by having all the answers, but by asking the right questions at the right time and making sure the team solves problems worth solving.

How to Use With AI

AI is useful for the parts of product management that eat up time without requiring deep judgment. Think of it as a research assistant that never gets tired.

Synthesize customer feedback at scale: paste a batch of support tickets, NPS comments, or interview transcripts into an AI tool and ask it to group the top five themes with representative quotes. What used to take a full day of reading now takes minutes. The PM still decides which theme matters most — that is judgment — but the sorting is mechanical.

Stress-test your prioritization: describe your top three priorities and ask the AI to argue the case for each one, then argue against each one. This surfaces blind spots you might miss when you are attached to a particular direction.

Draft the spec, not the strategy: AI can write a solid first draft of a product requirements document given a clear problem statement and constraints. Use it to compress the blank-page phase, then edit for nuance and context that only a human with product judgment can add.

Guardrail: Never let AI make the prioritization call. Deciding which problem to solve is the PM’s core judgment. AI can inform that decision with data, synthesis, and alternative perspectives. But the final call — what to build and what to say no to — must come from someone who understands the customer, the business, and the team.

Conclusion

Product management is not about having all the answers. It is about asking the right questions. What is the most important problem our customers have? What is the best thing we could build to solve it? And what should we do first?

If you get those questions right, the roadmap writes itself. If you get them wrong, no amount of execution will save you.

This is not a formula. You will need to adapt these ideas to your context — your company size, your market, your team. But the core remains: problem space first, solution space second, and always, always own the “why.”

What do you think? Comments are gladly welcome.