Haruskah Anda Membuat MVP Sebelum Membuat Aplikasi?

Diterbitkan: 2022-03-10
Ringkasan cepat Aplikasi bukanlah pekerjaan kecil. Mereka juga tidak murah untuk dibangun dan dirawat. Jadi, sebelum Anda melanjutkan dengan membuat aplikasi seluler atau SaaS baru untuk klien Anda, mungkin Anda harus mempertimbangkan untuk meluncurkan produk minimum yang layak (MVP). Dengan MVP, Anda memiliki cara yang berisiko rendah dan biaya yang lebih rendah untuk menguji konsep Anda di pasar. Apa yang tidak disukai tentang itu?

Bisakah Anda bertaruh pada ide untuk sebuah aplikasi atau pada asumsi tentang bagaimana konsumen akan menanggapinya? Saya yakin klien Anda juga tidak nyaman melakukan itu, terutama jika uang dan reputasi mereka dipertaruhkan.

Aplikasi dapat menjadi investasi yang berisiko bagi bisnis jika tidak didekati dengan hati-hati. Meski begitu, konsep aplikasi yang paling banyak diteliti dapat menyebabkan tingkat unduhan dan retensi pengguna yang mengecewakan.

Baik Anda berkecimpung dalam bisnis pembuatan aplikasi seluler atau produk SaaS, pernahkah Anda berpikir untuk menggunakan produk minimum yang layak (MVP) untuk melindungi investasi klien Anda?

MVP tidak hanya memungkinkan Anda untuk mendapatkan proyek melalui saluran Anda lebih cepat, tetapi juga memungkinkan pengembang untuk membuat produk yang lebih kuat secara keseluruhan untuk klien mereka.

Inilah yang perlu Anda ketahui.

Nilai MVP Dalam Pengembangan Aplikasi

Frank Robinson adalah orang pertama yang mendefinisikan apa itu MVP pada tahun 2001. Pada dasarnya, MVP adalah versi kecil dari produk yang dirilis ke publik untuk tujuan menguji dan memvalidasi konsep dan kelayakan produk di pasar. .

Lebih banyak setelah melompat! Lanjutkan membaca di bawah ini

Eric Ries, penulis The Lean Startup, adalah salah satu pendukung awal MVP dan dia memiliki beberapa hal menarik untuk dikatakan tentang mengapa dan bagaimana kita harus menggunakannya pada tahun 2013:

Intinya bukan untuk menciptakan produk yang lebih ramping. Ini untuk mendapatkan versi atau konsep paling dasar dari sebuah aplikasi ke tangan pengadopsi dan penginjil. Dengan begitu, pengembang mengumpulkan umpan balik pengguna sejak awal yang, pada gilirannya, digunakan untuk membentuk produk dengan benar ke dalam versi finalnya.

Ambil Dropbox, misalnya. Ini adalah tampilan halaman arahan produk pada tahun 2009:

Dropbox pada tahun 2009
Situs web dan perangkat lunak Dropbox dari 2009. (Sumber: Dropbox) (Pratinjau besar)

Ini adalah halaman sederhana yang menyertakan nama perusahaan, penjelasan perangkat lunak, dan tautan untuk mengunduh aplikasi desktop atau seluler. Untuk pengguna yang ingin tahu lebih banyak tentang apa yang mereka dapatkan, "tur" membawa mereka ke situs mini dengan informasi lebih lanjut:

Deskripsi MVP Dropbox
MVP Dropbox memberikan detail dasar tentang perangkat lunaknya. (Sumber: Dropbox) (Pratinjau besar)

Itu jauh dari penyimpanan pembangkit tenaga listrik, pembuatan konten, dan layanan kolaborasi yang digunakan konsumen dan bisnis saat ini:

Situs web Dropbox 2019
Situs web Dropbox dan SaaS pada 2019. (Sumber: Dropbox) (Pratinjau besar)

Tapi itulah keindahan MVP. Pada dasarnya, ini memaksa pengembang untuk membuat produk hanya dengan serangkaian fitur minimum — tetapi sangat penting — .

Dropbox tidak perlu memperkirakan kekuatan layanan penyimpanan cloud atau menciptakan sesuatu yang tidak tepat untuk pasar saat itu. Yang perlu dilakukan hanyalah meluncurkan solusi sederhana yang dibutuhkan pengguna saat itu juga. Pengguna kemudian dapat memvalidasi produk dan memberi perusahaan arahan yang diperlukan untuk mengambil produknya.

