[Buku Bahasa Indonesia] The Lean Startup - Eric Ries

11. Beradaptasi

Ketika saya menjabat sebagai CTO di IMVU, sebagian besar waktu saya merasa telah melakukan pekerjaan dengan cukup baik. Saya telah membangun organisasi rekayasa yang lincah, dan kami berhasil bereksperimen dengan berbagai teknik yang kemudian dikenal sebagai Lean Startup. Namun, pada beberapa kesempatan saya tiba-tiba menyadari bahwa saya sebenarnya gagal menjalankan pekerjaan saya.

Bagi seseorang yang berorientasi pada pencapaian, pengalaman seperti itu sangat mengguncang. Yang paling buruk, Anda tidak pernah menerima memo pemberitahuan. Seandainya ada, isinya mungkin akan berbunyi seperti ini:

Dear Eric,

Selamat! Pekerjaan yang dahulu Anda lakukan di perusahaan ini sudah tidak lagi tersedia. Namun demikian, Anda telah dipindahkan ke posisi baru di perusahaan ini. Sebenarnya, ini juga bukan lagi perusahaan yang sama, meskipun namanya masih sama dan banyak orangnya masih sama. Dan walaupun jabatan Anda tetap memiliki gelar yang sama, serta Anda dulu cukup mahir menjalankan pekerjaan lama Anda, kini Anda sudah gagal dalam pekerjaan yang baru. Pemindahan ini berlaku efektif sejak enam bulan yang lalu, jadi memo ini sekadar memberi tahu bahwa Anda sebenarnya sudah cukup lama gagal menjalankannya.

Semoga beruntung!

Distributor pusat penjualan segala alat listrik tenaga surya. Toko online jual listrik tenaga matahari. Produsen Produk solar sel murah.www.tokosolarcell.net . daftar Paket harga penjualan listrik tenaga matahari

Setiap kali hal ini terjadi pada saya, saya harus berjuang keras untuk memahami apa yang seharusnya dilakukan. Saya tahu bahwa seiring pertumbuhan perusahaan, kami memerlukan proses dan sistem tambahan yang dirancang untuk mengoordinasikan operasi perusahaan pada skala yang semakin besar. Namun, saya juga telah melihat banyak startup menjadi kaku dan birokratis akibat keinginan yang keliru untuk tampak “profesional.”

Tidak memiliki sistem sama sekali bukanlah pilihan bagi IMVU, dan juga bukan pilihan bagi Anda. Ada begitu banyak cara bagi sebuah startup untuk gagal. Saya pernah mengalami kegagalan akibat overarchitecture, yaitu ketika upaya untuk mencegah segala kemungkinan masalah justru membuat perusahaan menunda peluncuran produk apa pun. Saya juga pernah melihat perusahaan gagal karena kebalikan dari itu—yang disebut efek Friendster—yaitu mengalami kegagalan teknis yang sangat mencolok tepat ketika adopsi pelanggan sedang melonjak pesat.

Sebagai seorang eksekutif departemen, hasil seperti ini adalah yang paling buruk, karena kegagalan tersebut tidak hanya terjadi di hadapan publik, tetapi juga dapat ditelusuri langsung ke satu fungsi atau departemen tertentu—yaitu milik Anda. Bukan hanya perusahaan yang akan gagal; kegagalan itu juga akan dianggap sebagai kesalahan Anda.

Sebagian besar nasihat yang pernah saya dengar mengenai masalah ini menganjurkan pendekatan kompromi—semacam “lakukan sedikit perencanaan, tetapi jangan terlalu banyak.” Masalah dari pendekatan yang serba tanggung seperti ini adalah sulitnya memberikan alasan yang jelas mengapa kita harus mengantisipasi satu masalah tertentu tetapi mengabaikan masalah lainnya. Hal ini dapat menimbulkan kesan bahwa pimpinan bertindak sewenang-wenang atau berubah-ubah, dan itu memperkuat perasaan umum bahwa keputusan manajemen menyembunyikan motif lain.

Bagi mereka yang dikelola dengan cara seperti ini, insentifnya menjadi jelas. Jika atasan cenderung membagi perbedaan di tengah, cara terbaik untuk memengaruhi atasan dan mendapatkan apa yang Anda inginkan adalah dengan mengambil posisi yang paling ekstrem. Misalnya, jika satu kelompok mengusulkan siklus peluncuran yang sangat panjang—katakanlah pengenalan produk baru setahun sekali—Anda mungkin memilih untuk berargumen sebaliknya dengan siklus peluncuran yang sama ekstremnya, misalnya mingguan atau bahkan harian, dengan mengetahui bahwa kedua pendapat itu pada akhirnya akan dirata-ratakan.

Dengan demikian, ketika kompromi diambil, hasil akhirnya kemungkinan akan lebih dekat dengan apa yang sebenarnya Anda inginkan sejak awal. Sayangnya, perlombaan semacam ini akan terus meningkat. Kelompok lain yang bersaing kemungkinan akan melakukan hal yang sama. Seiring waktu, semua orang akan mengambil posisi yang semakin terpolarisasi, sehingga kompromi menjadi semakin sulit dan semakin tidak efektif.

Para manajer harus bertanggung jawab karena secara sadar ataupun tidak mereka menciptakan insentif seperti ini. Meskipun bukan itu niat mereka, pada kenyataannya mereka justru memberi penghargaan pada polarisasi ekstrem.

Untuk keluar dari perangkap ini diperlukan perubahan cara berpikir yang cukup mendasar.

MEMBANGUN ORGANISASI ADAPTIF

Haruskah sebuah startup berinvestasi dalam program pelatihan bagi karyawan baru?

Jika Anda menanyakan hal itu kepada saya beberapa tahun yang lalu, saya mungkin akan tertawa dan berkata, “Tentu saja tidak. Program pelatihan itu untuk perusahaan besar yang mampu membiayainya.”

Namun di IMVU, kami justru akhirnya membangun program pelatihan yang begitu baik sehingga karyawan baru sudah produktif pada hari pertama mereka bekerja. Dalam beberapa minggu saja, mereka sudah mampu berkontribusi pada tingkat yang tinggi.

Hal ini menuntut upaya besar untuk menstandarkan proses kerja kami dan menyusun kurikulum mengenai konsep-konsep yang harus dipelajari oleh karyawan baru. Setiap insinyur baru akan dipasangkan dengan seorang mentor yang membantu mereka mempelajari sistem, konsep, dan teknik yang diperlukan agar dapat bekerja secara produktif di IMVU. Kinerja mentor dan mentee saling terkait, sehingga para mentor benar-benar menanggapi tugas pendidikan ini dengan serius.

