Permintaan Fitur yang Sebaiknya Benar-Benar Kamu Bangun (Dan Cara Mengenalinya)

Kamu sudah tahu cara berkata tidak pada permintaan fitur yang buruk. Kamu sudah belajar membedakan scope creep dari fitur inti. Kamu menjaga batas-batas produkmu.

Tapi sekarang kamu ada di posisi sulit yang berbeda: kamu punya selusin permintaan yang semuanya lolos tes. Semuanya untuk aplikasimu. Semuanya masuk akal. Semuanya hal yang benar-benar diinginkan penggunamu. Tapi kamu cuma bisa membangun tiga dari semua itu.

Tiga yang mana?

Di sinilah kebanyakan keputusan produk salah arah. Founder memilih yang kedengarannya paling mengesankan, atau paling menguntungkan, atau yang datang dari pelanggan terpentingnya. Kadang mereka benar. Biasanya mereka salah.

Sinyal-sinyal yang penting

Sinyal 1: Pengulangan tanpa dipancing

Kalau tiga pengguna terpisah meminta hal yang sama tanpa saling bicara, itu sebuah sinyal. Mereka tidak berkoordinasi. Mereka semua kebetulan memikirkannya. Kalau lima pengguna memintanya, itu bukan kebetulan — itu kebutuhan yang nyata.

Kebalikannya penting: kalau satu pengguna meminta dan tidak ada yang lain, lalu kamu membangunnya, sekarang kamu memelihara sebuah fitur yang tidak dipakai siapa pun dan pengguna satu itu pun mungkin tetap tidak puas (karena kamu membangunnya sedikit salah).

Hitung permintaan sebelum kamu membangun. Bukan yang dari pelanggan paling cerewet atau klien terbesarmu — hitung pengulangan tanpa dipancing-nya. Dua atau tiga pengguna independen yang meminta hal yang sama adalah sinyal yang jauh lebih kuat daripada satu pelanggan penting yang meminta lima hal.

Sinyal 2: Workaround-nya penting

Kalau kamu punya pengguna dan mereka bertahan meski fiturnya tidak ada, mereka sudah menemukan workaround. Mungkin mereka melakukannya di luar aplikasimu. Mungkin mereka melakukannya secara manual. Mungkin mereka memakai tool lain secara paralel.

Tapi mereka bertahan, yang berarti mereka tidak butuh fitur itu untuk memakai aplikasimu. Mereka membutuhkannya untuk memakai aplikasimu lebih baik. Itu berbeda dari sebuah penghalang.

Fitur yang paling penting adalah yang mencegah orang memakai aplikasimu sama sekali. Fitur yang sekadar enak untuk dimiliki adalah yang orang siasati.

Perhatikan permintaan mana yang merupakan penghalang. Ada yang bilang “Aku tidak bisa pakai ini sampai kamu melakukan X” vs. ada yang bilang “Akan keren kalau kamu punya X.” Bedanya itu emas.

Sinyal 3: Fitur yang menyatu dengan model bisnis

Sebagian fitur membuka cara baru untuk menghasilkan uang sama sekali. “Invoice pelangganku” membuka model bisnis di mana kamu memungut biaya untuk invoicing. “Export ke Salesforce” membuka pendapatan integrasi. “White-label untuk reseller” membuka kanal mitra.

Tapi inilah triknya: kamu tidak tahu apakah model-model itu akan berhasil sampai kamu sudah merilisnya. Kamu tidak bisa merencanakan di sekitarnya. Kamu hanya bisa menyadarinya setelah merilis dan melihat apakah orang benar-benar memakainya.

Penambahan fitur yang paling sukses adalah yang merilis fiturnya mengungkap sebuah pasar yang tidak kamu tahu keberadaannya. Kamu membangun export. Ternyata perusahaan ingin menyematkan export-mu ke dalam alur kerja mereka. Sekarang kamu punya cerita integrasi yang tidak kamu rencanakan.

Bangun fitur karena penggunamu membutuhkannya. Lalu amati apakah penggunamu membutuhkannya dengan cara yang menciptakan bisnis baru. Jangan menebak model bisnisnya lebih dulu.

