Cara Menentukan Lingkup MVP dalam 3 Jam

Ketika saya dibawa sebagai manajer produk oleh perusahaan pemrosesan pembayaran tahap awal, bisnis tersebut berjuang untuk membuat dan memberikan sistem manajemen inventaris secara tepat waktu. Solusinya adalah aplikasi keypad sederhana yang tidak ramah pengguna dan, akibatnya, menyebabkan churn pelanggan yang signifikan. Tugas saya adalah memimpin tim yang ditugasi membangun sistem inventaris yang akan memperluas kemampuan aplikasi di luar fungsi keypad.

Karena kami harus beroperasi pada garis waktu yang terpotong, saya membuat pendekatan yang sederhana namun sangat efisien untuk menyusun, merancang, dan membangun produk yang layak minimum (MVP) dengan fitur inti yang sesuai dengan apa yang dicari pengguna kami. Proses tersebut memadatkan pelingkupan MVP menjadi satu sesi tiga jam intensif—bukan berhari-hari atau berminggu-minggu—dan menghemat waktu berbulan-bulan tim kami dalam pengembangan.

Proses pelingkupan MVP yang dipercepat ini dapat digunakan untuk memandu tim produk mana pun dan dapat diterapkan pada pembuatan produk zero-to-one apa pun.

Ikhtisar Kasus Penggunaan

Masalah: Fungsionalitas keypad aplikasi yang sederhana tidak memberi pengguna, yang merupakan vendor, kemampuan untuk mengelola inventaris atau memilih item untuk ditambahkan ke pesanan pelanggan.

Kendala: Pimpinan perusahaan menginginkan solusi disampaikan dalam delapan minggu; putaran penggalangan dana yang potensial bergantung, sebagian, pada keberhasilan versi produk yang lebih baik.

Konteks: Dari analisis pasar, dan setelah menghabiskan waktu dengan banyak pengguna kami, saya memutuskan bahwa vendor ini memerlukan sistem manajemen inventaris untuk merampingkan aliran penjualan mereka. Saya melihat mereka memproses pesanan pelanggan: Pertama, mereka menulis item yang diminta di selembar kertas, menggunakan kalkulator untuk menghitung item, dan kemudian memasukkan pesanan ke dalam aplikasi. Mereka menggunakan tiga alat ketika mereka seharusnya hanya membutuhkan satu.

Solusi: Kami perlu mengembangkan solusi yang memungkinkan pengguna memuat inventaris mereka ke dalam katalog digital, mengelola inventaris tersebut, dan mengetuk item yang dipilih untuk menambahkannya ke keranjang belanja pelanggan—semuanya dalam aplikasi.

Keputusan Desain Sprint

Karena kami sudah tahu produk apa yang perlu kami kembangkan, saya memilih untuk tidak mengikuti sprint desain biasa—lokakarya empat hingga lima hari di mana tim berkolaborasi untuk mengidentifikasi tantangan bisnis utama, mengumpulkan ide dari pelanggan tentang cara memecahkan masalah, mengembangkan konsep untuk suatu produk, merancang prototipe, dan mulai mengujinya.

Sprint desain adalah metode yang efektif untuk membangun MVP—bagi mereka yang perlu mengidentifikasi masalah inti dan yang memiliki waktu yang cukup untuk mengembangkan solusi. Namun, pada perusahaan tahap awal atau unit bisnis baru di organisasi yang ada, masalah inti biasanya terlihat: Konsep telah dikembangkan, dan kesesuaian produk/pasar biasanya telah ditentukan sebelum manajer produk, insinyur, dan desainer dibawa masuk.

Bagan alur berikut menguraikan langkah-langkah yang saya ambil ketika memutuskan bahwa cara terbaik untuk melanjutkan proyek ini adalah dengan melewatkan sprint desain dan mulai dengan sesi tiga jam, yang juga dikenal sebagai kickoff tim. Dalam pertemuan itu, peserta akan melakukan brainstorming dan menghasilkan lusinan ide untuk fitur, dan kemudian mengelompokkan daftar hanya untuk apa yang diperlukan untuk MVP.

Proses Pengembangan MVP

Persiapan

