Program Studi Bisnis Digital • FEB UNDIP

Laboratorium Financial Technology

Pertemuan 14 — Presentasi dan Pengembangan Lanjutan Proyek Fintech: Kolaborasi Tim

Menutup satu semester praktik fintech: bagaimana mempresentasikan proyek dengan meyakinkan, bekerja efektif dalam tim, dan merancang langkah pengembangan berikutnya.

RPS MINGGU 15 • 2 × 50 MENIT

Selamat datang, Anda semua, di pertemuan terakhir Laboratorium Financial Technology. Setelah empat belas minggu berjalan dari sejarah disrupsi layanan keuangan, blockchain, pembayaran digital, hingga RegTech dan cybersecurity, hari ini saatnya proyek fintech kelompok Anda naik panggung. Bayangkan Anda dan tim sedang berdiri di depan calon investor seperti yang biasa terjadi di ajang demo day startup Indonesia — mirip suasana ketika founder OVO atau Kredivo pertama kali meyakinkan investor bahwa ide mereka layak didanai. Dua jam ke depan kita akan bahas cara menyusun presentasi proyek yang meyakinkan, bagaimana tim yang solid bekerja sama menyelesaikan pengembangan, dan bagaimana merancang langkah lanjutan setelah kelas ini selesai. Ini bukan sekadar tugas akhir semester, tapi latihan nyata sebelum Anda benar-benar terjun ke industri fintech.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menyusun presentasi proyek fintech yang meyakinkan dan mengelola pengembangan lanjutan secara kolaboratif dalam tim. Secara rinci:

PRESENTASI

Menyusun struktur pitch deck fintech yang lengkap dan runtut.
Menyampaikan demo produk & menjawab sesi tanya jawab dengan percaya diri.

KOLABORASI & ITERASI

Menjelaskan cara kerja tim agile (sprint, peran, tools) dalam proyek fintech.
Menghitung indikator sederhana (unit economics, velocity) & menyusun roadmap lanjutan.

Mari kita bedah dulu apa yang ingin dicapai hari ini, Anda semua. Pertama, dari sisi presentasi, Anda akan belajar menyusun pitch deck yang runtut dan menyampaikan demo dengan cara yang meyakinkan audiens, termasuk bagaimana menjawab pertanyaan sulit tanpa panik. Kedua, dari sisi kerja tim, Anda akan memahami bagaimana tim fintech profesional — baik di startup kecil maupun divisi digital bank seperti BCA Digital — bekerja secara agile dengan pembagian peran yang jelas. Ketiga, Anda akan berlatih menghitung dua indikator sederhana yang sering dipakai investor maupun tim internal untuk menilai kesehatan proyek: unit economics dan velocity tim. Terakhir, Anda akan merancang roadmap pengembangan lanjutan sehingga proyek ini tidak berhenti begitu nilai keluar, melainkan bisa terus Anda kembangkan sebagai portofolio.

Bagian 1 dari 3

Mempersiapkan Presentasi Proyek Fintech

Bagaimana menyusun cerita yang meyakinkan dari sebuah ide fintech mentah menjadi presentasi yang siap dinilai dosen dan "investor" simulasi.

Anatomi Pitch Deck Fintech yang Efektif

Pitch deck (materi presentasi ringkas untuk meyakinkan audiens) proyek fintech yang baik mengikuti alur logis dari masalah menuju permintaan dukungan.

Aturan praktis: maksimal 10 slide inti, satu ide besar per slide, dan durasi presentasi total 7-10 menit sebelum sesi tanya jawab.

Perhatikan alur di layar ini, Anda semua — ini adalah kerangka pitch deck yang dipakai hampir semua startup fintech dunia, dari Stripe sampai Flip di Indonesia. Dimulai dari masalah nyata yang Anda temukan, misalnya sulitnya UMKM di pasar tradisional mengakses modal kerja, lalu solusi konkret yang tim Anda bangun, diikuti model bisnis yang menjelaskan dari mana proyek ini akan menghasilkan pendapatan. Setelah itu baru traksi dan tim, yaitu bukti bahwa ide ini sudah diuji dan dikerjakan oleh orang yang tepat, dan ditutup dengan ask, permintaan dukungan atau langkah selanjutnya. Ingat aturan praktis di bawah: jangan membuat pitch deck bertele-tele, batasi sepuluh slide inti dan durasi tujuh sampai sepuluh menit, karena audiens seperti dosen atau investor sungguhan biasanya punya waktu terbatas dan mudah kehilangan fokus jika presentasi terlalu panjang.

