Same Car, Three Rulebooks

Summary

Three Hyundai national sales companies 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 in each: the operator system behind Singapore's online shop, and the dealer sales apps for Thailand and the Philippines. All three handle the same objects — configuration, quotation, order, contract, financing — and all three integrate with systems that already existed.

What made them three projects rather than one was the sales process itself, which is locally determined and legally binding. They ended up sharing a domain model but not a codebase. I ran all three as product manager, from requirements through UAT to deployment and in-market training.

Context

Each of Hyundai's regional sales companies sells through two routes at once: a dealer network on the ground, and an online shop. Both routes end in the same place — a configured vehicle, a signed contract, a financing arrangement, a delivery — and both need software behind them.

The programme covered a different slice 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 sales apps and their admin, 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 forty 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 manager with ownership across requirements, functional definition, UI/UX specification, prototyping, QA and rollout.

Where the Plan Broke

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

The 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 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 config 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 into the interface, and no amount of theming hides it.

Drawing the Fork Line

Rather than force one product and absorb the cost in conditional logic, I mapped where the three markets genuinely agreed, and put the fork exactly there.

What held across all three was the domain vocabulary: what a vehicle configuration is, what a quotation is, what a contract is, how they relate. What did not hold was the process that moves between them.

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 preferences. Each one is either a legal requirement or an entrenched local practice, and each one changes the order flow 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 path through the order flow with its own confirmation state, not something reconciled offline afterwards.
3. Registration paperwork sat inside the sale. A new vehicle carries an initial three-year LTO registration, and the dealer prepares the documents for it — the authenticated Sales Invoice and the Certificate of Stock Reported. Both are set by public regulation, and both had to be generated and tracked as part of the order rather than 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 took Thailand over mid-programme from another product manager, which meant re-deriving decisions that had already been made once. 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 a customer signs would not match what was actually agreed.
3. Integration timing was the hard part to estimate. Integration standards exist in every market — what differed was how much of the answer was already written down, 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 rather than 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 definition, information architecture, user flows, screen specifications, UI/UX design and prototypes, unit and integration test scenarios, UAT scripts, quality review, and training in-market. Collaboration ran through Jira and Confluence with distributed engineering and design teams.

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 document. The only reliable way to surface it is to put something working in front of the people who will use it, in their own environment. On this programme that happened at UAT. It needed to happen at requirements.

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 handover.

What I Would Do Differently

I specified screens without specifying measurement. The deliverables defined what each screen did, who could reach it and what happened on error — but not a single event to be logged. 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 belongs in the functional specification, next to the error states, and it is 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 fork as a one-time architectural decision. It is really a standing question. A market that diverges on financing today may converge after a regulatory change, and nothing in the programme was set up to notice that and pull the shared boundary back.