Sebelum sesi tiga jam, Anda akan ingin mengumpulkan informasi tentang persona pengguna Anda dengan berbicara dan mengamati pelanggan saat ini atau calon pelanggan dan melakukan riset pasar.

Kemudian, buat presentasi untuk para desainer dan insinyur. Ini harus menjelaskan:

• Masalah yang Anda coba pecahkan.
• Produk yang sedang Anda buat.
• Bagaimana produk akan menyelesaikan masalah itu baik dari segi metrik maupun UX.
• Dampak produk yang diprediksi pada bisnis Anda dan klien Anda.
• Misi dan tujuan dan hasil utama (OKR) tingkat perusahaan dan tim, serta bagaimana produk membantu menyelesaikan misi tersebut dan mencapai OKR tersebut.

Presentasi harus memberi para desainer dan insinyur pemahaman yang kuat tentang produk untuk melanjutkan pelingkupan MVP.

Kickoff Meeting Tiga Jam

Kickoff harus melibatkan seluruh tim pengembangan, memungkinkan mereka untuk berpartisipasi dalam setiap tahap proses, mulai dari pembuatan ide dan cerita hingga pengembangan konsep MVP. Ini termasuk manajer produk senior, junior, dan rekanan; pemilik produk; prospek produk (jika berlaku); desainer UX; insinyur perangkat lunak; dan insinyur QA.

Kiat cepat: Meskipun tidak ortodoks, saya sarankan menyertakan insinyur sebelum tahap pembangunan. Mereka biasanya memberikan ide-ide hebat dan memiliki hasrat untuk produk yang mereka coba tingkatkan. Sebagian besar dari mereka senang terlibat dalam pelingkupan MVP; itu membantu mereka menjadi lebih berinvestasi dalam proyek dan dihargai oleh tim lain.

Kumpulkan semua orang di ruang konferensi atau ruang kerja virtual. Dalam kasus kami, kami memiliki 10 orang. Blokir tiga jam.

Produk dan perjalanan pengguna (60 menit)

1. Menyampaikan presentasi. (15 menit)

2. Mulailah mengidentifikasi semua persona pengguna untuk produk Anda. Meskipun Anda belum mengidentifikasi alur atau fitur kerja apa pun, Anda dapat menentukan jumlah alur yang perlu dibuat. (10 menit)

   Kiat cepat: Jangan merekayasa berlebihan dengan menambahkan lebih banyak persona daripada yang diperlukan. Setelah rilis MVP, umpan balik pelanggan akan mengungkapkan apakah Anda memerlukan peran tambahan.

   Contoh kasus penggunaan: Kami memiliki tiga persona: manajer toko (atau admin), kasir, dan pelanggan akhir. Ada potensi persona tingkat senior lainnya, seperti pemilik toko, tetapi untuk tujuan MVP, itu bisa ditanggung oleh admin.

3. Petakan perjalanan pengguna dari awal hingga akhir. Tetapkan warna untuk setiap persona untuk membantu mengidentifikasi setiap langkah aliran yang akan dihadapi pengguna. Untuk pertemuan langsung, tempelkan catatan tempel di dinding atau gunakan papan tulis. Untuk rapat virtual, gunakan papan FigJam atau yang serupa. (35 menit)

   Kiat cepat: Mintalah tim membagikan semua ide mereka—dan menjadi lebih terperinci. Setiap langkah alur akan menjadi fitur yang akan dibangun—dan setiap pengguna akan memiliki alur terpisah—tetapi proses menguraikan langkah-langkahnya akan sama.

   Contoh kasus penggunaan: Berikut daftar fitur untuk persona kasir kami:

   • Buka aplikasi tempat penjualan.
   • Masuk menggunakan PIN.
   • Identifikasi item pertama untuk pembelian pelanggan.
   • Mengidentifikasi jumlah item.
   • Identifikasi item tambahan untuk pembelian pelanggan.
   • Tambahkan diskon pada item (jika ada).
   • Total biaya semua item dalam keranjang belanja (pada titik ini, harga pembelian penuh, termasuk pajak penjualan, ditampilkan).
   • Selesaikan proses checkout dan pembayaran.
   • Konfirmasi pembelian.
   • Izinkan pelanggan untuk menambahkan tip.
   • Tutup penjualan.
   • Tampilkan total semua penjualan harian.
   • Dapatkan waktu habis setelah periode tidak aktif yang telah ditentukan (misalnya, lima menit).

   Catatan: Daftar ini merinci sebagian besar fitur yang kami pikirkan untuk persona ini. Kami datang dengan sekitar 60 fitur total di semua persona, dengan tumpang tindih minimal, sebagai kasir, manajer toko, dan pelanggan akhir semua terlibat dengan aplikasi dengan cara yang berbeda. Bergantung pada jenis produk yang Anda kembangkan, mungkin ada lebih banyak fitur yang tumpang tindih di antara jenis pengguna.

   