Menyusun Problem Statement & Solusi yang Tajam

PROBLEM STATEMENT YANG KUAT

Spesifik: sebutkan siapa yang terdampak, bukan "masyarakat umum".
Didukung data: kutip angka nyata (survei, laporan OJK, BPS).
Relatable: audiens bisa membayangkan situasinya.

CONTOH PENERAPAN

"Pedagang di pasar tradisional Semarang butuh modal harian Rp1-3 juta, tapi 60% ditolak bank karena tidak punya agunan — mereka terpaksa pakai rentenir dengan bunga harian hingga 20%."

Solusi: platform P2P lending (pinjam-meminjam daring antar pihak, tanpa bank sebagai perantara) berbasis skor kredit alternatif dari transaksi digital harian.

Hitung dari Nol: Unit Economics Sederhana

Investor sering bertanya: "berapa biaya untuk mendapatkan satu pengguna, dan berapa nilai yang dihasilkan pengguna itu selama menjadi pelanggan?" Dua metrik ini disebut CAC (Customer Acquisition Cost — biaya akuisisi pelanggan) dan LTV (Lifetime Value — nilai seumur hidup pelanggan).

Langkah	Perhitungan	Nilai
1. Total biaya marketing bulan ini	diketahui	Rp50.000.000
2. Pengguna baru yang didapat	diketahui	500 pengguna
3. CAC per pengguna	Rp50.000.000 ÷ 500	Rp100.000
4. LTV (revenue Rp25.000/bulan × 12 bulan)	Rp25.000 × 12	Rp300.000
5. Rasio LTV : CAC	Rp300.000 ÷ Rp100.000	3,0x

RASIO LTV : CAC

3,0x

Sehat jika ≥ 3x — patokan umum yang dipakai investor startup

Mari kita hitung bersama, Anda semua, satu contoh unit economics paling dasar yang wajib ada di slide traksi pitch deck Anda. Anggap tim Anda menghabiskan lima puluh juta rupiah untuk marketing bulan ini dan berhasil mendapatkan lima ratus pengguna baru — dari situ CAC-nya adalah lima puluh juta dibagi lima ratus, hasilnya seratus ribu rupiah per pengguna. Di sisi lain, jika setiap pengguna menghasilkan revenue dua puluh lima ribu rupiah per bulan dan rata-rata bertahan dua belas bulan, LTV-nya adalah tiga ratus ribu rupiah. Bandingkan keduanya, rasio LTV dibagi CAC sama dengan tiga koma nol kali, dan ini persis patokan yang dipakai investor sungguhan — termasuk saat menilai startup fintech seperti Kredivo pada tahap awal — untuk menilai apakah model bisnis suatu proyek sehat secara jangka panjang, bukan sekadar menarik pengguna dengan biaya besar tanpa kembali modal.

Storytelling & Teknik Demo Live yang Meyakinkan

SHOW, DON'T JUST TELL

Mulai dengan narasi pengguna nyata: "Bu Sari, pedagang di Pasar Johar, butuh modal Rp2 juta besok pagi..."
Tunjukkan alur aplikasi langkah demi langkah, bukan hanya screenshot statis.
Sorot satu fitur unggulan saja — jangan demo semua fitur sekaligus.

RENCANA CADANGAN (BACKUP PLAN)

Siapkan video rekaman demo jika koneksi internet bermasalah saat presentasi.
Uji coba aplikasi di perangkat presentasi H-1, bukan menit terakhir.
Latihan timing: demo maksimal 2-3 menit dari total durasi presentasi.

Bagian ini sering menentukan menang atau tidaknya sebuah presentasi, Anda semua, karena audiens jauh lebih mudah ingat cerita ketimbang daftar fitur teknis. Alih-alih membuka demo dengan kalimat "berikut adalah fitur-fitur aplikasi kami", coba mulai dengan cerita seorang pengguna nyata, misalnya Bu Sari pedagang di Pasar Johar yang butuh modal besok pagi — baru setelah itu Anda tunjukkan bagaimana aplikasi Anda menyelesaikan masalahnya langkah demi langkah. Ingat juga untuk tidak mendemokan semua fitur sekaligus, pilih satu momen paling meyakinkan saja. Dan yang tidak kalah penting, selalu siapkan rencana cadangan seperti video rekaman demo, karena koneksi internet yang tiba-tiba putus di tengah presentasi bisa merusak kesan yang sudah Anda bangun susah payah — ini pelajaran yang sering dialami startup sungguhan saat demo day.

