Membangun Apa yang Pelanggan Butuhkan: Resep Utama

Menurut Clayton Christensen, seorang profesor di Harvard Business School, hampir 30.000 produk baru diperkenalkan setiap tahun, dan 95% gagal. Meskipun angka ini lebih terkait dengan produk fisik, hanya perlu sedikit usaha untuk menyadari hal ini berlaku untuk produk digital. Dan ini adalah pemikiran yang menakutkan dan mengganggu karena para pemula dan pengusaha menginvestasikan banyak uang untuk membangun produk ini. Hal ini membawa kita ke pertanyaan penting yang ditanyakan oleh setiap manajer produk dan tim teknologi terkait pada diri mereka sendiri setiap kali mereka terjun ke sungai dalam membangun produk digital. Mengapa produk gagal, dan apa yang dapat dilakukan tim untuk membuat produk yang dibutuhkan pelanggan?

Beberapa hari yang lalu, saya mengobrol dengan seorang manajer produk di salah satu perusahaan perangkat lunak terbesar saat ini. Dia telah memimpin banyak tim selama lebih dari dua tahun sekarang. Bagian paling menarik dari pengalamannya adalah dia telah melakukan lebih dari 50 eksperimen dalam dua tahun ini. Dan ini telah membantu timnya untuk memahami apa yang harus dibuat dan, yang lebih penting, apa yang tidak boleh dibuat untuk pelanggan. Saat mengobrol dengannya, saya mengerti bahwa eksperimen ini mahal dari segi modal dan waktu. Jadi, bahkan memutuskan eksperimen apa yang akan dilakukan itu sulit karena tim perlu membenarkan modal yang mereka butuhkan untuk melakukan eksperimen.

Sayangnya, hanya sedikit perusahaan yang memiliki bandwidth dan modal sebanyak ini untuk bereksperimen. Oleh karena itu, sangat penting untuk memahami apa yang dibutuhkan pelanggan dan membangun produk yang sesuai. Namun sebelum kita mendalami cara membuat produk yang dibutuhkan pelanggan, penting untuk memahami mengapa perusahaan gagal melakukannya.

Alasan Mengapa Perusahaan Gagal Membangun Produk yang Dibutuhkan Pelanggan

• Memecahkan Masalah yang Salah

Setelah diselidiki, ternyata otomatisasi dimungkinkan hanya dengan mengutak-atik sistem. Dan masalahnya bukan menggunakan "ML" untuk mengotomatiskan tugas-tugas tertentu, tetapi untuk mengotomatiskan tugas-tugas tertentu terutama karena memakan waktu. Nyatanya, setelah penelitian lebih mendalam, ternyata otomatisasi ini tidak diperlukan sama sekali. Ini dimungkinkan karena manajer produk menginvestasikan waktu untuk memahami dan mendefinisikan masalah. Dan inilah mengapa sangat penting untuk memahami masalah pada tingkat yang lebih dalam sehingga tim/perusahaan dapat menemukan masalah yang tepat untuk dipecahkan. Ini adalah langkah pertama dan terpenting, dan sebagian besar produk gagal pada langkah ini sendiri.

• Bertujuan Untuk Solusi Sempurna

Hal serupa terjadi dengan manajer produk yang saya ajak mengobrol. Dia terlibat dalam pembuatan produk yang akan sepenuhnya menggantikan sistem manajemen konten saat ini untuk sekitar 600 pengguna internal. Periode awal untuk membangun sistem ini adalah 12 bulan. Tetapi ketika tim teknik mulai mengerjakan solusinya, mereka menemukan banyak kasus sudut. Ini meningkatkan waktu dari 12 bulan menjadi 18 bulan. Saat pengguna mengetahui hal ini, mereka mulai mempertanyakan seluruh sistem manajemen konten. Maksud mereka adalah jika butuh waktu selama ini untuk membangun keseluruhan sistem, akan membutuhkan waktu yang sama, waktu yang lebih lama untuk membangun fitur baru di masa mendatang. Jadi, mereka terus mendorong lebih banyak fitur untuk ditambahkan ke ruang lingkup.

Semua ini terjadi karena tim teknologi sedang menunggu untuk membuat dan meluncurkan solusi terbaik. Manajer produk berbagi bahwa alih-alih ini, mereka seharusnya membagi sistem manajemen konten menjadi fitur minor yang lebih diprioritaskan dan merilisnya secara iteratif alih-alih satu rilis sistem besar. Untungnya, risiko pelepasan dengan cara ini lebih rendah karena sistem ini dimaksudkan untuk pengguna internal, tetapi ini bisa menjadi masalah yang lebih besar jika pengguna eksternal.

