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:

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 does a PM actually do?

Here's the simplest version I can define it by:

That's it. That's the whole job.

Except -

• Figuring out what to build means spending hours talking to users and stakeholders 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 every PM 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 that what they actually mean is "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?

Whether the answer is yes or no - start over.

Discover → Define → Deliver → repeat forever

Only the problem and scope changes. The process repeats forever.

---

How I got into this (without planning to)

I didn't start in the product field. To be honest, I didn't even know what Product Management was.

I joined the company as a Salesforce developer in mid-2024. My job was to write Apex classes, configure flows, and automate things. It was a work with clean scope, clear deliverables.

Then we started building PractMD - 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, a 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?
• What's the scope of what we're building?
• Which features do we need?
• What do users actually need?
• What should we build first? And how?

Nobody was formally responsible for those questions. And that led to a lot of wasted time and effort.

So I started answering them.

Then documenting them.

Then drawing flows to present to the team.

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.

---

Is this job for you?

If you like holding the full picture while everyone else is heads-down in one piece of it - yes, probably.

If you want clearly defined scope and someone else managing the ambiguity - this will drive you a little crazy(Scratch that - it'll drive you completely crazy).

The people who do this well tend to share a few things:

• They ask why before they ask what
• They write clearly under pressure
• They care about the user more than about being right
• They can say no without making it personal
• They don't need credit to stay motivated
• They update their thinking when the facts change

None of these require a PM background. Some of the sharpest product thinkers come from engineering, design, and customer support.

The title is a formality. The mindset is what matters.

Let's be honest

Product Management is the work of making good decisions - repeatedly, under uncertainty, for users who can't always tell you what they need and getting a group of very different people to ship something together.

It's messy. It's sometimes thankless. It involves a lot of documents nobody reads until something goes wrong.

But when someone opens an app you helped design and it actually makes sense, and it doesn't feel like something built by people who've never needed it themselves that's the product doing what you intended.

That's the whole job. That's why it's worth it.

---