Commerce Integrations & Data Flows

MY CONTRIBUTION

My role was not to implement these integrations as an engineer, but I needed enough technical understanding to manage them as products rather than treating integration as an engineering black box. Depending on the integration, that meant understanding technical documentation, identifying required data and behavior, aligning requirements across internal teams and external partners, working through mappings and edge cases, supporting testing, and investigating issues across different systems. The integration patterns varied significantly. Some systems consumed catalog information through structured feeds. Others communicated through APIs. Mobile and web capabilities could depend on SDKs or scripts. Analytics and attribution products introduced another layer of instrumentation, while internal systems could exchange information through synchronous or event-driven patterns. Working across web, mobile, kiosk, and commerce systems meant the same business concept could also need to remain consistent across several technical surfaces. I didn’t need to write every integration myself. But I did need to understand enough of each one to ask the right questions, challenge assumptions, test behavior, and help different teams agree on what “working correctly” actually meant.

PROBLEM

Integrations create an interesting kind of product complexity because no single team necessarily controls the entire experience. One system produces data. Another transforms it. Another consumes it. A third-party platform may interpret it differently. And the user only sees the final result. When something goes wrong at the end, the visible symptom rarely tells you where the actual problem started. A product may appear incorrectly in search because of something that happened much earlier in the data flow. An analytics discrepancy may originate from instrumentation, transformation, or how another platform interprets the event. A capability may work on one surface but behave differently elsewhere because the underlying integration isn’t equivalent. The challenge is therefore not merely connecting systems. It’s maintaining a shared understanding of the data and behavior across boundaries that are often owned by different teams and organizations.

OUTCOME

Over several years, I supported integrations across JD Sports Indonesia’s commerce ecosystem spanning product discovery, analytics, marketing technology, attribution, personalization, notifications, and internal services. The visible outcomes were different for each initiative, but collectively they helped different parts of the digital ecosystem exchange information more consistently across web, mobile, kiosk, and supporting systems. For me, the more meaningful outcome was the technical depth accumulated through repetition. After enough integrations, technical documentation stopped feeling intimidating. APIs, feeds, SDKs, data mappings, and event-driven systems became different ways of expressing a familiar problem: how one system communicates its state to another.

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.