Hilangnya Keyakinan (Lost confidence)

• Framework prioritas berbasis keyakinan seperti RICE sebagian besar hanyalah noise, dan kita membutuhkan cara mengambil keputusan tanpa berpura-pura mengetahui masa depan yang tidak bisa diketahui
• Skor keyakinan cenderung diberi tinggi untuk proyek kecil (small) dan rendah untuk proyek besar (large), sehingga secara sistematis menyingkirkan proyek bernilai besar dan mendistorsi prioritas
• Skor keyakinan tidak dapat diandalkan karena definisinya kabur, data validasinya minim, dan proyek selalu terlambat serta dampaknya lebih kecil dari ekspektasi
• Solusinya adalah berada di ranah ketidakpastian (uncertainty), bukan probabilitas (probability): menanyakan “tindakan apa yang bijak dalam distribusi probabilitas apa pun”
• Alih-alih keyakinan, penting untuk menetapkan prioritas dengan teknik seperti hal yang selalu benar, dampak pelanggan, menjaga opsi, dan taruhan asimetris

---

Permainan keyakinan (Confidence games)

• Banyak framework prioritas memasukkan keyakinan bahwa dampak yang diprediksi bisa dicapai dengan upaya yang diprediksi ke dalam skor
  • Dari dua proyek dengan nilai dan upaya yang sama, memilih proyek yang keyakinan eksekusinya lebih tinggi memang rasional
  • Namun cara penggunaannya di dunia nyata bukan “1) beri skor → 2) jalankan pemenang yang jelas → 3) jika seri, pilih yang keyakinannya lebih tinggi”
• RICE memasukkan keyakinan secara langsung ke dalam rumus perhitungan skor tahap pertama
  • Rumus RICE: Score = (Reach × Impact × Confidence) / Effort
  • Rumus RPS: Score = Reach × Potential × Solution Confidence
• Cara ini memperlakukan dua skenario berbeda sebagai setara dan menciptakan kesetaraan palsu
  • Fitur inkremental yang kecil tetapi pasti bisa dieksekusi
  • Fitur besar dengan dampak besar tetapi mengandung risiko
• Biasanya proyek kecil memiliki keyakinan tinggi dan proyek besar rendah, sehingga jika keyakinan dikalikan, kita secara sistematis menjauh dari arah yang memaksimalkan penyampaian nilai
  • Motivasi inti gerakan Agile sendiri adalah wawasan bahwa “keberhasilan proyek besar memang seharusnya selalu punya keyakinan rendah”
• Alasan tidak memercayai skor keyakinan
  • Definisinya kabur: tidak jelas apa arti “30%”. Seharusnya, skor keyakinan semua proyek dicatat lalu dibandingkan dengan hasil nyata untuk menghitung akurasi secara numerik, tetapi dalam praktiknya itu tidak dilakukan
  • Jika setiap tahun hanya meluncurkan sedikit fitur utama, bahkan setelahnya pun data untuk validasi itu sendiri tidak cukup
  • Proyek hampir selalu terlambat, dan dampaknya lebih kecil serta lebih lambat dari ekspektasi. Proyek 9 bulan dengan 6 tim pun dimulai karena ada “tingkat keyakinan tertentu”
• Kutipan Hofstadter's Law: “Selalu memakan waktu lebih lama dari yang Anda perkirakan, bahkan ketika Anda memperhitungkan Hofstadter's Law”
• Jika bertanya kepada PM berpengalaman tentang “fitur yang Anda yakini pasti akan disambut baik tetapi ternyata tidak”, semua orang punya banyak contoh
  • Meski ada dasar seperti percakapan pelanggan, permintaan eksplisit, atau janji membeli, ketika akhirnya dibuat, bahkan orang yang berjanji pun hampir tidak menggunakannya
  • Teknik memperbaiki prediksi: minta pelanggan menjelaskan bagaimana mereka akan menggunakannya langkah demi langkah dalam workflow nyata. Saat menelusuri langkah-langkah itu, mereka bisa menyadari sendiri, misalnya “ini berarti kami harus menulis ulang kode, jadi kami tidak akan melakukannya”
• Kreator konten juga sama: tulisan yang dikeluarkan terburu-buru tanpa banyak ekspektasi bisa mendapat view dan respons tertinggi tahun itu, sementara karya besar yang dikerjakan puluhan jam bisa diabaikan
  • Keempat sel dalam tabel 2×2 “ada/tidaknya keyakinan × hasil (dicintai/diabaikan)” penuh dengan contoh

