Home / Entrepreneur / Cerita di saat Pre-Inkubasi Indigo (1)
get out of the building

Cerita di saat Pre-Inkubasi Indigo (1)

Sampai tanggal 20 April 2015 ini, saya sudah beberapa kali memberikan materi Lean Startup dengan teman-teman mentor dari BDV dan JDV. Masa Pre-inkubasi sudah dimulai sejak awal bulan April dan akan berakhir pada tanggal 30 April 2015 nanti. Artikel ini adalah oleh-oleh dari pandangan mata saya sebagai pengamat.  Semoga bisa menjadi masukan bagi teman-teman startup semua…

Saya tidak akan membahas secara detail dari berbagai topik yang menjadi bahan diskusi dalam masa mentoring pra-inkubasi. Tapi saya akan menceritakan beberapa kecenderungan yang masih saja terulang. Beberapa diantaranya masih kurang bagus untuk ditiru tapi baik untuk dipelajari.

Banjir Fitur Sejak Awal
Tidak ada masalah kalau mau buat fitur banyak. Tapi pastikan dulu kalau fitur itu memang dibutuhkan oleh pengguna anda. Saya menemukan beberapa startup yang sudah “bicara dan menjual” fitur dari awal. Padahal lean startup menghindari hal tersebut sampai kita yakin sudah menemukan solusi yang memang dibutuhkan oleh pengguna.

Dasar dari masalah banjir fitur adalah karena umumnya pembuat aplikasi/layanan adalah orang teknis yang sudah dari “sononya” suka dengan fitur. Semakin banyak fitur maka akan semakin lengkap rasanya hehehe… Tapi kebiasaan itu perlu diubah karena rentan akan kegagalan dan juga cenderung memakan biaya development yang besar selain masa pembuatan yang lama. Contoh kasus bisa dilihat dari aplikasi MS-Office. Banjir fitur bukan? Padahal seberapa banyak anda menggunakan semua fitur yang diberikan? Sampai 30%? Saya rasa tidak. Nah, bandingkan dengan Google Doc yang memberikan aplikasi minimalis tapi malah sukses digunakan saat ini.

Daripada membuat fitur banyak, lebih baik fokus kepada masalah dasar yaitu: apa masalah yang dihadapi oleh calon pengguna dan solusi apa yang mereka harapkan?

Berangkat dari hal diatas, anda bisa membuat solusi dasar atau fitur utama yang menyelesaikan masalah tersebut. Dengan demikian, validasi permasalahan utama agar proses meminimalkan kegagalan sudah dimulai sejak awal. Kemudian anda bisa mengembangkan fitur tambahan hanya jika pengguna memang membutuhkannya. Jadi lakukan validasi lagi, dan pastikan pengguna anda memang butuh.

Customer Centric
Sering saya melihat sudut pandang yang digunakan untuk mengukur permasalahan muncul dari persepsi pelaku startup. Sebenarnya tidak salah, karena tidak mudah melihat dari sudut pandang pengguna. Tapi bukan berarti tidak mungkin. Yang perlu dilakukan adalah mencoba melihat kemungkinan yang bisa dihadapi oleh pengguna dan bukan solusinya. Bila kita mencoba mengabaikan solusi ditahap awal (ingat: sebaiknya memang anda abaikan dulu asumsi solusi karena hipotesa anda belum teruji), hal yang menarik kita bahas adalah “apakah ini masalahnya?” dan bukan “kalau begini masalahnya, maka inilah solusinya!”. Sekilas tidak berbeda, namun bila anda menggunakan Javelin Board untuk membuat hipotesa maka anda akan sadar akan hal ini.

javelin board

Dalam Javelin Board, kita diminta untuk tidak membuat asumsi solusi diawal. Kita baru diminta membuat asumsi yang lebih valid setelah melakukan Get Out Of The Building (GOOTB) terlebih dahulu. Artinya kita menguji sebuah asumsi masalah dan mendapatkan validasinya. Dari sana kita baru bisa memberikan asumsi solusi yang lebih mengarah kepada masalah yang telah terbukti validasinya.

Dari berbagai sesi GOOTB yang dilakukan oleh pelaku startup Indigo, banyak yang akhirnya menemukan realita bahwa apa yang mereka kira solusi ternyata bukan apa-apa bahkan masalah yang mereka anggap ada pun ternyata tidak diamini oleh pengguna.

Mengapa ini terjadi? Seperti yang saya sebutkan diatas, sudut pandang pengguna seringkali berbeda dengan sudut pandang kita. Yang perlu kita lakukan adalah memvalidasi apakah hipotesa masalah yang kita buat benar? Memenuhi kriteria sampling tertentu yang kita yakini bisa valid sebagai representasi responden sasaran? Kalau tidak? Lakukan asumsi lain sampai kita menemukannya dan diantara asumsi-asumsi itu kita harus memilih Riskiest Asumption sebagai faktor penguji yang paling utama.

Oke, saya akan batasi artikel ini hanya untuk 2 topik tadi. Karena saya melihat banyak yang masih berkutat di dalam hal tersebut.

Jika anda belajar Lean Startup, maka anda pasti mengenal pola pembahasan diatas. Sebaiknya hindari kesalahan diatas untuk meminimalkan hilangnya tenaga dan waktu anda…

 

 

About Samuel Henry

Saya seorang Gamer. Itu pekerjaan utama saya, sementara sampingan yang lain adalah Pembicara baik untuk bidang Teknologi & Softskill, juga sering menjadi Coach & Trainer untuk bidang IT, saya penulis buku, dan saat ini saya menjadi Mentor di Jogja Digital Valley (JDV) Hobby saya menulis, melukis dan menggambar serta mendengar musik. Saya suka topik kreativitas, karena saya percaya kita mendapat anugerah kreatif agar kita tidak lupa menjadi bagian dari Pencipta.