Same Car, Three Rulebooks

Summary

Three Hyundai national sales companies (NSCs) needed operational software behind their vehicle sales. The plan everyone started from — build once, configure per country — did not survive contact with local law.

Each market runs both a dealer network and an online shop. The programme covered a different surface of the sales-operations system in each: an operator back-office behind Singapore’s online shop, and dealer point-of-sale systems for Thailand and the Philippines. All three own the same domain objects — configuration, quotation, order, contract, financing — and all three integrate with pre-existing systems of record (ERP, CRM) as upstream and downstream dependencies through documented integration contracts.

What made them three system builds rather than one was the sales process itself — locally determined, legally binding, outside a product team’s negotiation surface. They ended up sharing a domain model, not a runtime. I owned all three as Product Owner across the full system lifecycle — requirements analysis, system design, functional specification, UAT, deployment, hand-over to operations, and in-market user training.

Context

Each NSC sells through two routes at once: a dealer network on the ground, and an online shop. Both routes converge on the same domain objects — a configured vehicle, a signed contract, a financing arrangement, a delivery — and both need software behind them.

The programme covered a different slice of that stack per market. In Singapore, the operator system behind the online shop: catalogue, quotation, order, contract and third-party loan product linkage, integrated with ERP. In Thailand and the Philippines, the dealer point-of-sale apps and their admin back-office, with an existing CRM carrying the customer record.

The scale is worth stating plainly, because it sets what a bad release costs. The Philippine track alone covered a dealer network of around 40 passenger-car dealerships. Those are the people who quote, order and close on whatever the system does or does not let them do.

I joined as Product Owner with ownership across requirements analysis, functional specification, UI/UX design, prototyping, QA/UAT, rollout and stakeholder governance.

Where the Plan Broke

Every stakeholder started from the same assumption. Same brand, same portfolio of vehicles, similar catalogue shape — so one product with three configurations, and localisation is language, currency and tax rate.

The domain objects really are the same everywhere. A quotation is a quotation in all three markets. What is not the same is the sequence that turns one object into the next: which step has to happen before which, who has to sign, what must be presented before a deposit can be taken, how financing attaches to the order. Those rules are set locally and they are not negotiable by a product team.

A feature flag can change a label. It cannot change the moment a sale becomes a sale.

Once the sequence differs, the order state machine differs. Once the state machine differs, the screens that move an order between states differ. The divergence propagates upward from the legal layer, through the business logic, into the UI — and no amount of theming hides it.

Drawing the Fork Line

Rather than force a single-tenant deployment absorbing the divergence in conditional logic, I mapped where the three markets genuinely agreed and placed the system boundary at exactly that seam — not above it, not below it.

What held across all three was the domain vocabulary (ubiquitous language): what a vehicle configuration is, what a quotation is, what a contract is, how they relate. What did not hold was the workflow transitioning between those objects — the order state machine itself.

What Divergence Actually Looked Like

Abstractly, "the sales process differs by market" is easy to nod along to and easy to under-budget. Here is what each market actually did, itemised.

None of these are UX preferences. Each item is either a hard legal requirement or an entrenched local practice, and each one mutates the order state machine rather than sitting beside it.

The Philippines, Itemised

1. Channels the base system had retired were still live. The base product had dropped certain order channels as obsolete, but the market was still transacting over them. Those paths had to be built back in rather than migrated away from — the system does not get to decide how a market already works.
2. Settlement arrived by several routes. More than one settlement method was routine rather than exceptional. Each had to be a first-class state in the order flow with its own confirmation path, not something reconciled offline afterwards.
3. Registration paperwork sat inside the order lifecycle, not adjacent to it. A new vehicle carries an initial three-year LTO (Land Transportation Office) registration; the dealer prepares the authenticated Sales Invoice and the Certificate of Stock Reported (CSR). Both are set by public regulation and had to be generated, versioned and tracked as first-class artefacts of the order — not filed after it closed.
4. Negotiation moved in non-price terms. Bargaining often happened through what was added to a deal rather than the headline figure. That is not a discount field; it is its own line-item flow with its own approval path, and the system had to represent it honestly or the numbers would not reconcile.
5. Selling happened at national events. National-scale public events came with on-the-ground promotion and live selling. That needed a separate event-sales surface with its own inventory and lead handling — not a variant of the standard flow.

Thailand, Itemised

I inherited Thailand mid-programme from another product manager — a scope handover that meant re-deriving decisions already made once, without the original discovery notes. The market itself diverged on four counts.

1. A routine local instrument had no domestic equivalent. One payment instrument in everyday use there behaves nothing like its closest counterpart at home. It needed study before it could be specified, and it had to become a first-class payment state rather than an offline exception.
2. Pricing was set locally, not nationally. There was no single national figure to print on a quotation. Locally-determined pricing had to live inside the quotation object, or the document the customer signs would not match what was actually agreed.
3. Integration timing was the hardest thing to estimate. Integration standards exist in every market — what differed was how much of the answer was already documented, and how quickly it came back. Two working rhythms met on this programme, and the real risk was planning on one side’s assumptions. I built the estimate from confirmed answers rather than documentation, kept expectations on both sides tied to what had actually been confirmed, and re-based the plan as each integration firmed up.
4. There was no local assembly at the time. Local assembly came later; during this programme every unit was imported. Availability and delivery timing were therefore calculated on import lead times, not production slots.

