- Sebagian besar pengguna hanya memanfaatkan sekitar 20% fitur aplikasi yang benar-benar mereka butuhkan, dan 20% itu berbeda untuk tiap pengguna
- 80% fitur sisanya bahkan bisa dianggap sebagai gangguan, dan justru memicu ketidaknyamanan atau keluhan
- Jika pasar niche dibidik dengan tepat, kita bisa membangun basis pengguna yang kuat
- Contoh seperti Kagi, Figma, dan Notion, yang berhasil menyelesaikan 20% yang diabaikan perusahaan besar dan membangun pasar dengan loyalitas tinggi, menunjukkan adanya peluang pasar baru
- VS Code, Slack, dan Discord mendukung ekstensibilitas dan personalisasi sehingga pengguna dapat mengoptimalkan sendiri 20% versi mereka
- Intinya bukan membuat produk untuk semua orang, melainkan membuat alat yang sangat memuaskan bagian yang diinginkan masing-masing orang, dan inilah cara menghindari masalah pembengkakan fitur
Pengalaman Masa Kecil dan Cara Orang Menggunakan Perangkat Lunak
- Saat kecil, penulis sering merusak komputer karena menghapus file yang tidak perlu demi mengelola ruang penyimpanan 2GB
- Setelah menghapus file sistem penting seperti
.ini, ia harus memasang ulang Windows dan Office 97 dari awal
- Ayahnya selalu menekankan agar Excel обязательно terpasang, tetapi bagi penulis Excel hanyalah alat untuk menempelkan tabel ke Word
- Dari sekian banyak fitur Excel, hanya salin/tempel tabel yang benar-benar bermakna baginya
- Seorang kenalan juga hanya pernah memakai Excel sebagai buku kas rumah tangga, tanpa menyentuh fitur lainnya
20% yang Berbeda untuk Setiap Orang
- Dalam penggunaan perangkat lunak, ada 'aturan 80/20': sebagian besar pengguna hanya memakai 20% dari seluruh fitur
- Namun, 20% yang menjadi fokus tiap pengguna berbeda-beda, dan masing-masing menganggap bagian yang mereka pakai sebagai yang paling penting
- Contoh: memakai tabel di Word tetapi tidak memakai mail merge, memakai pivot table di Excel tetapi tidak memakai skrip, tidak memakai animasi di PowerPoint
- Akibat penambahan fitur baru atau pembaruan UI, pengguna merasa aplikasi menjadi lebih lambat atau dipenuhi fitur yang tidak perlu, lalu timbul ketidakpuasan
- 80% fitur yang tidak dipakai bahkan bisa dianggap sebagai elemen yang mengganggu alur kerja 20% yang penting bagi mereka
Hasrat terhadap Hasil yang Sempurna
- Fenomena ini tidak hanya terjadi di Microsoft, tetapi juga sama di perusahaan IT lainnya
- Misalnya, saat seseorang menginginkan pencarian kata kunci yang tepat di Google Search, hasil pencarian dengan istilah terkait yang tidak perlu justru bisa memicu ketidakpuasan
- Dari sudut pandang perusahaan, ini mungkin dianggap sebagai "kebutuhan 1% pengguna", tetapi 1% dari 1 miliar orang adalah 10 juta orang, sebuah pasar yang sangat besar
- Kagi menyerang pasar dengan diferensiasi berupa pencarian berfokus pada kualitas tanpa iklan dan menjaga privasi, khusus untuk pasar kecil yang diabaikan Google
- Dengan memanfaatkan celah perusahaan raksasa, dimungkinkan terbentuk pasar niche yang memuaskan kelompok pengguna kecil
- Kita tidak perlu memuaskan semua orang; sangat mungkin menyusun strategi yang secara sempurna memuaskan pengalaman 20% dari kelompok tertentu
Menemukan 20% yang Terlupakan
- Banyak perusahaan inovatif berfokus menyerang kelompok pengguna tertentu yang terlewat oleh perusahaan besar
- Figma fokus melampaui Adobe pada aspek desain kolaboratif, dan Notion juga memantapkan diri sebagai alat hibrida yang dioptimalkan untuk kebutuhan pengguna tertentu
- Perangkat lunak yang sukses biasanya menambah fitur seiring waktu, tetapi dalam proses itu muncul celah ketika 20% milik pengguna tertentu menjadi terkubur
- Perangkat lunak open source unggul di area ini karena dapat membuat build kustom yang dikhususkan untuk alur kerja tertentu
- Contohnya, memungkinkan pengembangan versi ringan Blender khusus untuk visualisasi arsitektur
Merancang untuk 20% yang Tepat
- Filosofi ini diterapkan dengan baik di VS Code
- Fitur dasarnya berfokus pada penyuntingan teks sederhana, tetapi melalui ekstensi, pengguna dapat membangun lingkungan pengembangan yang mereka inginkan
- Strukturnya memungkinkan semua pengguna mengustomisasi 20% milik mereka sendiri
- Integrasi Slack dan bot Discord juga mendukung prinsip yang sama agar pengguna bisa menyesuaikan sendiri pengalaman mereka
- Memang sulit memprediksi 20% milik semua pengguna sejak awal, tetapi jika menyediakan ekstensibilitas dan kustomisasi, masing-masing orang bisa mencapai pemanfaatan optimalnya
Kesimpulan: Daripada Produk untuk Semua Pengguna, Fokus pada '20% yang Dibutuhkan' Masing-Masing
- Jika mencoba melakukan semua fitur dengan sama baiknya, hasil akhirnya adalah perangkat lunak yang semakin berat dan makin banyak memicu keluhan
- Yang penting adalah berfokus agar tiap fitur bekerja sempurna bagi pengguna tertentu yang benar-benar mencarinya
- Karena pengguna pada akhirnya hanya akan memakai sebagian dari seluruh fitur, akan lebih efektif untuk fokus membuat fitur tertentu benar-benar unggul
- Perlu perencanaan yang mengakui bahwa perangkat lunak bisa dipakai dengan cara yang tidak terduga, lalu menerima keragaman tersebut
- Tidak memaksakan semua bagian kepada pengguna, dan hanya mengembangkan bagian yang benar-benar dicintai, justru menghasilkan kepuasan yang lebih besar
2 komentar
Selalu saja langsung ditempelkan dengan Hukum Pareto;; memangnya tidak bisa saja 15%? wkwk
Opini Hacker News
Di sebuah perusahaan SaaS tempat saya pernah bekerja, kami pernah mencoba menganalisis hanya berdasarkan sebagian fitur yang benar-benar digunakan pengguna. Tujuannya adalah mengurangi kompleksitas produk agar sesuai dengan beberapa tipe pengguna inti, sekaligus menghapus fitur yang merepotkan. Hasilnya, selain layar login, 20% fitur yang dianggap penting ternyata benar-benar berbeda untuk tiap orang. Hasil analisisnya nyaris tidak berbeda dari pengambilan sampel acak berbobot
Sangat relate. Tapi ketika mulai menjual produk ke pelanggan enterprise, situasinya berubah total. Kurang satu "fitur kebersihan" saja bisa membuat deal batal. Dan tiap enterprise punya fitur wajib yang berbeda-beda. Fitur kebersihan di sini adalah analogi untuk elemen minimum yang mutlak diperlukan semua orang, seperti toilet
Ini tulisan yang mengingatkan pada posting blog Spolsky
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
Saya pernah membuat aplikasi hobi pribadi sendiri, dan kadang terpikir ingin merapikannya lalu merilisnya. Tapi saya sama sekali tidak punya niat untuk mempromosikan atau mengenalkannya, jadi rasanya merilis pun tidak ada gunanya. Sebenarnya alasan yang lebih besar adalah karena saya tidak punya niat mengimplementasikan 80% fitur sisanya yang tidak saya pakai sendiri
Di bidang marketing ada konsep Modified Pareto. Bukan 80/20, melainkan 60/20. Sebanyak 20% heavy user mengonsumsi 60% nilai produk, sedangkan 80% light user mengonsumsi 40%-nya. Ini bukan porsi yang cukup kecil untuk diabaikan, jadi pengguna ringan pun tetap harus diperhatikan
value-paretos-bottom-80
Begitulah. Padahal yang jauh lebih penting adalah apakah pengguna 'merasakan' bahwa software itu bisa menyelesaikan masalah mereka. Kalau ingin membuat orang mau membayar, software harus memberi kesan bahwa ia juga berpotensi menyelesaikan beragam masalah pengguna. Masalah yang beragam itu bisa saja terkait fitur yang tidak dipakai langsung oleh pengguna. Misalnya sistem rigging yang saya lihat di software 3D mungkin hanya dipakai 2% pengguna selama 1% waktu, tetapi tanpa fitur itu ada orang yang bahkan tidak akan mempertimbangkan produknya sama sekali
Saya memang tidak berbakat memprediksi bagaimana hasil kerja saya akan benar-benar dipakai, jadi saya hanya suka pendekatan seperti yang sering dianalogikan dengan "Desire paths", yaitu mengaspal jalur yang sudah tampak digunakan
the-road-most-traveled-by-paving
Saya setuju dengan gagasan bahwa "alih-alih mencegah pertambahan fitur, kita harus menerima bahwa software bisa dipakai dengan cara-cara yang tak pernah kita bayangkan". Karena itu saya menganggap interoperability adalah unsur terpenting dalam software. Masalah utama yang saya tangkap dari tulisan ini adalah sifat tertutup format file antar-software dan antar-versi. Saya tidak keberatan memakai kombinasi beberapa alat, tetapi masalahnya alat-alat itu tidak bisa bekerja sama dengan baik dalam pipeline. Impian Unix memang terasa sangat sulit
Pada aplikasi yang sudah punya ukuran tertentu, hampir tak pernah semua fitur dimanfaatkan 100%. Menurut pengalaman saya, hampir semua aplikasi punya sekitar 10~30% bagian yang sama sekali tidak dimanfaatkan. Biasanya itu karena alurnya sulit dipahami siapa pun selain tim pengembang, atau workflow-nya buruk dan tidak efisien, atau karena fiturnya begitu mendasar sehingga perusahaan yang benar-benar membutuhkannya justru tidak punya daya beli untuk membeli software tersebut
Betul, tetapi banyak pengguna masing-masing punya 20% fitur yang mereka anggap penting secara berbeda, jadi semua fitur harus dipertahankan agar jumlah pengguna saat ini bisa tetap terjaga. Meski begitu, kalau fitur yang hampir tak dipakai tetapi menyita banyak waktu pemeliharaan atau pengembangan dihapus, ROI akan meningkat
Tapi pengguna belum tentu menganggap 20% yang sama itu penting. Hal lain yang perlu dipikirkan adalah, pengguna sebenarnya tidak terlalu tahu fitur apa saja yang ada sebelum benar-benar mencoba aplikasinya. Keputusan untuk menginstal didasarkan pada fitur yang mereka harapkan ada sebelum instalasi, bukan pada fitur yang benar-benar ada di aplikasi. Ini perbedaan yang penting. Anda bisa mencurahkan banyak usaha pada fitur, tetapi hasilnya sering baru terasa setelah pengguna berhasil didapatkan.
Ini sangat penting saat membuat MVP, karena dalam banyak kasus yang menghalangi instalasi dan penggunaan berkelanjutan bukanlah kurangnya fitur. Biasanya masalahnya adalah penyampaian pesan, marketing, atau memang tidak ada nilai yang cukup menarik bagi pengguna. Menjejalkan fitur tidak akan menyelesaikan masalah seperti ini. Meski terdengar sederhana, banyak perusahaan melewatkan hal ini.
MVP paling sederhana adalah bahkan belum mengimplementasikan apa pun, lalu mulai dengan mendorong orang mendaftar lebih dulu. Dengan cara ini Anda bisa memverifikasi apakah pesannya sudah tersampaikan dengan benar. Jika mereka kecewa setelah mendaftar, setidaknya pesannya berarti berhasil tersampaikan.
Namun cara seperti ini berarti MVP dirilis dalam keadaan belum memenuhi janji yang dibawanya, sehingga ada risiko menimbulkan kekecewaan karena janji yang belum tuntas. Selain itu, banyak fitur sebenarnya boleh tidak ada, terutama di SaaS, karena banyak fitur yang nyatanya tidak cukup esensial sampai orang mau membayar untuknya. Alih-alih langsung menerima permintaan pelanggan sebagai persyaratan wajib, Anda perlu benar-benar memastikan apakah mereka menganggapnya sebagai 'nilai', apakah mereka benar-benar bersedia membayar, dan apakah itu benar-benar menyelesaikan pain point yang penting. Memahami mengapa permintaan itu muncul jauh lebih penting daripada langsung membuat fiturnya