Program Studi Bisnis Digital • FEB

Teknologi Web & Mobile

Pertemuan 5 — Perencanaan & Pengembangan Produk Digital

Dari ide mentah menjadi produk digital yang terencana: siklus hidup produk, proses pengembangan, dan teknik memprioritaskan fitur.

RPS minggu 5 · 2x50 menit

Selamat datang kembali di mata kuliah Teknologi Web dan Mobile. Minggu lalu Anda sudah mengenal lanskap teknologi mobile — native, hybrid, dan web app — sekarang saatnya kita mundur satu langkah dan bertanya: bagaimana sebuah produk digital itu lahir dari sekadar ide sampai benar-benar ada di genggaman pengguna? Bayangkan tim di balik Tokopedia atau Gojek ketika pertama kali merancang fitur baru — mereka tidak langsung menyuruh programmer menulis kode, ada proses perencanaan panjang sebelumnya. Sebagai calon pengambil keputusan bisnis digital, Anda tidak harus bisa coding, tetapi Anda wajib paham tahapan perencanaan ini supaya bisa duduk satu meja dengan tim produk dan teknologi. Hari ini kita akan bahas siklus hidup produk digital, proses pengembangan ala Agile dan Scrum, cara menghitung estimasi waktu dan prioritas fitur, sampai menyusun roadmap sederhana.

Bagian 1 dari 3

Fondasi Perencanaan
Produk Digital

Apa itu produk digital, mengapa perencanaan krusial, dan bagaimana produk hidup dari lahir sampai "pensiun".

Apa Itu "Produk Digital"?

Produk digital adalah barang atau layanan yang dibuat, didistribusikan, dan dikonsumsi melalui teknologi digital — tidak berwujud fisik, tetapi memberi nilai nyata bagi penggunanya.

WEBSITE / WEB APP

Dibuka lewat browser, tanpa instalasi. Contoh: Tokopedia.com, portal e-learning kampus.

APLIKASI MOBILE

Diunduh dari Play Store/App Store. Contoh: Gojek, BCA Mobile.

PLATFORM DIGITAL

Menghubungkan banyak pihak sekaligus. Contoh: GoTo, marketplace UMKM.

Kesamaan ketiganya: dibangun berdasarkan kebutuhan pengguna yang direncanakan, bukan dadakan.

Mengapa Perencanaan Produk Itu Krusial?

Riset industri (CB Insights, analisis kegagalan startup) menunjukkan sebagian besar kegagalan produk digital bukan karena teknologi buruk, melainkan perencanaan yang lemah.

PENYEBAB #1

~35%

Kegagalan startup disebabkan produk "tidak ada kebutuhan pasar" (no market need) — dibangun tanpa riset pengguna. Angka survei industri, bersifat estimasi.

DAMPAK NYATA

Rp SIA-SIA

Biaya development, gaji tim, dan waktu terbuang untuk fitur yang tidak pernah dipakai pengguna.

Perencanaan yang baik = menjawab "untuk siapa" dan "masalah apa" sebelum menjawab "dibangun dengan teknologi apa".

Anda mungkin pernah dengar cerita startup Indonesia yang tutup padahal aplikasinya bagus dan timnya jago coding — mengapa bisa gagal? Riset dari lembaga seperti CB Insights, walau angkanya bervariasi antar survei, konsisten menunjukkan bahwa penyebab kegagalan nomor satu adalah produk yang dibangun tanpa benar-benar memahami kebutuhan pasar. Saya beri contoh ilustratif: bayangkan sebuah tim menghabiskan enam bulan dan ratusan juta rupiah membangun aplikasi pencatat keuangan untuk UMKM, tapi ternyata pedagang pasar lebih nyaman mencatat manual di buku karena tidak ada literasi digital yang cukup — itu kerugian yang bisa dicegah kalau ada riset di depan. Ini sebabnya perencanaan produk digital selalu dimulai dengan pertanyaan "untuk siapa" dan "masalah apa yang kita selesaikan", bukan langsung "kita pakai teknologi apa".

Siklus Hidup Produk Digital

Produk digital melewati beberapa fase sejak lahir hingga akhirnya "pensiun" atau digantikan produk baru.

