Inside Product Minds: How I Think About Product in 2026

Recently, I was invited by Apiary Academy to be featured in Inside Product Minds, a campaign around Indonesia Product Conference 2026 that collects perspectives from people working in product.

They sent me a set of questions around Product Management, AI, strategy, decision-making, and how the role is changing.

Some of my answers were later selected, shortened, and adapted for the campaign posts.

Which makes sense. Nobody wants to read several pages of my thoughts inside an Instagram carousel.

But since I had already written the longer versions, I thought I might as well keep them somewhere.

So this is the less-truncated version.

Not necessarily a definitive view of Product Management, and definitely not an attempt to predict exactly where the industry is going.

Just how I currently think about these things after a few years of building products, working with different teams and organizations, making mistakes, changing my mind, and watching the role continue to evolve.

1. In the era of AI-native products, what Product Management skill becomes even more important and cannot easily be replaced by AI?

I think one skill that becomes even more important is judgment.

AI can help us generate ideas, summarize data, create prototypes, write documentation, and even help with coding.

But AI still doesn't fully understand the real context behind our product, business, organization, users, and all the trade-offs happening around it.

So I think the PM skill that becomes more valuable is not just knowing frameworks or writing good requirements.

It is being able to understand the real problem, separate signal from noise, challenge assumptions, and decide what is actually worth building.

Because when generating solutions becomes much cheaper, choosing the right problem becomes more important.

In the AI-native era, the main question might no longer be:

Can we build this?

But more like:

Should we build this at all, for whom, and why now?

And I think that kind of judgment is still very human.

2. Everyone is talking about AI features. When does a product actually need AI, and when does it not?

I think the simplest answer is:

A product needs AI when AI actually improves the problem you're trying to solve.

Not because someone suddenly asks in a meeting:

Where is our AI feature?

For me, AI makes sense when the problem involves ambiguity, large amounts of unstructured information, personalization, prediction, pattern recognition, or something that would otherwise take a human too much time to process manually.

But if the problem can be solved with a deterministic rule, a simple filter, better UX, or even just fixing an existing broken flow, I would probably do that first.

Sometimes we overcomplicate things because AI sounds more exciting than fixing the boring fundamentals.

And I get it.

"AI-powered" sounds much more interesting in a presentation than:

We fixed the broken filtering logic.

But the user probably doesn't care.

I would rather have a boring product that solves the problem extremely well than an "AI-powered" product where nobody really understands why the AI is there.

AI is a tool.

A very powerful one.

But the objective is still solving the problem, not proving that we managed to put AI somewhere in the architecture.

3. Who has influenced the way you think and lead as a product professional?

I don't think I have one single role model that I try to copy.

A lot of how I think today was shaped by people I actually worked with, and also by a few ideas that stayed with me for years.

One of them is The Lean Startup by Eric Ries.

It shaped the way I think about building products.

You don't always need to start with something complicated or high-investment when you haven't even proven the hypothesis yet.

Sometimes the better approach is to build the smallest thing that can help you learn whether the assumption is true.

Then there are people I've worked with.

Pak Qodri, my former manager at Erajaya, taught me a lot about empowering a team.

Giving people trust.

Delegating real ownership.

Giving them enough room to think instead of controlling every detail.

One thing I appreciated was that we could disagree and debate openly without turning disagreement into something personal.

That probably shaped how I think about leadership more than any leadership framework I've read.

Jonathan, one of the product leaders I worked with at Moladin, influenced another important part of how I think about product.

Don't jump into solutions too quickly.

Don't become a Yes Man.

And don't be afraid to challenge a request when the problem itself is still unclear.

We debated quite a lot too.

I think that was healthy.

And, well, I also learned quite a lot from people I don't want to become.

I've seen enough situations to know that having a senior title doesn't automatically mean someone has good judgment.

Especially when someone enters a discussion already convinced that they're right, doesn't really listen, doesn't try to understand the context deeply, and gives very little room for people closer to the problem to challenge the assumption.

Experiences like that taught me something important about leadership:

Seniority should make you more willing to listen and understand, not less.

So I wouldn't say my product philosophy came from one person.

