A Few Things That Make Me Think, “This Person Is a Good PM”

I’m a bit hesitant to write something framed as how to be a good Product Manager.

The reason is simple:

Am I already a good PM?

Feels a bit too confident if I’m the one answering yes.

So this isn’t a tutorial on how to become a great Product Manager. It’s more like a collection of observations after spending several years working as a PM and meeting a lot of people with the same title.

Managers.

Peers.

Juniors.

And also PMs from other companies that I know personally, whose writing I’ve read, or whom I’ve listened to in webinars.

But I’m personally quite skeptical about judging someone’s ability based only on what they write or say in public.

Someone can sound extremely smart when talking about Product Management.

Do they actually work that way every day?

I have no idea.

So this article is probably influenced more by people I’ve actually worked with. People who were in the same company, the same project, the same meetings, or at least had to deal with the same messy problems.

There have been a few moments where I watched someone work and thought:

damn, this person is really good at being a PM.

And over time I started paying attention to what actually made me think that.

This is also partly a note to myself.

What kind of PM do I actually want to become?

Because some of the things below I can already do reasonably well.

Some I’m still learning.

And one of them is still very much a work in progress.

Two things I’ve already written about: adapt and learn fast

In my previous article, Maybe Product Management Is Really About Filling the Gaps, I wrote that the PM role depends a lot on the organization.

A PM in one company might be very business-heavy.

In another, more technical.

Somewhere else, they might need to go fairly deep into UX, analytics, operations, or whatever gap happens to exist.

That’s why the first two things I think matter are:

adaptability and the ability to learn fast.

A PM who is too rigid about:

“PMs are supposed to do this”

will probably be disappointed by the real world pretty often.

But adapting isn’t enough.

You also need to learn quickly enough to become useful when you enter a domain you don’t understand yet.

A company isn’t a university.

You don’t get an entire semester to learn how APIs are structured before joining the technical discussion.

You don’t get a two-credit course before you’re allowed to talk about UX mental models.

Sometimes you don’t understand something today.

There’s a meeting tomorrow.

A decision needs to happen this week.

That doesn’t mean becoming an expert overnight.

It means learning fast enough and accurately enough for the problem in front of you.

I wrote more about those two things in the previous article.

But the longer I work, the more I think there are a few other things that matter just as much.

And one of them I learned pretty directly from a former lead.

Don’t say yes to everything

When I was at Moladin, I had a lead named Jonathan.

During one of my 1-on-1s while I was still on probation, he gave me feedback that stuck with me.

It was roughly:

“Don’t keep saying yes to everyone. Yes to UI/UX, yes to Ops, yes to Dev. If you say yes to everything, eventually you’ll be the one confused about what should be built first.”

Honestly, I haven’t had another manager since then who gave feedback that directly.

But damn, it was useful.

Luckily I’m not the type to get offended easily by feedback like that.

And the longer I worked, the more I understood why he said it.

A PM can’t be a Yes Man.

Because requests never stop.

Business wants A.

Operations wants B.

Marketing wants C.

Engineering might want technical improvement D.

Design has concern E.

And somehow they’re all:

urgent.

If you accept everything, accommodate everything, and put everything into the backlog as “important”…

then nothing is actually important.

I’ve also seen PMs who are simply too uncomfortable saying no.

Every request gets accepted.

Everything gets accommodated.

The result isn’t happier stakeholders and faster delivery.

Usually the PM ends up struggling to decide what to build first, scope keeps growing, and delivery gets slower.

This doesn’t mean PMs should be defensive toward every request.

And it definitely doesn’t mean stakeholders are always wrong.

The job is to understand:

what is actually a problem,

what is actually a priority,

what can wait,

and what is really just nice to have.

Because I’ve also seen stakeholders ask very confidently for a certain feature.

It gets built.

It ships.

And then…

they barely use it.

A request isn’t automatically the problem you need to solve

I think being able to say “no” also connects to one thing I took from The Lean Startup.

If we still don’t know whether an idea will actually work, why spend a huge amount of effort building the complete version immediately?

One thing I like from The Lean Startup is the idea that when you’re still testing a hypothesis, you should find the cheapest and fastest way to learn whether the hypothesis is true.

But in reality, requests often arrive already packaged as a complete solution.

“We need feature A.”

It needs this.

And that.

The flow should work like this.

There needs to be a dashboard.

A notification.

Automation.

Make it configurable too.