Contoh nyata: aplikasi BBM pernah mendominasi (growth), lalu memasuki fase decline saat WhatsApp mengambil alih pasar Indonesia.

Sama seperti manusia, produk digital juga punya "umur" — dari lahir sampai tumbuh dewasa dan akhirnya menurun. Fase pertama adalah ideation, di mana ide masih berupa gagasan kasar. Lalu masuk development, di mana tim membangunnya. Setelah itu launch, saat produk pertama kali dirilis ke publik. Kalau responsnya baik, produk masuk fase growth dengan pengguna yang terus bertambah — bayangkan bagaimana pesatnya pertumbuhan pengguna Gojek di tahun-tahun awal. Tapi tidak ada produk yang tumbuh selamanya; pada akhirnya ia mencapai maturity, stabil, atau bahkan decline seperti yang dialami BBM setelah kalah bersaing dengan WhatsApp di Indonesia. Memahami di fase mana produk Anda berada membantu menentukan strategi yang tepat — apakah saatnya menambah fitur baru, atau justru mempertahankan yang sudah ada.

Product-Market Fit

Product-market fit (PMF) adalah kondisi ketika sebuah produk digital benar-benar cocok dengan kebutuhan pasar yang dituju — pengguna memakainya berulang kali tanpa perlu banyak dipaksa.

TANDA SUDAH PMF

Pengguna kembali memakai produk tanpa promo
Word-of-mouth (rekomendasi dari mulut ke mulut) tinggi
Retensi pengguna stabil, bukan cuma ramai di awal

TANDA BELUM PMF

Pengguna hilang setelah promo/diskon berakhir
Tim harus terus "mendorong" orang memakai app
Ulasan bernada "tidak terlalu butuh ini"

Titik Awal Perencanaan: User Persona & Pain Point

Sebelum merancang fitur, tim produk menyusun user persona (profil representatif pengguna) dan memetakan pain point (masalah/keluhan nyata) mereka.

Kumpulkan data pengguna nyata — wawancara, survei, atau data transaksi. Contoh: tim riset mewawancarai pedagang pasar tradisional yang jadi target aplikasi UMKM.

Susun persona & pain point — misalnya "Bu Sri, 45 tahun, pedagang sembako, pain point: sulit mencatat utang piutang pelanggan secara manual". Persona inilah yang menjadi acuan setiap keputusan fitur berikutnya.

Tanpa persona yang jelas, tim mudah membangun fitur "keren" tapi tidak relevan bagi penggunanya.

Bagian 2 dari 3

Proses & Metodologi
Pengembangan

Bagaimana rencana produk diterjemahkan jadi kerja nyata tim — tahapan, metodologi Agile/Scrum, dan estimasi waktu.

Product Development Life Cycle (PDLC)

PDLC (siklus pengembangan produk) adalah tahapan sistematis dari ide sampai produk dirawat pasca-rilis.

Sifatnya iteratif — tahap "Iterate" sering kembali memicu putaran Discovery baru berdasarkan masukan pengguna.

Kalau tadi kita bicara siklus hidup produk secara besar dari lahir sampai pensiun, sekarang kita perbesar salah satu bagiannya, yaitu bagaimana satu fitur atau produk baru dikembangkan — ini yang disebut Product Development Life Cycle atau PDLC. Tahapannya dimulai dari discovery, menggali masalah dan kebutuhan; define, merumuskan solusi dan target yang jelas; design, merancang tampilan dan alur; develop, di mana developer menulis kode; sampai deploy atau merilis dan iterate, terus memperbaiki berdasarkan masukan pengguna. Yang penting Anda catat, proses ini tidak linear kaku satu arah — begitu produk dirilis dan tim mendapat masukan pengguna, siklus discovery bisa terbuka lagi untuk fitur berikutnya. Inilah mengapa tim produk digital yang baik seperti di Tokopedia terus merilis pembaruan kecil, bukan menunggu versi besar sekali jadi.

Waterfall vs Agile

Dua pendekatan besar dalam mengelola proses pengembangan produk digital.

WATERFALL

Tahapan berurutan & kaku: rencana selesai penuh dulu, baru dibangun
Cocok untuk proyek yang requirement-nya sudah pasti sejak awal
Perubahan di tengah jalan mahal & sulit