Yang menarik, jika melihat kembali pengalaman ini, kami sebenarnya tidak pernah berhenti bekerja dan secara formal memutuskan untuk membangun program pelatihan yang hebat. Program tersebut justru berkembang secara organik dari pendekatan yang sistematis dalam menyempurnakan proses kerja kami sendiri.

Proses orientasi ini terus-menerus diuji dan direvisi sehingga dari waktu ke waktu menjadi semakin efektif—dan semakin ringan bebannya.

Saya menyebut pendekatan ini sebagai membangun organisasi adaptif, yaitu organisasi yang secara otomatis menyesuaikan proses dan kinerjanya dengan kondisi yang sedang dihadapi.

Bisakah Bergerak Terlalu Cepat?

Sejauh ini buku ini menekankan pentingnya kecepatan. Startup berada dalam perjuangan hidup dan mati untuk mempelajari bagaimana membangun bisnis yang berkelanjutan sebelum sumber daya mereka habis.

Namun, berfokus hanya pada kecepatan justru dapat merusak. Agar dapat bekerja dengan baik, startup memerlukan pengatur kecepatan bawaan yang membantu tim menemukan ritme kerja yang optimal.

Kita telah melihat contoh pengaturan kecepatan ini pada Bab 9 melalui penggunaan andon cord dalam sistem seperti continuous deployment. Prinsip ini terangkum dalam peribahasa Toyota yang paradoksal: “Hentikan produksi agar produksi tidak perlu dihentikan.”

Kunci dari andon cord adalah menghentikan pekerjaan segera setelah muncul masalah kualitas yang tidak dapat diperbaiki—sehingga masalah tersebut harus diselidiki.

Ini merupakan salah satu penemuan terpenting dalam gerakan lean manufacturing: kualitas tidak dapat ditukar dengan waktu. Jika Anda menciptakan—atau melewatkan—masalah kualitas sekarang, cacat yang dihasilkan akan memperlambat Anda di kemudian hari. Cacat menyebabkan pekerjaan ulang, moral yang rendah, dan keluhan pelanggan, yang semuanya memperlambat kemajuan serta menggerogoti sumber daya yang berharga.

Kebijaksanaan Lima Mengapa

Untuk mempercepat laju, Lean Startup memerlukan proses yang menyediakan lingkaran umpan balik alami. Ketika Anda bergerak terlalu cepat, lebih banyak masalah akan muncul. Proses adaptif memaksa Anda memperlambat diri dan berinvestasi dalam pencegahan masalah yang sedang menyia-nyiakan waktu.

Seiring upaya pencegahan tersebut membuahkan hasil, Anda secara alami akan kembali bergerak lebih cepat.

Salah satu cara untuk melakukannya adalah dengan sistem yang disebut Five Whys (Lima Mengapa).

Gagasan inti dari Five Whys adalah mengaitkan investasi secara langsung dengan pencegahan gejala masalah yang paling mengganggu. Metode ini dinamai dari teknik investigatif dengan mengajukan pertanyaan “Mengapa?” sebanyak lima kali untuk menemukan akar penyebab suatu peristiwa.

Teknik ini dikembangkan oleh Taiichi Ohno, pencipta Toyota Production System, sebagai alat pemecahan masalah yang sistematis.

Contoh yang diberikan Ohno adalah sebagai berikut:

Ketika menghadapi sebuah masalah, pernahkah Anda berhenti dan bertanya “mengapa” lima kali? Kedengarannya mudah, tetapi sebenarnya sulit dilakukan. Misalnya, bayangkan sebuah mesin berhenti berfungsi:

1. Mengapa mesin berhenti? (Karena terjadi kelebihan beban dan sekring putus.)
2. Mengapa terjadi kelebihan beban? (Karena bantalan tidak cukup dilumasi.)
3. Mengapa tidak cukup dilumasi? (Karena pompa pelumas tidak memompa dengan baik.)
4. Mengapa pompa tidak memompa dengan baik? (Karena poros pompa sudah aus dan bergetar.)
5. Mengapa poros pompa aus? (Karena tidak ada saringan yang dipasang sehingga serpihan logam masuk.)

Dengan mengulangi pertanyaan “mengapa” lima kali, kita dapat menemukan akar masalah dan memperbaikinya. Jika proses ini tidak dilakukan, seseorang mungkin hanya mengganti sekring atau poros pompa. Dalam kasus itu, masalah yang sama kemungkinan akan muncul kembali dalam beberapa bulan.

Sistem produksi Toyota dibangun di atas praktik dan pengembangan pendekatan ilmiah ini. Dengan bertanya dan menjawab “mengapa” lima kali, kita dapat mencapai penyebab sebenarnya dari suatu masalah, yang sering kali tersembunyi di balik gejala yang lebih tampak.

Perhatikan bahwa bahkan dalam contoh sederhana Ohno, penyebab utama masalah bergeser dari kerusakan teknis (sekring putus) menuju kesalahan manusia (seseorang lupa memasang saringan). Hal ini sangat umum terjadi pada sebagian besar masalah yang dihadapi startup, apa pun industrinya.

Sebagian besar masalah yang pada awalnya tampak sebagai kesalahan individu sebenarnya dapat ditelusuri kembali pada masalah dalam pelatihan atau dalam pedoman awal mengenai bagaimana layanan atau pekerjaan seharusnya dilakukan.

Untuk menggambarkannya, berikut contoh bagaimana metode Five Whys digunakan di IMVU ketika kami menerima keluhan pelanggan mengenai versi baru produk yang baru saja dirilis:

1. Versi baru menonaktifkan sebuah fitur bagi pelanggan. Mengapa?
   Karena sebuah server tertentu gagal.
2. Mengapa server gagal?
   Karena sebuah subsistem yang jarang digunakan dipakai dengan cara yang salah.
3. Mengapa digunakan dengan cara yang salah?
   Karena insinyur yang menggunakannya tidak tahu cara menggunakannya dengan benar.
4. Mengapa ia tidak tahu?
   Karena ia tidak pernah dilatih.
5. Mengapa ia tidak dilatih?
   Karena manajernya tidak percaya pada pelatihan insinyur baru—menurutnya tim mereka “terlalu sibuk.”

Apa yang pada awalnya tampak sebagai kesalahan teknis murni dengan cepat ternyata merupakan persoalan manajerial yang sangat manusiawi.

Lakukan Investasi yang Proporsional

Berikut cara menggunakan analisis Five Whys untuk membangun organisasi yang adaptif: secara konsisten lakukan investasi yang proporsional pada setiap dari lima tingkat hierarki penyebab. Dengan kata lain, investasi yang dilakukan harus kecil ketika gejalanya ringan dan lebih besar ketika gejalanya lebih menyakitkan. Kita tidak melakukan investasi pencegahan yang besar kecuali jika kita sedang menghadapi masalah yang besar.

