Lakukan Hal-Hal yang Tidak Bisa Diskalakan (2013)

 (paulgraham.com)
3 poin oleh GN⁺ 2025-08-17 | 1 komentar | Bagikan ke WhatsApp
  • Y Combinator menyarankan agar pada tahap awal pendirian startup, pendiri secara aktif melakukan 'hal-hal yang tidak bisa diskalakan'
  • Startup sukses seperti Stripe dan Airbnb memilih pendekatan yang langsung dan agresif untuk merekrut pengguna awal
  • Sebagian besar startup sangat rapuh pada awalnya, dan kerja keras pendiri yang turun langsung menjadi kunci pertumbuhan
  • Memberikan pengalaman dan kepuasan yang luar biasa kepada pengguna awal penting untuk pertumbuhan jangka panjang
  • Pada tahap awal, pekerjaan manual alih-alih otomatisasi, menyasar ceruk pasar, dan konsultasi langsung terbukti efektif

Pendahuluan: Realitas Pertumbuhan Startup

  • Banyak calon pendiri mengira startup tumbuh dengan sendirinya, tetapi kenyataannya pendiri harus turun tangan langsung untuk menyalakan percikan pertumbuhan
  • Seperti tuas starter mobil zaman dulu, pada tahap awal proses yang padat tenaga adalah hal yang wajib

Merekrut Pengguna Secara Langsung (Recruit)

  • Sebagian besar startup tidak boleh pasif menunggu pengguna datang, tetapi perlu secara aktif mencari mereka
  • Dalam kasus Stripe, pada awalnya mereka menggunakan strategi akuisisi pengguna yang agresif yang disebut 'Collison installation', yaitu langsung mengambil laptop calon pengguna yang diperkenalkan pada versi beta lalu memasangkan produknya sendiri
  • Alasan para pendiri enggan melakukan hal seperti ini adalah karena takut ditolak, merasa malu, dan meremehkan kecilnya jumlah pengguna
  • Kenyataannya, berkat efek pertumbuhan majemuk, jika pertumbuhan mingguan 10% bisa dipertahankan, dalam 2 tahun jumlah pengguna bisa mencapai jutaan
  • Airbnb juga sangat proaktif sampai mendatangi host langsung di New York untuk membantu mereka mendaftar

Kerapuhan Startup Tahap Awal (Fragile)

  • Hampir semua startup sangat tidak stabil pada awalnya, dan keberhasilan atau kegagalan bisa ditentukan oleh upaya langsung dalam waktu singkat
  • Dibanding ketidakpedulian kritikus luar atau investor, jauh lebih berbahaya jika pendiri sendiri meremehkan nilai bisnisnya
  • Pada tahap awal, alih-alih bertanya 'apakah perusahaan ini akan mengubah dunia?', pendiri perlu bertanya pada diri sendiri, 'seberapa besar ini bisa tumbuh jika saya melakukan upaya yang benar?'
  • Sebagai contoh, pada masa awal Microsoft dan Airbnb juga tampak sangat kecil dari luar, tetapi itu adalah jalur terbaik mereka
  • Pengguna yang cocok sebaiknya dimulai dari orang-orang yang mirip dengan diri sendiri, atau dengan mengidentifikasi kelompok paling antusias di antara pengguna awal lalu memusatkan serangan ke kelompok itu

Memaksimalkan Kegembiraan Pengguna (Delight)

  • Bukan hanya merekrut pengguna, startup juga perlu melakukan upaya luar biasa untuk memberi kepuasan istimewa kepada pengguna yang sudah ada
  • Wufoo membangun kepercayaan awal dengan layanan yang begitu dramatis sampai mengirim surat terima kasih tulisan tangan kepada setiap pendaftar baru
  • Jangan terikat pada pakem layanan pelanggan ala perusahaan besar; tekankan pengalaman yang dipersonalisasi yang hanya bisa diberikan startup pada tahap awal
  • Jika pekerjaan untuk membahagiakan pengguna awal menjadi terlalu banyak sampai sulit ditangani, justru itu adalah sinyal pertumbuhan yang baik
  • Kurangnya pengalaman layanan pelanggan pada pendiri tahap awal adalah salah satu alasan mengapa mereka tidak cukup memanfaatkan keunggulan kompetitif perusahaan kecil