AGILE

Dikerjakan bertahap & berulang dalam siklus pendek (sprint)
Terbuka pada perubahan berdasarkan masukan pengguna
Umum dipakai startup/scale-up digital Indonesia (Gojek, Tokopedia)

Rule of thumb: makin tidak pasti kebutuhan pasar, makin cocok pendekatan Agile.

Dua pendekatan ini sering diadu di kelas manajemen proyek, jadi mari kita luruskan. Waterfall itu seperti membangun rumah — Anda harus punya blueprint lengkap dulu sebelum tukang mulai bekerja, dan kalau di tengah jalan Anda ingin mengubah desain, itu mahal dan merepotkan. Pendekatan ini cocok kalau kebutuhannya sudah sangat jelas dan jarang berubah, misalnya sistem inti perbankan yang diatur ketat oleh regulasi OJK. Agile sebaliknya, bekerja dalam siklus pendek berulang yang disebut sprint, dan sangat terbuka terhadap perubahan — inilah mengapa hampir semua startup digital besar di Indonesia seperti Gojek dan Tokopedia memakai pendekatan Agile, karena kebutuhan pasar digital bergerak sangat cepat dan sulit diprediksi di awal. Aturan praktisnya sederhana: semakin tidak pasti kebutuhan pasarnya, semakin cocok Agile dipakai.

Scrum: Kerangka Kerja Agile Paling Populer

Scrum adalah kerangka kerja Agile yang membagi pekerjaan dalam siklus pendek bernama sprint.

SPRINT

Periode kerja tetap, biasanya 1–2 minggu, menghasilkan bagian produk yang bisa diuji.

BACKLOG

Daftar semua fitur/tugas yang belum dikerjakan, diurutkan sesuai prioritas.

DAILY STANDUP

Rapat singkat harian (~15 menit): apa yang dikerjakan kemarin, hari ini, dan kendalanya.

Scrum adalah kerangka kerja Agile yang paling sering Anda dengar di dunia kerja digital, jadi penting untuk paham istilah-istilahnya. Sprint adalah periode kerja tetap, biasanya satu sampai dua minggu, di mana tim berkomitmen menyelesaikan sekumpulan pekerjaan tertentu yang bisa langsung diuji hasilnya. Backlog adalah daftar seluruh pekerjaan yang belum dikerjakan — bayangkan seperti to-do list raksasa milik produk, yang terus diurutkan ulang berdasarkan prioritas sebelum masuk ke sprint berikutnya. Daily standup adalah rapat singkat setiap pagi, biasanya berdiri agar tidak berlama-lama, di mana tiap anggota tim menjawab tiga pertanyaan: apa yang saya kerjakan kemarin, apa yang saya kerjakan hari ini, dan apakah ada hambatan. Kalau nanti Anda bekerja sebagai product manager atau business analyst, istilah-istilah ini akan Anda dengar setiap hari.

Menuliskan Kebutuhan: User Story

Tim produk menerjemahkan kebutuhan pengguna menjadi user story — format sederhana yang bisa dipahami tim bisnis maupun developer.

Sebagai [peran], saya ingin [tujuan], agar [manfaat]

Isi peran & tujuan — "Sebagai pengguna aplikasi belanja, saya ingin melihat status pengiriman secara real-time."

Tambahkan manfaat — "…agar saya tidak perlu menghubungi kurir atau customer service untuk bertanya." Manfaat inilah yang jadi dasar tim menilai apakah fitur layak dikerjakan.

Salah satu keterampilan paling praktis dari pertemuan hari ini adalah menuliskan kebutuhan dalam format user story, formatnya sangat sederhana: sebagai peran tertentu, saya ingin melakukan sesuatu, agar mendapat manfaat tertentu. Mari kita coba bersama-sama, langkah pertama isi peran dan tujuannya, misalnya sebagai pengguna aplikasi belanja online seperti Shopee, saya ingin melihat status pengiriman paket secara real-time. Langkah kedua, tambahkan bagian "agar", yaitu manfaat yang didapat, misalnya agar saya tidak perlu repot menghubungi kurir atau customer service hanya untuk bertanya posisi paket. Bagian manfaat ini penting sekali karena menjadi alasan mengapa fitur itu layak dikerjakan — kalau Anda tidak bisa mengisi bagian "agar" dengan jelas, itu tanda fitur tersebut mungkin belum benar-benar dibutuhkan pengguna.