Menjawab Sesi Tanya Jawab dengan Percaya Diri

Sesi Q&A (tanya jawab) sering lebih menentukan penilaian daripada presentasi itu sendiri, karena di sinilah audiens menguji seberapa dalam Anda memahami proyek sendiri.

SIAPKAN JAWABAN UNTUK

"Bagaimana model bisnis ini menghasilkan uang?"
"Apa yang membedakan Anda dari kompetitor?"
"Bagaimana Anda menjamin keamanan data pengguna?"

Jika tidak tahu jawaban pastinya: jujur katakan "kami belum menguji itu, tapi rencana kami adalah...", jangan mengarang jawaban. Kejujuran lebih dihargai daripada jawaban asal.

Latihan Kelompok: Simulasi Pitching 5 Menit

Sebelum presentasi final, latih tim Anda dengan simulasi singkat berikut.

INSTRUKSI LATIHAN

Bentuk kelompok sesuai tim proyek fintech masing-masing (3-5 orang).
Satu anggota tampil sebagai presenter utama, sisanya berperan sebagai "investor" yang bertanya.
Waktu presentasi: 5 menit (problem, solusi, demo singkat) + 3 menit tanya jawab.
Kelompok "investor" mencatat 1 kelebihan dan 1 saran perbaikan untuk disampaikan setelahnya.
Rotasi peran presenter setiap putaran agar semua anggota tim berlatih.

Bagian 2 dari 3

Kolaborasi Tim dalam Pengembangan

Presentasi yang bagus lahir dari proses kerja tim yang rapi. Bagian ini membahas cara tim fintech profesional mengorganisasi pekerjaan mereka.

Model Kerja Agile/Scrum untuk Tim Proyek Kecil

Scrum adalah kerangka kerja agile yang membagi pekerjaan menjadi periode pendek berulang disebut sprint (biasanya 1-2 minggu), agar progres bisa dievaluasi secara rutin.

Istilah kunci: backlog (daftar tugas yang belum dikerjakan), story point (satuan estimasi usaha per tugas).

Perhatikan siklus di layar ini, Anda semua — inilah cara kerja Scrum yang paling ringkas untuk tim kecil seperti tim proyek Anda. Setiap sprint dimulai dengan sprint planning, di mana tim memilih tugas dari backlog yang akan dikerjakan dalam satu atau dua minggu ke depan. Selama sprint berjalan, tim melakukan daily stand-up singkat setiap hari, cukup sepuluh sampai lima belas menit, untuk saling update apa yang sudah dikerjakan, sedang dikerjakan, dan hambatan apa yang dihadapi. Di akhir sprint ada sprint review untuk menunjukkan hasil kerja, dan retrospective untuk mengevaluasi apa yang berjalan baik dan apa yang perlu diperbaiki di sprint berikutnya. Siklus ini terus berputar, dan cara kerja inilah yang dipakai hampir semua tim produk digital di Indonesia, dari startup kecil sampai divisi teknologi bank besar seperti BCA Digital.

Pembagian Peran dalam Tim Proyek Fintech

PRODUCT & DESIGN

Product Manager: prioritas fitur & roadmap
UI/UX Designer: alur & tampilan aplikasi

TEKNIS

Developer/Engineer: membangun fitur
QA/Tester: memastikan bebas bug

BISNIS & KEPATUHAN

Business/Growth: model bisnis & traksi
Compliance: kepatuhan regulasi OJK/BI

Dalam tim proyek fintech, baik di kelas maupun di dunia nyata, setiap orang idealnya punya peran yang jelas agar tidak ada tugas yang tumpang tindih atau justru terlupakan. Product manager bertanggung jawab menentukan fitur mana yang diprioritaskan dan menjaga roadmap tetap realistis, sementara UI/UX designer memastikan alur aplikasi mudah dipahami pengguna awam. Di sisi teknis, developer membangun fitur sesuai rencana dan QA memastikan hasilnya bebas bug sebelum dirilis. Jangan lupakan peran business dan compliance — business bertanggung jawab menyusun model bisnis dan strategi pertumbuhan, sementara compliance memastikan produk fintech Anda tidak melanggar aturan OJK atau Bank Indonesia, sesuatu yang sangat krusial mengingat kita sudah membahas RegTech di pertemuan-pertemuan sebelumnya. Kalau tim Anda kecil, satu orang boleh merangkap beberapa peran, tapi pastikan semua peran ini tetap terpikirkan.