Dalam contoh sebelumnya, solusinya adalah memperbaiki server, mengubah subsistem agar lebih kecil kemungkinan terjadinya kesalahan, mendidik insinyur yang bersangkutan, dan—ya—melakukan percakapan dengan manajer insinyur tersebut.

Bagian terakhir ini, percakapan dengan manajer, selalu sulit, terutama di lingkungan startup. Ketika saya masih menjadi manajer startup, jika seseorang mengatakan bahwa saya perlu berinvestasi dalam pelatihan bagi tim saya, kemungkinan besar saya akan mengatakan bahwa itu hanya membuang-buang waktu. Selalu ada terlalu banyak hal lain yang harus dikerjakan. Mungkin saya akan menjawab secara sinis, “Tentu saja saya bersedia melakukannya—kalau Anda bisa menyediakan waktu saya selama delapan minggu untuk menyiapkannya.” Itu adalah bahasa manajer untuk mengatakan: “Tidak mungkin.”

Itulah sebabnya pendekatan investasi proporsional sangat penting. Jika gangguan yang terjadi hanyalah kesalahan kecil, kita cukup melakukan investasi kecil untuk memperbaikinya. Misalnya, kita melakukan satu jam pertama dari rencana delapan minggu tersebut. Mungkin terdengar tidak berarti, tetapi itu adalah awal.

Jika masalah tersebut muncul kembali, proses Five Whys akan menuntut kita untuk terus membuat kemajuan dalam menanganinya. Jika masalah itu tidak pernah terjadi lagi, kehilangan satu jam bukanlah kerugian besar.

Saya menggunakan contoh pelatihan insinyur karena pada awalnya saya sendiri enggan berinvestasi di bidang itu di IMVU. Pada masa awal perusahaan kami, saya merasa seluruh energi kami harus difokuskan pada pembangunan dan pemasaran produk. Namun setelah kami memasuki periode perekrutan yang pesat, sesi Five Whys yang berulang kali mengungkap bahwa masalah yang disebabkan oleh kurangnya pelatihan justru memperlambat pengembangan produk.

Kami tidak pernah menghentikan seluruh pekerjaan untuk fokus sepenuhnya pada pelatihan. Sebaliknya, kami terus melakukan perbaikan kecil secara bertahap pada proses tersebut, dan setiap kali memperoleh manfaat tambahan yang kecil pula. Seiring waktu, perubahan-perubahan kecil itu terakumulasi, membebaskan waktu dan energi yang sebelumnya terbuang untuk memadamkan krisis dan menangani masalah darurat.

Pengatur Kecepatan Otomatis

Pendekatan Five Whys berfungsi sebagai pengatur kecepatan alami. Semakin banyak masalah yang Anda alami, semakin banyak pula investasi yang Anda lakukan untuk menyelesaikan masalah tersebut. Ketika investasi pada infrastruktur atau proses mulai membuahkan hasil, tingkat keparahan dan jumlah krisis akan menurun, dan tim akan kembali bergerak lebih cepat.

Dalam startup khususnya, terdapat bahaya bahwa tim akan bekerja terlalu cepat, menukar kualitas dengan waktu sehingga menghasilkan kesalahan yang ceroboh. Five Whys mencegah hal ini dan memungkinkan tim menemukan ritme kerja yang optimal.

Metode ini mengaitkan laju kemajuan dengan proses pembelajaran, bukan sekadar pelaksanaan. Tim startup seharusnya melakukan Five Whys setiap kali menghadapi kegagalan apa pun—baik kesalahan teknis, kegagalan mencapai hasil bisnis, maupun perubahan perilaku pelanggan yang tidak terduga.

Five Whys merupakan teknik organisasi yang sangat kuat. Beberapa insinyur yang pernah saya latih bahkan percaya bahwa seluruh teknik Lean Startup lainnya dapat diturunkan dari metode ini. Dikombinasikan dengan praktik bekerja dalam batch kecil, metode ini memberikan fondasi yang memungkinkan perusahaan merespons masalah dengan cepat tanpa berlebihan dalam berinvestasi ataupun merekayasa sistem.

Kutukan Lima Menyalahkan

Ketika tim pertama kali mengadopsi Five Whys sebagai alat pemecahan masalah, mereka sering menghadapi beberapa jebakan umum. Kita memerlukan sistem seperti ini untuk mengatasi keterbatasan psikologis kita, karena kita cenderung bereaksi berlebihan terhadap apa yang sedang terjadi. Kita juga mudah frustrasi ketika sesuatu terjadi di luar perkiraan.

Ketika pendekatan Five Whys berjalan keliru, saya menyebutnya Five Blames—lima kali menyalahkan.

Alih-alih terus bertanya “mengapa” untuk memahami apa yang sebenarnya terjadi, anggota tim yang frustrasi mulai saling menunjuk dan mencoba menentukan siapa yang bersalah. Alih-alih menggunakan Five Whys untuk menemukan dan memperbaiki masalah, manajer dan karyawan justru menjadikannya sarana melampiaskan frustrasi dan menuduh rekan kerja atas kegagalan sistemik.

Meskipun merupakan sifat manusia untuk menganggap bahwa kesalahan terjadi karena kekurangan pada departemen, pengetahuan, atau karakter orang lain, tujuan dari Five Whys adalah membantu kita melihat kebenaran objektif: bahwa masalah kronis biasanya disebabkan oleh proses yang buruk, bukan oleh orang yang buruk.

Saya merekomendasikan beberapa taktik untuk menghindari Five Blames. Yang pertama adalah memastikan bahwa semua orang yang terdampak oleh masalah tersebut hadir dalam ruangan ketika analisis akar penyebab dilakukan.

Pertemuan itu sebaiknya mencakup siapa pun yang menemukan atau mendiagnosis masalah, termasuk perwakilan layanan pelanggan yang menerima keluhan. Ia juga harus melibatkan siapa pun yang mencoba memperbaiki gejalanya serta siapa pun yang bekerja pada subsistem atau fitur yang terkait. Jika masalah tersebut sampai diekskalasi ke manajemen senior, para pengambil keputusan yang terlibat dalam eskalasi juga harus hadir.

Hal ini mungkin membuat ruangan menjadi penuh, tetapi sangat penting. Dalam pengalaman saya, siapa pun yang tidak dilibatkan dalam diskusi akhirnya akan menjadi sasaran untuk disalahkan. Hal ini sama merusaknya, baik ketika kambing hitamnya adalah karyawan junior maupun CEO. Jika yang disalahkan adalah karyawan junior, terlalu mudah untuk menganggap bahwa orang tersebut dapat diganti. Jika CEO tidak hadir, terlalu mudah untuk menganggap bahwa perilakunya tidak dapat diubah. Kedua asumsi tersebut biasanya tidak benar.