Meanwhile, we don’t even know if people will use the basic functionality.

If a PM is uncomfortable challenging requests, it’s very easy to end up building something polished, complete, and over-engineered for a problem that hasn’t even been proven yet.

So to me, not being a Yes Man isn’t only about being brave enough to reject stakeholders.

It’s also about protecting the product from spending effort just because the person making the request sounds confident.

Sometimes the right answer is:

yes.

Sometimes:

not now.

Sometimes:

let’s try the smallest version first.

And sometimes:

why do we need this?

That last question leads to the next thing.

Don’t be too quick to think you already know the answer

This is another lesson I got from Jonathan.

Even before I officially joined Moladin.

During the interview process, he gave me direct feedback that I was still too quick to jump to conclusions.

And I think he was right.

At the time, I was still pretty new to Product Management.

The classic mistake is thinking that the PM’s job is to provide solutions.

Someone brings a problem.

Your brain immediately goes:

“Oh, then we should build this feature.”

A request comes in.

You start designing the flow.

A metric drops.

You immediately have a theory.

It feels productive.

But maybe you’re just being wrong faster.

The longer I work, the more I think one important skill is actually holding yourself back from having an answer too quickly.

A stakeholder asks for feature A?

Why?

What problem is actually happening?

How often?

Who experiences it?

How do they solve it today?

Why isn’t the current workaround enough?

What happens if we build nothing?

Sometimes after a few questions, a request that sounded very clear starts changing shape.

And sometimes you realize:

oh, that wasn’t the real problem.

This probably also explains why some features are heavily requested before launch and then barely used afterward.

We accepted the stakeholder’s solution too quickly without understanding the problem underneath.

And I don’t think PMs need to be the person who always has the answer.

Sometimes a good PM is the person who is comfortable saying:

“I don’t know yet. Let’s figure it out first.”

Asking better questions is probably more useful than having faster answers.

Big problems are often just smaller problems that haven’t been separated yet

The next thing is the ability to break problems into smaller pieces.

The first time I really noticed this idea was from the book Cracking the PM Interview, especially the guesstimate exercises.

At first, they just looked like weird interview questions.

“How many golf balls could fit inside a Toyota Innova?”

“How many cinema seats are there in Jakarta Province?”

And all kinds of similarly strange questions.

At first glance, they sound pointless.

When exactly is a CEO going to suddenly ask a PM how many golf balls fit in an Innova?

But after working for a while, I started understanding why this type of thinking gets tested in PM interviews, especially for junior to mid-level roles.

The point isn’t whether the final number is correct.

What’s interesting is:

when someone gives you a big ambiguous problem, what does your brain do?

Do you just throw out a number?

Do you panic because you don’t have the data?

Or do you start breaking it apart?

Roughly how big is an Innova?

How much usable space is inside?

How big is one golf ball?

How much space is taken up by seats and the interior?

Then you make assumptions and estimate.

The final number might still be wrong.

But the thinking process becomes visible.

And that exact same kind of thinking is incredibly useful at work.

Because work problems rarely arrive like this:

Problem A is caused by variable X at step three.

That would be convenient.

Usually they arrive like:

“Why did conversion drop?”

or:

“How do we get more users to click this button?”

or:

“Why are so many orders failing?”

That’s it.

Now go figure it out.

What matters is whether we get overwhelmed by the size of the problem, or whether we can start breaking it down.

Conversion dropped.

Okay.

All traffic or only certain channels?

New users or returning?

Mobile or desktop?

All categories or just some?

Does the drop start on PLP?

PDP?

Add to cart?

Checkout?

Payment?

When did it start?

Any release?

Campaign?

Inventory issue?

Payment issue?

A big problem slowly turns into smaller problems we can check one by one.

And once you can break it down, you can isolate it.

Once you can isolate it, you can move.

It sounds basic.

But the longer I work, the more I realize this skill isn’t automatic.

Some people get a big problem and immediately stress out.

Panic.

Jump to a solution.

Or try to solve everything at once.

Sometimes what you really need is to stop for a moment and start cutting the problem into pieces.

If you want to get better at this kind of thinking, I still like recommending Problem Solving 101 by Ken Watanabe.

The funny part is that it was originally written to make problem solving understandable for children.

But surprisingly…

quite a lot of adults could probably use it too.

Especially if you work in Product.

Then there’s stakeholder management. Unfortunately.

Now we get to the part I like the least.

And maybe one of the most important.

