50 Pelajaran yang Dipelajari Saat Membangun Produk yang Sukses [Artikel terjemahan]

1. Tim kecil (6 orang atau kurang) dapat membuat produk yang hebat, tetapi mereka harus diberi otonomi penuh atas penetapan tujuan, penentuan prioritas roadmap, pemilihan metrik, komunikasi dengan pengguna, dan deployment kode yang cepat.

2. Kesuksesan produk bergantung pada orang-orang yang membuatnya. Kuncinya adalah menetapkan standar rekrutmen yang tinggi, karena kemampuan talenta bersifat akumulatif. Perekrutan yang salah memperlambat tim lebih besar daripada faktor lain mana pun.

3. Kepercayaan sangat penting untuk membuat produk yang hebat. Kurangnya kepercayaan adalah salah satu bottleneck terbesar dalam tim, dan biasanya merupakan akibat dari merekrut talenta yang tidak memenuhi standar atau tidak memberikan umpan balik perbaikan dengan benar kepada orang tersebut.

4. Kepercayaan juga dibangun melalui transparansi. Bekerjalah secara terbuka, lakukan diskusi di ruang terbuka, dan dokumentasikan pekerjaan. Dengan begitu, semua orang dapat berbagi konteks yang dibutuhkan dan menghilangkan konflik politik yang terjadi di banyak perusahaan.

5. Andalkan kepercayaan dan umpan balik, bukan proses. Ini adalah salah satu nilai inti kami. Membangun dan mengembangkan sesuatu yang diinginkan orang adalah persoalan yang penuh nuansa, jadi kami mempercayai penilaian karyawan. Jika ada yang salah, kami memberikan umpan balik secara langsung.

6. Manajemen membagikan tujuan perusahaan, lalu tim produk (insinyur) menentukan apa yang akan dibangun dan sasaran mereka sendiri untuk mencapainya. Kedua belah pihak harus meninjau dampak nyata melalui metrik dan umpan balik pengguna.

7. Produk bergantung pada ideal customer profile (ICP). ICP menentukan untuk siapa Anda membangun, dan merupakan faktor terpenting dalam memutuskan apa yang akan dibuat. ICP yang tepat mendefinisikan bukan hanya pelanggan target, tetapi juga setiap aspek dari produk dan strategi go-to-market.

8. Untuk menemukan ICP, mulailah dengan menebak lalu mengujinya. Ajukan pertanyaan saat pendaftaran, bandingkan retensi, identifikasi power user, dan lakukan survei NPS. Saat informasi dan keyakinan bertambah, tambahkan detail lebih lanjut.

9. Buat prinsip produk. Kami menjadikan “menyediakan semua alat yang diperlukan untuk mengevaluasi kesuksesan, menjadi yang terdepan, dan berperan sebagai sumber kebenaran bagi data pelanggan serta produk” sebagai prinsip. Ini memberi bahasa bersama untuk mendiskusikan ide dan membuat keputusan.

10. Petakan semua hal yang mungkin diinginkan pengguna. Ini diperlukan saat menentukan prioritas roadmap. Dengan begitu, Anda tidak akan melewatkan ide-ide hebat yang berada di luar cakrawala.

11. Produk lebih dari sekadar fitur. Produk adalah brand dan pengalaman produk yang diberikan kepada orang lain. Besarnya investasi pada tiap fitur, orang yang direkrut, keputusan pembangunan, fitur utama, komunikasi pelanggan, dan kebijakan harga semuanya membentuk keunikan.

12. Situs web adalah kesan pertama dari produk. Situs yang membosankan dan terasa seperti template memberi sinyal bahwa produk dan tim di baliknya lemah. Membuat situs yang unik sesuai ideal customer profile Anda dapat mencegah hal itu dan mendorong akuisisi pengguna.

13. Terkadang masalahnya bukan pada produk, melainkan pada pasar. Misalnya, ketika Tom Blomfield, pendiri Monzo sekaligus partner YC, membuat layanan pembagian tagihan untuk teman kuliah, ia diberi saran untuk berhenti membangun dan fokus pada akuisisi pengguna. Setelah 4 minggu cold calling dan hanya mendapat satu pengguna, ia tahu sudah waktunya pivot.

14. Jika Anda pivot, lakukan secara besar-besaran. Stewart Butterfield mengubah dua perusahaan game menjadi Flickr dan Slack. Reid Hoffman, co-founder LinkedIn, mengatakan bahwa agar pendiri startup bisa pivot dari kegagalan menuju kesuksesan, mereka harus melakukan slash and burn pada sisa bisnisnya. Jika masih terlihat mirip, pergilah lebih jauh.

15. Seperti kata Jason Fried dari 37signals, “Anda tidak bisa memvalidasi ide. Karena ide itu belum ada, Anda harus benar-benar membuatnya. Pasarlah yang akan memvalidasinya.”

16. Rencana itu berguna, tetapi bukan untuk diikuti secara kaku. Eksekusi yang baik bukanlah menjalankan rencana tertentu, melainkan terus mengulang hal yang paling penting. Nilailah orang berdasarkan apa yang mereka kirim, seberapa sering mereka melakukan deployment, dan dampaknya, bukan dari apakah mereka “mengikuti rencana”.

