I didn’t transition into product. The work pulled me there.

I studied computer science at Universitas Indonesia. Partway through, I started paying attention to which problems in software were actually hard, not algorithmically but in practice. The answer, consistently, was the gap between what a system was designed to do and what it actually did when real users touched it.

That gap is where quality engineering lives. I chose it not because I wanted to find bugs, but because it put me closest to the full picture: the product intent, the implementation, and the user experience. All at once, most roles in software give you one or two of those. Quality engineering gives you all three, simultaneously, usually under pressure.

My first professional roles confirmed this instinct. The interesting problems were never purely technical. They were decisions that had been made (about scope, about edge cases, about what “working correctly” even meant) that hadn’t been questioned carefully enough, and were now visible as failures in production.

At Tokopedia, the scope of the problems grew. The systems were larger, the teams were bigger, and the consequences of a production failure were measurable in real business terms. Quality work at this scale stopped being about individual test cases and became about understanding systems: how components depended on each other, where the fragile points were, and what a failure in one place meant for everything downstream.

This is also where my responsibilities started expanding beyond their formal description. At Tokopedia, test engineers were expected to participate actively in cross-functional planning. Not just execute tests, but contribute to readiness decisions, flag risks before they became incidents, and communicate status to product and engineering leadership. I found myself doing that work and noticing that the most important contributions I was making were upstream of execution: shaping how the team thought about the problem before anyone wrote code.

The TokoFood integration (one of the first major joint initiatives following the GoJek-Tokopedia merger) put this into sharp focus. The coordination challenge across multiple teams and two organizational structures was not a testing problem. It was a product problem. I took on the dependency tracking, the cross-team sync, and the stakeholder communication because the project needed someone to do it. Because, honestly, that was the most interesting work available.

By the time I was working within the GoTo Financial ecosystem, the pattern was clear. I kept asking questions that weren’t strictly in my remit: Why are we building this? What does the user actually need here? What’s the simplest version of this that solves the real problem? These are product questions. I was asking them from an engineering chair, which meant I could see the technical constraints clearly, but I wasn’t in the room when the decisions were made.

I want to be in that room. Not because I want authority for its own sake, but because the decisions being made there (about scope, about trade-offs, about what gets cut and what gets kept) determine whether the engineering work that follows matters. Getting those decisions right requires someone who understands what’s technically possible, what the user actually experiences, and what the business needs. That is what I have spent seven years learning to see.