Membangun dengan empati pelanggan

"Kebutuhan adalah induk penemuan." Pepatah ini menangkap ketidaklayakan roh manusia dan dorong alami kita untuk menciptakan. Seperti yang dijelaskan dalam Kamus Bahasa Inggris Oxford, "Ketika kebutuhan akan sesuatu menjadi penting, Anda dipaksa untuk menemukan cara mendapatkan atau mencapainya." Hanya sedikit yang akan menyangkal kebenaran universal tentang penemuan ini. Namun, seperti yang dijelaskan artikel Inovasi dalam ekonomi digital , inovasi cloud membutuhkan keseimbangan antara penemuan dan adopsi.

Jika kita melanjutkan dengan analogi, inovasi berasal dari keluarga yang lebih luas. Empati pelanggan adalah orang tua inovasi yang bangga. Untuk menciptakan solusi empati pelanggan, yang mendorong inovasi, membutuhkan kebutuhan pelanggan yang sah yang membuat mereka kembali untuk menyelesaikan tantangan penting. Solusi ini didasarkan pada apa yang dibutuhkan pelanggan daripada keinginan atau keinginan. Untuk menemukan kebutuhan pelanggan yang sebenarnya, mulailah dengan empati dan pemahaman mendalam tentang pengalaman pelanggan. Empati merupakan keterampilan yang kurang dikembangkan bagi banyak insinyur, manajer produk, dan bahkan pemimpin bisnis. Untungnya, interaksi yang beragam dan kecepatan cepat peran arsitek cloud menumbuhkan keterampilan ini.

Bagaimana Anda membangun empati dan mengapa empati pelanggan begitu penting? Empati pelanggan membantu Anda memahami dan berbagi dalam pengalaman pelanggan. Dari rilis pertama produk layak minimum (MVP), hingga ketersediaan umum solusi tingkat pasar, empati pelanggan membantu Anda membangun solusi yang lebih baik. Lebih penting lagi, empati lebih baik menempatkan tim untuk menciptakan solusi yang mendorong adopsi. Dalam ekonomi digital, tim produk yang paling mudah berempati dengan kebutuhan pelanggan dapat membangun masa depan yang lebih cerah dengan alat yang lebih baik yang mendefinisikan kembali dan memimpin pasar.

Menentukan asumsi untuk dibangun dengan empati pelanggan

Mendefinisikan asumsi adalah bagian mendasar dari perencanaan. Semakin Anda merencanakan, semakin jelas Anda dapat melihat asumsi Anda merayap ke fondasi ide hebat. Asumsi biasanya merupakan produk dari empati diri. Dengan kata lain, apa yang saya inginkan jika saya berada di posisi ini? Ketika Anda mulai dengan fase build, itu meminimalkan periode di mana asumsi dapat menyerbu solusi. Pendekatan ini juga mempercepat umpan balik dengan pelanggan nyata, memicu peluang lebih awal untuk belajar dan mempertajam empati.

Perhatian

Mendefinisikan dengan benar apa yang harus dibangun bisa rumit dan membutuhkan beberapa latihan. Jika Anda membangun sesuatu terlalu cepat, itu mungkin tidak mencerminkan kebutuhan pelanggan. Jika Anda menghabiskan terlalu banyak waktu untuk mencoba memahami kebutuhan pelanggan awal dan persyaratan solusi, pasar mungkin memenuhinya sebelum Anda memiliki kesempatan untuk membangun apa pun. Dalam kedua skenario, kesempatan untuk belajar dapat secara signifikan tertunda atau berkurang. Terkadang data bahkan bisa rusak.

Solusi paling inovatif dalam sejarah dimulai dengan keyakinan intuitif. Firasat itu berasal dari keahlian yang ada dan pengamatan langsung. Mulailah dengan fase build karena memungkinkan tes cepat intuisi Anda. Dari sana, Anda dapat membudayakan pemahaman yang lebih dalam dan tingkat empati yang lebih jelas. Pada setiap perulangan atau rilis solusi, keseimbangan berasal dari membangun MVP yang menunjukkan empati pelanggan.

Untuk mempertahankan tindakan penyeimbangan ini, dua bagian berikut menjelaskan konsep cara membangun dengan empati dan mendefinisikan MVP.

Menentukan hipotesis yang berfokus pada pelanggan

Ketika Anda membangun dengan empati, itu berarti Anda membuat solusi berdasarkan hipotesis yang ditentukan yang menggambarkan kebutuhan pelanggan tertentu. Langkah-langkah berikut merumuskan hipotesis yang mendorong membangun dengan empati.