It's probably a mixture of books, good leaders, difficult people, debates, mistakes, and years of seeing what actually happens when things get messy.

4. In a work culture that is increasingly async and remote, how do you keep product alignment strong across teams?

For me, asynchronous work only works when the context is written properly.

If important product decisions only exist inside meetings, chat conversations, or someone's head, eventually people will develop different interpretations of what we're building and why.

So I try to make the important things explicit.

What problem are we solving?

Why are we doing it?

What assumptions do we have?

What are the constraints?

What decision was made?

And sometimes, more importantly:

What did we intentionally decide not to do?

I don't think alignment means everyone needs to attend every meeting.

Actually, I don't think attending the same meeting automatically means people are aligned either.

People can sit in the same call for an hour and still leave with three different interpretations.

For me, good alignment means someone can open the documentation two weeks later and still understand why the team made that decision.

That written context becomes especially useful when someone wasn't in the room, joins the project later, or when everyone has simply forgotten the details several months later.

That said, async doesn't mean never talk.

When something is complicated, controversial, emotionally sensitive, or has already turned into fifty messages going back and forth, sometimes a fifteen-minute conversation is still the better tool.

The point isn't to eliminate meetings.

It's to stop treating synchronous communication as the default solution for every communication problem.

5. What's one small habit that has had a surprisingly large impact on decision-making quality?

Asking one very simple question before discussing solutions:

What problem are we actually trying to solve?

It sounds painfully basic.

But I've seen a lot of discussions jump directly into features, designs, or technical solutions before everyone even agrees on the problem.

Someone says:

We need a new filter.

Someone else says:

Let's add AI recommendations.

Another person starts talking about APIs.

Ten minutes later, we realize everyone is solving a different problem.

Maybe the original problem was actually that users couldn't find a particular category.

Maybe the issue was bad search relevance.

Maybe the problem was inventory availability.

Maybe nothing was wrong with discovery at all and the real issue happened much later in the funnel.

If we don't align on the problem first, every solution can sound reasonable because everyone is answering a different question.

That one question forces people to align their mental model first.

And I think a surprising amount of unnecessary product complexity can be prevented just by doing that consistently.

6. What's one Product Management trend you think is emerging in 2026?

I think the boundary between PM, designer, and engineer is becoming much blurrier, especially during the exploration phase.

With AI coding tools, prototyping tools, and agents, PMs can now go much further than writing requirements or drawing boxes in Figma.

You can test an API.

Query some data.

Build a prototype.

Simulate a flow.

Create a small internal tool.

Or sometimes build enough of the idea yourself to discover whether it even makes sense before asking an engineering team to invest heavily in it.

I don't think this means PMs should become engineers.

That isn't the point.

The interesting change is that the cost of turning an idea into something tangible is becoming very low.

Historically, a PM could describe an idea and maybe create a mockup.

Then engineering and design had to do quite a lot of work before everyone could actually interact with the idea.

That gap is becoming much smaller.

So I think the expectation will gradually shift from:

Can you explain the idea?

toward:

Can you show me?

And personally, I think that's a good direction.

A tangible prototype exposes assumptions much faster than a long discussion about what something might feel like.

7. If you could give only one piece of advice to the next generation of Product People, what would it be?

Don't become a framework collector. Learn how to think.

Frameworks are useful.

RICE.

JTBD.

OKRs.

Prioritization matrices.

Discovery frameworks.

All of them can help.

But real product problems rarely arrive neatly formatted like a case study.

Most of the time, you get incomplete information.

Unclear requirements.

Conflicting stakeholder expectations.

Technical constraints.

Weird user behavior.

Limited resources.

And sometimes people who don't fully understand the problem or the complexity behind it, but still keep asking:

When will this be done?

And not always in the nicest way.

That's where product thinking actually matters.

You need to be able to ask questions.

Structure ambiguity.

Challenge assumptions.

Estimate things.

Understand trade-offs.

And translate a messy situation into something the team can actually work with.

You also need enough understanding of business, users, data, and technology to recognize when a timeline is realistic, when something needs more investigation, and when the most accurate answer is simply:

We don't know yet.

Because in the real world, being a PM isn't about opening a textbook and choosing the correct framework for the current chapter.

