JD Sports Indonesia Website, Kiosk & Internal Apps

MY CONTRIBUTION

I joined when the main commerce platforms were already running, so I don’t have a story about building everything from zero. Most of my work has been about understanding an existing system, finding where it could be improved, and introducing new capabilities without creating unnecessary problems elsewhere. Over the years, I have worked across customer-facing features, product discovery, account experiences, store-related journeys, analytics and marketing integrations, product data distribution, and internal tools used to operate the commerce experience. Some initiatives were small improvements. Others required coordination across several systems and teams before anything changed on the screen. As the scope grew, I also started working with two junior Product Managers. They support several smaller areas while I help with context, prioritization, and decisions when the problem starts touching a wider part of the product.

PROBLEM

At first, I tended to see ecommerce problems by where they appeared. A search problem belonged to search. A stock problem belonged to inventory. A tracking problem belonged to analytics. An order problem belonged to order management. The longer I worked across the system, the less useful those boundaries became. A change to product information could affect merchandising, search, advertising, and what customers eventually saw. Availability could influence what customers were allowed to buy. A seemingly simple customer-facing feature could depend on information coming from several places before it could work reliably. The difficult part was often not making one component work. It was understanding what else might move when that component changed.

APPROACH

Over time, I became less interested in immediately discussing the feature and more interested in understanding what surrounded it. Where does the information come from? What happens to it afterwards? Who else uses it? Which systems depend on the same thing? And what happens when one of those assumptions is wrong? This was especially useful when working on integrations. Different platforms often needed similar information in completely different ways. The technical details varied, but the product problem was usually about understanding expectations on both sides and making sure the connection still served an actual business or customer need. The same thinking applied to feature development. Before treating something as an isolated frontend requirement, I learned to trace enough of the surrounding flow to understand its dependencies and consequences. I didn’t need to know every system better than the engineers or specialists working on it. I needed to understand enough of the relationships between them to ask better questions and make better product decisions.

OUTCOME

More than three years of this work resulted in a long list of improvements, integrations, and new capabilities across the commerce experience. Some became visible customer features such as store discovery, store stock visibility, click & collect, account experiences, product discovery, and other improvements across the shopping journey. Others worked almost entirely behind the scenes, connecting the commerce experience with analytics, marketing, product data, merchandising, and internal operational systems. There isn’t one launch date or one metric that neatly summarizes the work. The better outcome is that the ecosystem has continued to evolve while remaining an active commerce platform used by customers and internal teams every day.

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.