Ikuti siklus hidup inovasi

  • 5 menit

Tailwind Traders dihadapkan dengan pertanyaan tentang inovasi yang juga memengaruhi banyak organisasi lain:

  • Bagaimana cara meningkatkan laju perubahan tanpa memengaruhi bisnis yang sedang berjalan?
  • Bagaimana kita memutuskan di mana harus berinovasi dan perubahan apa yang harus diterapkan untuk memaksimalkan pengembalian bisnis dari inovasi tersebut?

Jawaban atas kedua pertanyaan tersebut adalah: Tailwind Traders perlu merangkul perubahan sebagai bagian dari budaya organisasinya. Salah satu alasan mengapa organisasi yang menolak perubahan sering mengalami gangguan terkait perubahan adalah bahwa perubahan tersebut terlalu besar dan berdampak. Perubahan sulit diuji dalam lingkungan yang terkontrol dan realistis.

Jika proses dibuat untuk sering memperkenalkan perubahan, perubahan tersebut berukuran lebih kecil dan berisiko. Namun, proses ini tidak hanya melibatkan adopsi alat atau teknologi tertentu. Ini membutuhkan budaya yang menghargai perubahan dan menerima kegagalan.

Konsep menerima kegagalan mungkin tampak kontra intuitif, tetapi sangat penting bagi siklus inovasi. Jika orang takut gagal karena kesalahan menempatkan mereka di pusat permainan menyalahkan, mereka tidak mungkin mengejar pendekatan baru untuk memecahkan masalah karena takut kegagalan. Seluruh organisasi kemudian menjadi tahanan dari praktik yang ditetapkan.

Dimungkinkan untuk membangun budaya "gagal cepat" di mana orang didorong untuk mencoba metode baru. Mereka diberdayakan untuk dengan cepat mengubah arah jika mereka tidak mendapatkan hasil yang diharapkan, membantu menciptakan budaya inovasi yang lebih kaya.

Inovasi berbasis hipotesis

Anda dapat menggambarkan inovasi sebagai siklus berulang berbasis hipotesis. Ketika Anda mengidentifikasi adanya masalah, satu atau beberapa hipotesis dapat diformulasikan untuk berpotensi menjelaskan akar penyebab dan mengarah ke solusi. Definisi masalah itu sendiri bisa jadi menantang, karena perlu diukur.

Misalnya, definisi masalah "Pelanggan tidak senang dengan pilihan platform pembayaran kami" tidak dapat diukur, sehingga sulit untuk diselesaikan. Jika Anda dapat menentukan masalah sebagai "23 persen pelanggan meninggalkan sesi belanja mereka pada langkah memilih platform pembayaran," Anda berada dalam posisi yang lebih baik untuk mengukur keberhasilan solusi yang mungkin.

Setelah Anda mendefinisikan masalah dengan cara yang terukur, Anda dapat merumuskan hipotesis yang akan digunakan untuk menjelaskan dan menyelesaikan masalah. Misalnya, hipotesis untuk Tailwind Traders dapat dijelaskan sebagai: "Menambahkan ContosoPay ke platform pembayaran kami yang didukung akan mengurangi churn pelanggan di halaman pembayaran dari 23 persen menjadi 10 persen." Sekarang ide ada di atas meja, dan bertindak di atasnya, adalah masalah memverifikasi validitasnya.

Hipotesis harus fokus pada penambahan nilai bagi pelanggan dan meningkatkan pengalaman mereka dalam berinteraksi dengan organisasi Anda. Ide ini dikenal sebagai empati pelanggan: menempatkan pelanggan Anda di pusat inovasi Anda, dan berfokus pada peningkatan nilai bagi mereka dan untuk Anda.

Ada banyak cara untuk memvalidasi hipotesis tanpa menyentuh kode aplikasi. Survei pelanggan dan penelitian pasar adalah dua contoh sumber informasi yang berguna yang dapat membantu memutuskan validitas hipotesis. Memeriksa sumber-sumber ini memungkinkan Anda untuk memenuhi syarat hipotesis Anda, dan untuk membangun hipotesis dengan kemungkinan akurasi tertinggi dan nilai bisnis tambahan.

Bangun

Setelah hipotesis memiliki potensi nilai yang memadai untuk dibangun dalam aplikasi Anda, proses pembuatannya dimulai. Sekali lagi, kecepatan sangat penting.

Kecepatan pengembangan Anda harus sesingkat mungkin. Menjaga sprint singkat memungkinkan verifikasi cepat atau penolakan hipotesis. Ini juga berpotensi memungkinkan Anda menyempurnakan cara fungsionalitas yang diperlukan diintegrasikan ke dalam aplikasi. Hasilnya adalah siklus inovasi yang lebih cepat.

Pengukuran

Anda ingin memverifikasi keakuratan hipotesis sesegera mungkin. Produk minimum yang praktis (MVP) adalah versi awal fungsionalitas baru yang mengumpulkan umpan balik dan membantu mengkonfirmasi apakah Anda bergerak ke arah yang benar.

Tujuan MVP adalah memverifikasi tidak hanya hipotesis Anda, tetapi juga asumsi yang mungkin Anda buat. Misalnya, jika 23 persen pelanggan Tailwind Traders meninggalkan proses pembelian di halaman pembayaran, hipotesis menyatakan bahwa alasannya adalah karena perusahaan tidak menawarkan platform pembayaran yang memadai. Namun, alasannya mungkin berbeda. MVP harus dirancang untuk mengonfirmasi atau menolak asumsi dan hipotesis ini.

Pelajari

Fase belajar sama dengan awal proses. Setelah Anda mempelajari asumsi dan hipotesis lebih lanjut, Anda mungkin mendapati bahwa asumsi dan hipotesis tersebut memang benar, benar sebagian, atau salah. Memiliki pola pikir pertumbuhan dan kerendahan hati yang cukup untuk mengakui kegagalan memungkinkan Anda untuk:

  • Pivot dengan cepat jika Anda perlu terus mengerjakan MVP Anda.
  • Memfokuskan kembali upaya Anda di bidang lain dan merumuskan hipotesis alternatif.

Perlu disadari bahwa meskipun hipotesis dan asumsi Anda salah, dari proses tersebut, Anda dapat mempelajari hal baru tentang pelanggan dan bisnis Anda. Jangan menganggapnya sebagai waktu yang terbuang sia-sia. Kuncinya adalah mendapatkan pengetahuan sesegera mungkin dan menerapkannya pada hipotesis berikutnya. Ide ini adalah inti dari budaya yang gagal-cepat.

Di mana berikutnya

Ringkasan Inovasi Cloud Adoption Framework adalah referensi yang paling tepat untuk memulai eksplorasi tentang cara berinovasi.