SELECTED PRODUCT WORK

Things I’ve helped build.
What I learned from building them.

A selection of product & engineering work across digital commerce, platforms, mobile apps, internal tools, IoT, and a few other systems I’ve worked on over the years.

Erajaya Group - JD Sports Indonesia2026Shipped

Commerce Catalog Migration

Migrating around 80,000 products sounded like a data problem. It wasn’t. The harder part was replacing a catalog system that had accumulated years of dependencies, behaviors, and undocumented assumptions without changing how the existing commerce experience worked for customers. Before we could safely move anything, we first had to understand what we were actually moving away from.

MY ROLE: Senior Product Manager (Senior Assistant Manager)
IMPACT: This project changed how I think about migrations. Before this, I mostly saw migration as moving something from an old system to a new one. Now I see it more as an exercise in discovering everything people have forgotten the old system was responsible for. The data is often the visible part. The real risk lives in dependencies, assumptions, edge cases, and years of behavior that have quietly become part of the product. It also taught me that migration isn’t finished when the cutover succeeds. A new system needs to become understandable to the people operating it before it can genuinely replace the old one.

Product area

Product CatalogCommerce PlatformPlatform MigrationProduct DataWebsiteMobile AppKioskProduct DiscoveryMerchandisingCommerce InfrastructureInternal Tools

Platform

WebMobile AppKioskInternal App3rd Parties Integrations

Read case study

Erajaya Group - JD Sports Indonesia2024 - PresentMaintained

JD Sports Indonesia Mobile App

Many people assume the hardest part of building a mobile app is the development itself. In my experience, the more difficult challenge came afterwards—making product decisions when every stakeholder brought a different perspective, and each of them had a valid reason. This project became my real lesson in building a product not only for users, but alongside people with different priorities and expectations.

MY ROLE: Senior Product Manager (Assistant Manager - Digital Product)
IMPACT: From the outside, the outcome of this project might sound simple: the app was built, launched, and eventually used by a large number of customers. For me, the bigger impact was how it changed the way I work afterwards. I became much more skeptical of statements like “users need this,” “this is how another market does it,” or “the business wants this” without first understanding the context behind them. Any of those statements can be valid, but none of them automatically makes something the right product decision. I also learned that a Product Manager does not always need to be the person with the best answer in the room. Often, the more useful job is making sure everyone in the room is actually discussing the same problem. That is probably the biggest lesson I took from this project: building products is not only about making good decisions. A lot of the work is about finding decisions that are reasonable enough for people with different interests to keep moving in the same direction.

Product area

Mobile CommerceAndroidiOSCustomer ExperienceCommerceLoyaltyProduct DiscoveryAccount & IdentityCheckout & PaymentRetention

Platform

AndroidIOS

Read case study

Erajaya Group - JD Sports Indonesia2023 - PresentMaintained

Commerce Integrations & Data Flows

Some of the most technically demanding product work I’ve handled has barely had a user interface. Across JD Sports Indonesia’s digital products, I’ve managed integrations connecting commerce systems with product discovery, analytics, marketing, personalization, attribution, notifications, and other internal and external services. The implementations varied—feeds, APIs, SDKs, scripts, event-driven integrations, and other data exchanges—but the recurring product problem was the same: What information needs to move between systems, when should it move, and what happens when it doesn’t? Over time, integration work became one of the biggest contributors to my technical depth as a Product Manager.

MY ROLE: Senior Product Manager (Assistant Manager - Digital Product)
IMPACT: Integration work significantly changed my technical confidence as a Product Manager. I became more comfortable reading technical documentation, discussing data contracts, testing APIs, reasoning about system boundaries, and debugging problems collaboratively with engineers and external partners. More importantly, it changed where I look when evaluating product behavior. The interface is only the final surface. Behind a search result, recommendation, campaign, notification, analytics event, or product attribute can be a chain of systems exchanging information long before anything reaches the user. That perspective made me a more technical Product Manager without requiring me to become the engineer implementing those systems. I learned where my technical depth is useful—and where the boundary of my role should remain.

Product area

System IntegrationCommerce PlatformAPISDKProduct DataData FeedsAnalyticsMarketing TechnologyProduct DiscoveryAttributionPersonalizationPush NotificationWebMobile AppKioskInternal Services

Platform

UNBXDSalesforceGoogle Analytics 4Microsoft ClarityFirebaseAdjustImpactTrue FitMagentoInternal ToolsMiddlewareSAP

Read case study

Erajaya Group - B2B TAM2023Shipped

B2B Dealer Portal