Apa yang digunakan sebagai pengganti keyakinan dan risiko (What to use in place of confidence and risk)

• Jawabannya ada di ranah ketidakpastian (uncertainty), bukan probabilitas
  • Probabilitas mengasumsikan kita mengetahui distribusinya. Untuk 100 kali lemparan koin adil, kita bisa memprediksi bahwa jumlah sisi kepala sangat mungkin berada di antara 40–60 kali
  • Hampir semua hal di startup berbeda dari ini. Keberhasilan, strategi, dan fitur tidak punya preseden, terlalu kompleks, atau input variabelnya tidak memiliki presisi, sehingga probabilitas yang bermakna tidak dapat diberikan
  • Konsep “Knightian Uncertainty (ketidakpastian Knightian)” berasal dari karya ekonom Frank Knight pada 1921
  • Metode Bayesian pun membutuhkan prior numerik dan probabilitas kondisional; keduanya tidak diketahui dan tidak bisa didefinisikan
• Pertanyaan di ranah ketidakpastian: “Tindakan apa yang bijak terlepas dari distribusi probabilitasnya?”

• Hal yang selalu benar (True always)

  • Fokus pada hal yang selalu benar dalam situasi apa pun — prinsip konstanta jangka panjang (long-term constants) dari Bezos
    • Pengguna secara universal lebih menyukai software yang cepat dan responsif. Mereka menghargai sinkronisasi latar belakang, interaksi instan, dan kemampuan berjalan di semua perangkat
    • Dalam skenario terburuk (mereka tidak peduli pada kecepatan), mereka tetap tidak menganggap kecepatan sebagai hal negatif. Dalam skenario terbaik, seperti Notion, Figma, Miro, Gmail, dan Google Docs, performa menjadi faktor diferensiasi inti
  • Tidak semua fitur punya daya tarik universal. Alih-alih dekomposisi angka yang presisi, identifikasi fitur yang praktis dianggap bernilai oleh semua pelanggan, atau setidaknya disukai
    • Kadang sesuatu pasti bernilai karena merupakan kewajiban. Persyaratan enterprise seperti compliance SOC 2 mungkin tidak menarik, tetapi jelas bernilai saat menjual ke enterprise
    • Kepastian seperti ini mengompensasi ketiadaan diferensiasi
  • Namun ide yang paling inovatif dan terdiferensiasi jarang masuk kategori “benar-benar pasti”
    • Hal yang pasti memang bernilai, tetapi sulit menjadi faktor diferensiasi strategis
    • Produk hebat membutuhkan perbaikan yang dapat diandalkan sekaligus lompatan inovatif

• Penemuan cepat, pemulihan cepat (Quick discovery, quick recovery)

  • Sudah lama didukung untuk memvalidasi ide dengan mewawancarai calon pelanggan secara sistematis sebelum membangun, tetapi ini juga jatuh ke dalam “jebakan keyakinan”
    • Sebelum dibuat, kita tidak akan pernah tahu dengan pasti
    • Namun sebelum membangun, mematahkan validasi (invalidate) tetap memungkinkan, sehingga bisa mencegah pemborosan berbulan-bulan hingga bertahun-tahun; karena itu masih merupakan titik awal yang tepat
  • Solusi klasiknya adalah membuat SLC (konsep yang meng-upgrade MVP) — produk yang sederhana tetapi utuh untuk memperoleh feedback nyata (pengalaman, bukan prediksi)
    • Produk yang sudah ada menjaga portofolio yang seimbang antara kemenangan yang pasti dan taruhan inovatif, dengan metode validasi berbeda untuk masing-masing
  • Contoh “fitur dummy (dummy features)”: tombol yang ketika diklik menampilkan “Fitur ini belum tersedia. Beri tahu kami bagaimana Anda akan menggunakannya”
    • Memberikan sinyal nyata yang diperoleh melalui tindakan tentang jumlah pengguna yang tertarik dan kandidat wawancara potensial
    • Sinyal ini 100 kali lebih baik daripada survei. Dalam survei orang mudah menjawab “ya”, tetapi tindakan seperti mengeklik tombol menuntut ketertarikan nyata. Perilaku yang diamati mengalahkan niat yang dinyatakan