Singapore, Itemised

Singapore diverged less on payment mechanics and more on who sells what — a market-structure problem rather than a paperwork one.

1. An established distributor already held the market. A distributor had built the brand locally over years and held the customer relationship. The operator system had to be designed to fit an occupied market rather than an empty one — which meant understanding that commercial position before writing a single flow.
2. More than one route-to-market ran in parallel. Vehicles could reach a customer by more than one commercial route, and the routes did not share a process. The catalogue and the order path therefore had to carry that distinction rather than assume a single path.
3. Local assembly changed the delivery promise. With assembly in-market, delivery dates were derived differently from imported stock. The date shown to a customer is a commitment, so the calculation behind it had to reflect that difference rather than average it away.

One More Thing That Was Not Shared

Model and trim line-ups differed market by market. Establishing what was actually sold where — and how each specification maps onto the shared catalogue structure — took its own research pass in all three markets.

What the Fork Cost, and What It Bought

Three tracks meant three sets of specifications, three UAT cycles and three training programmes. It also meant that when one market’s rules moved, nothing in the other two had to be regression-tested.

The alternative — one product with market flags — would have concentrated the entire regional risk into a single release train. For a network where a broken order flow means a sale cannot legally close that day, that concentration was the more expensive option.

Delivery

Across the three tracks I owned requirements analysis, functional specification, information architecture, user flows, screen specifications, UI/UX design and prototypes, unit and integration test scenarios, UAT scripts, quality review, and in-market user training. Collaboration ran through Jira and Confluence with distributed engineering and design teams under a weekly stakeholder cadence.

Two of the three tracks came with their own delivery conditions. Thailand was handed to me mid-programme from another product manager, so part of the work was reconstructing decisions I had not made. Across markets I ran weekly sessions with the local business leads — reporting progress, resolving conflicting requirements, and getting the financial-integration standards confirmed by the people accountable for them.

Training was done in person, not by document. In Manila that meant three days visiting two of the larger dealerships a day and running a session of ten to twenty staff at each. It is the cheapest requirements review you will ever get: people tell you what the system cannot do within about four minutes of touching it.

What I Got Wrong: Payment

Before build we ran weekly working sessions with each market — system detail, direction, which local rules and working practices had been encoded, what we had assumed on their behalf. Every session went out again as a follow-up email so both sides had the same written record. By the time scope froze, everyone believed payment was settled.

It was not. At UAT in-market, new requirements surfaced and several things we thought were agreed turned out to have been understood differently on each side. Not through carelessness. Local payment practice is largely tacit: the people who do it daily do not think to state it, and the people reading a specification do not know what to ask.

Fixing it late was expensive in a specific way. The build sat on established integrations with narrow tolerance for change, so this was never a matter of adding a field. Every change had to be checked against an architecture that could not flex much and still had to hold. I spent the UAT period taking feedback in the room during the day and working through the nights with the development PL in the Korea office, reconciling what the market needed against what the integration would actually permit.

It shipped. But the conclusion is not that we should have communicated more — we communicated a great deal, in writing, on a schedule. It is that tacit local practice does not survive the trip through a written specification. The only reliable way to surface it is to put a clickable prototype in front of the people who will use it, in their own environment — continuous discovery, not delayed validation. On this programme that happened at UAT. It needed to happen at the requirements stage, before scope freeze.

Outcome

All three systems were delivered and deployed. They are internal business tools rather than public applications, so none of them appears in an app store.

Post-launch service metrics sat outside the programme scope, and my access ended at handover. What I can speak to is delivery: scope, sequence, and the state of each system at hand-over to operations.

What I Would Do Differently

I specified screens without specifying measurement or an event taxonomy. The deliverables defined what each screen did, who could reach it and what happened on error — but not a single tracked event, not one funnel metric. When the systems went live, nobody could answer which parts of the order flow people actually struggled with.

That gap was invisible to me at the time because the contract ended at handover. It is not invisible now. Instrumentation and an analytics contract belong in the functional specification, next to the error states — cheaper there than anywhere downstream.

The second thing follows from the payment episode. I treated requirements as something that could be gathered remotely and confirmed in writing, with the market visit reserved for UAT and training. That order is backwards for anything governed by local practice rather than local law. Law you can read; practice you have to watch. A two-day visit before scope freeze would have cost a fraction of what the late changes cost.

The third: I treated the system boundary as a one-time architectural decision. It is really a standing governance question — a boundary owner, not a milestone. A market that diverges on financing today may converge after a regulatory change, and nothing in the programme owned the signal to detect that and pull the shared/local seam back to the shared side.