Not every commerce product is built for millions of customers. For several months, I temporarily managed Erajaya’s B2B Dealer Portal, a commerce platform used by business partners to purchase products from its distribution businesses. The audience was smaller than the consumer products I was used to, but each transaction carried significantly more weight. It was my first close look at how different ecommerce becomes when the customer is a business rather than an individual.

MY ROLE: Product Manager temporarily responsible for the B2B Dealer Portal during a team transition.
IMPACT: The biggest impact of this short period wasn’t the number of features delivered. It was exposure to a different type of commerce problem. B2C had trained me to think about scale largely through customers, traffic, and transaction volume. B2B added another dimension: the consequence of each individual transaction. A smaller user base can still support a product where reliability, operational clarity, and transaction confidence matter enormously. It made me much more careful about using user volume as a shortcut for product complexity.

Product area

B2B CommerceDealer PortalWebOrder ManagementTransaction ManagementInternal OperationsBusiness OperationsWholesaleCustomer ExperienceOperational Workflows

Platform

WebInternal Tools

Read case study

ilustrasi jd sports digital commerce ecosystem

Erajaya Group - JD Sports Indonesia2023 - PresentMaintained

JD Sports Indonesia Website, Kiosk & Internal Apps

I started by seeing a website. More than three years later, I started seeing the system behind it. Working across JD Sports Indonesia’s website, kiosk, internal apps, and various integrations taught me how many things need to work together for an ecommerce experience to feel simple to customers. What started as maintaining and improving existing products gradually became an exercise in understanding how catalog, merchandising, inventory, orders, customer experience, analytics, and external platforms depend on each other.

MY ROLE: Senior Product Manager (Senior Assistant Manager - Digital Product)
IMPACT: The biggest impact of this work was probably on how I understand digital products. I started with the interface. Over time, I learned to follow what happened before and after it. A product doesn’t simply appear on a page. Information has to come from somewhere, be enriched and organized, become discoverable, stay aligned with pricing and availability, and sometimes be distributed to other platforms that understand that information differently. And once a customer decides to buy, another chain of dependencies begins. That changed how I approach product problems. I became less interested in owning individual features and more interested in understanding the connections around them.

Product area

EcommerceWebsiteKioskInternal ToolsCommerce PlatformProduct CatalogMerchandisingProduct DiscoveryInventoryOrder ManagementOmnichannelCustomer ExperienceOperations

Platform

WebKioskInternal ToolsSystem Integrations

Read case study

Moladin - Wholesale Business Unit2022Archived

Moladin Wholesale Mobile & Internal Apps

This was one of the shortest chapters of my product career, but probably one of the most formative. As an Associate Product Manager in Moladin’s Wholesale business, I managed an Android app used by field agents alongside internal applications used by operational teams. More importantly, this was where I first experienced a structured product environment with a dedicated engineering squad, regular development cycles, product analytics, and clearer ownership. I didn’t stay long enough to see everything we started mature. But I left with something that lasted much longer: a reference point for how I wanted to practice Product Management.

MY ROLE: Associate Product Manager - Core Platform
IMPACT: Moladin gave me a reference point. It was the first environment where I experienced many pieces of product development working together at the same time: clearer squad ownership, dedicated engineering capacity, QA, regular development cycles, product analytics, instrumentation, and a stronger connection between discovery and delivery. That reference became surprisingly useful later in my career. Not every organization has the same product maturity, tooling, structure, or leadership support. Once I had experienced one working model, however, I no longer needed every environment to tell me what good product practice could look like. I had a compass.

Product area

AndroidInternal ToolsWholesaleAutomotiveField OperationsVehicle InspectionVehicle ListingTransaction ManagementFraud PreventionUser Access ManagementOperational WorkflowsProduct Analytics

Platform

Android

Read case study

goKampus (Now LearNext.ai)2021Archived

goKampus University & Learning Platform

My first full-time Product Management role happened while the product itself was changing direction. goKampus had started as a platform helping students apply to universities through a single experience. By the time I joined, the company was expanding into online learning, and I worked across the learner experience, internal operations, content partner tools, and early experiments with live learning. It taught me one of my earliest product lessons: when you’re still learning what should exist, sometimes the fastest way to learn is to build much less than you initially imagined.

MY ROLE: Senior Associate Product Manager - goKampus University & Internal Platform
IMPACT: goKampus changed my relationship with product building. Before this role, I naturally associated Product Management with turning requirements into features. Working in a fast-moving startup taught me that the more uncertain the problem is, the less you should initially commit to the solution. Sometimes the right product decision was a new feature. Sometimes it was improving an internal workflow. And sometimes it was a form, a Zoom link, and enough manual work to answer the next important question. That distinction became something I carried into every product role afterwards.

Product area

EdTechOnline LearningLearning Management SystemLive LearningWebInternal ToolsPartner PlatformContent ManagementLearner ExperienceCourse CompletionCertificationEducation Marketplace