Coba Sendiri: Susun Matriks RACI Tim Anda

Tetapkan siapa Responsible, Accountable, Consulted, dan Informed untuk tiap tugas proyek fintech tim Anda.

Tools Kolaborasi Tim yang Umum Dipakai

MANAJEMEN KODE & TUGAS

Git/GitHub: version control (pelacak riwayat perubahan kode) agar anggota tim tidak saling menimpa pekerjaan.
Trello/Jira: papan tugas (task board) untuk melacak backlog, progres, dan siapa mengerjakan apa.

KOMUNIKASI & DESAIN

Slack/Discord: komunikasi harian & notifikasi cepat, menggantikan email untuk hal-hal rutin.
Figma: desain antarmuka kolaboratif, beberapa anggota bisa mengedit desain yang sama secara real-time.

Selain cara kerja, tim yang efektif juga butuh alat bantu yang tepat, Anda semua. Git dan GitHub membantu tim developer melacak setiap perubahan kode, sehingga kalau ada bug baru, Anda bisa tahu persis siapa yang mengubah bagian mana dan kapan — ini standar industri yang dipakai hampir semua perusahaan teknologi termasuk startup fintech Indonesia. Trello atau Jira berfungsi sebagai papan tugas visual, mirip sticky note digital, agar semua orang tahu status setiap pekerjaan tanpa harus bertanya satu-satu. Untuk komunikasi harian, banyak tim memakai Slack atau Discord karena lebih cepat dan terorganisir dibanding email, sementara Figma memungkinkan designer dan bahkan anggota non-teknis melihat dan memberi komentar langsung pada desain aplikasi yang sedang dikerjakan. Menguasai tools ini bukan sekadar nilai tambah, tapi hampir menjadi syarat wajib saat Anda melamar magang atau kerja di startup teknologi.

Hitung dari Nol: Velocity & Burndown Sprint

Velocity (kecepatan tim) mengukur berapa banyak story point (satuan estimasi usaha tugas) yang mampu diselesaikan tim dalam satu sprint — berguna untuk memperkirakan kapan seluruh proyek selesai.

Langkah	Perhitungan	Nilai
1. Story point direncanakan sprint 1	diketahui	40 SP
2. Story point selesai akhir sprint 1	diketahui	32 SP
3. Velocity tim (per sprint 2 minggu)	32 SP ÷ 1 sprint	32 SP/sprint
4. Sisa backlog total proyek	diketahui	96 SP
5. Estimasi sprint tersisa	96 SP ÷ 32 SP/sprint	3 sprint

ESTIMASI WAKTU PENYELESAIAN

3 SPRINT

≈ 6 minggu lagi (3 sprint × 2 minggu) dengan velocity tetap 32 SP/sprint

Sekarang kita hitung metrik kedua yang sangat berguna untuk mengelola proyek tim, yaitu velocity. Katakanlah di sprint pertama tim Anda merencanakan empat puluh story point tapi hanya berhasil menyelesaikan tiga puluh dua, maka velocity tim Anda untuk satu sprint dua mingguan adalah tiga puluh dua story point. Sekarang bayangkan sisa pekerjaan di seluruh proyek masih sembilan puluh enam story point — dengan membagi sisa backlog itu dengan velocity tim, Anda bisa memperkirakan butuh tiga sprint lagi, atau kira-kira enam minggu, untuk menyelesaikan seluruh proyek dengan asumsi kecepatan tim tetap stabil. Perhitungan sederhana seperti ini sangat berguna saat Anda harus menjawab pertanyaan dosen atau investor, "kapan proyek ini realistis selesai?" — jawaban berbasis data jauh lebih meyakinkan daripada sekadar menebak.

Coba Sendiri: Kalkulator Velocity & Estimasi Sprint

Ubah story point selesai per sprint dan sisa backlog — amati bagaimana estimasi jumlah sprint dan minggu tersisa berubah.