Ketika tuduhan tak terelakkan muncul, orang yang paling senior di ruangan harus mengulang mantra ini: jika suatu kesalahan terjadi, maka kita patut malu karena membuat kesalahan itu begitu mudah terjadi. Dalam analisis Five Whys, kita harus sebisa mungkin memandang masalah pada tingkat sistem.

Memulai

Berikut beberapa saran untuk memulai menggunakan Five Whys, berdasarkan pengalaman saya memperkenalkan teknik ini di berbagai perusahaan.

Agar Five Whys bekerja dengan baik, ada aturan yang harus diikuti. Metode ini membutuhkan lingkungan yang dilandasi kepercayaan timbal balik dan pemberdayaan. Jika kondisi ini tidak ada, kompleksitas metode Five Whys bisa terasa sangat berat. Dalam situasi seperti itu, saya sering menggunakan versi yang lebih sederhana yang tetap memungkinkan tim berfokus pada analisis akar penyebab sekaligus melatih kemampuan yang kelak diperlukan untuk menggunakan metode penuh.

Saya meminta tim untuk mengadopsi dua aturan sederhana:

1. Bersikaplah toleran terhadap semua kesalahan yang terjadi pertama kali.
2. Jangan pernah membiarkan kesalahan yang sama terjadi dua kali.

Aturan pertama mendorong orang untuk terbiasa bersikap penuh empati terhadap kesalahan, terutama kesalahan orang lain. Ingatlah bahwa sebagian besar kesalahan disebabkan oleh sistem yang cacat, bukan oleh orang yang buruk.

Aturan kedua membantu tim mulai melakukan investasi proporsional dalam pencegahan.

Sistem yang disederhanakan ini bekerja dengan baik. Bahkan, kami menggunakannya di IMVU sebelum saya mengenal Five Whys dan Toyota Production System. Namun, dalam jangka panjang sistem sederhana seperti ini tidak cukup efektif, sebagaimana saya alami sendiri. Hal inilah yang mendorong saya mempelajari produksi lean secara lebih mendalam.

Kekuatan sekaligus kelemahan sistem sederhana ini adalah bahwa ia memunculkan pertanyaan seperti: apa yang dianggap sebagai masalah yang sama? Jenis kesalahan apa yang harus kita fokuskan? Haruskah kita memperbaiki masalah individu ini saja atau mencegah seluruh kategori masalah yang serupa?

Bagi tim yang baru memulai, pertanyaan-pertanyaan ini dapat memicu pemikiran mendalam dan menjadi landasan bagi metode yang lebih lengkap. Namun pada akhirnya pertanyaan-pertanyaan tersebut tetap harus dijawab. Untuk itu diperlukan proses adaptif yang utuh seperti Five Whys.

Menghadapi Kebenaran yang Tidak Menyenangkan

Anda harus siap menghadapi kenyataan bahwa Five Whys akan mengungkap fakta-fakta yang tidak menyenangkan tentang organisasi Anda, terutama pada tahap awal. Metode ini sering kali menuntut investasi pencegahan yang memakan waktu dan biaya yang sebenarnya bisa digunakan untuk mengembangkan produk atau fitur baru.

Di bawah tekanan, tim mungkin merasa tidak punya waktu untuk menganalisis akar penyebab masalah, meskipun analisis tersebut justru akan menghemat waktu dalam jangka panjang. Kadang-kadang proses ini juga bisa berubah menjadi Five Blames.

Pada titik-titik seperti ini, sangat penting ada seseorang yang memiliki otoritas cukup untuk memastikan bahwa proses tersebut tetap dijalankan, bahwa rekomendasinya benar-benar dilaksanakan, dan bertindak sebagai penengah jika terjadi perselisihan.

Dengan kata lain, membangun organisasi yang adaptif membutuhkan kepemimpinan eksekutif yang bersedia mensponsori dan mendukung proses tersebut.

Mulailah dari Hal Kecil dan Spesifik

Setelah siap memulai, saya menyarankan untuk memulai dari kelas gejala yang sempit dan spesifik.

Ketika pertama kali berhasil menggunakan Five Whys, saya memakainya untuk mendiagnosis masalah pada salah satu alat pengujian internal kami yang tidak secara langsung memengaruhi pelanggan.

Mungkin terasa menggoda untuk memulai dari masalah yang besar dan penting karena di situlah sebagian besar waktu terbuang akibat proses yang cacat. Namun di situlah pula tekanan paling besar berada. Ketika taruhannya tinggi, Five Whys mudah berubah menjadi Five Blames.

Lebih baik memberi kesempatan kepada tim untuk mempelajari prosesnya terlebih dahulu, lalu secara bertahap memperluas penerapannya ke masalah yang lebih besar.

Semakin spesifik gejalanya, semakin mudah bagi semua orang mengenali kapan saatnya menjadwalkan pertemuan Five Whys. Misalnya, jika Anda ingin menggunakan metode ini untuk mengatasi keluhan pelanggan terkait penagihan, Anda bisa menetapkan tanggal setelah mana setiap keluhan penagihan secara otomatis memicu pertemuan Five Whys.

Aturan yang menentukan jenis keluhan apa yang memicu pertemuan harus sederhana dan tegas. Misalnya: setiap keluhan yang melibatkan transaksi kartu kredit akan diselidiki. Itu aturan yang jelas dan mudah diikuti.

Pada awalnya mungkin ada godaan untuk melakukan perubahan besar dan mendalam pada seluruh sistem penagihan. Jangan lakukan itu. Sebaliknya, buatlah pertemuan tetap singkat dan pilih perubahan yang relatif sederhana pada setiap tingkat penyelidikan. Seiring waktu, ketika tim semakin nyaman dengan proses ini, cakupannya dapat diperluas ke lebih banyak jenis keluhan dan kemudian ke jenis masalah lainnya.

Tunjuk Seorang Master Five Whys

Untuk mempermudah proses pembelajaran, saya menemukan bahwa akan sangat membantu jika menunjuk seorang master Five Whys untuk setiap area tempat metode ini digunakan.

Orang ini bertugas menjadi moderator dalam setiap pertemuan Five Whys, mengambil keputusan mengenai langkah pencegahan yang akan dilakukan, serta menugaskan tindak lanjut dari hasil pertemuan tersebut.

Master tersebut harus cukup senior untuk memiliki wewenang memastikan bahwa tugas-tugas tersebut benar-benar diselesaikan, tetapi tidak terlalu senior sehingga ia tidak dapat hadir dalam pertemuan karena tanggung jawab lain yang bertabrakan.