Hitung dari Nol: Estimasi Waktu Pengembangan

Tim menggunakan story point (satuan estimasi usaha, bukan jam pasti) dan velocity (kapasitas tim per sprint) untuk memperkirakan lama pengerjaan.

Langkah	Perhitungan	Nilai
Total story point fitur (dari backlog)	diberikan tim	40 poin
Velocity tim (kapasitas rata-rata/sprint)	diberikan (data historis tim)	10 poin/sprint
Jumlah sprint dibutuhkan	40 poin ÷ 10 poin/sprint	4 sprint
Total waktu pengembangan	4 sprint × 2 minggu/sprint	8 minggu

ESTIMASI SELESAI

~8 minggu

setara ~2 bulan kalender

Sekarang kita praktikkan langsung cara tim produk mengestimasi waktu pengerjaan, karena ini pertanyaan yang paling sering ditanyakan atasan atau klien: "kapan fiturnya selesai?" Langkah pertama, tim sudah memecah seluruh fitur menjadi story point, misalnya totalnya 40 poin — ini bukan jam kerja pasti, tapi ukuran relatif seberapa besar usaha yang dibutuhkan. Langkah kedua, tim punya data historis velocity, yaitu rata-rata berapa poin yang bisa mereka selesaikan tiap sprint, di sini katakanlah 10 poin per sprint. Dari situ kita bagi 40 dibagi 10, ketemu 4 sprint yang dibutuhkan, lalu kalikan dengan panjang satu sprint yaitu 2 minggu, sehingga totalnya sekitar 8 minggu atau kira-kira 2 bulan. Perhatikan kata "sekitar" — estimasi ini bukan janji pasti, tapi pegangan yang cukup akurat untuk perencanaan bisnis, seperti menentukan tanggal target peluncuran fitur baru di aplikasi.

Coba Sendiri: Rencanakan Sprint dengan Velocity Tim

Ubah total story point backlog dan velocity tim, lalu amati berapa sprint dan minggu yang dibutuhkan.

Siapa Saja yang Terlibat?

Perencanaan & pengembangan produk digital adalah kerja lintas peran — bukan cuma "tim IT".

Peran	Tanggung Jawab Utama
Product Manager (PM)	Menentukan prioritas fitur, menjembatani bisnis dan tim teknis
UI/UX Designer	Merancang tampilan (UI) & pengalaman pengguna (UX) yang mudah dipakai
Developer	Menulis kode & membangun sistem sesuai rancangan
QA (Quality Assurance)	Menguji produk agar bebas bug sebelum dirilis ke pengguna

Satu miskonsepsi umum di kalangan mahasiswa bisnis adalah menganggap pengembangan produk digital sepenuhnya urusan "tim IT" — padahal ini kerja lintas peran yang justru butuh orang dengan latar belakang bisnis seperti Anda. Product Manager, sering disingkat PM, bertugas menentukan fitur mana yang diprioritaskan dan menjadi jembatan antara kebutuhan bisnis dengan tim teknis — ini profesi yang sangat cocok untuk lulusan bisnis digital. UI/UX Designer merancang tampilan atau UI (user interface) dan pengalaman pemakaian atau UX (user experience) agar produk mudah dan nyaman dipakai. Developer adalah yang benar-benar menulis kode programnya, sementara QA atau Quality Assurance bertugas menguji produk secara menyeluruh untuk memastikan tidak ada bug sebelum dirilis ke jutaan pengguna, seperti yang dilakukan tim BCA sebelum merilis pembaruan BCA Mobile.

Bagian 3 dari 3

Roadmap, Prioritas
& Keputusan Bisnis

Menyusun peta jalan produk dan memilih fitur mana yang dikerjakan lebih dulu — keputusan bisnis, bukan sekadar teknis.

Product Roadmap

Roadmap adalah dokumen visual yang menunjukkan rencana pengembangan produk dalam jangka waktu tertentu — arah strategis, bukan daftar tugas harian.