Sinyal 4: Permintaan untuk membantu

Kalau seorang pengguna meminta kamu membangun sesuatu, itu sebuah permintaan. Kalau seorang pengguna bertanya apakah kamu bisa membangun sesuatu dan menawarkan untuk membantu mengujinya, itu berbeda.

Orang yang menawarkan membantu menguji adalah orang yang punya kepentingan dalam hasilnya. Mereka akan memakai fiturnya dengan hati-hati. Mereka akan melaporkan bug. Mereka akan memberitahumu apakah ia benar-benar menyelesaikan masalah mereka.

Orang yang sekadar meminta adalah orang yang berharap kamu secara ajaib membangun apa yang mereka bayangkan. Kadang kamu akan begitu. Sering kamu tidak.

Bangun bersama para tester dulu. Selebihnya nomor dua.

Godaan membangun fitur prestise

Setiap produk punya satu fitur yang, kalau kamu merilisnya, membuatmu terdengar lebih mengesankan. Untuk aplikasi penjadwalan, itu integrasi dengan Calendly. Untuk aplikasi tugas, itu integrasi dengan Slack. Semua orang tahu apa itu. Semua orang menginginkannya.

Inilah masalahnya: semua orang juga mendapatkannya dari orang lain. Kalau fiturmu bukan integrasi terbaik dan termudah dengan Slack, ia cuma menambah kerumitan ke aplikasimu tanpa membuatmu terkenal.

Fitur yang membuatmu terkenal adalah yang kamu punya posisi unik untuk membangunnya karena kamu memahami masalah pengguna spesifikmu lebih baik daripada siapa pun. Itu bukan fitur prestise. Itu fitur-fitur membosankan yang menyelesaikan masalah nyata untuk orang sungguhan.

Integrasi Slack itu mengesankan. Sebuah tool yang memungkinkan penggunamu melakukan satu hal spesifik jauh lebih cepat daripada yang pernah dipikirkan Slack itu berharga.

Cara benar-benar memutuskan

Saat kamu punya sekumpulan permintaan fitur yang semuanya lolos tes “apakah ini di dalam scope?”, urutkan berdasarkan:

1. Berapa banyak pengguna yang meminta (secara independen)? Lebih banyak lebih baik.
2. Apakah ini penghalang atau enak-untuk-dimiliki? Penghalang lebih mendesak.
3. Bisakah penggunamu menyiasatinya hari ini? Kalau tidak, ia lebih penting.
4. Akankah ada yang membantumu menguji ini? Kalau ya, bangun ini dulu.
5. Akankah ini mengungkap pasar baru? Kalau mungkin, itu bonus, bukan alasan.

Lalu bangun dengan urutan itu. Bukan urutan yang kedengarannya mengesankan. Bukan urutan pelanggan terbesarmu. Urutan sinyal nyata dari orang-orang yang memakai aplikasimu.

Fitur yang tidak akan kamu bangun (untuk sekarang)

Kamu akan punya permintaan yang tidak lolos. Jangan berpura-pura kamu akan membangunnya suatu hari nanti. Beri tahu penggunanya: “Kami tidak akan membangun itu sekarang. Inilah alasannya. Inilah yang sedang kami bangun. Inilah alternatif yang mungkin cocok untukmu.”

Kejujuran itu lebih penting daripada yang kamu kira. Pengguna lebih suka tahu kamu tidak akan melakukannya daripada menunggu enam bulan sambil berharap.

Dan kadang, begitu kamu sudah berkata tidak, pengguna menemukan workaround, atau tool yang berbeda, atau menyelesaikan masalahnya dengan cara lain. Itu tidak apa-apa. Kamu tidak bisa jadi segalanya untuk semua orang.

Produk yang menang adalah yang menjalankan tugasnya dengan baik dan mendengarkan dengan saksama apa yang benar-benar dibutuhkan pengguna, bukan yang mencoba jadi segalanya dan akhirnya jadi tidak ada apa-apanya.