Ada manfaat lain untuk membuat MVP:

  • Anda bisa mendapatkan produk di pasar jauh lebih cepat daripada jika Anda menunggu aplikasi lengkap dikembangkan.
  • Anda mendapat kesempatan untuk menguji kelayakan konsep sebelum Anda melakukan terlalu banyak jam kerja untuk pekerjaan itu.
  • Anda memberi diri Anda lebih banyak ruang (dan mungkin bahkan sedikit pengampunan juga) untuk mengatasi kekusutan dalam produk akhir Anda.
  • Anda menghemat uang dengan MVP. Pertama, karena Anda hanya menghabiskan waktu membangun fitur yang benar-benar dibutuhkan. Kedua, karena Anda mungkin menemukan bahwa pengguna puas dengan versi yang diperkecil dan Anda tidak perlu melakukan lebih banyak pekerjaan untuk menyelesaikan produk.
  • Dengan ide teruji yang dianut oleh pengguna, Anda memiliki sesuatu untuk dibawa ke investor yang dapat membuat sisa proses pengembangan berjalan lebih lancar.

Seperti yang Eric katakan dalam video, MVP adalah cara terbaik untuk memaksimalkan peluang kesuksesan Anda dan melakukannya dalam jangka waktu yang jauh lebih singkat daripada yang dimungkinkan oleh pengembangan produk lengkap.

Cara Membangun MVP Berharga yang Ingin Diuji Pengguna

Keberhasilan MVP Anda bergantung pada kemampuannya untuk memanfaatkan wawasan dan umpan balik yang diberikan oleh pengguna awal — mereka yang 100% mendukung Anda, percaya pada produk, dan ingin membantu Anda mengisi kekosongan. Jadi, jangan lupakan itu.

MVP bukanlah aplikasi setengah-setengah yang disatukan. Itu masih harus berharga.

Berikut adalah beberapa hal yang harus Anda lakukan sebelum membangun dan meluncurkan MVP:

1. Tentukan Tujuan Produk

Jika Anda ingin aplikasi Anda berhasil, itu perlu memecahkan masalah secara unik untuk segmen besar basis konsumen. Itu berarti MVP Anda perlu merinci dengan jelas apa yang dilakukan produk dan mengapa pengguna membutuhkannya.

Misalnya, ini adalah cara Uber (saat itu UberCab) menjual dirinya sendiri selama versi beta pada tahun 2010:

Situs web UberCab pada tahun 2010
Situs web untuk pendahulu Uber, UberCab, pada tahun 2010. (Sumber: Uber) (Pratinjau besar)

Seperti contoh Dropbox sebelumnya, konsepnya sangat sederhana dan tanpa embel-embel dalam menjelaskan apa itu atau mengapa itu sangat berharga. Tapi Anda masih mendapatkan ide. Ini adalah aplikasi yang memungkinkan orang memesan dan membayar mobil dari ponsel mereka. Pada dasarnya, ini adalah substitusi yang nyaman untuk taksi.

Melompat ke depan setahun, Anda akan melihat bahwa Uber mulai memperkuat identitas dan proposisi nilainya dengan peluncuran produk resminya:

Situs web Uber pada tahun 2011
Uber mulai memperbaiki citranya pada 2011 setelah pengujian beta selesai. (Sumber: Uber) (Pratinjau besar)

Ini kembali pada tahun 2011 ketika Uber menjatuhkan "Cab" dan melabeli dirinya sebagai layanan mengemudi pribadi panggilan. Itu adalah cara untuk membiarkan konsumen mengalami hak istimewa mewah tertentu yang mungkin tidak mampu mereka beli.

Meskipun itu bukan bentuk akhir yang diambil Uber, Anda dapat melihat bagaimana umpan balik pengguna awal membantu pengembang produk memutuskan bagian mana dari platform yang benar-benar layak disorot dan dikembangkan.

Ini persis seperti hal yang akan terjadi ketika Anda membangun MVP dan mulai mengumpulkan wawasan berharga dari pengguna tentang apa yang mereka inginkan dan fitur apa yang mereka butuhkan. Namun, pertama-tama, Anda harus mulai dengan memperjelas tujuan dan nilainya secara umum. Anda dapat memperbaikinya nanti.

2. Temukan Pengguna Ideal Anda