1. Ketika Anda membangun menggunakan empati, pelanggan selalu menjadi fokus. Niat tersebut dapat bermacam-macam bentuknya. Anda dapat merujuk arketipe pelanggan, persona tertentu, atau bahkan gambar pelanggan di tengah masalah yang ingin Anda pecahkan. Dan perlu diingat bahwa pelanggan dapat internal (karyawan atau mitra) atau eksternal (konsumen atau pelanggan bisnis). Definisi ini adalah hipotesis pertama bagi Anda untuk menguji: dapatkah kami membantu pelanggan khusus ini?
2. Pahami pengalaman pelanggan. Membangun dengan empati berarti Anda dapat terhubung dengan pengalaman pelanggan dan memahami tantangan mereka. Pola pikir ini menunjukkan hipotesis berikutnya yang akan diuji: dapatkah kita membantu pelanggan khusus ini terkait tantangan yang dapat dikelola ini?
3. Tentukan solusi yang jelas untuk satu tantangan. Jika Anda mengandalkan keahlian di seluruh orang, proses, dan pakar subjek, itu dapat menyebabkan solusi potensial. Hipotesis penuh yang akan diuji adalah: dapatkah kami membantu pelanggan khusus ini dengan tantangan yang dapat dikelola ini melalui solusi yang diusulkan?
4. Sampai pada pernyataan nilai. Nilai jangka panjang apa yang ingin Anda berikan kepada pelanggan ini? Jawaban atas pertanyaan ini menciptakan hipotesis lengkap Anda: bagaimana kehidupan pelanggan ini akan menjadi lebih baik dengan menggunakan solusi yang diusulkan untuk mengatasi tantangan yang dapat dikelola ini?

Langkah terakhir ini adalah puncak dari hipotesis berbasis empati pelanggan. Ini mendefinisikan audiens, masalah, solusi, dan metrik di mana perbaikan harus dilakukan, yang semuanya berpusat pada pelanggan. Selama fase pengukuran dan pembelajaran, Anda harus menguji setiap hipotesis. Antisipasi perubahan pada pelanggan, pernyataan masalah, atau solusi saat tim mengembangkan empati yang lebih besar untuk basis pelanggan yang dapat diatasi.

Perhatian

Tujuannya adalah untuk membangun berdasarkan empati pelanggan, bukan untuk merencanakannya. Terlalu mudah untuk terjebak dalam siklus perencanaan dan penyesuaian tanpa akhir untuk mencapai pernyataan empati pelanggan yang sempurna. Sebelum Anda mencoba mengembangkan pernyataan seperti itu, tinjau bagian berikut tentang mendefinisikan dan membangun MVP.

Setelah Anda membuktikan asumsi inti, perulangan kemudian berfokus pada pengujian pertumbuhan selain tes empati. Setelah Anda membangun, menguji, dan memvalidasi empati, Anda mulai memahami pasar yang dapat diatasi dalam skala besar. Anda dapat lebih memahami pasar yang dapat diatasi dengan memperluas rumus hipotesis standar yang dijelaskan sebelumnya. Kemudian, berdasarkan data yang tersedia, perkirakan ukuran total pasar (jumlah calon pelanggan).

Dari sana, perkirakan persentase total pasar yang mengalami tantangan serupa dan karenanya mungkin tertarik dengan solusinya. Anda kemudian memiliki pasar yang dapat diatasi. Hipotesis berikutnya yang akan diuji adalah: bagaimana x% kehidupan pelanggan akan ditingkatkan dengan menggunakan solusi yang diusulkan untuk mengatasi tantangan yang dapat dikelola ini? Pengambilan sampel kecil pelanggan mengungkapkan indikator terkemuka yang menyarankan efek persentase pada kumpulan pelanggan yang terlibat.

Menentukan solusi untuk menguji hipotesis

Selama setiap iterasi perulangan umpan balik bangun-ukur-pelajari, upaya Anda untuk membangun dengan empati ditentukan oleh MVP.

MVP adalah unit usaha terkecil (penemuan, teknik, pengembangan aplikasi, atau arsitektur data) yang diperlukan guna menciptakan cukup solusi untuk belajar dengan pelanggan. Tujuan dari setiap MVP adalah untuk menguji beberapa atau semua hipotesis sebelumnya dan untuk menerima umpan balik langsung dari pelanggan. Outputnya bukan aplikasi yang indah dengan semua fitur yang diperlukan untuk mengubah industri Anda. Output yang diinginkan dari setiap perulangan adalah kesempatan belajar, kesempatan untuk lebih mendalam menguji hipotesis.

