Maybe a Product Manager’s Job Is to Fill the Gaps

I didn’t exactly plan to get into Product Management.

My degree is in Telecommunications Engineering. I was mostly focused on network engineering, and toward the end of university, I spent quite a lot of time working with IoT.

IoT sits somewhere between hardware, networks, and software, so naturally I started getting exposed to software development too.

I took basic programming classes. I picked mobile app development as an elective. During my internship and the time I spent around IoT labs and research, I also worked quite a bit with software developers.

A lot of my friends were studying Computer Science too.

One by one, they started finding their paths.

Frontend developer.

Backend developer.

QA.

UI/UX designer.

Meanwhile, I was still wondering:

What am I actually supposed to become?

So yeah, I FOMO-ed my way into trying almost everything.

I bought web development courses on Udemy. Took BPPTIK/BNSP certification. Joined a bootcamp. Learned frontend development. Tried UI/UX. At some point I even bought a digital marketing course.

On the networking side, I studied CCNA and MikroTik too. I considered getting certified, but the exam fees were quite expensive for me at the time.

Basically, I tried a lot of things.

Not because I had some grand career plan.

I was just confused.

And there was a little extra pressure at the time.

I got married before graduating.

While I was still an intern.

Why?

I just wanted to.

Probably not the kind of career advice you’d find on LinkedIn.

But the consequences were pretty real. I had a wife to support, and I needed to find a full-time job.

The problem was that there weren’t nearly as many IoT engineering openings as there were software engineering jobs. Network engineering was an option too, but some of the certifications that could help me get there required money I didn’t really have yet.

Alhamdulillah, I eventually landed my first full-time job at Gamatechno as an IoT System Analyst.

And somehow, that only made things branch out even further.

Turns out I like knowing a little bit about everything

Working in IoT meant interacting with different parts of software development more often.

Engineers.

Designers.

Business.

Customers.

And the longer I worked, the more I started noticing something about myself.

I liked learning about all of it.

I just wasn’t sure I wanted to specialize in any one of them.

I could spend a few months getting interested in web development, then suddenly become curious about UX, then networking, then business.

I like understanding how things work.

But spending years going extremely deep into one specific domain?

Hmm.

Then one day, I found an article on Medium.

Unfortunately, I don’t remember the title or the author anymore. The one thing I remember is that the author was writing about their experience working as a Product Manager at Tokopedia.

I read it.

And my reaction was basically:

Wait. This is literally me.

They described a role where you need to understand many different things without necessarily being the deepest expert in any of them.

Jack of all trades, master of none.

Something that normally sounds like criticism suddenly sounded like a description of me.

I liked technology.

I was interested in UX.

I was curious about business.

I liked understanding how different things worked.

I got curious easily.

And, admittedly, I got bored pretty easily too.

Apparently there was a job where that weird combination could actually be useful.

Product Management.

That’s when I started taking it seriously.

I joined Product Management bootcamps at Apiary Academy and Binar Academy. I read books like The Lean Startup, Inspired, Cracking the PM Interview, and pretty much whatever PM material I could get my hands on at the time.

I spent a decent amount of money learning all of this.

But this time felt different from my previous phase of randomly buying courses.

For the first time, I was pretty confident:

I think this might actually be the right job for me.

Alhamdulillah, while I was still at Gamatechno, I eventually got the opportunity to act as a Product Owner for one of their IoT products.

That gave me a way to move fully into Product Management.

GoKampus.

Then Moladin.

And now Erajaya.

The titles have been more or less similar.

The actual job has never really been the same.

And that’s what eventually changed the way I think about Product Management.

Bootcamps tell you PM sits between Business, Tech, and UX

If you’ve ever learned Product Management from a bootcamp, book, or article on the internet, you’ve probably seen the same diagram.

Three circles.

Business.

Technology.

User Experience.

And right in the middle:

Product Manager.

There’s also the more dramatic version:

“The CEO of the Product.”

I used to believe that picture quite strongly.

And to be fair, I don’t think it’s completely wrong.

It’s a useful way to explain that PMs need to understand multiple domains and help them move toward the same goal.

The problem starts when we treat that diagram as a universal job description.

Because after working in several very different organizations, I found something slightly different.

I’ve worked in a software house where, as the product person, I literally had to design UX in Figma.

Not just rough wireframes for discussion.

Actual high-fidelity designs that frontend developers used to build the product.

I’ve worked at a small startup where the team wasn’t that big, so product could end up getting involved in marketing, partnerships, or other things that technically weren’t “product work.”

I’ve also worked at a Series B startup with hundreds of people across product and engineering. Roles were much more specialized. There were dedicated analysts, dedicated designers, a proper engineering structure, and a product development cycle that looked much closer to what the books usually describe.

And then I’ve worked in a large corporation.

Big organization.

Lots of stakeholders.

More politics.

Things move slower.