Master Five Whys adalah pusat akuntabilitas—agen perubahan utama. Orang yang memegang peran ini dapat menilai seberapa baik pertemuan berlangsung dan apakah investasi pencegahan yang dilakukan benar-benar memberikan hasil.

LIMA KALI “MENGAPA” DALAM PRAKTEK

IGN Entertainment, sebuah divisi dari News Corporation, adalah perusahaan media video game daring dengan jumlah audiens pemain game terbesar di dunia. Lebih dari 45 juta gamer mengunjungi portofolio properti media mereka. IGN didirikan pada akhir 1990-an, dan News Corporation mengakuisisinya pada 2005. Saat ini IGN telah berkembang hingga mempekerjakan beberapa ratus orang, termasuk hampir seratus insinyur.

Baru-baru ini, saya berkesempatan berbicara dengan tim pengembangan produk di IGN. Mereka telah meraih kesuksesan dalam beberapa tahun terakhir, tetapi seperti halnya semua perusahaan mapan yang kita bahas dalam buku ini, mereka ingin mempercepat pengembangan produk baru dan menemukan cara untuk lebih inovatif. Mereka mengumpulkan tim insinyur, produk, dan desain untuk membahas cara menerapkan model Lean Startup.

Inisiatif perubahan ini didukung oleh manajemen senior IGN, termasuk CEO, kepala pengembangan produk, wakil presiden bidang teknik, penerbit, dan kepala produk. Upaya mereka sebelumnya dalam menerapkan metode Five Whys tidak berjalan mulus. Mereka mencoba menangani daftar panjang masalah yang diajukan oleh tim produk. Masalahnya beragam, mulai dari perbedaan data analitik web hingga umpan data mitra yang tidak berfungsi. Pertemuan Five Whys pertama mereka berlangsung satu jam, dan meski menghasilkan beberapa wawasan menarik, dari sisi metode Five Whys, itu adalah bencana. Tidak ada orang yang paling terkait dan memahami masalah tersebut hadir, dan karena ini pertama kalinya mereka melakukan Five Whys bersama, mereka tidak mengikuti format yang benar dan sering menyimpang ke topik lain. Waktu itu tidak sepenuhnya sia-sia, tetapi tidak memberikan manfaat dari gaya manajemen adaptif yang dibahas dalam bab ini.

Jangan Membawa “Beban” ke Proses Five Whys
IGN memiliki pengalaman mencoba menyelesaikan semua masalah “beban” yang telah membuang waktu mereka selama bertahun-tahun. Karena jumlah masalahnya sangat banyak, menemukan solusi cepat justru menjadi membingungkan.

Dalam semangat mereka untuk memulai Five Whys, IGN mengabaikan tiga hal penting:

1. Untuk memperkenalkan Five Whys ke organisasi, sesi Five Whys harus dilakukan saat muncul masalah baru. Karena masalah “beban” bersifat endemik, mereka akan muncul secara alami dalam analisis Five Whys dan bisa diperbaiki secara bertahap. Jika masalah itu tidak muncul secara organik, mungkin masalahnya tidak sebesar yang terlihat.
2. Setiap orang yang terkait dengan masalah harus hadir dalam sesi Five Whys. Banyak organisasi tergoda untuk menghemat waktu dengan mengecualikan orang sibuk dari analisis akar masalah. Ini adalah penghematan palsu, seperti yang dialami IGN dengan pahit.
3. Pada awal setiap sesi Five Whys, luangkan beberapa menit untuk menjelaskan tujuan dan mekanisme proses bagi mereka yang baru mengenal. Jika memungkinkan, gunakan contoh sesi Five Whys sukses dari masa lalu. Jika benar-benar baru, bisa menggunakan contoh sebelumnya tentang manajer yang tidak percaya pada pelatihan. IGN belajar bahwa, kapan pun memungkinkan, membantu menggunakan sesuatu yang memiliki makna pribadi bagi tim.

Setelah pertemuan kami, manajemen IGN memutuskan untuk mencoba Five Whys lagi. Mengikuti saran dalam bab ini, mereka menunjuk seorang master Five Whys bernama Tony Ford, seorang direktur bidang teknik. Tony adalah seorang wirausahawan yang bergabung dengan IGN melalui akuisisi. Ia memulai kariernya di bidang teknologi internet, membangun situs web tentang video game pada akhir 1990-an. Kemudian ia mendapat kesempatan di startup TeamXbox sebagai pengembang perangkat lunak utama. TeamXbox diakuisisi oleh IGN Entertainment pada 2003, dan sejak itu Tony menjadi teknolog, pemimpin inovasi, dan pendukung praktik agile dan lean.

Sayangnya, Tony memulai tanpa memilih area masalah yang sempit untuk difokuskan. Hal ini menimbulkan kemunduran awal dan frustrasi.

Tony menceritakan, “Sebagai master baru, saya tidak begitu mahir menjalankan Five Whys secara efektif, dan masalah yang kami coba selesaikan awalnya bukan kandidat yang tepat. Bisa dibayangkan, sesi awal itu canggung dan pada akhirnya tidak terlalu berguna. Saya merasa sangat kecewa dan frustrasi.” Ini masalah umum ketika mencoba menangani terlalu banyak hal sekaligus, tetapi juga konsekuensi dari fakta bahwa keterampilan ini membutuhkan waktu untuk dikuasai. Untungnya, Tony bertahan: “Memiliki master Five Whys sangat penting menurut saya. Five Whys mudah dalam teori tapi sulit dalam praktik, jadi Anda membutuhkan seseorang yang benar-benar memahami untuk membimbing sesi bagi yang belum paham.”

Perubahan signifikan terjadi ketika Tony memimpin sesi Five Whys yang melibatkan proyek yang melewatkan tenggat waktu. Sesi ini menarik dan memberikan wawasan, serta menghasilkan investasi proporsional yang berarti. Tony menjelaskan: “Keberhasilan itu terkait master yang lebih berpengalaman dan peserta yang lebih berpengalaman. Kami semua memahami Five Whys, dan saya berhasil menjaga agar tetap fokus tanpa menyimpang. Ini momen penting. Saat itu saya tahu Five Whys adalah alat baru yang akan berdampak nyata pada keberhasilan tim dan bisnis kami.”

Secara permukaan, Five Whys tampak berkaitan dengan masalah teknis dan pencegahan kesalahan, tetapi saat tim mengeliminasi pemborosan permukaan ini, mereka mengembangkan pemahaman baru tentang cara bekerja sama. Tony menyatakan: “Saya berani mengatakan bahwa Five Whys melampaui analisis akar masalah dengan mengungkap informasi yang mendekatkan tim melalui pemahaman dan perspektif yang sama. Seringkali masalah justru memisahkan orang; Five Whys melakukan kebalikan.”