Fitur penting dari perjalanan pengguna (45 menit)

1. Kelompokkan fitur untuk setiap jenis pengguna ke dalam bagian terpisah dari setiap perjalanan pengguna di papan tulis nyata atau virtual. Kemudian, gambar garis horizontal di papan tulis. Di atas garis, identifikasi set yang diperlukan agar produk berfungsi. Di bawah garis, tempatkan fitur yang bagus untuk dimiliki tetapi dapat menunggu hingga rilis nanti. (30 menit)

   Kiat cepat: Bagi desainer dan insinyur menjadi beberapa kelompok untuk menyelesaikan langkah ini, lalu berkumpul kembali untuk membandingkan catatan. Ini sangat membantu dalam pertemuan 10 orang atau lebih.

   Contoh kasus penggunaan: Untuk aplikasi kami, kami memiliki 12 set fitur pada saat ini, yang mencakup memuat item ke dalam katalog inventaris, menetapkan harga, memilih item untuk ditambahkan ke keranjang pelanggan, memeriksa dan menutup penjualan, memesan ulang inventaris rendah, dan banyak lagi. Kami akhirnya mengurangi jumlah set fitur menjadi empat.

   Proses eliminasi ini membantu kami menentukan bahwa login keamanan pengguna tidak diperlukan dalam iterasi pertama aplikasi. Baik itu menambahkan diskon atau tip. Kami juga memutuskan bahwa kasir tidak perlu menunjukkan total semua penjualan harian sebagai bagian dari MVP, meskipun manajer toko atau pemilik mungkin.

2. Perbaiki daftar fitur. Tanyakan “Jika ini dihilangkan, apakah produk akan tetap berfungsi?” Jika jawabannya ya, tinggalkan fitur itu dari MVP—simpan untuk iterasi produk selanjutnya. Jika jawabannya tidak, Anda harus memasukkan fitur tersebut ke dalam MVP. Di akhir proses ini, Anda akan tahu apa yang benar-benar diperlukan untuk membuat produk Anda berfungsi. Seringkali, ini hanya terdiri dari tiga atau empat fitur untuk setiap set. (15 menit)

   Catatan: Hindari membangun terlalu banyak set fitur ke dalam MVP. Meskipun Anda harus mengantisipasi perbedaan pendapat tentang apa yang paling penting untuk disertakan, tugas Anda sebagai manajer produklah yang menelepon. Anda telah melakukan riset dan memiliki data untuk mendukung keputusan Anda. Dalam pengalaman saya, banyak produk pada awalnya dibuat lebih kuat dari yang seharusnya, dan sebagian besar perusahaan lebih memilih untuk mendapatkan sesuatu ke tangan pengguna untuk pengujian dan umpan balik secepat mungkin.

Desain, pengujian, dan rekayasa produk (75 menit)

1. Mintalah para desainer mengintegrasikan fitur inti ke dalam desain wireframe MVP, yang akan digunakan para insinyur untuk membangun arsitektur produk. (45 menit)

2. Izinkan spesialis produk dan desainer untuk bekerja sama dalam beberapa pengujian UX ringan dari desain wireframe. (15 menit)

   Catatan: Ada sangat sedikit skenario manajemen produk di mana Anda harus membangun tanpa melibatkan pelanggan akhir, tetapi dalam kasus pengujian dan pengembangan cepat, Anda dapat menguji prototipe desain secara internal atau dengan teman dan keluarga yang tidak mengetahui produk Anda. Jika mereka bingung, beberapa pengguna Anda juga akan bingung.

