I Build Things That Did Not Exist Yet

Roughly four out of five products I have worked on were greenfield — zero-to-one systems with no predecessor architecture, no reference implementation to copy from, and usually no local precedent to borrow patterns from either.

Thirteen years of owning delivery. The first four were physical — running quarterly production programmes on site in China and Cambodia for global sportswear brands, from the customer's requirements through to the shipment. The rest have been digital: mobility, commerce, public services and enterprise systems.

That order matters more than it looks. I learned how these markets actually work — who signs what, which step is legally binding, what people do instead of what the manual says — while standing in the factory, before I ever wrote a specification. It is why my instinct on a multi-market build is to ask what cannot be shared, rather than assuming everything can.

The work has been genuinely distributed rather than nominally global: a citizen system for Kampala, a Korean service built with a development team in Armenia, dealer platforms in Manila and Bangkok, fifteen national storefronts for LG. Different clients, different laws, different working hours.

Right now I am moving toward AI product. The coursework for a master's in AI & big data is behind me; the capstone is what I am building. The question that interests me is not how to fit a model into a product — it is how you decide whether the result is good enough to ship.

Jiwon Nam
01

How I Work

Step 01

Watch the Practice, Then Write the Requirements

Law you can read from a desk. How people actually work you have to sit next to. So I run continuous discovery on-site myself — contextual inquiry and user interviews with the operators who will run the system, before the first requirement, data contract or interface spec is written.

Then a proposal, and where the problem warrants it, a working prototype they can click before anyone signs off on a document. The requirement list comes last, written against something that already exists. The requirements that break a build late are the ones nobody thought to say out loud, and a prototype gets them said.

Step 02

Draw the System Boundary

Decide what belongs inside the shared platform and what has to be built as a market-specific service — then defend that boundary against the pressure to collapse everything into one codebase gated by feature flags. Shared domain model and shared platform primitives where they hold; separate services with their own release trains where local law or practice diverges.

Step 03

Ship With Measurement Attached

Instrumentation, event taxonomy and an SLO definition belong in the functional spec, right next to the error states and the runbook. A system without an analytics contract and without operational telemetry is a system nobody can debug in production, let alone improve after hand-over.

02

Education

03

Career

04

Recognition & Speaking

  • iF Design Award 2025 — User ExperienceNongupEZ · Ministry of Agriculture, Food and Rural Affairs
  • World Smart City ExpoLecturer · KOTRA · Goyang 2019
  • Smart Urban Solution Joint-WorkshopLecturer · Seoul Metro. Gov. & African Development Bank · Seoul 2019
  • Seoul—Danang Technology SeminarCo-organiser & moderator · KOTRA · Danang 2019
  • 7th Asia Smart City ConferenceLecturer, smart cities · World Bank · Yokohama 2018
  • Certified ScrumMaster®Scrum Alliance · Dec 2025 — Dec 2027
  • AWS Certified Cloud PractitionerAmazon Web Services · 2021
  • Google Analytics Individual QualificationGoogle · 2020
  • Content Marketing CertificationHubSpot Academy · 2019
Technology Seminar on intelligent e-government and smart city systems, Danang
Seoul—Danang Technology Seminar, 2019. Organised and moderated, with KOTRA — intelligent e-government and smart city systems.
Presenting at the Smart City Technology Forum, KINTEX
Smart City Technology Forum, 2019. Speaker, with the ASEAN-Korea Centre and KOTRA — Seoul & Goyang, KINTEX.
05

Tools & Languages

AI Tools

  • Claude
  • ChatGPT
  • Gemini
  • Claude Code
  • Cursor
  • Codex
  • NotebookLM
  • Copilot Studio

Product & Design

  • Demo with prototype
  • Field research
  • Customer interviews
  • Service planning
  • Screen design
  • Figma
  • Axure
  • Jira
  • Confluence
  • Notion
  • Trello

Technical

  • HTML
  • CSS
  • JavaScript
  • React
  • SQL
  • Python

Languages

  • Korean — native speaker
  • English — full professional proficiency

Markets Delivered For

  • Singapore
  • Thailand
  • Philippines
  • Korea
  • Uganda
  • + 15 LG.com markets

Worked On Site In

  • China
  • Cambodia
  • Vietnam
  • Philippines
  • Singapore
  • Uganda
  • Armenia
06

Questions I Get Asked

Are you willing to relocate?

Yes — and I have done it before. I lived and worked on site in China and Cambodia, and have run projects on the ground in Vietnam, the Philippines, Singapore, Uganda and Armenia. Moving for work is a known quantity rather than a leap.

Singapore is where I have the deepest footing — business development in the market since 2018 and delivery into it for Hyundai — but the deciding factor is the project, not the postcode. I am open to roles across Asia-Pacific, Europe and the Middle East. I hold a Korean passport and would need visa sponsorship.

What kind of roles are you looking for?

Senior Product Owner or Product / Platform / AI Systems PM in mobility and MaaS, commerce and payments platforms, or GovTech — particularly anything with a multi-market rollout, a regulated operating environment, or an agentic AI system with real reliability requirements at its centre. I am currently the product owner on an agentic-AI city super app, and I hold the coursework for a master’s in AI and big data.

Payments are the thread running through the commerce side of that work. Every market comes with its own payment instruments, PSP integrations and bank-of-record connections — specified market by market as separate integration contracts rather than inherited. I know the surface from the product and integration side: the order state machine, settlement path, reconciliation loop, KYC/AML touch-points, plus the idempotency and retry semantics you have to spec for any payment API you own. I have not worked inside a financial institution, so I would not present myself as a fintech specialist — but it is the direction I would like to move toward, and the surface is one I already know from the product side.

In any of these, I am most useful where the product touches existing operations rather than sitting on its own — and where someone has to decide what a model is actually allowed to do.

How much of your AI experience is hands-on?

It started in 2025 on Busan's autonomous mobility programme — the first time the product I owned sat on top of a physical AI system rather than beside one. The data governance portal followed, where the question was whether people could find data they trusted well enough to build on. Since then I have been product owner on an agentic-AI city super app, which puts me at the centre of both sides: the physical AI that moves vehicles through a city, and the software AI that decides what to say to a citizen and when.

Alongside that I have completed the coursework for a master's in AI and big data and am building the capstone — an offline evaluation harness for context-aware transit agents, with a ground-truth set derived from live transit APIs — plus two AI systems of my own. What I bring on top of the tooling is thirteen years of defining a ship threshold for systems whose output is not obviously correct — which is the hard part of AI systems product management, more than the modelling is.

Why can I only see one full case study?

Most of my work has been for enterprise and government clients under confidentiality, so screens and figures cannot go on a public site. I write up what I can — the decisions, the trade-offs, what went wrong — and I am happy to walk through the rest in detail in conversation.