And when there are gaps in technical leadership or coordination across systems, product can’t always walk into the room with a problem statement and say:

“The how is engineering’s problem.”

Yeah. Good luck with that.

Sometimes I need to find the API.

Read the documentation.

Understand which system talks to which system.

Understand the request and response.

Understand the payload.

Understand why data from system A isn’t reaching system B.

Sometimes the expected API request and response need to be clear enough in the requirement so several different teams don’t walk out of the same meeting with several different interpretations.

Is that textbook Product Management?

Probably not.

Does the work still need to get done?

Unfortunately, yes.

And after working across those different environments, I eventually landed on a definition of Product Management that makes more sense to me now.

Product Managers fill the gaps

I think one of the most fundamental functions of a Product Manager is to:

fill the gap.

Fill whatever gap is currently stopping the product or organization from moving properly.

And that gap can look completely different depending on where you work.

If engineering is strong but business context is weak, the PM might need to be much more business-heavy.

If the company is extremely sales-driven but lacks technical understanding, the PM may need enough technical depth to translate business needs into systems.

No analyst?

Product might need to act as the analyst.

Low UX maturity?

Product might need to get more involved in UX.

Small company with an understaffed partnership team?

Product might end up helping with partnerships too.

And if everything is already mature?

Great.

Maybe that’s when the PM job actually starts looking like the nice three-circle diagram.

Discovery.

Prioritization.

Strategy.

Roadmap.

Stakeholder alignment.

Outcomes.

Everyone has a clear scope.

Sounds nice.

But we live in the real world.

And real organizations almost always have gaps.

A function that isn’t mature yet.

Unclear ownership.

A team missing a certain capability.

A process that theoretically should work but, in reality, doesn’t.

And sometimes the Product Manager happens to be the person closest enough to the problem to help close that gap.

I don’t say “PMs shouldn’t be doing this” as much anymore

I used to go through that phase too.

“Product shouldn’t have to go this deep technically.”

“Engineering should decide the implementation.”

“Product should focus on the problem.”

“There should be an analyst doing this.”

“Business should handle that.”

And from an organizational design perspective?

Maybe that’s correct.

Maybe it should work that way.

But after moving between different environments, I’ve started finding another question much more useful than:

“Who should be doing this?”

Which is:

“What gap is currently stopping this product from moving?”

If the answer is technical clarity and nobody else is filling that gap, maybe product needs to step in.

Not forever.

It doesn’t mean the organization shouldn’t fix its structure.

And it definitely doesn’t mean PM should become the dumping ground for every piece of work that doesn’t have an owner.

That’s an important distinction.

Filling the gap doesn’t mean doing everything.

If every random problem gets thrown at the PM because “PMs need to be adaptable,” that’s not Product Management.

That’s organizational dysfunction being assigned to a Product Manager.

But if the gap is genuinely blocking the product and we have the ability to help close it, I’m much less interested now in arguing whether the task technically belongs in a PM job description.

Solve the problem first.

Then, if the same gap keeps appearing, start asking:

Why does this gap exist?

Do we need to hire someone?

Do we need to change the process?

Does ownership need to be clearer?

Because a PM repeatedly filling the same gap isn’t necessarily proof that they’re amazing.

It might just mean the organization never actually fixed the underlying problem.

That’s also why I don’t think there’s one template for a “good PM”

This changed the way I think about hiring Product Managers too.

We spend a lot of time looking for candidates who resemble the mythical “ideal PM.”

Great at discovery.

Data-driven.

Strategic thinker.

Great communicator.

Technical enough.

Business savvy.

User obsessed.

Leadership.

Stakeholder management.

The list can get so long that eventually we’re basically looking for someone who’s good at almost everything.

But PMs don’t work in a vacuum.

Someone can be an excellent PM in one organization and fairly average in another.

A PM who grew up in a tech-heavy company might be very comfortable working with a mature engineering organization, which lets them focus much more on discovery, strategy, and business problems.

Move that same person into an organization with a messy technical structure that needs a PM willing to dig through API integrations down to the payload level, and they may not enjoy it or even be particularly effective.

The opposite can happen too.

A highly technical PM who’s great at untangling system complexity may not be the best candidate for a role that actually needs much stronger market development, commercial thinking, and partnership skills.

Neither one is inherently better.

They’re being asked to fill different gaps.

So if I were hiring a PM, the first question I’d want answered before interviewing anyone would be:

“What is our organization missing right now?”

Not:

“What does a good Product Manager look like?”

What’s the team’s biggest problem?

Business understanding?

Technical translation?

Weak discovery?

Messy execution?

Stakeholder alignment?

Analytics?

UX?

Strategy?

Domain knowledge?

Then find someone whose shape fits that gap.

Hiring a PM without understanding what your organization needs is a bit like asking:

“What kind of doctor is the best doctor?”

Well, what are you sick with?