Roadmap yang baik menjawab "mengapa" tiap fitur ada di sana — terhubung ke tujuan bisnis, bukan sekadar wishlist.

Roadmap sering disalahpahami sebagai jadwal proyek yang detail, padahal fungsinya lebih strategis. Roadmap menunjukkan arah besar produk dalam beberapa bulan atau kuartal ke depan, misalnya kuartal ketiga fokus pada fitur pembayaran baru, kuartal keempat fokus pada sistem notifikasi, dan kuartal pertama tahun berikutnya fokus ekspansi ke kota baru. Bayangkan tim di balik aplikasi dompet digital seperti Dana atau OVO, mereka pasti punya roadmap yang menunjukkan kapan fitur split bill atau cicilan akan diluncurkan, dan itu dikomunikasikan ke seluruh perusahaan agar tim marketing dan sales bisa menyiapkan strategi. Roadmap yang baik selalu bisa menjawab pertanyaan "mengapa fitur ini ada di sini", terhubung jelas ke tujuan bisnis perusahaan, bukan sekadar kumpulan permintaan fitur yang menumpuk tanpa alasan strategis.

Teknik Prioritas: Metode MoSCoW

Ketika sumber daya terbatas, tim mengelompokkan fitur memakai MoSCoW: Must, Should, Could, Won't.

Must have — wajib ada, produk tidak berfungsi tanpanya. Contoh: fitur login & pembayaran di aplikasi e-commerce.

Should have — penting tapi bisa ditunda sedikit. Contoh: filter pencarian lanjutan.

Could have — menarik tapi bukan prioritas. Contoh: mode gelap (dark mode).

Won't have (saat ini) — disepakati ditunda ke rilis jauh berikutnya.

MoSCoW adalah salah satu teknik prioritas paling populer karena mudah diingat, hurufnya diambil dari Must, Should, Could, dan Won't. Must have adalah fitur wajib yang tanpanya produk sama sekali tidak bisa berfungsi, misalnya fitur login dan pembayaran di aplikasi e-commerce seperti Shopee — tanpa itu, aplikasi tidak ada gunanya. Should have adalah fitur penting yang menambah nilai signifikan tapi produk masih bisa berjalan tanpanya untuk sementara, misalnya filter pencarian lanjutan. Could have adalah fitur yang menyenangkan untuk dimiliki tapi bukan prioritas, seperti mode gelap yang banyak diminta pengguna tapi tidak mempengaruhi fungsi inti. Won't have artinya tim sudah sepakat fitur itu ditunda dulu untuk rilis yang jauh lebih belakangan — bukan ditolak selamanya, hanya belum sekarang. Teknik ini membantu tim menghindari perdebatan tanpa akhir soal fitur mana yang lebih penting.

Hitung dari Nol: Skor Prioritas RICE

Metode RICE mengubah prioritas jadi angka: Reach (jangkauan), Impact (dampak), Confidence (keyakinan), Effort (usaha).

RICE = (Reach × Impact × Confidence) ÷ Effort

Langkah	Perhitungan	Nilai
Reach (pengguna terdampak/bulan)	diberikan (data analitik)	5.000 pengguna
Impact (skala 0,25–3; dampak tinggi)	diberikan tim	2
Confidence (keyakinan data)	80% → 0,8	0,8
Reach × Impact × Confidence	5.000 × 2 × 0,8	8.000
Skor RICE	8.000 ÷ 4 (Effort, orang-bulan)	2.000

SKOR RICE FITUR

2.000

makin tinggi = makin diprioritaskan

Kalau MoSCoW mengelompokkan fitur secara kualitatif, RICE membantu tim membandingkan fitur secara kuantitatif dengan satu angka. Mari kita hitung untuk contoh fitur notifikasi push promo di aplikasi e-commerce. Reach adalah berapa banyak pengguna yang terdampak per bulan, di sini datanya 5.000 pengguna. Impact adalah seberapa besar dampaknya pada skala 0,25 sampai 3, tim menilai fitur ini berdampak tinggi dengan skor 2. Confidence adalah seberapa yakin tim dengan data dan asumsi ini, misalnya 80 persen yang kita tulis sebagai 0,8. Kita kalikan ketiganya, 5.000 dikali 2 dikali 0,8, hasilnya 8.000. Terakhir kita bagi dengan Effort, yaitu perkiraan usaha dalam orang-bulan, katakanlah 4 orang-bulan, sehingga skor RICE-nya adalah 2.000. Semakin tinggi skor RICE dibanding fitur lain, semakin layak fitur itu dikerjakan lebih dulu — ini bahasa yang sangat masuk akal untuk dipresentasikan ke manajemen.