3. Berikan gambar rangka yang dirancang kepada para insinyur agar mereka dapat mulai membangun arsitektur MVP. Mereka tidak akan memiliki semua yang mereka butuhkan—atau waktu—untuk membangun solusi lengkap, tetapi mereka dapat memulai, dan arsitektur yang mereka bangun akan digunakan saat menyelesaikan MVP. Sementara itu, tim produk dan desain dapat melanjutkan pengujian pada wireframe mereka dengan anggota tim internal atau teman dan keluarga yang bertindak sebagai pengguna. Membuat tim bekerja secara bersamaan pada langkah ini menghemat waktu. (15 menit)

Saat Anda menjadi lebih mahir menggunakan proses ini, akan menjadi lebih mudah untuk mengidentifikasi fitur mana yang merupakan komponen inti dari MVP dan mana yang dapat dibangun nanti. Praktik ini juga akan mencegah Anda membangun hal yang salah: Anda mungkin memiliki sesuatu dalam pikiran untuk daftar "nanti", hanya untuk kemudian mengetahui bahwa tidak ada pelanggan yang menginginkannya.

Hasil dan Takeaways Utama

Sebelum upaya kami, aplikasi kami adalah papan tombol dengan angka 0 hingga 9, titik desimal, dan tombol pengisian daya. Karena keterbatasan ini dan alur kerja yang tidak efisien yang dibuatnya, selama setahun, retensi kami rendah—sekitar 20%. Meskipun kami memperoleh pengguna baru lebih cepat daripada pesaing kami, kami kehilangan mereka hampir sama cepatnya.

Sepanjang proses pembuatan MVP, kami membangun empat set fitur utama, yang semuanya memiliki cakupan minimal tetapi berkualitas tinggi. Seorang pengguna sekarang dapat:

1. Muat item ke inventaris langsung dari perangkat seluler hanya dengan menggunakan kamera, memasukkan nama, dan memasukkan harga.
2. Pilih item tersebut dan tambahkan ke keranjang belanja pelanggan.
3. Tutup penjualan sambil melihat barang yang dijual.
4. Lihat jumlah barang yang terjual dalam jangka waktu tertentu.

Pelanggan menyukai produk yang ditingkatkan. Tingkat retensi adalah 45% di antara pengguna baru yang memanfaatkan fungsionalitas katalog untuk checkout setidaknya lima kali dalam minggu pertama pemuatan item.

Berkat efisiensi proses pelingkupan MVP kami, kami membangun dan mengirimkan aplikasi kami yang telah selesai sepenuhnya dalam waktu sekitar dua bulan. Proses itu kemungkinan akan memakan waktu empat bulan atau lebih dengan pendekatan pengembangan tradisional—jika produk itu benar-benar dibuat.

Proses yang dipercepat ini menghemat waktu dan uang. Sprint desain penuh bisa mahal. Dimulai dengan pertemuan awal membuat proses saya lebih ekonomis sejak awal, dan penghematan tersebut diperkuat oleh garis waktu pengembangan keseluruhan yang jauh lebih pendek.

Namun, kedua proses tersebut juga dapat bekerja bersama-sama: Jika tim Anda telah menyelesaikan sprint desain untuk menentukan masalah bisnis inti dan solusi yang perlu Anda buat, Anda dapat menggunakan proses saya untuk menentukan cakupan MVP Anda dengan lebih efisien.

Ingatlah bahwa proses ini baru permulaan: MVP adalah pekerjaan yang sedang berlangsung yang akan disempurnakan lebih lanjut di rilis selanjutnya. Setelah sepenuhnya dibuat dan siap dikirim, sebaiknya tambahkan sakelar beta yang dapat dimatikan pengguna untuk kembali ke pengalaman aplikasi lama. Memanfaatkan perangkat lunak perilaku, seperti Heap, untuk melacak berapa banyak pengguna yang menggunakan opsi ini akan memberi Anda ide bagus tentang apa yang perlu ditambahkan atau diubah untuk menyempurnakan produk Anda di iterasi berikutnya.