Prototipe vs. Produk: Cara Mengetahui Kapan Aplikasi Buatan AI-mu Benar-Benar Selesai

Beberapa minggu lalu, seorang founder yang aku kenal membangun aplikasi penjadwalan untuk terapis. Keseluruhannya memakan waktu empat hari dengan AI app builder. Ia melakukan apa yang ia butuhkan: terapis bisa melihat kalender mereka, klien bisa memesan janji temu, konfirmasi terkirim lewat email. Ia berfungsi.

Ia sudah menatapnya selama dua minggu dan belum meluncurkannya.

Saat aku tanya kenapa, ia bilang: “Ini berfungsi, tapi… rasanya belum selesai.”

Aku tanya apa yang akan ia ubah. Ia bilang: “Saya tidak tahu. Itulah masalahnya.”

Inilah momen tersulit dalam membangun dengan AI app builder. Benda itu fungsional, tapi ada jarak antara “fungsional” dan “saya nyaman meminta orang sungguhan memakai ini”. Memahami jarak itu—dan tahu di sisi mana sebenarnya kamu berada—adalah perbedaan antara merilis dan terjebak selamanya di fase suara-di-dalam-kepala.

Apa makna “selesai” sebenarnya

Inilah pembedaan yang penting: prototipe adalah sesuatu yang kamu pakai untuk menguji sebuah ide. Produk adalah sesuatu yang kamu pakai untuk menyelesaikan sebuah masalah.

Aplikasi penjadwalan terapis itu adalah prototipe. Ia membuktikan konsepnya berfungsi. Seorang terapis bisa memakainya. Tapi ada tujuh belas hal kecil yang membuatnya terasa kasar:

Konfirmasi email-nya polos. Tanpa logo, tanpa branding kustom, copy generik.
Pembatalan tidak mengirim notifikasi. Klien tinggal tidak datang.
Tidak ada daftar tunggu kalau seorang terapis penuh terisi.
Alur signup-nya tidak mengumpulkan spesialisasi terapis, jadi tidak ada cara memfilter berdasarkan jenis praktik.
Tidak ada email pengingat yang dikirim 24 jam sebelum janji temu.

Tak satu pun dari ini merusak aplikasinya. Tapi semuanya membuat seorang terapis sungguhan berpikir: “Ini terasa seperti sesuatu yang dirakit dalam satu akhir pekan, bukan sesuatu yang sampai ditagihkan ke saya.”

Perasaan itu nyata, dan ia penting. Sebuah prototipe menyelesaikan masalah secara teori. Sebuah produk menyelesaikannya dalam praktik, untuk manusia sungguhan yang memakainya.

Tiga pertanyaan yang memisahkan prototipe dari produk

Inilah bagian yang sulit: kamu tidak bisa tahu segala sesuatu yang kurang. AI builder-mu juga tidak bisa tahu. Jadi kamu butuh tiga pertanyaan cepat untuk mencari tahu di sisi mana garisnya kamu berada.

1. Apakah kamu akan memakai ini untuk menyelesaikan masalahmu sendiri?

Yang satu ini jujur, karena kamu harus benar-benar hidup dengan produkmu sendiri.

Kalau kamu founder dari aplikasi penjadwalan terapis itu, apakah kamu akan memakainya untuk menjadwalkan janji terapimu sendiri? Bukan “bisakah kamu”—tapi apakah kamu benar-benar akan memakainya alih-alih rantai email atau Google Doc bersama?

Kalau jawabannya tidak, kamu belum selesai. Kamu tahu persis apa yang salah—kamu merasakannya setiap kali membuka aplikasinya. Kalau jawabannya ya, kamu lebih dekat.

Founder yang aku sebut tadi menjalani sendiri signup terapis miliknya. Ia tersangkut di formulir (ia meminta terlalu banyak informasi sebelum membolehkanmu memesan). Ia melihat email konfirmasinya dan merasa terlihat amatiran. Ia mulai memikirkan bagaimana terapisnya akan menerima email itu dan apakah ia akan berakhir di spam.

Ia tidak memakai produknya sendiri seperti pelanggan berbayar akan memakainya. Saat ia melakukannya, ia menemukan sepuluh hal untuk diperbaiki.