Code Review & Quality Assurance sebagai Budaya Tim

Code review (tinjauan kode oleh anggota tim lain sebelum digabungkan) menjaga kualitas produk dan mencegah bug lolos ke pengguna.

CHECKLIST SEBELUM MENGGABUNGKAN KODE (MERGE)

Kode mudah dibaca dan diberi nama variabel yang jelas.
Tidak ada data sensitif (API key, password) yang tertulis langsung di kode.
Sudah diuji coba (testing) minimal untuk skenario utama sebelum digabung.
Minimal 1 anggota tim lain menyetujui (approve) sebelum kode masuk ke versi utama.

Bug keamanan yang lolos code review — misalnya API key OVO atau data pengguna yang bocor — bisa berakibat fatal bagi kepercayaan pengguna aplikasi fintech.

Code review adalah budaya yang membedakan tim profesional dari tim asal jadi, Anda semua, dan ini berlaku sangat ketat di industri fintech karena taruhannya adalah uang dan data pribadi pengguna. Sebelum kode digabungkan ke versi utama, pastikan checklist di layar ini terpenuhi: mudah dibaca, tidak ada kunci akses atau kata sandi yang tertulis langsung di kode — kesalahan yang sayangnya masih sering terjadi bahkan di perusahaan besar — sudah diuji untuk skenario utama, dan disetujui minimal satu anggota tim lain. Bayangkan kalau sebuah aplikasi fintech seperti dompet digital tiba-tiba membocorkan API key pembayaran karena tidak ada proses review, dampaknya bisa berupa kebocoran data ribuan pengguna dan hilangnya kepercayaan secara instan. Membiasakan code review sejak proyek kelas ini akan sangat membantu Anda ketika bekerja di tim sungguhan nanti.

Mengelola Konflik dan Komunikasi dalam Tim Lintas-Peran

PENYEBAB KONFLIK UMUM

Deadline tidak realistis atau beban kerja tidak merata.
Miskomunikasi antara developer dan non-teknis soal fitur.
Perubahan scope mendadak tanpa diskusi tim.

CARA MENGELOLANYA

Dengarkan dulu (active listening) sebelum membela diri.
Perjelas ulang scope & prioritas bersama, tulis kesepakatan.
Eskalasi ke dosen/PM jika konflik tidak selesai di level tim.

Tidak ada tim proyek yang benar-benar bebas dari gesekan, dan itu wajar, Anda semua — yang membedakan tim baik dan tim buruk adalah cara mereka mengelola konflik itu. Penyebab paling umum biasanya deadline yang terlalu ketat, beban kerja yang tidak merata antaranggota, atau miskomunikasi antara developer yang bicara bahasa teknis dan anggota non-teknis yang fokus pada bisnis. Ketika konflik muncul, langkah pertama adalah mendengarkan dulu sudut pandang rekan Anda sebelum langsung membela diri, lalu perjelas ulang ruang lingkup dan prioritas pekerjaan secara tertulis agar tidak ada kesalahpahaman lagi. Jika konflik tetap tidak selesai di level tim, jangan ragu meminta bantuan dosen atau product manager sebagai penengah — ini bukan tanda kegagalan, justru tanda kedewasaan profesional yang akan sangat berguna saat Anda bekerja di tim lintas divisi nanti.

Bagian 3 dari 3

Pengembangan Lanjutan dan Iterasi Proyek

Proyek fintech tidak berhenti di hari presentasi. Bagian penutup ini membahas cara mengolah feedback, menyusun roadmap, dan membawa proyek ke luar kelas.

Feedback Loop: Build-Measure-Learn & Mengolah Kritik

Saat menerima kritik: dengarkan penuh sebelum menjawab, pisahkan kritik pada ide dari kritik pada diri Anda, dan prioritaskan masukan yang paling sering muncul dari banyak sumber.