Anda memiliki konsep Anda. Sekarang, saatnya untuk mencari tahu apakah konsumen akan menginginkannya. Meskipun MVP lebih murah dan lebih cepat untuk dibuat, tidak berarti itu tidak akan membuang-buang waktu dan sumber daya Anda. Anda harus setidaknya mengkonfirmasi bahwa minat itu ada dan kemudian menentukan, dalam istilah yang jelas, siapa pengguna target Anda.

Secara khusus, Anda perlu memikirkan lokasi.

Pada contoh Uber di atas, Anda dapat melihat bahwa produk beta hanya diuji di San Francisco.

Versi awal Airbnb melakukan hal serupa. Joe Gebbia, salah satu pendiri Airbnb, menceritakan kisah MVP-nya pada episode 2017 How I Built This.

Pada dasarnya, dia kekurangan uang dan memutuskan untuk menyewakan kasur angin di apartemennya di San Francisco untuk konferensi yang akan datang. Mengetahui bahwa hotel akan kekurangan kamar, dia pikir dia bisa menghasilkan uang dari itu. Tapi itu bukan hanya uang sewa yang dia hasilkan. Dia mendapat ide untuk bisnis baru setelah banyak orang menunjukkan minat untuk menyewa ruang di apartemennya.

Jadi, dia dan rekannya membuat situs web bernama “AirBed & Breakfast”. Namun, begitu ditayangkan, itu menyebar jauh melampaui area uji San Francisco yang asli.

Airbnb pada tahun 2009
Versi awal konsep AirBnB dari 2009. (Sumber: Airbnb) (Pratinjau besar)

Pada tahun 2009, ada penyewaan AirBnB di 72 negara. Hari ini, Anda praktis memilih sampah di kota mana pun di seluruh dunia. Tapi semuanya dimulai dengan San Francisco.

Jadi, saat Anda mulai membuat produk, pikirkan tempat terbaik untuk menguji dan mendapatkan umpan balik tentang aplikasi Anda sebelum Anda merilisnya secara penuh. Anda ingin area tersebut menjadi representasi yang baik dari populasi dan demografi yang ingin Anda targetkan. Anda juga harus memastikan ada permintaan untuk produk tersebut dan bahwa pengguna target Anda mampu menggunakannya (setelah Anda mulai memonetisasi).

3. Pilih Format MVP

Format MVP Anda adalah hal lain yang penting untuk dipikirkan sebelum Anda membuat bangunan apa pun.

Dalam beberapa kasus, Anda harus membuat produk yang bisa diterapkan. Misalnya, katakanlah tujuan Anda adalah membuat aplikasi kencan baru. Ada banyak sekali aplikasi kencan di pasaran; dengan dua aplikasi, khususnya, yang terus mendominasi paket. Anda tahu bahwa membangun segala jenis aplikasi kencan seluler akan menjadi pertaruhan besar dan mahal, tidak peduli seberapa banyak Anda mengurangi fitur. Jadi apa yang kamu lakukan?

Anda dapat membuat aplikasi kencan PWA sebagai gantinya. Biayanya akan lebih rendah, waktu pemasarannya jauh lebih cepat, dan akan jauh lebih mudah untuk menampilkan MVP Anda di depan pengguna daripada jika Anda meletakkan sesuatu di app store. Anda bahkan mungkin menemukan bahwa PWA cukup dalam hal format produk pada akhirnya.

Dalam kasus lain, MVP bahkan tidak perlu menjadi produk yang sebenarnya. Itu bisa berupa situs web yang mengumumkan produk atau menyediakan kerangka gambar/prototipe konsep.

Pada tahun 2018, Rand Fishkin mengumumkan bahwa ia meninggalkan Moz, perusahaan yang ia dirikan bersama pada tahun 2004. Secara bersamaan, ia mengumumkan produk baru bernama SparkToro.

Halaman arahan SparkToro
Halaman arahan SparkToro MVP menjelaskan produk yang akan datang, tetapi tidak menyediakan akses. (Sumber: SparkToro) (Pratinjau besar)

Sekarang, Rand adalah seseorang yang dapat meluncurkan sebuah konsep sebagai MVP dan membuatnya tetap sukses. Dia memiliki sejarah panjang dan reputasi yang solid di bidang ini, jadi, tentu saja, pengguna akan tertarik pada produk baru ini meskipun tidak tersedia untuk dikonsumsi.

Bagi Anda yang membangun MVP untuk merek baru, Anda mungkin tidak akan seberuntung itu. Namun, itu benar-benar akan tergantung pada jenis produk yang Anda rencanakan untuk dibuat.