It's about making sense of messy problems, messy organizations, and sometimes messy human behavior.

Frameworks should help your thinking.

They shouldn't replace it.

8. If you were asked to teach a class about product strategy, what three core lessons would you definitely discuss?

The first would be:

Understand the problem before choosing the solution

A surprisingly large number of bad product decisions happen because teams fall in love with a solution too early.

The conversation starts with:

Let's build X.

Instead of:

What exactly is happening, and why?

Once people become attached to a particular solution, discovery can quietly turn into an exercise in finding evidence to justify something they already wanted to build.

So I would start there.

Understand the problem first.

The second would be:

Trade-offs and prioritization

Strategy is not just deciding what you want to build.

It is deciding what you are willing not to build.

At least for now.

Resources are finite.

Engineering capacity is finite.

Attention is finite.

Even organizational ability to absorb change is finite.

If everything becomes a priority, basically nothing is.

And the third would be:

Context matters more than frameworks

The same strategy can be brilliant in one company and completely stupid in another.

Because the users are different.

The business model is different.

Technology is different.

Distribution is different.

Organizational capability is different.

Timing is different.

Constraints are different.

There is rarely one universally correct product strategy.

There is usually a strategy that makes the most sense given the context you currently have.

That distinction matters.

9. What's one framework, tool, or new way of working in 2026 that has changed how you build products the most?

For me, it is less about one specific framework and more about AI-assisted building as part of product discovery.

The traditional flow was something like:

idea → requirement → design → development → test

Obviously reality was never quite that clean, but there was usually still a meaningful distance between having an idea and having something people could actually interact with.

That distance is getting much shorter.

A PM can describe a hypothesis, generate a prototype, connect mock or sometimes real data, test the interaction, and discuss something tangible with engineering and design very quickly.

That changes the conversation.

Instead of spending one hour debating:

What would this feature feel like?

Sometimes you can spend twenty minutes building a rough version and immediately discover what is wrong.

Maybe the flow feels awkward.

Maybe an assumption doesn't hold.

Maybe the technically complicated part wasn't actually important.

Maybe the feature isn't useful at all.

That immediate feedback loop is what I find interesting.

I'm less excited about AI because it lets us produce more artifacts.

I'm more interested in how it can reduce the distance between a hypothesis and learning whether the hypothesis makes sense.

And I suspect that feedback loop will become much more valuable than whatever new fancy Product Management framework happens to become popular next.

Looking back at all nine answers

Reading all of these answers together, I realized there's probably one theme underneath most of them.

I care a lot about thinking before doing.

Understand the problem before choosing the solution.

Understand the context before applying the framework.

Question whether something deserves to be built before worrying about whether it can be built.

Write important context down instead of assuming everyone remembers it.

Use AI to shorten the learning loop, not simply to produce more things.

And be comfortable admitting that sometimes the answer is:

We don't know yet.

Maybe that's also why I'm increasingly less interested in Product Management as a collection of processes and artifacts.

Those things still matter.

PRDs matter when they're useful.

Analytics matter.

Roadmaps matter.

Prototypes matter.

Frameworks can absolutely help.

But none of them can make the decision for you.

Eventually someone still needs to look at incomplete information, conflicting interests, limited resources, technical reality, user behavior, and organizational constraints and decide:

Given everything we know right now, what actually makes sense?

I think that's the interesting part of the job.

And probably the part I'm still trying to get better at.

Also, a small thank you to Apiary Academy and the team behind Indonesia Product Conference for featuring me in their Inside Product Minds campaign.

It was a nice excuse to sit down and put some of these thoughts into words, especially around how Product Management is changing, what AI does and doesn't change, and what I personally think still matters when the tools around us keep getting better.

The Instagram post below is the shorter version that was published as part of the campaign.

Naturally, some of the answers were condensed to fit the format, so think of the post as the summarized version and this article as the unnecessarily long director's cut.

If you're interested in the broader Indonesian product community, it's also worth checking out what Apiary Academy and Indonesia Product Conference are putting together. They regularly bring together product people, practitioners, and different perspectives from across the industry.

Thanks again to the team for having me as part of the campaign.