Kapan Harus Bilang Tidak ke Fitur Sendiri
Cerita satu keputusan prioritas MVP di Kafipos: menunda sistem resep multi-level yang sudah saya rancang sendiri, dan memilih solusi yang lebih kecil tapi lebih cepat berguna.
- Peran
- Product Manager & UI/UX Designer
- Tim
- 3 orang (Kafiloo)
- Produk
- Kafipos — SaaS POS & Loyalty F&B
- Fase
- MVP, 2025
Problem
Saat merancang fitur stocking system untuk Kafipos, muncul kebutuhan menangani produk dengan varian yang saling tumpang tindih bahan. Contoh paling sederhana ada di menu harian kedai: Cafe Latte dan Almond Latte sama-sama memakai kopi, tapi berbeda jenis susu.
Tanpa sistem yang presisi membedakan titik variasi ini, stock bisa salah terpotong — susu reguler ikut berkurang padahal yang dipesan Almond Latte. Buat pemilik kedai, ini bukan sekadar angka meleset di laporan; ini bahan yang mendadak habis di jam ramai.
Process
Breakdown masalah saya lakukan sendiri dulu lewat wireframe dan skema alur: memetakan bagaimana sistem resep multi-level (Recipe/BoM) idealnya bekerja untuk menangani kasus semacam ini — mana bahan yang dibagi bersama, dan di titik mana varian mulai bercabang.
Setelah punya gambaran solusi, hasil breakdown itu saya bawa ke diskusi dengan PM senior di tempat magang untuk divalidasi. Bukan untuk minta jawaban, tapi untuk menguji apakah asumsi saya soal kompleksitasnya masuk akal.
Decision & Trade-off
Dari diskusi tersebut saya menyadari satu hal yang tidak enak didengar: scope sistem konversi resep multi-level yang akurat untuk semua kombinasi varian jauh lebih besar dari kapasitas tim kami bertiga dan timeline MVP yang ada.
Keputusannya: defer fitur Recipe/BoM, dan alihkan effort ke solusi yang lebih ringan tapi tetap actionable. Fitur “Bottom 5 Slow Movers” kami pivot menjadi tampilan QTY sold plus status “Low Demand” — memberi value ke user tanpa kompleksitas sistem resep penuh.
“Kadang keputusan produk terbaik bukan soal fitur apa yang dibangun, tapi fitur apa yang berani ditunda.”
Outcome
MVP launch lebih cepat sekitar 1–2 minggu dari rencana awal. Tim tidak terjebak membangun mesin resep yang belum tentu dipakai penuh di rilis pertama.
Pendekatan solusi Recipe/BoM sendiri tidak dibuang: sudah divalidasi secara desain dan plan bersama PM senior, lalu disimpan sebagai rancangan siap dikembangkan lagi ketika produk sudah matang dan skala penggunanya lebih besar.