Jika sama sekali tidak ada cara untuk membuat produk dalam versi yang lebih kecil, maka ini bisa menjadi opsi yang perlu ditelusuri. Ini juga merupakan ide yang baik jika Anda atau klien Anda sama sekali tidak memiliki dana dan memerlukan umpan balik yang divalidasi untuk membuktikan kelayakan konsep Anda kepada investor. Itulah satu-satunya cara saya melihat Joe Schmoes lolos dari ini.

Jika Anda mengikuti rute ini, Anda akan membutuhkan bagian penjelasan yang sangat bagus juga. Inilah yang dimiliki SparkToro di halaman Apa yang Kami Bangun:

SparkToro Apa yang Kami Bangun
Situs web SparkToro menjelaskan apa yang sedang dikerjakannya untuk membangun. (Sumber: SparkToro) (Pratinjau besar)

Saya pikir untuk jenis pengguna yang akan tertarik pada produk seperti ini — yaitu, pemasar tingkat lanjut yang benar-benar membutuhkan solusi semacam ini — cara menguji konsep dan kelayakan fitur ini adalah baik. Itu ditulis dalam bahasa mereka dan dengan visual yang mereka pahami.

Namun, untuk pengguna yang tidak terbiasa dengan merek Anda atau tidak terlatih dengan baik seperti audiens Rand, gambar rangka atau prototipe dasbor produk akan menjadi ide yang lebih baik. Bahkan video penjelasan dari pendiri akan berfungsi dengan baik. Itu hanya perlu sesuatu yang meyakinkan pengguna untuk mendaftar dan mulai memberikan umpan balik sedini mungkin.

4. Temukan Minimum Anda yang Sebenarnya

Jika Anda menonton video Eric Ries, Anda akan melihat bahwa ia memberikan formula untuk menentukan fitur minimum MVP Anda. Ini berjalan seperti ini:

# fitur minimum yang Anda pikir Anda butuhkan / 8 = Minimum yang Sebenarnya

Masuk akal jika formula itu membuat Anda merasa khawatir. Tapi pikirkanlah seperti ini:

Anda membangun MVP sesederhana mungkin tanpa menjadi tidak berguna. Anda mengirimkannya ke pengguna dan memberi mereka kesempatan untuk memberikan umpan balik.

Beberapa hal mungkin terjadi sebagai akibatnya:

Mereka benar-benar membencinya.

Mereka mengeluh kepada Anda tentang bagaimana Fitur A menyebalkan dan bagaimana mereka berharap fitur itu melakukan sesuatu yang lain atau bagaimana Fitur B hampir sampai, tetapi kemudian jauh dari harapan. Itu sempurna! Pengguna uji Anda akan memberi tahu Anda apa yang mereka inginkan dari produk Anda. Dapatkan umpan balik yang cukup konsisten dan Anda akan memiliki daftar fitur yang harus dimiliki yang perlu muncul di versi aplikasi berikutnya.

Mereka baik-baik saja dengan itu, tapi tidak menyukainya ... belum.

Sekali lagi, tidak apa-apa jika pengguna tidak 100% senang dengannya. Anda telah memberi mereka kesempatan untuk mencoba produk yang akan menjadi luar biasa dan mereka melihat janji di dalamnya. Beri mereka kesempatan untuk mengungkapkan pikiran mereka dan beri tahu Anda apa yang mereka sukai dan apa yang tidak mereka sukai. Kemudian, fokuslah untuk memperkuat titik-titik lemah itu dan memasukkan fitur-fitur yang akan menjadikannya pengubah permainan yang nyata.

Mereka akan menyukainya apa adanya.

Jujur saja, ini tidak mungkin terjadi. Tapi bukankah lebih bagus jika umpan balik sangat langka sehingga Anda bisa bermain dengan MVP apa adanya? Plus, pikirkan semua waktu yang Anda hemat sendiri dan uang yang Anda hemat klien Anda dengan memotong produk kembali begitu banyak. Terkadang lebih sederhana lebih baik.

Jangan lupa untuk berterima kasih kepada para pengguna ini atas umpan balik dan dukungan mereka terhadap produk. Tidak mungkin Anda dapat membuat solusi yang mereka butuhkan tanpa wawasan mereka, jadi sebaiknya Anda mengenali peran yang mereka mainkan dalam hal ini. Sebagai imbalannya, mereka akan terus menjadi penginjil produk Anda lama setelah diluncurkan.