17. Menunda sesuatu “satu minggu lagi” hampir selalu merupakan ide buruk. Jika sikap ini menumpuk selama berbulan-bulan, momentum akan turun drastis. Semakin cepat Anda menyerahkannya ke tangan pengguna, semakin cepat Anda belajar nilainya dan bisa memperbaikinya.

18. Kurangi pekerjaan yang sedang berjalan. PR seharusnya selesai dalam sehari, mulailah hari dengan merespons permintaan review dari orang lain, merge kapan saja, deploy di balik feature flag, dan uji di production. Semua ini mengurangi beban konteks pekerjaan.

19. Deployment cepat adalah inti filosofi pengembangan produk kami, tetapi ada trade-off. Pengadaan teknologi, rapat perencanaan, ritual agile, dan review metrik menjadi prioritas kedua. Kerja asinkron membuat hal ini lebih memungkinkan.

20. Adopsi teknologi baru ke produk hanya saat menghadapi masalah mendesak seperti biaya berlebih, masalah scaling, atau kebutuhan pelanggan. Untuk menemukan teknologi penyelesaiannya, tanyakan bagaimana tim Anda atau tim lain pernah menyelesaikan masalah serupa secara langsung.

21. Deadline buatan tidak membuat tim bergerak lebih cepat. Sebaliknya, itu menciptakan lingkaran bencana berupa tumpukan technical debt dan burnout. Hilangkan proses yang memperlambat tim dan beri otonomi deployment cepat pada tim kecil.

22. Cara lain untuk deployment lebih cepat adalah menghilangkan desain default. Setelah design system berjalan, biarkan insinyur yang membangun. Jika perlu, rapikan apa yang sudah dikirim lewat design review.

23. Feature flag memungkinkan product engineer melakukan deployment perubahan dengan cepat, mengujinya di production, dan mendapatkan umpan balik nyata dari pengguna. Saat sesuatu tidak berjalan sesuai harapan, ia juga berfungsi sebagai kill switch untuk mengurangi risiko.

24. Di PostHog, komunikasi terbaik adalah pull request. Tidak seperti pesan atau issue, pull request langsung mengubah umpan balik menjadi dampak. Ini cocok dengan kecenderungan mendahulukan tindakan dan menciptakan feedback loop yang lebih rapat.

25. Perjelas ownership. Ini membuat keputusan tentang apa yang akan dibangun jauh lebih jelas dan cepat. Tim yang menghindari ownership membuang waktu pada perencanaan, brainstorming, rapat, dan manajemen proyek alih-alih deployment.

26. Insinyur mampu memutuskan apa yang harus dibangun. Mereka memahami batasan teknis, mengenali pola fitur, dan tahu cara memecahkan masalah. Namun, bisa ada bottleneck informasi terkait kebutuhan pengguna.

27. Alih-alih mengendalikan insinyur, product manager harus memberi konteks kepada tim produk melalui analisis produk, riset pengguna, dan riset kompetitor.

28. Kebanyakan orang bukan Steve Jobs. Mereka tidak punya visi untuk langsung membangun “secara naluriah” sejak awal, dan juga tidak melukis gambaran besar yang sempurna. Sebaliknya, mereka melakukan deployment, memberikannya ke pengguna, lalu mengulang umpan balik. Semakin cepat kecepatan ini, semakin baik produknya.

29. Rekrut dan andalkan product engineer. Mereka memiliki keterampilan full-stack dan obsesi pada pelanggan yang dibutuhkan untuk membangun produk. Mereka harus mampu berbicara dengan pengguna, melakukan wawancara, merekrut penguji fitur baru, mengumpulkan umpan balik, menangani support, dan merespons insiden.

30. Baca The Mom Test. Buku ini mengajarkan cara berbicara tentang masalah calon pengguna. Intinya ada dua jenis wawancara pengguna: eksplorasi masalah dan validasi solusi. Yang pertama membantu memandu keputusan produk di masa depan, yang kedua membantu meningkatkan pekerjaan yang sedang dilakukan sekarang.

31. Untuk mendapatkan hasil maksimal dari wawancara pengguna, pahami terlebih dahulu siapa pengguna Anda (ICP), bagaimana mereka menggunakan produk, dan apa yang ingin Anda bangun berikutnya. Dengan begitu, wawancara akan memperjelas fokus langkah selanjutnya, bukan menimbulkan kebingungan.

32. Di antara kandidat hal yang bisa dibangun, permintaan support adalah yang paling “nyata”. Ada pengguna tertentu yang mengalami masalah spesifik, jadi jika Anda menyelesaikannya, produk langsung membaik. Perubahan lain tidak seintuitif itu.

33. Ketika insinyur menangani support, itu mendorong ownership atas seluruh siklus hidup produk, dari ideasi hingga implementasi dan pemeliharaan berkelanjutan. Tiap tahap saling terhubung karena membangun konteks atas pain point pelanggan yang nyata dan kode di balik isu tersebut.