Obsesi pada Pengalaman Pengguna (Experience)

  • Seperti ungkapan Steve Jobs 'Insanely great' (sangat luar biasa), pada tahap awal perlu ada obsesi terhadap pengalaman pengguna
  • Daripada mengejar produk yang terasa sudah selesai, perbaikan melalui interaksi dengan pengguna meski produk masih belum sempurna jauh lebih penting
  • Umpan balik yang diperoleh lewat interaksi langsung dengan pengguna memberi pengaruh terbesar pada pertumbuhan

Memulai dari Pasar yang Sempit (Fire)

  • Seperti Facebook dan Airbnb, gunakan strategi memulai secara sengaja dari pasar yang sangat kecil (misalnya mahasiswa Harvard) lalu mencapai massa kritis di dalam kelompok itu
  • Pada tahap awal, lebih efektif menemukan kelompok early adopter yang merespons paling cepat
  • Program akselerator seperti YC juga bermanfaat untuk pendekatan pasar yang menjadikan startup lain sebagai pelanggan

Strategi Khusus untuk Startup Hardware (Meraki)

  • Karena biaya produksi massal awal besar, startup hardware seperti Meraki dan Pebble membuat para pendirinya merakit produk secara langsung
  • Dengan membuatnya sendiri, akan terjadi pembelajaran empiris seperti optimasi desain dan cara mendapatkan komponen

Pendekatan Ekstrem ke Pengguna ala Konsultasi (Consult)

  • Untuk produk B2B, startup bisa membuat solusi yang disesuaikan seolah sedang berkonsultasi untuk satu pelanggan tertentu, lalu setelah itu berekspansi ke pasar yang berdekatan
  • Petunjuk pertumbuhan muncul dari proses menyesuaikan diri sepenuhnya dengan masalah yang benar-benar dibutuhkan pelanggan
  • Pada tahap awal, ada juga cara dengan menggunakan perangkat lunak itu langsung atas nama pelanggan, atau segera mencerminkan fitur yang mereka butuhkan

Strategi Serba Manual (Manual)

  • Saat jumlah pengguna masih sedikit, pekerjaan bisa dilakukan secara manual, lalu secara bertahap dialihkan ke otomatisasi
  • Pada awalnya Stripe menangani 'pembukaan akun instan' secara manual untuk menyampaikan pengalaman pengguna yang diinginkan
  • Jangan terobsesi dengan otomatisasi sejak awal; yang lebih penting adalah memahami produk dan masalah nyata pelanggan melalui pekerjaan manual

Ketidakefisienan 'Peluncuran Besar' (Big)

  • Strategi meluncurkan produk secara besar-besaran sekaligus, atau menyerahkan pertumbuhan pada kemitraan dengan perusahaan besar, umumnya gagal
  • Pada tahap awal, fokus harus pada mendapatkan sejumlah kecil pengguna, dan upaya yang intens serta metode langsung jauh lebih penting
  • Perhatian pengguna tumbuh perlahan, melalui pengelolaan langsung dan pemberian kepuasan