• Tidak Mendapatkan Umpan Balik Dini

Pada tanggal 30 Juni 1970, AT&T membuka selubung layanan Picturephone komersialnya di kota Pittsburgh, Pennsylvania. Dibutakan oleh visinya sendiri, eksekutif perusahaan mengabaikan umpan balik negatif yang didapat perusahaan dalam fase pengujian. Mereka percaya bahwa satu juta unit akan digunakan dalam sepuluh tahun setelah diluncurkan. Yang mengejutkan, mereka menariknya dari pasar hanya dalam tiga tahun karena kurangnya minat konsumen. Mengapa?

Selama fase uji coba, pengguna membagikan umpan balik mereka. Mereka menganggap peralatannya terlalu besar, layarnya terlalu kecil, dan mahal. Tapi semua ini diabaikan, menyebabkan kegagalan seluruh produk.

Mendapatkan umpan balik sejak awal dan mengerjakannya akan membantu Anda membangun solusi yang tepat untuk masalah pelanggan Anda.

Produk Bangunan yang Dibutuhkan Pelanggan

• Bekerja Pendekatan Mundur

• Tajuk — Ini idealnya harus menjadi nama produk dan pada dasarnya memberi tahu tentang apa produk itu
• Subpos - Manfaat inti dari produk
• Ringkasan — Ringkas apa yang dilakukan produk beserta manfaat utamanya
• Masalah — Masalah khusus yang dipecahkan oleh produk ini
• Solusi — Dengan cara apa produk memecahkan masalah
• Kutipan dari Anda — Buat juru bicara fiktif dan minta satu kalimat yang menjelaskan mengapa produk ini harus dimiliki.
• Cara memulai — Jelaskan cara menggunakan produk dengan cara termudah.
• Penutup dan ajakan bertindak — Akhiri siaran pers dengan memberi tahu pembaca cara mengetahui lebih lanjut atau mulai menggunakan produk.

• Sprint Desain

Salah satu contoh yang dibagikan oleh manajer produk adalah bagaimana sprint desain membantu timnya memutuskan antara membangun dan membeli. Timnya bertugas mengubah alur produksi konten yang mendukung 400 pengguna internal. Tugas pengguna ini adalah membuat konten (gambar, video, gif, dll.) setiap hari yang muncul di situs web untuk 50 juta pengguna aktif harian. Alur produksi konten baru dikatakan menghemat 2 juta Euro per tahun pada tahun 2020. Manajer produk mengumpulkan tim sprint yang terdiri dari beberapa pengguna, pimpinan mereka, manajer teknik, dan pimpinan desain. Sprint berlangsung selama seminggu. Di akhir sprint, tim teknologi tidak hanya memahami masalah yang dihadapi tetapi juga menghasilkan solusi berbiaya rendah yang mereka ubah menjadi produk lengkap dalam waktu 2 bulan.

• Umpan Balik Kuantitatif Dan Kualitatif

• Umpan balik kuantitatif mencakup eksperimen seperti pengujian A/B, survei dengan pertanyaan tertutup, dan analitik produk. Ini membutuhkan kemampuan analitis karena datanya besar dan dinyatakan dalam grafik dan angka.
• Umpan balik kualitatif meliputi penelitian menggunakan kuesioner dengan pertanyaan terbuka, wawancara 1:1, observasi langsung, penyelidikan kontekstual, kelompok fokus, dan pengumpulan data yang dipersonalisasi. Dibandingkan dengan umpan balik kuantitatif, ini diungkapkan dengan kata-kata.

Dengan demikian, ada banyak cara untuk memahami apa yang dibutuhkan pelanggan dan membangun solusi yang sesuai, dan itu sepenuhnya bergantung pada perusahaan dan tim untuk menggunakan salah satu metode tersebut. Namun, yang lebih penting adalah tidak membuat produk yang tidak dibutuhkan pelanggan. Sejarah mengatakan bahwa semakin awal umpan balik diambil dari pelanggan, semakin mudah membangun solusi yang tepat dan menghemat sumber daya.

Metode apa yang Anda gunakan dalam tim/perusahaan Anda untuk membangun produk/solusi yang tepat? Masalah apa yang Anda hadapi saat menggunakan metode ini? Komentar dibawah; Saya ingin tahu.