34. Dukungan yang ditangani insinyur memperpendek loop antara masalah pengguna dan perbaikan yang dideploy. Staf support, product manager, dan proses perencanaan tidak menghambatnya. Bonusnya, pengguna sangat menyukainya.

35. Menggunakan produk sendiri (dogfooding) membantu meningkatkan kecepatan deployment, mencegah masalah sebelum mencapai pengguna, memperdalam pemahaman produk, dan membangun empati terhadap pengguna. Namun, ini tidak menggantikan percakapan dengan pengguna, umpan balik nyata, atau pelacakan metrik penggunaan.

36. Seperti saat tim produk kami memecahkan kebutuhan sendiri dengan popup wawancara, memecahkan kebutuhan internal adalah cara efektif untuk memvalidasi use case. Jika Anda seharusnya memakai produk sendiri tetapi tidak melakukannya, itu sinyal ada sesuatu yang salah dan harus diperbaiki.

37. Product builder yang hebat selalu membuat prototipe dan bereksperimen. Mereka harus terbiasa membangun MVP dan proof of concept, melakukan deployment pada pekerjaan yang belum selesai, menyerap umpan balik, dan pivot saat gagal. Mereka juga membutuhkan semua keterampilan untuk membangun dari nol, dari infrastruktur hingga desain.

38. A/B test yang sukses memerlukan hipotesis yang baik yang menjelaskan apa yang diuji dan mengapa. Sertakan konteks pengujian, perubahan yang dilakukan, metrik, dan hasil yang diharapkan.

39. Saat bereksperimen dengan produk, sadari bahwa hasilnya bisa gagal dan dihapus. Siapkan agar mudah dihapus dengan feature flag, dan deploy versi yang “cukup baik” alih-alih versi yang sempurna untuk pemeliharaan dan scaling. Jika berhasil, Anda bisa memperbaikinya nanti.

40. Eksperimen produk bisa dilakukan jauh lebih “bodoh” daripada yang Anda kira. Alih-alih membangun fitur penuh, cobalah fake door test. Tambahkan opsi atau tombol yang tidak menuju ke apa pun, lalu lihat apakah orang mengkliknya.

41. Kegagalan eksperimen produk bukan akhir dunia. Di Google, 80–90% eksperimen “gagal”. Ini mungkin tampak seperti pemborosan waktu, tetapi pada skala besar, 10% keberhasilan menutupi semua kegagalan—seperti A/B test tampilan headline di Bing yang meningkatkan pendapatan 12% (lebih dari $100 juta).

42. Saat fokus pada growth, berpikirlah dan prioritaskan seperti growth engineer. Identifikasi area target, pilih metrik representatif, buat hipotesis perbaikan, lalu implementasikan pengujian dengan eksperimen sekecil mungkin.

43. Memasang analytics hampir tidak pernah terlalu dini. Itu masuk akal untuk produk yang belum diluncurkan, tetapi mengatakan “masih terlalu dini” lalu meluncurkan tanpa analytics adalah penghematan palsu. Setelah peluncuran, prioritas bergeser dari deployment secepat mungkin menjadi deployment hal yang benar secepat mungkin.

44. Saat mulai dengan analytics, mulailah dari kecil. Pilih produk atau fitur tertentu, lacak penggunaan dengan autocapture, visualisasikan lewat grafik tren dan retensi, lalu coba deploy fitur yang meningkatkan metrik tersebut. “Kompleks industri modern data stack” membuat semuanya terlihat lebih rumit daripada kenyataannya.

45. Jika Anda tidak tahu metrik awal yang tepat, saya merekomendasikan activation. Metrik ini berada di hulu dari metrik lain, bisa dipengaruhi langsung oleh insinyur, dan berguna bagi seluruh organisasi.

46. Selain activation, retention adalah metrik kunci lain untuk memahami dampak dari apa yang dibangun. Dengan melacak perubahan mingguan, Anda bisa memperkirakan apakah perubahan itu membantu mempertahankan pengguna.

47. Saat mengukur product-market fit, periksa apakah keterlibatan pengguna tumbuh secara eksponensial lebih cepat daripada pertumbuhan pengguna dan apakah retensi menjadi datar (di atas 0%). Setelah itu, lihat apakah retensi pengguna ICP unggul dan apakah pelanggan berbayar termasuk dalam ICP.

48. Review growth memeriksa apakah apa yang dibangun tim memengaruhi metrik penting seperti pendapatan, analisis produk, dan umpan balik pengguna. Di PostHog, ini adalah tanggung jawab utama product manager.

49. Jika Anda membangun beberapa produk, perlakukan masing-masing seperti mini startup. Mereka harus punya keputusan produk, harga, pendapatan, biaya, dan koordinasi dengan tim yang berhadapan langsung dengan pelanggan.

50. Tekunlah pada produk yang menarik. Seperti ditulis James, co-founder PostHog, dalam panduan product-market fit: “Jika tidak menarik, pivot saja. Itu saja. Anda akan mencapai hasil yang lebih besar saat tekun pada hal yang terasa seperti milik Anda sendiri.”