Timeboxing adalah cara standar untuk memastikan produk tetap ramping. Misalnya, konfirmasikan bahwa tim pengembangan Anda berpikir solusi dapat dibuat dalam satu iterasi untuk memungkinkan pengujian cepat. Untuk lebih memahami cara menggunakan kecepatan, perulangan, dan rilis untuk menentukan apa arti minimal, lihat Merencanakan kecepatan, perulangan, rilis, dan jalur perulangan.

Mengurangi kompleksitas dan menunda lonjakan teknis

Disiplin penemuan yang dijelaskan dalam Metodologi inovasi mengeksplorasi fungsionalitas yang sering diperlukan untuk memberikan inovasi matang atau solusi MVP siap skala. Gunakan disiplin ilmu ini sebagai panduan jangka panjang untuk inklusi fitur. Demikian juga, gunakan disiplin tersebut sebagai panduan peringatan selama pengujian awal nilai dan empati pelanggan dalam solusi Anda.

Luasnya fitur dan berbagai disiplin penemuan tidak semuanya dapat dibuat dalam satu perulangan. Mungkin diperlukan beberapa rilis bagi solusi MVP untuk menyertakan kompleksitas berbagai disiplin ilmu. Tergantung pada investasi dalam pengembangan, mungkin ada beberapa tim paralel yang bekerja dalam disiplin ilmu yang berbeda untuk menguji beberapa hipotesis. Meskipun cerdas untuk menjaga keselarasan arsitektur antara tim-tim tersebut, tidak bijaksukan untuk mencoba membangun solusi yang kompleks dan terintegrasi sampai Anda dapat memvalidasi hipotesis nilai.

Anda mendeteksi kompleksitas yang terbaik dalam frekuensi atau volume lonjakan teknis. Lonjakan teknis adalah upaya untuk menciptakan solusi teknis yang tidak dapat dengan mudah diuji dengan pelanggan. Ketika nilai pelanggan dan empati pelanggan tidak terujar, lonjakan teknis mewakili risiko terhadap inovasi, dan harus diminimalkan. Untuk jenis solusi yang telah teruji matang yang ditemukan dalam upaya migrasi, lonjakan teknis dapat secara umum terjadi selama adopsi. Tetapi mereka menunda pengujian hipotesis dalam upaya inovasi dan Anda harus menundanya jika memungkinkan.

Pendekatan penyederhanaan tanpa henti membantu definisi MVP apa pun. Pendekatan ini berarti Anda menghapus apa pun yang tidak membantu kemampuan Anda untuk memvalidasi hipotesis. Untuk meminimalkan kompleksitas, kurangi jumlah integrasi dan fitur yang tidak diperlukan untuk menguji hipotesis.

Membangun MVP

Pada setiap iterasi, solusi MVP dapat bermacam-macam bentuknya. Persyaratan umumnya hanyalah output memungkinkan untuk pengukuran dan pengujian hipotesis. Persyaratan sederhana ini memulai proses ilmiah dan memungkinkan tim membangun dengan empati. Untuk memberikan fokus yang mengutamakan pelanggan ini, MVP awal mungkin hanya mengandalkan salah satu disiplin penemuan.

Dalam beberapa kasus, jalur tercepat untuk inovasi berarti untuk sementara menghindari disiplin ilmu ini sepenuhnya, sampai tim adopsi cloud yakin bahwa hipotesis divalidasi secara akurat. Dari perusahaan teknologi seperti Microsoft, panduan ini mungkin terdengar kontraintuitif. Tetapi menekankan bahwa kebutuhan pelanggan, bukan keputusan teknologi tertentu, adalah prioritas tertinggi dalam solusi MVP.

Biasanya, solusi MVP terdiri dari aplikasi atau solusi data dengan fitur minimal dan polesan terbatas. Untuk organisasi yang memiliki keahlian pengembangan profesional, jalur ini seringkali yang tercepat untuk pembelajaran dan perulangan. Daftar berikut mencakup beberapa pendekatan lain yang mungkin dilakukan tim untuk membangun MVP:

• Algoritma prediktif yang salah 99 persen tetapi itu menunjukkan hasil spesifik yang diinginkan.
• Perangkat IoT yang tidak berkomunikasi dengan aman dalam skala produksi tetapi menunjukkan nilai data yang hampir real-time dalam suatu proses.
• Aplikasi yang dibangun oleh pengembang warga negara untuk menguji hipotesis atau memenuhi kebutuhan skala kecil.
• Proses manual yang menciptakan kembali manfaat aplikasi untuk diikuti.
• Bingkai kawat atau video yang cukup rinci untuk memungkinkan pelanggan berinteraksi.

