Marketing Service — From Hardcoded Promos to 10-Minute ProgramsMarketing Service — Dari Promo Hardcoded ke Program 10 Menit
Decoupling program logic and financing calculation from the acquisition appsMemisahkan logika program dan perhitungan pembiayaan dari aplikasi akuisisi
"A marketing program shouldn't need an engineer." — the principle behind the service.
.png)
Snapshot
| Role | Product Owner → Senior Product Owner — owned Marketing Service end-to-end |
| Company | PT KB Finansia (KreditPlus) — pattern later reapplied at Sinarmas (Garasi) |
| Timeline | 2021 – 2023 (reapplied 2025) |
| Team | Cross-functional — Product, Engineering, Product Marketing |
| Domain | Platform & internal tooling |
TL;DR
Every marketing program — a new promo, a campaign, a change to the financing structure — was hardcoded inside the acquisition apps. Launching one meant a full development cycle: 2–4 weeks waiting on engineering. And because each app calculated financing on its own, the numbers drifted from the core system — about 100 calculation mismatches per quarter.
I built Marketing Service: a web-based configuration and calculation engine that the product marketing team runs themselves, with apps calling it via API. Program launch dropped from 2–4 weeks to 1–10 minutes, and calculation mismatches went from ~100/quarter to 0. I later reapplied the same pattern at Sinarmas to pull program logic out of the Garasi dealer app.
This case study is about a platform instinct: when logic that should be shared lives at the edges, you don't patch the edges — you extract the service.
1. Context
In multifinance, marketing programs are a primary acquisition lever — promos, subsidies, and financing-scheme tweaks change constantly to compete for dealers and customers. The speed at which marketing can launch and adjust those programs is, in effect, the speed of the business.
2. The Problem — "Every promo was a software release."
- Program logic was embedded in the apps. To set up or change a program, engineering had to ship code — so a marketing idea waited 2–4 weeks behind a development cycle.
- Calculation lived in every app separately. Each acquisition app computed the financing structure on its own, so results drifted from the core system — ~100 mismatches per quarter, each one a potential dispute or wrong installment.
"I want to launch a promo this week — and I'm told it needs a development cycle." — a Product Marketing lead
The real problem wasn't "ship programs faster." It was: "take marketing off the engineering critical path, and make financing calculation a single source of truth."
3. Discovery — Two problems, one root cause
- Both pains traced to the same flaw: logic that should be centralized was scattered across the app edges.
- Marketing was a captive, frustrated user. They owned the programs but couldn't touch them without filing engineering tickets.
- The drift was silent but expensive. Mismatched calculations surfaced as disputes and rework long after release.
4. The Strategic Bet — Extract a service, don't patch the apps
The tempting fix was to keep improving each app's program module. I bet against it. The leverage was to pull program configuration and financing calculation into one service — a single source of truth — and turn the apps into thin clients that call it via API.
5. Prioritization & Trade-offs — Deciding what to build first
Decision 1 — Centralize the calculation engine first. Making one service the single source of truth for financing math killed the mismatch problem at the root and gave every app one number to trust. Trade-off: more foundational work upfront, before any visible "feature."
Decision 2 — Self-serve configuration for marketing. A no-code surface let product marketing set up programs and campaigns themselves — the change that actually removed the 2–4 week wait.
Decision 3 — Integrate apps as thin clients, highest-volume first. Rather than migrate every app at once, I sequenced integration starting where it mattered most, so value landed early without a big-bang cutover.
6. Execution — Treating marketing as the customer
The real users were the product marketing team, so I built with them — validating that the self-serve flow matched how they actually think about programs — while engineering hardened the calculation service and the API contracts the apps depended on.
7. Impact
- Program launch time: 2–4 weeks → 1–10 minutes
- Calculation mismatches (core vs. acquisition apps): ~100/quarter → 0
- Programs became personalizable per dealer/agent, not one-size-fits-all
- Pattern reused at Sinarmas to decouple program logic from the Garasi dealer app
8. Reflections — What I'd carry forward
- Centralize what should be shared. Both problems were really one: shared logic living at the edges.
- The best internal tools remove a team from the critical path. The win wasn't a feature — it was marketing no longer waiting on engineering.
- A good pattern is portable. The same extraction worked again at a different company, on a different app.
Prepared by Hamdan Fauzi — Product Manager. Some figures generalized for company confidentiality. Happy to walk through the full version in conversation.
"Program marketing seharusnya tak perlu seorang engineer." — prinsip di balik service ini.
Snapshot
| Peran | Product Owner → Senior Product Owner — memegang Marketing Service end-to-end |
| Perusahaan | PT KB Finansia (KreditPlus) — pola kemudian diterapkan ulang di Sinarmas (Garasi) |
| Timeline | 2021 – 2023 (diterapkan ulang 2025) |
| Tim | Lintas fungsi — Product, Engineering, Product Marketing |
| Domain | Platform & internal tooling |
TL;DR
Setiap program marketing — promo baru, campaign, perubahan struktur pembiayaan — tertanam langsung di dalam aplikasi akuisisi. Meluncurkan satu program berarti satu siklus development penuh: 2–4 minggu menunggu engineering. Dan karena tiap aplikasi menghitung pembiayaan sendiri-sendiri, angkanya menyimpang dari core system — sekitar 100 selisih perhitungan per kuartal.
Saya membangun Marketing Service: mesin konfigurasi sekaligus perhitungan berbasis web yang dijalankan sendiri oleh tim product marketing, dengan aplikasi memanggilnya via API. Waktu peluncuran program turun dari 2–4 minggu ke 1–10 menit, dan selisih perhitungan dari ~100/kuartal ke 0. Pola yang sama kemudian saya terapkan ulang di Sinarmas untuk menarik logika program keluar dari aplikasi dealer Garasi.
Studi kasus ini tentang insting platform: ketika logika yang seharusnya dibagi bersama justru hidup di pinggiran, kamu tak menambal pinggirannya — kamu mengekstraknya jadi service.
1. Konteks
Di multifinance, program marketing adalah tuas akuisisi utama — promo, subsidi, dan penyesuaian skema pembiayaan terus berubah demi bersaing memperebutkan dealer dan konsumen. Kecepatan tim marketing meluncurkan dan menyesuaikan program itu, pada praktiknya, adalah kecepatan bisnisnya.
2. Masalah — "Setiap promo adalah sebuah rilis software."
- Logika program tertanam di aplikasi. Untuk menyiapkan atau mengubah program, engineering harus merilis kode — jadi sebuah ide marketing menunggu 2–4 minggu di belakang siklus development.
- Perhitungan hidup di tiap aplikasi terpisah. Setiap aplikasi akuisisi menghitung struktur pembiayaan sendiri, sehingga hasilnya menyimpang dari core system — ~100 selisih per kuartal, masing-masing berpotensi jadi sengketa atau cicilan yang salah.
"Saya mau luncurkan promo minggu ini — tapi katanya butuh siklus development." — seorang Product Marketing lead
Masalah sebenarnya bukan "luncurkan program lebih cepat." Melainkan: "keluarkan marketing dari critical path engineering, dan jadikan perhitungan pembiayaan satu sumber kebenaran."
3. Discovery — Dua masalah, satu akar
- Kedua keluhan berujung pada cacat yang sama: logika yang seharusnya tersentralisasi justru tersebar di pinggiran aplikasi.
- Marketing adalah pengguna yang tersandera dan frustrasi. Mereka memiliki programnya tapi tak bisa menyentuhnya tanpa membuat tiket engineering.
- Penyimpangannya senyap tapi mahal. Perhitungan yang tak cocok muncul sebagai sengketa dan rework jauh setelah rilis.
4. Taruhan Strategis — Ekstrak jadi service, jangan tambal aplikasinya
Perbaikan yang menggoda: terus memoles modul program di tiap aplikasi. Saya menolaknya. Leverage-nya adalah menarik konfigurasi program dan perhitungan pembiayaan ke dalam satu service — satu sumber kebenaran — dan mengubah aplikasi menjadi thin client yang memanggilnya via API.
5. Prioritas & Trade-off — Menentukan apa yang dibangun lebih dulu
Keputusan 1 — Sentralisasi mesin perhitungan lebih dulu. Menjadikan satu service sebagai sumber kebenaran tunggal untuk matematika pembiayaan mematikan masalah selisih dari akarnya dan memberi tiap aplikasi satu angka yang bisa dipercaya. Trade-off: kerja fondasi lebih banyak di depan, sebelum ada "fitur" yang terlihat.
Keputusan 2 — Konfigurasi mandiri untuk marketing. Sebuah permukaan no-code memungkinkan product marketing menyiapkan program dan campaign sendiri — perubahan yang benar-benar menghapus waktu tunggu 2–4 minggu.
Keputusan 3 — Integrasikan aplikasi sebagai thin client, yang volume tertinggi dulu. Alih-alih memigrasikan semua aplikasi sekaligus, saya mengurutkan integrasi mulai dari yang paling penting, sehingga nilai mendarat lebih awal tanpa cutover big-bang.
6. Eksekusi — Memperlakukan marketing sebagai pelanggan
Pengguna sebenarnya adalah tim product marketing, jadi saya membangun bersama mereka — memastikan alur mandirinya cocok dengan cara mereka benar-benar memikirkan program — sementara engineering memperkuat service perhitungan dan kontrak API yang diandalkan aplikasi.
7. Dampak
- Waktu peluncuran program: 2–4 minggu → 1–10 menit
- Selisih perhitungan (core vs. aplikasi akuisisi): ~100/kuartal → 0
- Program jadi bisa dipersonalisasi per dealer/agent, bukan seragam
- Pola dipakai ulang di Sinarmas untuk memisahkan logika program dari aplikasi dealer Garasi
8. Refleksi — Yang akan saya bawa terus
- Sentralisasi yang seharusnya dibagi bersama. Kedua masalah sebenarnya satu: logika bersama yang hidup di pinggiran.
- Internal tool terbaik mengeluarkan satu tim dari critical path. Kemenangannya bukan sebuah fitur — melainkan marketing yang tak lagi menunggu engineering.
- Pola yang baik itu portabel. Ekstraksi yang sama berhasil lagi di perusahaan berbeda, di aplikasi berbeda.
Disusun oleh Hamdan Fauzi — Product Manager. Sebagian angka digeneralisasi demi kerahasiaan perusahaan. Dengan senang hati menjelaskan versi lengkapnya secara langsung.