2. Apakah kamu sudah menunjukkannya ke tiga orang yang bukan kamu?

Berbicara dengan calon pengguna lebih sulit daripada membangun, dan sebagian besar founder melewatinya karena mereka ingin mengejutkan orang saat peluncuran. Itu kesalahan.

Kamu tidak butuh focus group. Kamu butuh tiga orang yang mirip dengan siapa yang kamu kira pelangganmu. Untuk aplikasi terapis, itu tiga terapis sungguhan.

Inilah yang kamu cari: di mana mereka bingung? Di mana mereka ragu? Apa yang mereka tanyakan? Bukan “apa pendapat mereka soal ini?” (orang terlalu sungkan). Minta mereka benar-benar melakukan hal itu—pesan janji temu, kirim email konfirmasi, batalkan sesuatu.

Saat sang founder menunjukkan aplikasi terapisnya ke tiga terapis, dua dari mereka bertanya: “Bisakah saya mengatur aturan untuk kapan saya tersedia? Misalnya, saya hanya menerima klien baru di hari Kamis, dan saya tidak menerima dua janji sekaligus sebelum jam 2 siang.” Aplikasinya punya kalender, tapi bukan aturan. Ia membangun prototipe untuk bagaimana ia mengira penjadwalan bekerja, bukan bagaimana terapis sebenarnya bekerja.

Itu adalah informasi produk. Kamu tidak bisa menebaknya dari sebuah spesifikasi.

3. Apa yang akan rusak kalau kamu memberikan ini ke sepuluh pengguna sungguhan?

Ini pertanyaan tersulit karena ia menuntutmu untuk benar-benar memikirkan kasus-kasus tepimu.

Untuk aplikasi terapis:

Apa yang terjadi kalau klien mencoba memesan dua janji temu di waktu yang sama? (Aplikasinya tidak memeriksanya.)
Apa yang terjadi kalau seorang terapis membatalkan janji temu? Apakah klien diberi tahu otomatis? (Tidak.)
Bagaimana kalau alamat email klien salah? Adakah cara memperbaikinya tanpa mengulang dari awal? (Tidak.)
Bagaimana kalau seorang terapis sakit dan perlu menutup kalendernya selama seminggu? (Ia harus menghapus setiap janji temu secara manual.)

Ini bukan bug. Aplikasinya tidak crash. Tapi ini luka-luka kecil. Dengan sepuluh pengguna sungguhan dan kasus tepi sungguhan, kamu akan menabrak semuanya dalam minggu pertama.

Sebuah produk menangani kasus tepi. Bukan semuanya—beberapa hal bisa menunggu. Tapi yang terjadi dalam dua minggu pertama dengan pengguna sungguhan, itu harus berfungsi.

Cara memutuskan: tes tiga lapis

Pakai ini untuk mencari tahu kamu ada di mana:

Lapis 1: Alur inti — Apakah happy path-nya berfungsi? Bisakah seorang pengguna melakukan hal utama yang menjadi tujuan rancangan aplikasimu?

Untuk penjadwal terapis: ya. Seseorang bisa daftar, memesan janji temu, mendapat konfirmasi. Ia berfungsi.

Lapis 2: Kasus tepi dari penggunaan nyata — Kamu sudah menunjukkannya ke tiga pengguna sungguhan. Apakah mereka menabrak sesuatu yang tak kamu bangun? Apakah mereka bingung di suatu tempat?

Untuk penjadwal terapis: ya. Ketiga terapis menginginkan ketersediaan berbasis aturan. Satu bingung karena email konfirmasinya terlihat terlalu generik. Satu mencoba menghapus janji temu secara massal dan tidak bisa.

Lapis 3: Pemolesan dan profesionalisme — Apakah ia terasa seperti kamu peduli? Atau terasa seperti kamu merangkainya asal-asalan?

Untuk penjadwal terapis: terasa rangkaian asal. Konfirmasi email-nya polos. Tidak ada branding kustom. Tidak ada pesan error kalau sesuatu salah, jadi kalau ada yang rusak, pengguna sama sekali tidak tahu apa yang terjadi.