You don’t need a cardiologist when the problem is your bones.

Same thing with PMs.

The best candidate isn’t necessarily the one with the most boxes checked.

It’s the person whose strengths match the problems your organization actually needs to solve.

So what if we’re the PM?

This is the slightly uncomfortable part.

Organizations aren’t always going to reshape themselves around the ideal job description we learned.

So there are roughly two choices:

stay idealistic and remain frustrated because the world doesn’t work like the framework,

or adapt.

I prefer the second one.

The company doesn’t care about our ego.

If the environment changes, we need the ability to change with it.

And I think there are two things that matter a lot for PMs:

curiosity and the ability to learn fast.

Curiosity makes us willing to enter things we don’t understand yet.

But curiosity alone isn’t particularly useful if every unfamiliar domain takes us months to understand.

A company isn’t a university.

You don’t get an entire semester to learn how APIs are structured.

There’s no two-credit course on UX mental models.

Nobody gives you a syllabus from beginner to advanced before asking you to join the discussion.

The problem already exists.

The meeting is tomorrow.

The decision might need to happen this week.

So the goal isn’t always deep expertise.

The goal is to learn enough, fast enough, to help solve the problem properly.

If there’s an API issue, you don’t need to turn into a backend engineer.

But you should be able to understand enough about endpoints, payloads, responses, dependencies, and data flow that you’re not just sitting silently through the technical discussion.

If there’s a UX problem, you don’t suddenly need to become a product designer.

But you should understand enough about user behavior, hierarchy, affordance, mental models, or interaction patterns to have a useful discussion with the designer instead of saying:

“I just think this one looks better.”

If there’s a business problem, you don’t need to become the finance or commercial lead.

But you should understand enough about margin, conversion, revenue, inventory, or unit economics so the product decision doesn’t exist in a vacuum.

Learning fast doesn’t mean learning things superficially.

It’s more about knowing:

what you actually need to understand,

what matters for the problem in front of you,

who you need to ask,

and when you understand enough to participate in a proper decision.

Because if every time you enter a new domain your response is:

“I don’t understand this,”

and that’s where it ends,

well…

good luck.

This role was never really designed for people who only want to stay inside one comfortable box.

“I’m not technical” isn’t a personality trait

One thing that bothers me a little is when a knowledge gap becomes a permanent identity.

“I’m a non-technical PM.”

“I don’t understand UX.”

“I’m not really a data person.”

“I don’t understand business.”

Okay.

You don’t understand it yet.

Now what?

If your job keeps interacting with software systems and you’ve spent three years actively choosing not to understand how those systems work, I don’t think your educational background is the problem anymore.

The same applies to me.

Having an engineering background didn’t magically make me understand business.

I had to learn.

Conversion.

Margin.

Revenue.

Inventory.

Marketing.

Customer behavior.

None of those things were part of my Telecommunications Engineering degree.

Your background determines your starting point.

I don’t think it should determine your boundary.

A PM doesn’t need to be the most technical person in the room.

They don’t need to be the best designer.

They don’t need to become the finance person.

But saying “that’s not my area” every time something unfamiliar appears feels fundamentally incompatible with the nature of the job.

Because if part of our role is filling gaps, we can’t only choose gaps that happen to sit inside what we already know.

Maybe “jack of all trades” isn’t an insult after all

I found Product Management because I once read someone describing themselves, more or less, as a jack of all trades, master of none.

Years later, I think that description still holds up surprisingly well.

Not because PMs need to know everything.

Impossible.

But this job rewards people who are genuinely curious about many things and can learn fast enough when the problem suddenly moves into another domain.

Today I might be discussing which API payload needs to be passed when a user adds something to cart.

Tomorrow I might be trying to understand why conversion for a certain shoe brand suddenly dropped over the last month.

The day after that, I might be debating a UX mental model and why a particular button should probably be red instead of green.

Next week it could be inventory.

Loyalty.

Payments.

Search ranking.

Warehouse operations.

Or some stakeholder issue that wasn’t even on the radar a week ago.

For some people, that probably sounds exhausting.

For me, that’s the fascinating part.

I never really know what kind of problem is going to show up next.

And after doing this for a few years, I care less and less about whether that problem technically counts as “PM work” according to a textbook.

The questions I care about now are much simpler:

What’s the gap here?

Is it stopping the product from moving?

Can I help close it?

If yes, then get involved.

Learn what you don’t understand.

Ask people who know more than you.

Do what actually needs to be done.

And if you keep filling the exact same gap over and over again, don’t get too heroic about it either.

Maybe it’s time to fix the organization instead.

I think Product Management naturally lives somewhere inside that kind of imperfection.

Not the CEO of the Product.

Not simply the point in the middle of Business, Technology, and UX.

Maybe we’re just the people curious enough to notice that something between all of them isn’t quite connected yet, and say:

“Okay. Nobody owns this yet. How do we fix it?”