Saya meminta Tony memberikan contoh analisis Five Whys sukses terbaru di IGN. Berikut laporannya:

Mengapa Anda tidak bisa menambah atau mengedit posting di blog?
Jawaban: Setiap permintaan posting (write) ke content API artikel mengembalikan error 500.
Investasi proporsional: Jim — Kami akan memperbaiki API, tetapi mari buat CMS lebih ramah pengguna. Izinkan pengguna menambah dan mengedit draft tanpa error untuk pengalaman yang lebih baik.

Mengapa content API mengembalikan error 500?
Jawaban: Gem bson_ext tidak kompatibel dengan gem lain yang menjadi dependensinya.
Investasi proporsional: King — Hapus gem (sudah dilakukan untuk menyelesaikan gangguan).

Mengapa gem tersebut tidak kompatibel?
Jawaban: Kami menambahkan versi baru gem selain versi lama, dan aplikasi mulai menggunakannya secara tak terduga.
Investasi proporsional: Bennett — Konversi aplikasi Rails agar menggunakan bundler untuk manajemen gem.

Mengapa kami menambahkan versi baru gem di produksi tanpa pengujian?
Jawaban: Kami tidak menganggap perlu pengujian dalam kasus ini.
Investasi proporsional: Bennett dan Jim — Tulis unit atau functional test di API dan CMS untuk mencegah hal serupa di masa depan.

Mengapa kami menambahkan gem tambahan yang tidak akan digunakan segera?
Jawaban: Sebagai persiapan untuk push kode, kami ingin semua gem baru siap di lingkungan produksi. Walau deployment kode otomatis, gem tidak.
Investasi proporsional: Bennett — Otomatiskan manajemen dan instalasi gem ke proses Continuous Integration dan Continuous Deployment.

Bonus — Mengapa kami melakukan perubahan produksi pada Jumat malam?
Jawaban: Karena tidak ada yang melarang dan itu waktu yang nyaman bagi developer untuk menyiapkan deployment hari Senin.
Investasi proporsional: Tony — Umumkan kepada tim: Tidak ada perubahan produksi pada Jumat, Sabtu, atau Minggu kecuali ada pengecualian yang disetujui David (VP Engineering). Kebijakan ini akan dievaluasi kembali saat proses deployment otomatis penuh tersedia.

Hasil dari sesi Five Whys dan investasi proporsional ini, deployment menjadi lebih mudah, cepat, dan tidak akan ada lagi developer menempatkan gem ke sistem produksi dengan konsekuensi yang tidak diinginkan. Memang, kami belum menghadapi masalah serupa lagi. Kami memperkuat “sistem imun klaster”, begitu ungkapannya.

Tanpa Five Whys, kami tidak akan pernah menemukan semua informasi yang ada di sini. Saya kira, sebelumnya kami hanya akan memberitahu developer tersebut untuk tidak melakukan hal bodoh pada Jumat malam dan melanjutkan. Inilah yang saya tekankan sebelumnya, di mana sesi Five Whys yang baik menghasilkan dua hal: pembelajaran dan tindakan.

Investasi proporsional dari sesi ini jelas bernilai, tetapi pembelajarannya jauh lebih halus, sekaligus luar biasa untuk perkembangan para developer dan tim.

MENYESUAIKAN DIRI DENGAN BATCH YANG LEBIH KECIL

Sebelum meninggalkan topik tentang membangun organisasi yang adaptif, saya ingin memperkenalkan satu kisah lagi. Kisah ini berkaitan dengan produk yang mungkin pernah Anda gunakan jika pernah menjalankan bisnis sendiri. Produk itu bernama QuickBooks, salah satu produk unggulan Intuit.

QuickBooks telah menjadi produk terdepan di kategorinya selama bertahun-tahun. Akibatnya, produk ini memiliki basis pelanggan yang besar dan setia, dan Intuit mengharapkan kontribusi signifikan terhadap pendapatan perusahaan. Seperti sebagian besar perangkat lunak komputer pribadi (PC) dalam dua dekade terakhir, QuickBooks diluncurkan dalam siklus tahunan, dalam satu batch besar. Begitulah cara kerjanya tiga tahun lalu, ketika Greg Wright, direktur pemasaran produk QuickBooks, bergabung dengan tim.

Seperti yang dapat dibayangkan, sudah ada banyak proses yang diterapkan untuk memastikan produk konsisten dan rilis tepat waktu. Pendekatan rilis yang biasa dilakukan adalah menghabiskan waktu cukup lama di awal untuk mengidentifikasi kebutuhan pelanggan:

Biasanya, tiga hingga empat bulan pertama dari setiap siklus tahunan digunakan untuk strategi dan perencanaan, tanpa membangun fitur baru. Setelah rencana dan milestone ditetapkan, tim menghabiskan enam hingga sembilan bulan berikutnya untuk pembangunan.

Ini akan berpuncak pada peluncuran besar, dan kemudian tim baru akan mendapatkan umpan balik pertama tentang apakah mereka berhasil memenuhi kebutuhan pelanggan di akhir proses.

Jadi, garis waktunya adalah: memulai proses pada bulan September, rilis beta pertama pada bulan Juni, beta kedua pada bulan Juli. Beta pada dasarnya adalah pengujian untuk memastikan tidak menyebabkan komputer pelanggan crash atau kehilangan data—pada titik itu, hanya bug besar yang bisa diperbaiki. Desain produk sendiri sudah terkunci.

Ini adalah metodologi pengembangan “waterfall” standar yang telah digunakan tim pengembangan produk selama bertahun-tahun. Sistem linear dengan batch besar ini mengandalkan keberhasilan pada peramalan dan perencanaan yang tepat. Dengan kata lain, metode ini sama sekali tidak sesuai dengan lingkungan bisnis saat ini yang berubah dengan cepat.

Tahun Pertama: Mencapai Kegagalan
Greg menyaksikan keruntuhan ini pada 2009, tahun pertamanya di tim QuickBooks. Tahun itu, perusahaan merilis sistem baru sepenuhnya di QuickBooks untuk perbankan daring, salah satu fitur terpentingnya. Tim menjalani serangkaian pengujian kegunaan menggunakan mock-up dan prototipe non-fungsional, diikuti pengujian beta signifikan dengan data pelanggan contoh. Pada saat peluncuran, semuanya tampak baik.

