Inspired: How to Create Tech Products Customers Love

Marty Cagan masih muda saat itu, bekerja di HP, terlibat dalam peluncuran produk yang dipersiapkan dengan sangat matang secara teknis.

Timnya kerja keras. Kodenya rapi. Fiturnya lengkap.

Produk itu gagal total di pasar.

Bertahun-tahun kemudian, setelah memegang posisi produk senior di perusahaan seperti eBay dan Netscape, Cagan menyadari kegagalan itu bukan kecelakaan langka. Itu pola yang berulang di hampir semua perusahaan teknologi yang pernah dia lihat dari dekat.

Timnya menghabiskan energi luar biasa untuk membangun sesuatu dengan sempurna, tapi nyaris tidak pernah benar-benar bertanya, apakah orang-orang di luar sana benar-benar menginginkannya.

Cagan mendirikan Silicon Valley Product Group, dan lewat buku ini, dia membongkar cara berpikir yang menurutnya keliru secara fundamental di kebanyakan perusahaan, yaitu memperlakukan product manager sebagai penulis daftar fitur, dan tim engineering sebagai tukang bangun yang cuma dipanggil belakangan.

Cagan menawarkan cara pandang berbeda, satu yang dia lihat langsung bekerja di perusahaan seperti Apple, Google, dan Netflix, tempat tim produk yang sukses justru punya kesamaan pola yang jarang disadari perusahaan lain.

Bagian 1: Discovery dan Delivery, Dua Proses yang Sering Dianggap Satu

Kebanyakan perusahaan menganggap proses membangun produk itu sederhana: kumpulkan requirement, lalu bangun sesuai jadwal.

Cagan bilang, itu justru akar dari kegagalan yang dia lihat berulang-ulang.

Menemukan yang Tepat, Baru Membangunnya dengan Baik

Discovery adalah proses mencari tahu apa yang sebenarnya layak dibangun, lewat pengujian ide secara cepat dan murah sebelum berkomitmen penuh. Delivery adalah proses membangun hal itu dengan benar setelah tahu apa yang dibutuhkan.

Menurut Cagan, kebanyakan perusahaan terlalu banyak berinvestasi di delivery, dan terlalu sedikit di discovery, menghasilkan produk yang dibangun dengan sangat baik secara teknis, tapi ternyata tidak ada yang menginginkannya.

Separuh dari ide yang Anda punya kemungkinan besar tidak akan berhasil, dan ide yang berhasil sekalipun butuh beberapa kali iterasi sebelum benar-benar tepat sasaran. Discovery yang baik adalah cara murah untuk menemukan mana yang layak dilanjutkan, sebelum menghabiskan sumber daya besar di delivery.

Bagian 2: Kenapa Model Waterfall Diam-diam Masih Hidup di Banyak Tim yang Mengaku "Agile"

Tim Anda pakai sprint, standup harian, dan retrospective. Apakah itu berarti tim Anda sudah benar-benar bekerja dengan cara yang efektif?

Cagan bilang, belum tentu.

Agile yang Cuma Dipakai untuk Setengah Proses

Masalah yang sering dia temui, agile hanya diterapkan di tahap delivery, sementara requirement dan roadmap sudah ditentukan lebih dulu lewat proses yang pada dasarnya masih waterfall, penuh asumsi yang tidak pernah divalidasi ke pelanggan nyata.

Engineer dilibatkan terlalu telat, padahal menurut Cagan, merekalah salah satu sumber inovasi terbaik kalau dilibatkan sejak awal proses discovery. Desainer juga sering baru masuk setelah requirement sudah dikunci, sehingga cuma bisa bekerja dalam batasan yang sudah kadung ditetapkan, bukan ikut membentuk solusi terbaik dari awal.

Cacat terbesar dari pendekatan seperti ini, validasi pelanggan terjadi paling akhir, setelah produk selesai dibangun, ketika biaya untuk mengubah arah sudah jauh lebih mahal dibanding kalau divalidasi sejak konsep awal.

Bagian 3: Empat Peran yang Harus Jalan Bersama dari Hari Pertama

Siapa yang seharusnya menentukan apa yang dibangun tim Anda?

Cagan menjawab, seharusnya bukan satu orang, dan bukan pula lewat dokumen requirement yang dilempar dari satu departemen ke departemen lain.

Product Manager sebagai "CEO Kecil" dari Produknya

Product manager bertanggung jawab memahami pelanggan secara mendalam, dari masalah mereka, cara mereka berpikir, sampai bagaimana mereka memutuskan untuk membeli. Tapi ini bukan berarti product manager bekerja sendirian.

Cagan menekankan pentingnya kolaborasi erat antara product manager, desainer, dan tech lead sejak tahap paling awal, bukan sekadar serah terima dokumen dari satu pihak ke pihak lain. Ketiganya harus duduk bersama, berpikir bersama, dan menguji ide bersama sebelum satu baris kode produksi pun ditulis.