Mengembangkan MVP seharusnya tidak memerlukan investasi pengembangan dalam jumlah besar. Sebaiknya, Anda membatasi investasi sebanyak mungkin untuk meminimalkan jumlah hipotesis yang sedang diuji pada satu waktu. Kemudian, dalam setiap perulangan dan dengan setiap rilis, Anda sengaja meningkatkan solusi menuju solusi siap skala Anda yang mewakili beberapa disiplin penemuan.

Mempercepat pengembangan MVP

Waktu ke pasar sangat penting untuk keberhasilan inovasi apa pun. Rilis yang lebih cepat mengarah pada pembelajaran yang lebih cepat. Pembelajaran yang lebih cepat mengarah pada produk yang dapat menskalakan lebih cepat. Kadang-kadang, siklus pengembangan aplikasi tradisional dapat memperlambat proses ini. Lebih sering, inovasi dibatasi oleh batasan pada keahlian yang tersedia. Anggaran, headcount, dan ketersediaan staf semuanya dapat menciptakan batasan jumlah inovasi baru yang dapat ditangani tim.

Kendala kepegawaian dan keinginan untuk membangun dengan empati memunculkan tren yang berkembang pesat terhadap pengembang warga. Pengembang ini mengurangi risiko dan memberikan skala dalam komunitas pengembangan profesional organisasi. Pengembang warga adalah pakar subjek dalam pengalaman pelanggan, tetapi mereka tidak dilatih sebagai insinyur. Orang-orang ini menggunakan alat prototyping atau alat pengembangan yang lebih ringan yang mungkin tidak disukai oleh pengembang profesional. Pengembang yang selaras dengan bisnis ini menciptakan solusi MVP dan menguji teori. Ketika diselaraskan dengan baik, proses ini menciptakan solusi produksi yang memberikan nilai tetapi tidak melewati hipotesis skala yang cukup efektif. Teams juga dapat menggunakan solusi untuk memvalidasi prototipe sebelum upaya skala dimulai.

Dalam rencana inovasi apa pun, tim adopsi cloud harus mendiversifikasi portofolio mereka untuk menyertakan upaya pengembang warga negara. Dengan menskalakan upaya pengembangan, Anda dapat membentuk dan menguji lebih banyak hipotesis dengan investasi yang berkurang. Ketika Anda memvalidasi hipotesis dan mengidentifikasi pasar yang dapat diatasi, pengembang profesional kemudian dapat mengeras dan menskalakan solusi dengan menggunakan alat pengembangan modern.

Gerbang pembangunan akhir: Permasalahan pelanggan

Ketika empati pelanggan kuat, masalah yang jelas ada seharusnya mudah diidentifikasi. Permasalahan pelanggan harus jelas. Selama build, tim adopsi cloud sedang mengerjakan solusi untuk menguji hipotesis berdasarkan titik nyeri pelanggan. Jika hipotesis didefinisikan dengan baik tetapi titik rasa sakitnya tidak, solusinya tidak benar-benar didasarkan pada empati pelanggan. Dalam skenario ini, build bukanlah titik awal yang tepat. Sebaliknya, berinvestasi terlebih dahulu dalam membangun empati dan belajar dari pelanggan nyata. Pendekatan terbaik untuk membangun empati dan memvalidasi rasa sakit adalah mudah: dengarkan pelanggan Anda. Luangkan waktu untuk bertemu dan mengamati mereka sampai Anda dapat mengidentifikasi titik permasalahan yang sering terjadi. Setelah Anda memahami titik nyeri pelanggan dengan baik, Anda siap untuk menguji solusi hipotesis untuk mengatasi rasa sakit itu.

Kapan waktu untuk tidak menerapkan pendekatan ini

Ada banyak persyaratan hukum, kepatuhan, dan industri yang mungkin memerlukan pendekatan alternatif. Pendekatan ini mungkin tidak cocok jika rilis publik dari solusi pengembangan:

• Menciptakan risiko terhadap waktu paten, perlindungan kekayaan intelektual, atau kebocoran data pelanggan
• Melanggar persyaratan kepatuhan yang ditetapkan

Ketika risiko yang dirasakan ini ada, konsultasikan dengan penasihat hukum sebelum mengadopsi pendekatan terpandu untuk merilis manajemen.

Referensi

Beberapa konsep dalam artikel ini dibangun berdasarkan ide yang dibahas oleh The Lean Startup Eric Ries.

Langkah berikutnya

Setelah Anda membangun solusi MVP, Anda dapat mengukur nilai empati dan nilai skala. Pelajari cara mengukur dampak pelanggan.

Mengukur dampak pelanggan