Inilah heuristiknya:

Ketiga lapis berfungsi? Kamu adalah produk. Rilis.
Lapis 1 dan 2, tapi tidak 3? Kamu 80% selesai. Habiskan sehari untuk pemolesan.
Lapis 1 berfungsi, lapis 2 dan 3 tidak? Kamu adalah prototipe. Jangan rilis dulu.
Lapis 1 belum solid? Kamu belum selesai. Terus bangun.

Aplikasi terapis itu terjebak di perbatasan antara Lapis 1 dan Lapis 2. Alur intinya berfungsi, tapi terapis sungguhan menemukan ada bagian yang hilang. Jadi sang founder punya pilihan: habiskan seminggu lagi dengan AI builder-nya menambahkan fitur yang sebenarnya dibutuhkan terapis, atau luncurkan dengan apa yang ia punya dan tambahkan nanti.

(Ia menambahkannya. Butuh tiga hari. Sekarang ia adalah produk.)

Hal yang membuat ini sulit

Alasan begitu banyak founder terjebak di sini adalah karena membangun itu seru dan merilis itu menakutkan.

Membangun adalah percakapan dengan tools AI-mu. Kamu punya ide, kamu jelaskan, tools-nya menjalankannya. Ada feedback loop yang memakan waktu hitungan menit. Merilis berbeda. Kamu menekan publish, dan kalau ada yang salah, manusia sungguhan tahu. Tidak ada kesempatan kedua.

Jadi kita mencari alasan untuk tidak merilis. “Belum cukup poles.” “Saya harus menambahkan satu fitur lagi.” “Bagaimana kalau font-nya salah?” Dan enam minggu kemudian, kamu masih duduk di atas sesuatu yang berfungsi tapi tidak terasa selesai, dan kamu sudah meyakinkan dirimu bahwa itu karena font-nya.

Itu bukan karena font-nya.

Biasanya karena kamu belum menghabiskan waktu dengan pengguna sungguhan, atau kamu membangun sesuatu yang masuk akal di kepalamu tapi tidak begitu pas dengan cara orang sungguhan bekerja. Itu bisa diperbaiki. Ia cuma menuntut pengakuan bahwa kamu tidak tahu apa yang tidak kamu ketahui, lalu pergi berbicara dengan seseorang yang tahu.

Checklist kesiapan peluncuran

Pakai ini. Pendek dan jujur.

Saya sudah memakainya sendiri untuk melakukan tugas sungguhan, dan ia berfungsi (bukan secara demo, tapi sungguhan).
Saya sudah menunjukkannya ke tiga orang yang benar-benar akan memakainya, dan saya sudah memperbaiki hal-hal yang membuat mereka bingung.
Setiap error yang bisa terjadi punya pesan yang memberi tahu pengguna apa yang harus dilakukan (bukan “error”, tapi panduan yang nyata).
Saya tidak masalah kalau ini jadi versi terakhir selama enam bulan (artinya: ia cukup lengkap untuk berguna sekalipun saya tidak pernah menyentuhnya lagi).
Saya lebih bersemangat soal apa yang akan saya pelajari dari pengguna sungguhan daripada soal menambahkan lebih banyak fitur dalam ruang hampa.

Kalau kamu bisa mencentang kelima kotak, kamu selesai. Luncurkan.

Kalau tidak bisa, jangan. Tapi spesifiklah soal alasannya. “Rasanya belum selesai” bukan alasan. “Terapis sungguhan butuh aturan ketersediaan dan saya belum membangunnya” adalah alasan. Itu bisa ditindaklanjuti. Itu bisa diperbaiki. Itulah perbedaan antara terjebak dan berada di sebuah jalur.

Founder aplikasi terapis itu meluncurkannya kemarin. Ia punya pelanggan berbayar pertamanya. Produknya tidak sempurna, tapi ia nyata, dan pelanggannya sudah memberitahunya apa yang harus dibangun berikutnya. Saat itulah kamu tahu kamu selesai: bukan ketika aplikasinya sempurna, tapi ketika kamu siap belajar apa arti sempurna yang sebenarnya bagi orang-orang yang memakainya.