Pendekatan Dua Dimensi pada Ide Startup (Vector)

  • Startup yang berhasil perlu dipikirkan sebagai vektor: produk (apa yang akan dibuat) + strategi yang tidak bisa diskalakan (hal apa yang akan dilakukan sendiri pada awalnya)
  • Tindakan langsung di tahap awal seperti ini meninggalkan pengaruh positif pada DNA produk
  • Upaya langsung pada awalnya, seiring waktu, berubah menjadi produk dan budaya organisasi, lalu menjadi mesin pendorong pertumbuhan yang berkelanjutan

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-17
Pendapat Hacker News

  • Ada satu hal dari podcast yang baru-baru ini saya dengar yang benar-benar terasa relevan: masalah terbesar startup adalah inersia. Dunia tidak terlalu menyukai kita, juga tidak merasa membutuhkan kita... kitalah yang harus membalikkan keadaan itu. Kita harus menciptakan momentum sepenuhnya dari nol, dan pekerjaan terpenting yang harus dilakukan pendiri adalah tindakan yang membalikkan inersia. Ini juga benar-benar terjadi secara fisik. Dunia berada dalam keadaan diam, dan kita harus menciptakan momentum sendiri seperti saat pertama kali menyalakan mesin. Kalau dilihat dari sudut pandang ini, tidak aneh jika pada awalnya kita melakukan hal-hal yang tidak scalable. Kita bukan sedang mengoptimalkan mesin yang sudah berjalan, melainkan masih berada pada tahap memutar satu per satu agar mesinnya benar-benar mulai hidup. Poin Paul Graham adalah bahwa pertumbuhan yang scalable atau otomatisasi adalah masalah setelah itu. Dengan pendekatan manual, kita harus menemui pengguna satu per satu agar benar-benar belajar apa yang berhasil. Ini adalah proses membangun bukti bahwa pengguna menganggap kita dibutuhkan, sambil membuktikan apa yang layak untuk diskalakan

    • Menurut saya, nilai sejati dari kerja manual adalah belajar secara langsung. Salah satu pelanggan saya dulu secara pribadi memilih berita finansial dan sekuritas penting mingguan lalu menyajikannya sebagai daftar terkurasi. Itu adalah niche kecil di dalam niche lain yang juga kecil, dan para pengguna benar-benar menyukainya. Namun pada suatu titik, semuanya ingin diotomatisasi, lalu kontennya membengkak tanpa seleksi dan informasi mirip spam ikut meningkat, sehingga nilainya hilang; pada akhirnya produknya sendiri juga ikut berjalan ke arah yang sama. Beritanya memang jadi lebih banyak, tetapi karena tidak lagi dipilih dan diedit langsung, rasio sinyal terhadap noise justru memburuk. Faktanya, kerja manual meskipun cakupannya terbatas jauh lebih bernilai. Banyak perusahaan tidak memahami hal itu dan terlalu cepat terobsesi pada otomatisasi. Contoh lain, ada klien yang dulu memeriksa harga pesaing secara manual. Karena ingin otomatisasi, dibuatkan scraper sederhana berbasis Excel. Awalnya mereka puas, tetapi kemudian baru sadar bahwa dengan tidak lagi menjelajahi situs pesaing secara langsung, mereka kehilangan kesempatan belajar tentang produk baru, tren katalog, dan sebagainya. Akhirnya mereka kembali menjelajah secara manual, dan scraper hanya dipakai untuk analisis harga sederhana. Namun sebagian besar pelanggan saya yang lain terus melewatkan kesempatan belajar penting karena lebih fokus pada otomatisasi daripada hakikat produk dan masalahnya

    • Itulah sebabnya ucapan “buatlah sesuatu yang diinginkan orang” menjadi pepatah terkenal di dunia startup

    • Saya sangat suka dengan ungkapan “membalikkan inersia”, tetapi pendekatan ini tidak berlaku untuk semua startup. Menurut framework Arc dari Sequoia, ada tiga cara: Hair on Fire (rasa sakit yang mendesak, momentum itu penting), Hard Fact (ada masalah, tetapi kebiasaan harus diubah), dan Future Vision (orang-orang bahkan belum percaya hal itu mungkin, jadi kepercayaan harus dibangun lebih dulu). Mencapai hasil dengan melakukan langsung hal-hal yang tidak scalable itu wajib di ranah Hair on Fire, tetapi untuk dua sisanya, pendekatannya lebih ke menyusun ulang realitas itu sendiri atau lebih dulu membangun kredibilitas

  • Teori saya adalah ini bisa dibagi menjadi tiga tahap: Not Scaling (belum scaling), Scaling (scaling), dan Antiscaling (tahap dibenci). Not Scaling adalah tahap membangun moat sendiri di pasar. Scaling adalah saat produk sudah cukup populer sehingga pelanggan mendatangkan pelanggan baru, dan kita hanya perlu menangani permintaan yang meningkat, misalnya dengan memecah server atau DB. Antiscaling adalah saat Anda berubah menjadi perusahaan yang menjadi sumber masalah web modern. Badan intelijen mulai menghubungi Anda karena masalah penggunaan oleh teroris, dan pemerintah kota atau pemerintah pusat mulai membuat lisensi atau hukum regulasi khusus untuk menargetkan Anda. Pendiri menjadi terkenal sampai muncul meme dan orang bisa melacak lokasinya. Kita tidak perlu menguasai dunia; cukup menghasilkan uang. Orang-orang yang datang dengan dalih ingin mengubah dunia jarang menghasilkan hal yang benar-benar baik, jadi yang penting adalah membuat sesuatu yang berguna

    • Ucapan "cukup menghasilkan uang" mengingatkan saya pada Goodhart’s Law: ketika suatu metrik (misalnya pendapatan) berubah menjadi tujuan, metrik itu tidak lagi menjadi ukuran yang baik

    • Sudut pandang ini terasa terlalu bias. Ini tidak membahas ketidakpedulian ekstrem saat Anda membuat sesuatu yang sama sekali tidak diinginkan siapa pun. Dan sebenarnya kasus yang lebih umum adalah sedikit berhasil dengan sangat biasa-biasa saja. Tidak ada yang membencinya, tetapi juga tidak ada yang benar-benar mencintainya. Agak positif, tetapi tanpa hype atau keunggulan kompetitif yang eksklusif, jadi tidak ada yang terlalu peduli—kasus seperti inilah yang paling sering terjadi

  • Saya meninggalkan beberapa tautan di bawah karena ingin mengumpulkan lebih banyak contoh terkait

  • Saya ingin membagikan ini karena menurut saya ini layak direkomendasikan kepada semua founder tahap awal dan juga semua karyawan yang bergabung sebagai anggota awal. Bahkan setelah kami tumbuh menjadi lebih dari 15 orang, kami masih menelepon langsung setiap pendaftar baru. Alasannya adalah 1) untuk tahu bagaimana mereka mengenal kami 2) apakah mereka butuh bantuan saat pertama kali memakai produk 3) dan secara implisit untuk menunjukkan bahwa tim kami benar-benar peduli secara langsung. Layanan kami adalah platform B2B jadi sepertinya ini bekerja lebih baik, dan meskipun targetnya developer, ketika benar-benar ditelepon, setelah melewati bagian “bukan, ini bukan telepon penjualan”, kami justru sering mendapat masukan yang sangat jujur dan bagus

  • Ada banyak suara yang mengkritik Paul Graham, tetapi inti tulisan ini sendiri bisa diringkas sebagai jangan melakukan premature optimization. Artinya, jangan bertindak seperti perusahaan besar. Jika pendiri langsung mengerjakan pekerjaan operasional, meskipun tidak efisien, mereka bisa mengumpulkan pengalaman nyata dan umpan balik; dan dengan tidak buru-buru mengadopsi solusi yang scalable sejak awal, mereka juga bisa mendapat umpan balik lebih cepat. Ini juga efektif untuk membangun diferensiasi sendiri. Menurut saya, ada baiknya menanamkan kalimat “lakukan hal-hal yang tidak scalable” secara harfiah di kepala

    • Karena khawatir layanan tidak akan sanggup menahan popularitas atau permintaan yang berlebihan, orang sering kali membangun sistem yang terlalu scalable sejak tahap yang sebenarnya belum membutuhkan itu sama sekali. Namun saya merasa vertical scaling (cara menambah resource saja) terlalu diremehkan. Dengan hanya menambah resource pada backend monolitik yang ada, kita masih bisa membeli waktu untuk benar-benar memahami layanan. Yang terpenting, itu membuat kita meninjau ulang apa sebenarnya “nilai inti” yang disukai pengguna dari produk kita. Lagi pula, jika pengguna benar-benar mencintai produk kita, mereka akan memaklumi sedikit kekurangan performa di tahap awal. Pada masa awal Twitter, “fail whale” sering muncul, tetapi karena fungsi yang diinginkan tetap berjalan dengan baik, pertumbuhannya tetap meledak. Pada tahap awal, yang terpenting adalah umpan balik cepat, iterasi, dan kepuasan pelanggan. Eksperimen, komunikasi dengan pengguna, dan observasi harus didahulukan daripada scaling. Saat firasatnya benar-benar datang, barulah masuk akal memikirkan scaling, dan kapan momen itu datang tidak bisa diprediksi. Teknologi hanyalah alat; sekalipun kita punya biola mewah, yang paling penting tetap membuat “musik yang bagus” lebih dulu

    • Kita harus ingat bahwa tidak semua bisnis yang sukses menargetkan ratusan juta atau miliaran pengguna. Saya bekerja membuat internal tool, dan skala lingkungan kami sudah tetap, tidak terlalu sensitif terhadap performa, serta tidak ada trafik yang tidak menentu. Namun ada anggota tim kami yang terobsesi menulis ulang seluruh kode ke bahasa yang hanya dia sendiri pahami demi memangkas beberapa milidetik. Tidak ada yang peduli, dan yang dia bangun hanya meninggalkan risiko maintenance. Setelah dia keluar, atas keputusan manajer semuanya dibuang; seandainya desainnya lebih sederhana dan lebih lambat, orang lain pasti jauh lebih mudah mengambil alih

    • “Premature optimization” dan “Do Things That Don’t Scale” agak berbeda secara halus. Yang pertama mengasumsikan bahwa versi yang scalable adalah yang “optimal”, sedangkan yang kedua menyiratkan bahwa cara yang tidak scalable justru bisa jadi yang terbaik. Misalnya, pendekatan di mana CEO sendiri menangani kontak mungkin jauh lebih baik daripada shared inbox yang mengurus semuanya. Cara yang scalable (formulir kontak) bukanlah sesuatu yang optimal sejak awal, melainkan dalam praktiknya adalah penurunan kualitas proses. Scaling sendiri bukanlah kejahatan, tetapi ada kompleksitas yang tak terhindarkan dan jarak dengan pelanggan yang ikut muncul. Kita harus menyadari bahwa tergantung situasinya, proses bisa menjadi lebih buruk. Menurut saya, pesannya lebih dekat ke “mencegah degradasi proses yang terlalu dini”

    • Pada akhirnya ini bisa diringkas menjadi "jangan mencoba menyelesaikan masalah yang belum ada"

    • Nasihat “jangan bertindak seperti perusahaan besar” sejujurnya berlaku untuk organisasi ukuran apa pun. Sebagai konsultan, saya menghabiskan banyak waktu untuk mencegah startup atau UKM mengadopsi aturan dan kebijakan organisasi besar hanya karena mereka adalah badan hukum. Kebijakan seperti itu baru diperlukan pada skala ratusan orang, tetapi dalam organisasi kecil justru menghambat. Contohnya k8s, nosql, kebijakan keamanan yang lebih ketat dari yang dibutuhkan, dan sebagainya. Panduan budaya internal Netflix juga menunjukkan hal ini dengan baik. Jika organisasinya kecil, dengan asumsi perekrutannya bagus, seharusnya ada delegasi wewenang yang nyata sehingga tiap anggota tim bisa mengambil keputusan sendiri. Tidak perlu mengurung semuanya dalam aturan sampai masalah atau risikonya benar-benar membesar

  • Stripe adalah salah satu perusahaan paling sukses di portofolio YC, dan masalah yang diselesaikan Stripe benar-benar sangat mendesak dan genting. Dalam situasi di mana hampir semua orang mungkin akan memilih menunggu pengguna datang, Stripe justru terkenal karena sangat agresif dalam mengakuisisi pengguna. Itu terjadi 12 tahun lalu, dan saat itu saya tidak menyangka mereka akan tumbuh sebesar ini. Andai saja dulu saya bisa berinvestasi

  • Tentu saja ada survivor bias. Namun saya sepenuhnya setuju dengan poin bahwa masa ketika kita benar-benar mengerjakan sesuatu sendiri dan belum mengotomatisasikannya itu penting. Hanya dengan begitu kita bisa menanamkan pemahaman yang lebih presisi tentang seluruh proses atau sistem di kepala kita, dan itu tidak mungkin didapat hanya dari slide atau dokumen. Dalam istilah sekarang, ini bisa disebut proses membangun “taste”. Kita mengembangkan rasa tentang apa yang bagus dan mengapa itu bagus, lalu membentuk sudut pandang yang tegas pada titik-titik pengambilan keputusan yang bahkan tidak dipikirkan orang lain. Karena sekarang ada AI, banyak tempat yang terlalu cepat melompat ke otomatisasi, tetapi di www.socratify.com kami masih membuat konten secara manual. Semua orang berkata semuanya harus dibuat dengan AI, tetapi tujuan utama kami adalah mengkurasi konteks dan kualitas dengan benar. Proses verifikasi mungkin nanti bisa diotomatisasi sampai batas tertentu, tetapi dari banyak pengalaman tidak langsung, kami juga melihat bahwa sangat sulit menggantikan otak dan wawasan manusia sepenuhnya

  • YC mengubah permainan karena membuat seed funding jauh lebih mudah. Saya yakin Paul Graham, Jessica Livingston, dan tim YC melihat masalah dalam sistem lama dengan tepat lalu memperbaikinya. Sebelum YC muncul, seed funding nyaris mustahil didapat. Sistemnya timpang, dan rasanya seperti presentasi di kantor bank tua di hadapan delapan partner yang sedang marah. Kalau ada pihak yang layak diberi kredit, mereka memang pantas mendapatkannya karena merekalah yang memperbaiki pasar ini

    • Saya rasa bagian ini bisa diperdebatkan. Meskipun pendanaan dibuka untuk lebih banyak orang, pada kenyataannya baik sebelum maupun sesudah YC, memperoleh seed funding tetap sulit. Perbedaannya adalah, dengan munculnya pemain besar seperti YC, posisi founder bootstrapping justru melemah. Pada suatu titik, para founder mulai mengikuti tema yang dipilih YC, bukan hal yang benar-benar mereka inginkan. Kesempatan founder untuk menekuni hal yang benar-benar ingin mereka kuasai jadi berkurang

  • Saya berharap perusahaan besar seperti OpenAI membaca “Do Things That Don’t Scale” dengan serius dan benar-benar menjadikannya rujukan. Dengan modal sebesar itu, mereka seharusnya bisa membeli lisensi data yang diperlukan secara sah. Namun mereka hanya memilih cara yang scalable (scraping, stealing), seolah berharap bahwa kalau mereka mengambil banyak hal diam-diam, pada akhirnya orang tidak akan tahu, atau protes baru akan datang belakangan. Seakan-akan mereka berharap situasi saat para pembuat konten saat ini tidak tahu bahwa karya mereka dipakai sebagai data pelatihan AI tanpa dibayar sepeser pun akan berlalu begitu saja

    • Ini menurut saya lebih berkaitan dengan keserakahan untuk tidak mengeluarkan uang yang memang inheren dalam kapitalisme, daripada masalah scaling

  • Ini adalah tulisan pertama yang saya lihat di Hacker News. Setiap kali sesekali muncul lagi, kenangan lama terasa hidup kembali