Kerangka yang Anda lihat ini disebut Build-Measure-Learn, konsep inti dari pendekatan Lean Startup yang dipakai hampir semua produk digital modern, termasuk fintech. Anda membangun (build) versi produk, mengukur (measure) bagaimana pengguna sungguhan bereaksi, lalu belajar (learn) dari data tersebut untuk memutuskan apakah lanjut, mengubah arah, atau berhenti — dan siklus ini berputar terus tanpa akhir. Sama pentingnya adalah bagaimana Anda mengolah kritik yang muncul dari dosen, investor simulasi, atau pengguna uji coba hari ini: dengarkan dulu sepenuhnya sebelum membela proyek Anda, dan yang paling penting, pisahkan antara kritik terhadap ide proyek dengan kritik terhadap diri Anda sebagai pribadi — ini bukan hal yang sama. Jika ada satu masukan yang muncul berulang dari beberapa orang berbeda, itu sinyal kuat bahwa masukan tersebut layak diprioritaskan di iterasi berikutnya.

Menyusun Roadmap Lanjutan dengan Metode MoSCoW

MoSCoW membantu tim memprioritaskan fitur mana yang dikerjakan lebih dulu setelah presentasi, sebelum proyek siap dipakai secara lebih luas (skalabilitas).

PRIORITAS FITUR (MOSCOW)

Must have: fitur inti wajib ada (mis. verifikasi identitas/KYC).
Should have: penting tapi bisa menyusul (mis. notifikasi push).
Could have: nilai tambah jika waktu tersedia (mis. mode gelap).
Won't have (saat ini): ditunda ke fase berikutnya.

KESIAPAN MENUJU PRODUKSI

Audit keamanan & uji beban (load testing) sebelum pengguna nyata bertambah.
Cek kepatuhan regulasi terkait (OJK/BI) bila menyentuh dana pengguna.
Rencana migrasi dari sandbox uji coba ke lingkungan produksi.

Setelah menerima feedback, langkah berikutnya adalah menyusun roadmap yang realistis, dan metode MoSCoW membantu Anda memilah mana yang benar-benar prioritas. Fitur must have adalah yang wajib ada, misalnya verifikasi identitas pengguna yang kita bahas saat membicarakan KYC di pertemuan RegTech, sementara should have penting tapi bisa menyusul, dan could have hanya nilai tambah jika waktu masih tersisa. Jangan lupa juga mempertimbangkan kesiapan menuju produksi sungguhan — ini berbeda dengan sandbox atau lingkungan uji coba yang kita pakai sepanjang semester ini. Sebelum aplikasi Anda dipakai pengguna nyata dalam jumlah besar, perlu ada audit keamanan, uji beban server, dan pengecekan kepatuhan regulasi, terutama jika produk Anda menyentuh dana atau data pribadi pengguna, sama seperti yang dilakukan platform pembayaran digital resmi seperti DANA atau ShopeePay sebelum meluncurkan fitur baru ke publik.

Menutup Mata Kuliah: dari Proyek Kelas ke Portofolio Karier

BAWA PROYEK KE LUAR KELAS

Unggah kode ke GitHub sebagai portofolio publik.
Tulis studi kasus proyek di LinkedIn dengan hasil terukur.
Simpan pitch deck & demo video untuk lamaran magang/kerja.

LANGKAH SELANJUTNYA

Lanjutkan iterasi mandiri jika tim tertarik jadi proyek nyata.
Cari peluang magang di startup fintech atau divisi digital bank.
Terapkan kerangka Build-Measure-Learn di proyek berikutnya.

Selamat menempuh empat belas pertemuan Laboratorium Financial Technology — dari memahami disrupsi layanan keuangan sampai hari ini, mempresentasikan karya Anda sendiri.

Kita sampai di penutup mata kuliah ini, Anda semua, dan saya ingin mengajak Anda melihat kembali perjalanan yang sudah ditempuh — dari memahami sejarah disrupsi layanan keuangan tradisional di pertemuan pertama, sampai hari ini mampu membangun dan mempresentasikan proyek fintech Anda sendiri secara tim. Jangan biarkan proyek ini berhenti begitu nilai keluar; unggah kodenya ke GitHub, tulis studi kasusnya di LinkedIn lengkap dengan hasil terukur seperti unit economics dan velocity yang baru saja kita hitung, dan simpan pitch deck serta video demo Anda karena itu semua adalah portofolio nyata yang akan sangat berguna saat melamar magang di startup fintech atau divisi digital bank seperti BCA Digital maupun Bank Jago. Terapkan terus kerangka Build-Measure-Learn dalam proyek apa pun yang Anda kerjakan setelah ini. Terima Kasih atas kerja keras Anda sepanjang semester, dan selamat mempersiapkan presentasi terbaik Anda.