If you’ve scrolled through a PM job posting lately, you’ve seen the script: “Shape the vision. Drive strategy. Own the roadmap. Be the voice of the customer.” It sounds grand. It sounds like leadership. It sounds nothing like the job.
Here’s what product management actually is: a constant negotiation between what you want to build and what you can build, with an audience that keeps changing the rules midway through.
My first week working alongside PMs in corporate learning, I watched someone spend three hours arguing about whether a checkbox should be checked by default. On the surface, absurd. Below the surface, she was trying to solve a real problem: thousands of company administrators would make a decision in forty milliseconds, and if we defaulted the wrong way, we’d either break hundreds of workflows or create an impossible administrative burden. That’s product management. Not the version on the job posting.
A PM’s actual day is about seventy percent unglamorous. You’re writing a requirements document that keeps growing and won’t stop. You’re sitting in a meeting where engineering, design, and sales are talking past each other, each one right in their own frame. You’re taking a customer call where someone is describing a problem so badly you have to translate it into what they actually need. You’re explaining to a stakeholder why their pet feature isn’t on the roadmap, again, for the fourth time this quarter. You’re making a decision based on sixty percent of the information you’d like to have, and you’ll find out in three months whether it was right.
The other thirty percent is what makes it interesting. When you ship something that works. When you realize the problem you’re supposed to be solving isn’t the problem at all, and you pivot. When a customer tells you the feature you built solved something completely different, something more valuable. When the numbers prove your intuition was wrong and you get to be surprised by what users actually want.
The confusion between product management and project management is worth untangling, because companies treat them like the same thing and they’re not.
Project management is about delivery. The how and when. You’ve got a scope, a timeline, dependencies, resources. You’re asking: Can we build this? When can we have it? What are the risks? A project manager is comfortable with constraint and detail. They track whether you’ll make the deadline. They’re invaluable.
Product management is about direction. The what and why. You’re asking: Should we build this? Who needs it and what does it actually solve? What happens after we ship it? A PM is responsible for the fact that you’re building the right thing, and then responsible again if you’re not.
Some organisations keep these roles separate. Most smaller SaaS companies merge them because they can’t afford not to, and the best project managers in those companies often have instincts for the product questions too. But if you’re hiring, or being hired, it’s worth knowing which one you’re actually building for.
What makes the job harder than the job description suggests is the authority gap. A PM owns the product but can’t actually make anyone do anything. You can’t tell engineering to work faster. You can’t tell design to cut complexity. You can’t tell sales to stop promising features. You can recommend, argue, persuade, and if you’re lucky, you’re trusted enough that people listen. But if someone decides not to follow your direction, your recourse is influence, not power.
This is where the best PMs I’ve worked with differ from the ones who burn out. The ones who burn out expect authority. They’re frustrated that people don’t just do what they’ve decided. The ones who thrive treat it as a puzzle. How do you make the case so clearly that following your direction is actually what people want to do? How do you build enough trust that your judgment counts? How do you make the stakeholder who disagrees feel heard enough that they can change their mind?
The work is clearer to describe than to do. You live in the space between what’s desirable, what’s feasible, and what’s viable. Users want something. Engineers can build it, probably, if you spec it well enough and don’t keep changing your mind. The business needs something to work financially. Usually these three things are in tension. The PM’s job is to find the path that serves all three, or at least make it crystal clear when you’re choosing one over the others.
You spend a lot of time writing. PRDs, meeting notes, spec documents, Slack explanations for why we’re not doing that thing someone asked about. You spend a lot of time listening — to customers, to your team, to the numbers, to the feedback you’re getting from support. You spend time in meetings that could have been one sentence but had to be an hour because the word “prioritisation” means something different to everyone in the room.
And sometimes, not always but sometimes, you ship something that didn’t exist before, that people use, that makes their work easier or their life better. That’s the part nobody puts on the job posting. That’s the part that makes up for the three hours arguing about checkbox defaults.