Tim produk yang paling sukses yang pernah Cagan amati selalu punya kesamaan ini, kolaborasi yang erat dan berkelanjutan, bukan proses berurutan yang kaku dari satu peran ke peran lain.

Bagian 4: Prototipe Murah Sebelum Komitmen Mahal

Bagaimana Anda tahu sebuah ide produk benar-benar layak dibangun, tanpa harus menghabiskan berbulan-bulan mengerjakannya dulu?

Cagan mendorong penggunaan berbagai bentuk prototipe murah untuk menguji ide secepat dan semurah mungkin sebelum berkomitmen penuh ke pengembangan.

Live-Data Prototype, Cara Menguji dengan Data Nyata dalam Skala Kecil

Salah satu teknik yang dia soroti adalah live-data prototype, mengirim sebagian kecil trafik nyata ke sebuah konsep, lalu mengumpulkan data analitik dari penggunaan nyata itu. Ini hanya butuh sebagian kecil dari usaha membangun produk penuh, tapi bisa memberi nilai validasi yang sangat besar.

Kesalahan yang sering Cagan lihat, tim langsung membangun fitur penuh berdasarkan asumsi, alih-alih menguji versi murah dan cepat terlebih dahulu untuk melihat apakah asumsi itu benar sebelum menghabiskan sumber daya besar.

Bagian 5: Tim yang Diberdayakan, Bukan Tim yang Cuma Menjalankan Perintah

Ada dua jenis tim produk yang Cagan amati di berbagai perusahaan. Satu jenis diberi daftar fitur untuk dibangun. Jenis lain diberi masalah untuk dipecahkan.

Perbedaannya, menurut Cagan, menentukan hasil akhir yang jauh berbeda.

Diberi Masalah, Bukan Diberi Instruksi

Tim yang diberdayakan diberi masalah bisnis nyata untuk dipecahkan, lengkap dengan konteks strategi dan batasan yang jelas, lalu diberi ruang untuk menentukan sendiri solusi terbaik lewat proses discovery yang mereka jalankan.

Tim yang sekadar menjalankan fitur biasanya berakhir jadi tim eksekusi proyek, mengukur kesuksesan dari seberapa tepat waktu fitur dirilis, bukan dari seberapa besar dampak nyata fitur itu bagi pelanggan dan bisnis.

Cagan berargumen, perusahaan yang benar-benar sukses jangka panjang di industri teknologi hampir selalu memilih model tim yang diberdayakan, meski ini membutuhkan kepercayaan lebih besar dari level manajemen di atasnya.

Pelajaran untuk Hari Ini

1. Investasikan Waktu Lebih Banyak di Discovery, Bukan Cuma di Delivery Sebelum membangun fitur penuh, uji dulu ide Anda lewat cara yang murah dan cepat untuk memastikan itu benar-benar dibutuhkan pelanggan.

2. Libatkan Engineer dan Desainer Sejak Tahap Paling Awal Jangan tunggu sampai requirement dikunci baru melibatkan mereka. Kolaborasi sejak awal sering menghasilkan solusi yang jauh lebih baik.

3. Gunakan Prototipe Murah untuk Memvalidasi Asumsi Sebelum Berkomitmen Penuh Live-data prototype atau bentuk prototipe murah lainnya bisa menghemat banyak sumber daya dibanding langsung membangun fitur penuh berdasarkan tebakan.

4. Beri Tim Anda Masalah untuk Dipecahkan, Bukan Cuma Daftar Fitur untuk Dibangun Tim yang diberdayakan dengan konteks jelas biasanya menghasilkan solusi dengan dampak jauh lebih besar dibanding tim yang cuma menjalankan instruksi.

Penutup

Inspired ditulis oleh seseorang yang sudah melihat dari dekat cara kerja tim produk terbaik di dunia, sekaligus menyaksikan langsung betapa seringnya perusahaan lain mengulangi kesalahan dasar yang sama, membangun sesuatu dengan sempurna secara teknis, tapi tidak ada yang menginginkannya.

Buku ini menjadi salah satu bacaan wajib di dunia product management bukan karena menawarkan trik cepat, melainkan karena membongkar cara berpikir yang keliru sejak akarnya, yaitu anggapan bahwa membangun produk hebat cuma soal eksekusi yang rapi, bukan soal menemukan masalah yang tepat untuk dipecahkan lebih dulu.

Di era ketika kecepatan eksekusi semakin mudah dicapai berkat berbagai tools dan otomatisasi, kemampuan menemukan masalah yang tepat untuk dipecahkan justru menjadi pembeda yang lebih menentukan antara produk yang sukses dan produk yang, meski dibangun dengan sempurna, akhirnya sepi peminat.

Pertanyaan untuk Anda, berapa banyak waktu tim Anda dihabiskan untuk memvalidasi apakah sebuah ide layak dibangun, dibanding waktu yang dihabiskan untuk benar-benar membangunnya?

Tentang Buku Asli