Rilis beta pertama pada bulan Juni, dan umpan balik pelanggan mulai masuk dengan negatif. Meskipun pelanggan mengeluh, tidak ada alasan cukup kuat untuk menghentikan rilis karena secara teknis produk tidak cacat—tidak crash pada komputer. Saat itu, Greg berada dalam dilema. Ia tidak tahu bagaimana umpan balik itu akan tercermin pada perilaku pelanggan di pasar. Apakah ini hanya keluhan terisolasi, atau bagian dari masalah luas? Satu hal yang pasti: timnya tidak mampu melewatkan tenggat waktu.

Ketika produk akhirnya diluncurkan, hasilnya buruk. Pelanggan membutuhkan waktu empat hingga lima kali lebih lama untuk merekonsiliasi transaksi perbankan dibandingkan versi sebelumnya. Pada akhirnya, tim Greg gagal memenuhi kebutuhan pelanggan yang ingin mereka selesaikan (meskipun produk dibangun sesuai spesifikasi), dan karena rilis berikutnya harus melalui proses waterfall yang sama, tim membutuhkan sembilan bulan untuk memperbaikinya. Ini adalah contoh klasik “mencapai kegagalan”—menjalankan rencana cacat dengan sukses.

Intuit menggunakan survei Net Promoter Score (NPS) untuk menilai kepuasan pelanggan terhadap banyak produknya. Ini merupakan sumber metrik yang dapat ditindaklanjuti tentang apa yang benar-benar dipikirkan pelanggan. Bahkan, saya juga menggunakannya di IMVU. Salah satu hal baik dari NPS adalah stabilitasnya dari waktu ke waktu. Karena mengukur kepuasan inti pelanggan, skor ini tidak dipengaruhi fluktuasi kecil; hanya perubahan signifikan dalam sentimen pelanggan yang tercatat.

Tahun itu, skor QuickBooks turun 20 poin, pertama kalinya perusahaan berhasil menggerakkan jarum pada Net Promoter Score. Penurunan 20 poin ini menimbulkan kerugian signifikan bagi Intuit dan memalukan bagi perusahaan—semua karena umpan balik pelanggan datang terlalu terlambat, sehingga tidak ada waktu untuk iterasi.

Manajemen senior Intuit, termasuk general manager divisi usaha kecil dan kepala akuntansi usaha kecil, menyadari perlunya perubahan. Untuk itu, mereka menugaskan Greg memimpin perubahan tersebut. Misinya: mencapai kecepatan startup untuk pengembangan dan penerapan QuickBooks.

Tahun Kedua: Memori Otot
Bab berikutnya menggambarkan betapa sulitnya membangun organisasi adaptif. Greg berusaha mengubah proses pengembangan QuickBooks dengan menggunakan empat prinsip:

1. Tim lebih kecil. Beralih dari tim besar dengan peran fungsional seragam ke tim kecil yang sepenuhnya terlibat, dengan anggota yang mengambil berbagai peran.
2. Mencapai siklus waktu yang lebih pendek.
3. Umpan balik pelanggan lebih cepat, menguji apakah produk crash di komputer pelanggan dan kinerja fitur baru/pengalaman pelanggan.
4. Memungkinkan dan memberdayakan tim untuk membuat keputusan cepat dan berani.

Secara permukaan, tujuan ini tampak sejalan dengan metode dan prinsip yang dibahas sebelumnya, tetapi tahun kedua Greg di QuickBooks tidak begitu sukses. Misalnya, ia memutuskan tim akan pindah ke milestone rilis pertengahan tahun, secara efektif memangkas waktu siklus dan ukuran batch menjadi setengah. Namun, ini tidak berhasil. Dengan tekad bulat, tim berusaha keras merilis versi alpha pada Januari. Masalah yang melekat pada pengembangan batch besar tetap ada, dan tim kesulitan menyelesaikan alpha hingga April. Ini merupakan peningkatan dibanding sistem lama karena masalah bisa terlihat dua bulan lebih awal, tetapi tidak menghasilkan hasil dramatis seperti yang Greg harapkan.

Faktanya, sepanjang tahun, proses tim kembali mirip dengan tahun-tahun sebelumnya. Greg berkata, “Organisasi memiliki memori otot,” dan sulit bagi orang untuk melepaskan kebiasaan lama. Greg berhadapan dengan sistem, dan perubahan individual seperti mengubah tanggal rilis secara sewenang-wenang tidak cukup.

Tahun Ketiga: Ledakan
Frustrasi oleh kemajuan terbatas tahun sebelumnya, Greg bekerja sama dengan pemimpin pengembangan produk Himanshu Baxi. Bersama-sama mereka menyingkirkan semua proses lama. Mereka membuat deklarasi publik bahwa tim gabungan mereka akan menciptakan proses baru dan tidak akan kembali ke cara lama.

Alih-alih fokus pada tenggat baru, Greg dan Himanshu berinvestasi pada perubahan proses, produk, dan teknologi yang memungkinkan kerja dalam batch lebih kecil. Inovasi teknis ini membantu mereka menghadirkan produk desktop ke pelanggan lebih cepat untuk mendapatkan umpan balik.

Alih-alih membangun roadmap lengkap di awal tahun, Greg memulai tahun dengan apa yang mereka sebut “idea/code/solution jams” yang menghadirkan insinyur, manajer produk, dan pelanggan untuk menciptakan aliran ide. Awal tahun tanpa daftar rilis yang jelas menakutkan bagi Greg sebagai manajer produk, tetapi ia percaya pada tim dan proses baru.

Ada tiga perbedaan pada tahun ketiga:

• Tim terlibat dalam menciptakan teknologi, proses, dan sistem baru.
• Tim lintas fungsi dibentuk di sekitar ide besar baru.
• Pelanggan terlibat sejak awal konsep fitur.

Penting dipahami bahwa pendekatan lama bukan tanpa umpan balik atau keterlibatan pelanggan. Dalam semangat genchi gembutsu sejati, manajer produk Intuit melakukan “follow-me-homes” untuk mengidentifikasi masalah yang harus diselesaikan di rilis berikutnya. Namun, manajer produk bertanggung jawab atas semua riset pelanggan dan menyampaikannya ke tim: “Ini masalah yang ingin kami selesaikan, dan ini ide untuk menyelesaikannya.”

Peralihan ke kerja lintas fungsi tidak mulus. Beberapa anggota tim skeptis. Misalnya, beberapa manajer produk merasa waktu insinyur di depan pelanggan terbuang. Mereka berpikir tugas mereka adalah menemukan masalah pelanggan dan menentukan apa yang perlu dibangun. Sebagai respons, beberapa manajer produk bertanya: “Apa tugas saya? Apa yang harus saya lakukan?” Begitu pula beberapa insinyur ingin hanya diberi tahu apa yang harus dilakukan; mereka tidak ingin berbicara dengan pelanggan. Seperti lazimnya pengembangan batch besar, kedua kelompok bersedia mengorbankan kemampuan tim untuk belajar demi bekerja lebih “efisien.”

