So… what exactly is Product Management?
I have heard this question more times than I can count.
And honestly, I have answered differently each time - because each time, I would have learned something new that I had to do as a PM.
Some people say:
A Product Manager is the CEO of the Product.
Sounds impressive, right?
But only until you actually become one. Because the moment you start working on a real product, you realize something very quickly.
You have all the responsibility in the world and almost none of the authority.
You don't manage engineers, designers don't report to you, sales & marketing are working with their own priorities and the leadership was expecting results yesterday.
And yet somehow, everyone expects you to make sure the product succeeds.
Welcome to Product Management.
So what is it, actually?
Here's the simplest version I've landed on after doing this for a while:
A PM figures out what to build, gets everyone to agree on it, and makes sure it actually ships.
That's it. That's the whole job.
Except - figuring out what to build means spending hours talking to users who can't quite explain what they need. Getting everyone to agree means navigating engineers, designers, compliance teams, and a leadership that wants everything by end of quarter. And making it ship means you're responsible for a thing you have no direct control over.
So yeah. Simple in theory.
The three things a PM actually does
Every PM, on every product, in every company, is doing some version of these three things:
1. Discover
Talk to users. Watch how they use the product. Ask why, then ask why again. The goal is to find the real problem - not the one they're describing, but the one underneath it.
Most users will say "I want a faster horse." Your job is to discover "I need to get somewhere faster."
2. Define
Take what you learned and turn it into something buildable. Write the spec. Draw the flow. Prioritize ruthlessly.
This is where you fight the hardest battles - because everyone has an opinion about what should be built, and your job is to make a call and defend it.
3. Deliver
Work through the build. Unblock people. Make tradeoff decisions when things go sideways (and they will). Communicate status to stakeholders. Ship.
Then ask yourself: did it actually solve the problem?
And then start over.
Discover → Define → Deliver → repeat forever
How I got into Product (without planning to)
I didn't start as a PM.
I joined the company as a Salesforce developer in mid 2024. My job was to write Apex, configure workflows, and automate things. It was work with clean scope and clear deliverables.
Then we started building an ambulatory care platform for US healthcare and within no time everyone noticed the absence of someone to own the product.
There was no PM on the team. There was an architect, a designer, engineers, tester, the business team.
And along with them there were a lot of unanswered questions floating around.
- Who is the primary user of this product?
- Whats the scope of the product we are building
- Which features do we need to build?
- What do the users clearly need?
- What should we build first? and How?
Nobody was formally responsible for those questions. And that led to a lot of wasted time & effort.
So I started answering them.
Then documenting them.
Then drawing flows.
Then writing user stories.
Then designing and defining user experience.
Then building the roadmap.
One day I looked up and realized I was doing a full PM job. My title still said Salesforce Developer.
That's how it happens for a lot of people. Product thinking doesn't wait for a hire. Someone fills the gap - and if you're the one asking "but why are we building this?" before "how do we build this?" - that someone is you.