Coba Sendiri: Hitung Skor RICE Fitur Anda

Ubah Reach, Impact, Confidence, dan Effort suatu fitur, lalu amati bagaimana skor prioritas RICE-nya berubah.

Studi Kasus: Perencanaan Produk Fintech Lokal

Ilustrasi (disederhanakan untuk pembelajaran) sebuah startup fintech pembayaran UMKM merencanakan fitur baru.

RINGKASAN KASUS

Riset pengguna: pedagang UMKM kesulitan rekap transaksi harian (pain point utama)
Tim menyusun user story: "Sebagai pedagang, saya ingin rekap otomatis, agar tak perlu hitung manual tiap tutup toko"
Fitur diberi skor RICE tinggi → masuk kategori Must have di roadmap kuartal berjalan
Dikerjakan dalam 4 sprint (~8 minggu), lalu dirilis bertahap ke sebagian pengguna dulu

Semua konsep hari ini — persona, RICE, MoSCoW, sprint — bekerja bersama, bukan berdiri sendiri.

Untuk merangkai semua yang kita pelajari hari ini, mari lihat ilustrasi sederhana sebuah startup fintech pembayaran yang melayani UMKM — konteksnya mirip dengan yang dilakukan pemain seperti Bank Jago atau Xendit, walau detail ceritanya disederhanakan untuk pembelajaran. Semua dimulai dari riset pengguna yang menemukan pain point utama: pedagang UMKM kesulitan merekap transaksi harian secara manual. Dari situ tim menyusun user story yang jelas, lalu menghitung skor RICE dan menemukan fitur ini berdampak besar dengan effort yang masih terjangkau, sehingga masuk kategori Must have di roadmap. Tim kemudian mengestimasi pengerjaannya sekitar 4 sprint atau 8 minggu memakai kerangka Scrum, dan merilisnya bertahap ke sebagian pengguna dulu untuk melihat respons sebelum diluncurkan penuh. Perhatikan bagaimana persona, RICE, MoSCoW, dan sprint semuanya bekerja bersama sebagai satu alur berpikir, bukan konsep yang terpisah-pisah.

Latihan Kelompok & Persiapan Pertemuan 6

LATIHAN KELOMPOK (15 MENIT)

Pilih 1 aplikasi yang sering Anda pakai (mis. GoTo, Shopee, Ruangguru)
Susun 1 user persona & pain point-nya
Tuliskan 1 user story untuk fitur baru yang relevan
Hitung skor RICE sederhana untuk fitur tersebut

PERTEMUAN 6

UI/UX → TEKNOLOGI

Minggu depan: bagaimana rancangan UI/UX yang sudah diprioritaskan hari ini diterjemahkan menjadi implementasi teknologi nyata.

Sekarang saatnya mempraktikkan langsung, silakan berkelompok tiga sampai empat orang, waktu Anda lima belas menit. Pilih satu aplikasi yang sering Anda pakai sehari-hari, misalnya GoTo, Shopee, atau Ruangguru, lalu bayangkan diri Anda sebagai tim produknya. Susun satu user persona sederhana lengkap dengan pain point-nya, tuliskan satu user story dengan format yang sudah kita pelajari, dan coba hitung skor RICE untuk fitur baru yang menurut Anda relevan — angka-angkanya boleh estimasi asal masuk akal. Setelah ini, minggu depan di pertemuan enam kita akan lanjutkan alur ini: bagaimana rancangan UI/UX yang sudah Anda prioritaskan hari ini benar-benar diterjemahkan menjadi implementasi teknologi yang nyata. Sampai jumpa minggu depan, dan jangan lupa bawa hasil latihan kelompok Anda hari ini karena akan kita pakai lagi.