Komunikasi menjadi kunci keberhasilan perubahan ini. Semua pemimpin tim terbuka tentang perubahan yang mereka jalankan dan alasannya. Banyak skeptisisme muncul karena mereka tidak memiliki contoh konkret keberhasilan sebelumnya; ini adalah proses baru untuk Intuit. Mereka harus menjelaskan dengan jelas mengapa proses lama gagal dan mengapa “kereta” rilis tahunan tidak mempersiapkan mereka untuk sukses. Sepanjang perubahan, mereka menyampaikan hasil yang dituju: umpan balik pelanggan lebih awal dan siklus pengembangan lebih cepat yang terlepas dari jadwal rilis tahunan. Mereka berulang kali menekankan bahwa pendekatan baru adalah cara pesaing startup bekerja dan beriterasi. Mereka harus menyesuaikan diri atau berisiko menjadi tidak relevan.

Secara historis, QuickBooks dibangun dengan tim besar dan siklus panjang. Misalnya, tim perbankan daring yang malang sebelumnya terdiri dari lima belas insinyur, tujuh spesialis quality assurance, satu manajer produk, dan kadang lebih dari satu desainer. Kini, tidak ada tim yang lebih dari lima orang. Fokus setiap tim adalah iterasi dengan pelanggan secepat mungkin, menjalankan eksperimen, dan menggunakan pembelajaran tervalidasi untuk membuat keputusan investasi real-time tentang apa yang dikerjakan. Akibatnya, dulunya ada lima “cabang” besar QuickBooks untuk menggabungkan fitur saat rilis, kini ada dua puluh hingga dua puluh lima cabang. Ini memungkinkan eksperimen jauh lebih banyak. Setiap tim mengerjakan fitur baru sekitar enam minggu secara menyeluruh, mengujinya dengan pelanggan nyata sepanjang proses.

Meskipun perubahan utama dalam organisasi adaptif terletak pada pola pikir karyawan, mengubah budaya saja tidak cukup. Seperti terlihat di Bab 9, manajemen lean membutuhkan perlakuan pekerjaan sebagai sistem dan menangani ukuran batch serta siklus proses secara menyeluruh. Untuk perubahan yang berkelanjutan, tim QuickBooks harus berinvestasi pada alat dan platform yang memungkinkan cara kerja baru yang lebih cepat.

Misalnya, salah satu titik stres utama saat mencoba merilis versi alpha awal tahun sebelumnya adalah QuickBooks merupakan produk misi-kritis. Banyak usaha kecil menggunakan QuickBooks sebagai repositori utama data keuangan penting. Tim sangat berhati-hati merilis produk minimum viable dengan risiko korupsi data pelanggan. Oleh karena itu, meski bekerja dalam tim kecil dengan ruang lingkup lebih kecil, beban risiko tetap membuat kerja dalam batch kecil sulit dilakukan.

Untuk mengecilkan ukuran batch, tim QuickBooks harus berinvestasi dalam teknologi baru. Mereka membangun sistem virtualisasi yang memungkinkan menjalankan beberapa versi QuickBooks di komputer pelanggan. Versi kedua dapat mengakses semua data pelanggan tetapi tidak dapat melakukan perubahan permanen. Dengan demikian, tidak ada risiko data pelanggan rusak secara tidak sengaja.

Ini memungkinkan mereka mengisolasi rilis baru untuk diuji oleh pelanggan terpilih dan memberikan umpan balik.

Hasil pada tahun ketiga menjanjikan. Versi QuickBooks yang dirilis saat itu memiliki tingkat kepuasan pelanggan lebih tinggi dan terjual lebih banyak unit. Jika Anda menggunakan QuickBooks saat ini, besar kemungkinan Anda menggunakan versi yang dibangun dalam batch kecil. Saat Greg memasuki tahun keempat di tim QuickBooks, mereka mengeksplorasi cara lebih lanjut untuk mengecilkan batch dan siklus. Seperti biasa, kemungkinan yang ditemukan tidak hanya bersifat teknis. Misalnya, siklus penjualan tahunan software desktop boxed menjadi penghalang untuk pembelajaran cepat, sehingga tim mulai bereksperimen dengan produk berbasis langganan untuk pelanggan paling aktif. Dengan pelanggan mengunduh pembaruan daring, Intuit dapat merilis software lebih sering. Segera, tim QuickBooks akan merilis ke pelanggan setiap kuartal.

Seiring pertumbuhan Lean Startup, mereka dapat menggunakan teknik adaptif untuk mengembangkan proses yang lebih kompleks tanpa mengorbankan keunggulan inti mereka: kecepatan melalui siklus umpan balik Build-Measure-Learn. Faktanya, salah satu manfaat utama menggunakan teknik yang diturunkan dari lean manufacturing adalah bahwa Lean Startup, ketika mereka berkembang, berada pada posisi yang tepat untuk membangun keunggulan operasional berdasarkan prinsip lean. Mereka sudah mengetahui cara bekerja dengan disiplin, mengembangkan proses yang disesuaikan dengan situasi mereka, dan menggunakan teknik lean seperti Five Whys dan batch kecil. Saat startup yang sukses melakukan transisi menjadi perusahaan mapan, mereka akan berada pada posisi yang tepat untuk membangun budaya eksekusi disiplin yang menjadi ciri perusahaan terbaik dunia, seperti Toyota.

Namun, berhasil tumbuh menjadi perusahaan mapan bukanlah akhir dari cerita. Pekerjaan sebuah startup tidak pernah selesai, karena seperti yang dibahas di Bab 2, bahkan perusahaan mapan pun harus berjuang untuk menemukan sumber pertumbuhan baru melalui inovasi disruptif. Kebutuhan ini muncul lebih awal dalam siklus hidup perusahaan. Tidak lagi dapat diharapkan bahwa startup sukses memiliki waktu bertahun-tahun setelah penawaran umum perdana untuk menikmati kesuksesan sebagai pemimpin pasar. Saat ini, perusahaan sukses menghadapi tekanan segera dari pesaing baru, pengikut cepat, dan startup tangguh.

Akibatnya, tidak lagi masuk akal untuk memandang startup sebagai melewati fase-fase terpisah seperti metafora metamorfosis ulat menjadi kupu-kupu. Baik startup yang sukses maupun perusahaan mapan harus belajar menangani berbagai jenis pekerjaan secara bersamaan, mengejar keunggulan operasional sekaligus inovasi disruptif. Hal ini menuntut cara berpikir portofolio baru, yang akan menjadi topik Bab 12.