Platform

IOSAndroidWeb

Read case study

PT Gamatechno Indonesia2021Archived

End-to-end Smart Water Meter Platform

What started as an IoT device became a much bigger product problem. At Gamatechno, I was trusted to take Product Owner responsibility for an end-to-end smart water metering platform aimed at regional water utilities in Indonesia. The product connected physical meters, IoT connectivity, operational software, and customer-facing mobile apps into one service. We built it. We demonstrated it to prospective users. But during my time there, we never reached commercial adoption. That experience taught me something I couldn’t have learned from technical prototypes alone: having a working and relatively complete product still doesn’t mean the market is ready to buy it.

MY ROLE: Product Owner · IoT System Analyst
IMPACT: This was probably my first experience owning something that looked much more like a complete product than a prototype. That distinction taught me an uncomfortable but important lesson. You can have working hardware. You can have connectivity. You can have an operational platform. You can have mobile apps. You can demonstrate the entire thing successfully. And still not have a business. That experience stayed with me when I later moved into Product Management. I became much more skeptical of using product completeness as evidence that a product was valuable.

Product area

IoTSmart MeteringUtility TechnologyB2BHardwareLoRaWANIoT PlatformInternal ToolsBillingPaymentCustomer ManagementAndroidiOSOperational Platform

Platform

IoT HardwareIoT GatewayIoT ConnectivityWebIOSAndroid

Read case study

PT Gamatechno Indonesia2021Archived

IoT Solution Prototyping

Before moving into Product Management, I spent several months working much closer to the technology itself. I joined Gamatechno as an IoT Engineer, although the actual role quickly became closer to an IoT System Analyst. I worked with prospective clients to translate operational problems into technical concepts, then built prototypes to find out whether those concepts could actually work. Some worked technically. None became production deployments during my time there. That turned out to be one of the most useful parts of the experience.

MY ROLE: IoT System Analyst
IMPACT: This period gave me technical depth that became unexpectedly useful after I moved into Product Management. Working from physical sensors through connectivity, data processing, and application interfaces made systems feel less abstract. It taught me to trace information across boundaries and to understand enough of each layer to have better conversations with specialists later in my career. But the more important lesson wasn’t technical. It was learning that building something is itself a cost, and sometimes the most valuable result of building a prototype is deciding not to build the full product.

Product area

IoTHardwareConnected DevicesIndoor PositioningAsset TrackingSmart AgricultureIndustrial MonitoringPredictive MaintenanceLoRaWANBluetooth Low EnergyCloud PlatformData Visualization

Platform

IoT HardwareIoT ConnectivityWebWeb DasdhboardWeb Internal ToolsIOSAndroid

Read case study

ilustrasi antares iot platform ecosystem

PT Telkom Indonesia (Persero) Tbk2020Shipped

ANTARES IoT Platform & LoRAWAN Connectivity Deployment

My first serious exposure to building technology happened during a year-long internship with Telkom Indonesia’s IoT team. I worked around ANTARES, Telkom’s IoT platform and connectivity ecosystem, supporting work across hardware prototyping, LoRaWAN connectivity, network testing, technical documentation, and product quality. At the time, I mostly saw it as an opportunity to learn more engineering. Looking back, it gave me something broader: the ability to move between physical hardware, networks, software, and documentation—and understand enough of the system to explain it to someone else.

MY ROLE: IoT Research & Development Intern
IMPACT: The biggest impact of this experience was technical literacy. Not technical depth for the sake of becoming the strongest engineer in the room, but enough understanding to see how different layers depend on each other and ask better questions when something goes wrong. That became surprisingly useful after I moved into Product Management. When engineers later talked about APIs, data flows, network constraints, integrations, or application behavior, those conversations did not feel like complete black boxes. I could usually build a mental model of where the information came from, what it passed through, and where a problem might actually be happening. The documentation work also stayed with me. Writing technical tutorials taught me that understanding something and explaining it are two different skills. Years later, the same habit became useful when writing product requirements: if engineers and QA cannot understand the context, expected behavior, and constraints without repeatedly asking what I meant, then the communication is still incomplete. The tools changed. The underlying skill did not.

Product area

IoT PlatformLoRaWANIoT ConnectivityDeveloper PlatformHardwarePCB DesignRF & AntennaNetwork InfrastructureGatewayDeveloper DocumentationQuality AssuranceResearch & Development

Platform

IoTHardwareWebIoT ConnectivityIoT PlatformIoT Gateway

Read case study

LET'S TALK

Something worth talking about?

Product, systems, something you're building, or just an idea worth comparing notes on—feel free to reach out.

Email me WhatsApp