The reality is: as a PM, you’re responsible for the product’s success, but you don’t truly manage any of the people building it. You’re supposed to lead with vision, research, and a suspiciously cheerful attitude despite having no authority to make anyone do anything.

The myth: The mini-CEO
(Without the power or the pay).
Your job is to convince, cajole, and occasionally bribe (with coffee, not cash) your team to build the right thing, the right way, at the right time. You’re the advocate for the customer, the translator of vague business goals into actual features, and the person who gets blamed when the product flops.
But hey, at least you’re not alone: every PM spends half their career explaining what they do to their family and the other half explaining it to their team.
If you Google “what does a product manager do,” you’ll find earnest diagrams showing a PM at the intersection of business, technology, and user experience. Some call you the “CEO of the product,” which sounds glamorous until you realize you have all the responsibility and none of the authority. You can’t fire anyone, you don’t sign cheques, and your big power move is scheduling a meeting with too many people.
“Nobody asked you to show up. Every experienced product manager has heard some version of those words at some point in their career.”
— Product School
The legend:
What product managers actually do.
Let’s clear the fog. Product managers are the glue, the translator, the slightly frazzled person in the corner muttering about “trade-offs.”
Here’s what you’ll actually do:
- Represent the customer. You’re the voice in the room saying, “Would anyone actually use this?” Bonus points if you can answer that without sounding like a broken record.
- Define the vision. You set the direction, usually after several hours of “alignment” meetings and at least one whiteboard marker running dry.
- Prioritize features. Everyone wants everything yesterday. You’re the one who says “no” more than a toddler at bedtime.
- Align stakeholders. Translation: you spend a lot of time explaining the same thing to different people in different ways until they all nod (or at least stop arguing).
- Deliver outcomes. You make sure the thing gets built, shipped, and doesn’t immediately catch fire on launch day. If it does, you’re the one writing the apology note.
In smaller companies, you might do everything from writing specs to QA testing to making the coffee. In bigger places, you’ll spend more time in meetings, trying to get everyone to agree on what “done” means.
The job nobody asked for:
Why PMs exist.
Why do PMs exist? Because someone needs to:
- See the big picture, while also sweating the small stuff.
- Balance what customers want, what the business needs, and what’s technically possible.
- Say “no” with a smile and “yes” with a caveat.
- Keep the team moving in the same direction, even when the wind changes.
Without a PM, teams build what they want, not what users need. With a PM, teams still build what they want, but at least someone’s there to ask awkward questions and occasionally redirect the ship.
The Reality:
Explaining your job (forever).
Here’s the secret: You’ll spend half your career explaining your job to your family (“No, Mum, I don’t fix computers. No, I’m not in sales either.”), and the other half explaining it to your team (“No, I don’t just schedule meetings. No, I can’t make the deadline move by shouting at engineering.”).
This is partly because the PM role changes from company to company, even team to team. Some PMs are technical, some are business-focused, some are basically therapists with a Gantt chart. The only constant is confusion.
How the sausage gets made.
Let’s say you join a new team. The product’s a bit wobbly, the vision’s as clear as a foggy morning on The Burren, and nobody quite agrees what “success” looks like.
Here’s how it usually plays out:
- Workshops. You run a workshop. Half the team thinks it’s a waste of time, the other half brings biscuits. You try to align on a vision. Someone draws a pyramid. Someone else says, “Shouldn’t we be agile?” Nobody knows what that means.
- Conversations. You talk to users, and discover they use your product in ways you never imagined. One person uses it as a doorstop. You try not to take it personally.
- Experimentation. You launch a new feature. Usage goes up. Or down. Or sideways. You run an A/B test and realise you don’t know what you’re testing anymore.
- Friction. Engineering wants to rebuild everything. Design wants to make it beautiful. You want to ship something before you retire.
- Iteration. You ship, you learn, you tweak, you repeat. Sometimes you even celebrate.
What we learned
(Besides how to drink more coffee).
In the end, product management is about people. It’s about listening, nudging, persuading, and sometimes just surviving. The best PMs aren’t the ones with the fanciest frameworks. They’re the ones who get things done, bring people together, and make the product (and the team) a little bit better.
You'll learn that:
- The job is never really done. There’s always another feature, another bug, another meeting.
- Success is messy and hard to measure. Sometimes it’s a graph going up. Sometimes it’s just fewer complaints.
- People matter more than process. The best ideas come from anywhere, and the best teams trust each other.
- You’ll never stop explaining your job. But that’s OK—it means you’re doing something interesting.
So, you want to be a product manager? Welcome to the circus. Bring snacks, a sense of humour, and a willingness to be wrong. You’ll need all three 😉