Stakeholder management.

I’m still figuring this one out myself.

I’m not particularly good at hiding when I’m annoyed.

If I don’t like something, my face can change.

My tone can change too.

I’m fairly direct.

And as someone who occasionally gets road rage, emotional regulation probably isn’t my strongest achievement.

So yeah…

I’ve probably been the PM some stakeholders disliked.

I’m fairly comfortable saying no to requests that don’t make sense to me.

The problem is:

being able to say no and being able to say no well are two different skills.

The first one, I think I’m reasonably okay at.

The second one?

Still a lot of work.

And the longer I work, the more I think that if you can avoid becoming a Yes Man and still maintain a good relationship with stakeholders after saying no…

yeah, you’ve basically completed the game.

Because a huge part of a PM’s day is interacting with people.

Meetings.

Discussions.

Negotiation.

Alignment.

Follow-up.

Conflict.

And unfortunately, those people aren’t APIs.

They’re humans.

They have egos.

Moods.

Emotions.

Different backgrounds.

Targets.

Pressure from their managers.

Different communication styles.

Personal interests.

Sometimes they know something we don’t.

Sometimes they’re also just…

annoying.

There are plenty of stakeholder-management frameworks out there.

One that I find pretty fun is Productboard’s Dangerous Animals of Product Management, which maps different stakeholder types and how to deal with them.

Useful as a mental model.

But the problem is still the same.

Humans are much more complicated than four boxes in a matrix or a handful of animal types.

Trying to build a framework that maps every stakeholder feels like building an API with a parameter list that never ends.

Title.

Personality.

Domain knowledge.

Ego.

Mood that day.

Political power.

Personal target.

Relationship with their manager.

Relationship with us.

How much they understand the product.

How much they care about data.

How stubborn they are.

Keep adding.

It never ends.

And from my own experience, the combinations are all over the place.

Some people are stubborn but actually very smart.

Difficult, but once you understand their argument, there’s often something useful in it.

Some people don’t understand the domain that deeply but are open to discussion.

Still manageable.

Some are smart and not stubborn.

That’s the jackpot.

And some are…

well.

Let’s just leave it there.

They have senior titles too.

Good luck.

The point is, I don’t think there will ever be one stakeholder-management framework that works for everyone.

The treatment has to be different.

And ironically, learning how to read people like this might be much harder than learning how to write a PRD.

I still don’t have a great answer for how to become much better at this.

But I’m pretty sure:

this is one of the most important skills I need to improve if I want to become a better PM.

So what does a good PM look like to me?

If I summarize what I’ve observed over the last few years, the list is actually pretty short.

Adapt.

Because the PM role changes depending on the organization and the problem.

Learn fast.

Not learn everything until you’re an expert. Learn the right thing, deeply enough, quickly enough to become useful.

Don’t be a Yes Man.

A request is not a command. Challenge, filter, prioritize, and be willing to say no when necessary.

Don’t jump to conclusions too quickly.

Problem first. Solution later. Ask more questions before assuming you already know the answer.

Break problems into smaller pieces.

Ambiguity is always going to exist. Being able to turn something large into smaller parts that can actually be analyzed and worked on makes problems much more manageable.

Learn to manage stakeholders.

I’m still learning this last one myself.

Probably always will.

And maybe someone will ask:

What about writing PRDs?

Making mockups?

SQL?

Analytics?

Prioritization frameworks?

Roadmaps?

I still think all of those are useful.

But most of them are technical skills that can be learned relatively quickly, and the need for them varies a lot by organization.

Some companies have PMs who never make mockups.

Others have PMs creating high-fidelity Figma designs.

Some have dedicated analysts.

Others expect PMs to dig through the data themselves.

Some write fifteen-page PRDs.

Others use a few paragraphs and talk directly with engineers.

That’s why I’m more interested in the things that still matter when the environment changes.

How you react to something you don’t understand.

How you learn.

How you say no.

How you ask questions.

How you break down a problem.

And how you work with people.

Do those six things automatically make someone a good Product Manager?

I don’t know.

I don’t think I’ve mastered all of them myself either.

But from the people I’ve actually worked with who made me think:

“damn, this person is really good at being a PM,”

there are almost always a few of those traits in there.

So maybe this isn’t really a checklist for how to become a good PM.

It’s more like a checklist for the kind of PM I want to become someday.

Some parts are already okay.

Some are still far away.

At least now I know what I need to work on.