5. Rancang Halaman Arahan Anda Lebih Awal

Meskipun saya tidak terlalu tertarik pada halaman arahan atau situs web mini yang hanya berfungsi sebagai MVP (karena alasan yang disebutkan di atas), saya pikir itu ide yang baik untuk mendapatkan halaman arahan pertama seluler saat MVP sedang bekerja .

Aplikasi game dan SaaS akan menjadi pilihan yang sangat baik untuk meluncurkan halaman pendaftaran beta lebih awal. Berikut ini contoh dari Hytale:

Aplikasi game Hytale
Aplikasi game Hytale menggunakan halaman arahannya untuk mendidik pengguna tentang game dan mendapatkan pengguna beta sebelum diluncurkan. (Sumber: Hytale) (Pratinjau besar)

Jika Anda ingin MVP Anda berhasil, Anda harus meluangkan waktu ekstra yang Anda miliki sekarang untuk membangun halaman arahan yang kuat. Mulailah dengan meneliti situs web awal dari perusahaan yang ditampilkan dalam posting ini. Mereka semua berhasil menjelaskan konsep mereka, memasarkan produk mereka dengan lembut, dan meyakinkan pengguna awal untuk mendaftar untuk pengujian.

Saat melakukannya, Anda juga harus mengatur blog, akun media sosial, dan fitur komunitas (dengan buletin aktif). Kau tak pernah tahu. Seseorang mungkin menemukan pengumuman MVP Anda di tempat lain selain pencarian Google dan memutuskan mereka ingin mem-bookmark situs atau mendaftar lebih awal untuk menjadi penguji beta.

Tidak pernah terlalu dini untuk mulai mendapatkan dukungan dari set pengguna Anda!

6. Tentukan Kriteria Sukses Anda

Last but not least, Anda harus memutuskan bagaimana Anda akan mengukur keberhasilan MVP Anda. Karena ini bukan hanya tentang kualitas umpan balik.

Pertimbangkan hal berikut:

  • Berapa banyak pengunjung yang mengunjungi halaman arahan Anda?
  • Berapa banyak dari orang-orang yang mendaftar untuk beta?
  • Berapa banyak pengguna yang Anda pertahankan selama periode tertentu (1 bulan, 3 bulan, dll.)?
  • Berapa banyak orang yang memberikan umpan balik dan apakah itu cukup substansial untuk membuat keputusan yang solid tentang desain produk dan fitur ke depan?
  • Apakah demografi set pengguna Anda cocok dengan audiens yang Anda rancang aplikasinya? Menurut Anda mengapa demikian?
  • Berapa lama rata-rata waktu yang dihabiskan pengguna di dalam aplikasi?
  • Fitur mana yang paling sering mereka gunakan? Sangat sedikit?
  • Fitur mana yang menerima umpan balik paling baik? Sangat sedikit?
  • Apakah ada pengguna tertentu yang memiliki pengalaman positif dengan produk? Apa yang membuat mereka berbeda?

Ambil semua informasi yang Anda kumpulkan — dari halaman arahan asli, penguji beta, data penggunaan, dan sebagainya — dan periksa semuanya dengan seksama. Apa yang dikatakannya tentang MVP yang telah Anda rancang? Dan, sekarang, apa yang akan Anda lakukan dengannya?

Apakah Anda akan membiarkannya apa adanya atau membuatnya menjadi produk lengkap yang diinginkan dan diinginkan pengguna?

Apakah akan mudah untuk menarik dan mendapatkan pelanggan berdasarkan data penggunaan yang Anda kumpulkan? Terlebih lagi, apakah Anda dapat mempertahankan pengguna tersebut atau lebih hemat biaya untuk mempertahankan sisi browser aplikasi Anda daripada dalam bentuk aplikasi asli?

Dan, akhirnya, berapa banyak yang dapat dan harus Anda kenakan untuk akses ke produk? Apakah pada akhirnya akan membuat perusahaan menguntungkan atau tidak ada cukup minat (setidaknya di sisi monetisasi) untuk menjadikan ini usaha yang bermanfaat?

Saya tahu saya meninggalkan banyak pertanyaan untuk Anda, tetapi ada banyak hal yang harus Anda selesaikan begitu tes dimulai. Plus, itulah alasan utama Anda membuat MVP. Umpan balik pengguna ini sangat berharga untuk proses dan merupakan satu-satunya cara Anda akan tahu apakah itu produk yang layak didorong ke pasar atau dibawa kembali ke papan gambar.