• Fokus pada dampak pelanggan alih-alih keyakinan (Focus instead on customer impact)

  • Ganti keyakinan dengan dampak. Dampak didefinisikan dalam dua cara
    • Aturan mayoritas (Majority rule): fitur yang digunakan secara rutin oleh mayoritas pengguna jelas penting dan kemungkinan besar menjadi alasan utama adopsi serta retensi
    • Pendukung fanatik (Passionate advocates): fitur yang menciptakan penggemar fanatik pada segmen kecil. Orang-orang yang berkata, “Saya membelinya hanya karena ini.” Meski tidak universal, fitur seperti ini memicu loyalitas mendalam pada segmen tertentu (“magnificent delighters”)
  • Jika pengguna benar-benar mencintai bagian tertentu, mereka akan menoleransi kekurangan lain
    • Karena daya tarik iPod, miliaran orang menoleransi iTunes, software yang sangat buruk
    • Software yang dirancang indah bisa diterima hanya karena pengalaman desainnya, meskipun ada fitur yang hilang atau batasan platform
  • Definisi kuantitatif fitur berdampak tinggi
    • (1) digunakan secara rutin oleh setidaknya 51% pelanggan, atau
    • (2) disebut oleh setidaknya 15% pelanggan sebagai salah satu dari 3 alasan utama mereka memilih atau bertahan
    • Standar ini tinggi, tetapi fitur yang inovatif dan berisiko memang pantas memiliki standar tinggi; besarnya imbalan harus membenarkan risikonya

• Berinvestasi pada leverage (Invest in leverage)

  • Ada area di mana perubahan inkremental kecil menghasilkan dampak besar
  • Ada area leverage yang secara matematis dan struktural hampir selalu berlaku
    • (bagian promosi buku terkait dikecualikan sebagai iklan)

• Maksimalkan optionality (Maximize optionality)

  • Jika masa depan tidak dapat diketahui, pilihlah hal yang memaksimalkan jumlah opsi yang bisa dimiliki saat masa depan itu tiba
    • Melampaui fleksibilitas sederhana atau menghindari lock-in; rancang agar bisa menangani apa pun yang muncul
  • Contoh
    • Menjaga biaya tetap rendah → mempertahankan profitabilitas sekaligus memungkinkan eksperimen harga dan packaging yang beragam serta ketahanan masa depan
    • Memilih library dan framework UI cross-platform yang sudah teruji dan aktif dikembangkan → merespons evolusi platform dan perangkat
    • Arsitektur plugin → memungkinkan Anda dan komunitas membangun hal-hal yang saat ini belum bisa dibayangkan
    • Arsitektur API-first → mengisolasi tim, menghubungkan frontend, backend, dan integrasi pelanggan
    • Wrapper untuk layanan vendor → memungkinkan mengganti vendor yang tidak stabil, mahal, atau tertinggal
  • Mengamankan opsi masa depan menuntut pekerjaan tambahan hari ini
    • API pembungkus vendor tidak menambah nilai hari ini
    • Ini bijak untuk perusahaan matang yang memprioritaskan stabilitas dan prediktabilitas, tetapi bisa menjadi pilihan keliru pada tahap awal yang harus mengalahkan pemain mapan dengan kecepatan
  • Cara memaksimalkan opsi seluruh perusahaan adalah membangun perusahaan yang hebat
    • Pertumbuhan yang sehat dan berkelanjutan, gross margin yang besar dan terus meningkat, cinta pelanggan yang terbukti lewat retensi, upgrade, dan word of mouth, serta cinta karyawan yang terbukti lewat masa kerja panjang dan pertumbuhan karier
    • Perusahaan hebat memiliki banyak opsi seperti akuisisi, tetap independen, penggalangan dana, IPO, dan suksesi

• Portofolio taruhan (Portfolio of bets)

  • Portofolio mengurangi volatilitas, tetapi juga mengurangi upside maksimum
    • Kemungkinan tidak ada kemenangan sama sekali memang rendah sehingga downside tidak buruk, tetapi karena kemenangan harus menutupi kerugian, bahkan jackpot sesekali pun tidak sebesar taruhan tunggal
    • Analogi: membeli Amazon saat IPO lalu memegangnya selamanya akan menjadi yang terbaik, tetapi jika pendekatan yang sama diterapkan pada IPO lain di tahun yang sama, nilainya bisa menjadi $0. Portofolio tidak akan menjadi nol, tetapi pertumbuhan maksimumnya jauh lebih kecil daripada saham terbaik
  • Sidebar matematis: alasan portofolio bekerja terlepas dari distribusi adalah Central Limit Theorem (Teorema Limit Pusat)
    • Jika kita berulang kali mengambil N sampel dari populasi dengan distribusi yang stabil tetapi tidak diketahui, lalu menggambar histogram rata-rata sampel, distribusi itu akan konvergen ke Gaussian (distribusi normal), dengan rata-rata sama dengan rata-rata populasi dan varians sebesar varians populasi dibagi 1/n
    • Lindeberg–Lévy CLT menunjukkan bahwa ini tetap berlaku meskipun tiap sampel berasal dari distribusi berbeda (dengan syarat independensi, varians terbatas, dan tidak ada satu variabel pun yang mendominasi)
    • Namun dalam distribusi yang umum di lingkungan startup, syarat ini bisa gagal (sebagian Power Law memiliki varians tak terhingga)
  • Portofolio bekerja ketika Anda menginginkan hasil yang dapat diprediksi tetapi biasa-biasa saja, dan tidak bekerja ketika Anda menginginkan outlier
    • Contoh portofolio venture/angel: 65% merugi, dan hanya sekitar 10% menghasilkan return yang membenarkan risiko serta ilikuiditas
    • Saat mengejar outlier, yang dibutuhkan bukan portofolio, melainkan investasi all-in (karena distribusi return startup adalah Power Law yang melanggar kriteria Lindeberg)
  • Kesimpulan: jika prioritasnya adalah menemukan diferensiasi pasar dan mesin pertumbuhan, portofolio adalah alat yang salah. Portofolio cocok untuk hasil inkremental kecil yang dapat diandalkan; dalam kasus ini, tidak perlu berdebat soal keyakinan

• Taruhan asimetris (Asymmetric bets)

  • Kebalikan alami dari portofolio. Jika portofolio untuk reliabilitas, taruhan asimetris adalah untuk outlier
    • Bukan memprediksi berhasil atau gagalnya taruhan, melainkan mengambil taruhan dengan downside terbatas dan terukur, sementara upside besar
  • Jika skenario terburuk adalah “kehilangan 2 bulan” dan skenario terbaik adalah “diferensiasi total”, probabilitas nyaris tidak bermakna
    • Yang penting downside masih bisa ditanggung dan upside cukup besar untuk menutup sepuluh kerugian dengan satu kemenangan
    • Probabilitas persisnya tidak bisa diketahui, tetapi bentuk (shape) tiap taruhan bisa diketahui
  • Taruhan asimetris di level strategi biasanya sudah memiliki bentuk yang ditentukan sebelumnya (pasar baru tempat rekomendasi majemuk terakumulasi, moat yang makin dalam setiap kali menjual)
    • Di level fitur, asimetrinya harus dibangun sendiri. Bentuk default proyek software cenderung melenceng dari “2 minggu → 2 bulan → sudah terlalu lama dikerjakan sehingga harus diselesaikan”
    • Mekanismenya adalah anggaran yang ditulis sebelum mulai: “2 engineer, 3 minggu, lalu berhenti dan evaluasi.” Timebox adalah downside yang terbatas
  • Mengganti keyakinan dengan “seberapa asimetris ini” juga merupakan salah satu cara
    • RICE meminta Anda memperkirakan probabilitas yang sudah Anda akui tidak bisa diketahui
    • Asimetri menanyakan dua hal yang benar-benar bisa diperkirakan: skenario terburuk dari sisi waktu dan biaya serta skenario terbaik dari sisi nilai pelanggan. Keduanya konkret, dan jika semua angka dibatasi pada pangkat sepuluh, angka-angka itu bisa konvergen menjadi angka yang dapat disepakati dalam rapat

Kesimpulan

• Berhentilah berpura-pura bahwa keyakinan dapat dikuantifikasi atau didefinisikan
• Sebagai gantinya, gunakan teknik yang bekerja setiap kali masa depan tidak dapat diprediksi — karena masa depan memang selalu tidak dapat diprediksi

[hmmhmmhm]

"Sebaliknya, gunakan teknik yang bekerja setiap kali masa depan tidak dapat diprediksi, karena masa depan memang selalu tidak dapat diprediksi" Keren.

[spilist2]

Tulisan yang sangat bagus.