Pelajaran dari menjalankan bisnis selama 4 tahun di pasar SaaS yang sangat kompetitif

xguru · 2025-04-14T11:01:01+09:00

OnlineOrNot, yang didirikan oleh Max Rozen, dimulai di pasar yang sudah memiliki lebih dari 200 produk pesaing Pada awalnya banyak produk sulit digunakan, lalu setelah itu banyak sekali produk pesaing bermunculan dan cepat menghilang Beberapa produk pesaing menerima pendanaan VC dan diakuisisi perusahaan besar, lalu berkembang ke arah pengalaman pengguna yang makin memburuk OnlineOrNot menargetkan bisnis yang berkelanjutan dalam jangka panjang dengan pendanaan mandiri Penulis masih mempertahankan pekerjaan penuh waktu sambil terus mengembangkan SaaS secara konsisten Ia menulis refleksi tahunan, dan sebagian pelajaran yang dulu diyakini ternyata terbukti salah seiring waktu Prinsip-prinsip yang tidak berubah Selama bertahun-tahun menjalankan bisnis, ada banyak hal yang dipelajari, tetapi tetap ada prinsip inti yang tidak berubah dan terus dipertahankan Menginvestasikan 2 jam setiap hari kerja Bahkan sebelum memulai OnlineOrNot, ia sudah menghabiskan 2 jam setiap pagi sebelum berangkat kerja untuk fokus pada proyek pribadi Dengan memanfaatkan waktu ini, ia menyelesaikan ratusan tulisan, satu buku, dan beberapa proyek perangkat lunak Yang lebih penting daripada berapa banyak waktu yang dihabiskan per hari adalah upaya konsisten setiap hari itu sendiri Untuk mengamankan waktu ini, ia bangun 2 jam lebih awal dan menyesuaikan rutinitas hariannya Tidak mengerjakan side project lain Seperti pepatah “mengejar dua kelinci tidak akan menangkap satu pun”, ia memilih fokus pada satu hal Ada orang-orang luar biasa yang bisa membuat beberapa proyek sukses, tetapi ia mengakui dirinya berbeda Proses naik dari $0 ke $500 MRR adalah bagian tersulit dan menurutnya tidak perlu diulang berkali-kali Ia fokus pada model yang sudah berjalan, dan memilih pendekatan pemasaran dengan sudut pandang yang sama Prioritas utama adalah menyelesaikan rasa sakit pelanggan Saat pengguna mendaftar, email otomatis dikirim dengan pertanyaan “Mengapa Anda mendaftar?” Semua email dibaca dan dibalas langsung, dan inilah yang menjadi insight utama untuk peningkatan produk Pahami apa yang membuat pengguna tidak nyaman, lalu benar-benar selesaikan itu Mengulang dengan gigih dan terus memperbaiki Jika ada pekerjaan yang tidak bisa dirilis dalam 2 jam, ia mengecilkan cakupannya lalu merilis lebih dulu Memang tidak selalu bisa pas 2 jam, tetapi ia lebih suka merilis versi awal dengan cepat lalu memperluas fiturnya Jika mencoba membuat semua fitur sekaligus sebelum rilis, motivasi justru hilang dan fokus buyar Menyelesaikan fitur secara bertahap di balik feature flag jauh lebih efektif Pelajaran yang dipetik Baca beberapa buku saja lalu langsung buat Saat memulai, ia membaca puluhan buku bisnis untuk mengurangi kesalahan Namun pada akhirnya ia menyadari bahwa belajar dengan melakukan kesalahan sendiri adalah yang paling efektif Contoh: berhasil masuk halaman depan Hacker News dan mendatangkan 6000 pengunjung, tetapi hanya satu digit pengguna yang benar-benar sampai ke aplikasi Sebanyak 75% pengguna drop off di form pendaftaran → hanya dengan menambahkan satu opsi login OAuth, tingkat drop-off membaik hingga 50% Jika harus memulai lagi, ia hanya akan membaca tiga buku ini lalu langsung mulai: The Mom Test (Rob Fitzpatrick) Deploy Empathy (Michele Hansen) Badass: Making Users Awesome (Kathy Sierra) Jika butuh detail praktis tentang operasional SaaS, ia juga merekomendasikan The SaaS Playbook (Rob Walling) Menyelesaikan masalah lebih penting daripada menjual langganan Tujuan SaaS bukan menjual langganan, melainkan menyelesaikan rasa sakit pelanggan Pola pikir “kalau terus bikin fitur, suatu saat orang akan memakainya” perlu diubah menjadi “mari selesaikan masalah yang menjengkelkan dalam pekerjaan pengguna” SaaS hanyalah salah satu cara menyelesaikan masalah; selain itu juga ada pendekatan lain seperti screencast, dokumentasi, tulisan, buku, workshop, contoh kode, dan sebagainya Bangun kecil-kecil dan rilis sesering mungkin Pengguna memang mengusulkan ide fitur, tetapi pada praktiknya jarang benar-benar dipakai Orang yang baru memulai SaaS mudah merasa terlalu bersemangat hanya karena ada seseorang yang mau berbicara, lalu langsung membangun fitur begitu saja Tanyakan dulu bagaimana fitur itu akan digunakan, lalu teliti juga bagaimana pengguna lain menyelesaikan masalah serupa, kemudian implementasikan versi minimal dulu untuk melihat responsnya Pendekatan strategis untuk membangun fitur yang dipakai banyak orang lebih penting daripada membuat “fitur kepingan salju” yang hanya digunakan satu orang Menghapus fitur yang dibuat dalam beberapa jam memang menyakitkan, tetapi menghapus fitur yang memakan waktu berbulan-bulan jauh lebih menyakitkan Rilis dulu, pikirkan skalanya nanti Versi awal OnlineOrNot diluncurkan cepat tanpa optimasi arsitektur Pada kenyataannya ada bug yang membatasi sistem hanya bisa menangani sekitar 100 pengecekan, dan saat masalah terjadi, UI yang ditampilkan ke pengguna hanya sekadar “Error!”, jadi kondisinya sangat belum matang Namun penulis memilih lebih baik dikritik karena UI yang belum selesai daripada membuang waktu membuat fitur yang tidak perlu Karena tidak ada jaminan ribuan pengguna akan datang sejak awal, yang lebih penting adalah validasi secepat mungkin Sebagai langkah sementara, database di-upgrade ke paket yang lebih tinggi untuk menambah kapasitas pengecekan Dalam beberapa jam, sistem kemudian direfaktor menjadi arsitektur yang bisa menangani jutaan pengecekan, dan layar error juga diperbaiki Menjalankan program early access Pada tahap awal pengembangan produk, mayoritas pengguna cukup toleran terhadap fitur yang belum sempurna Seiring waktu, makin banyak pengguna yang mengharapkan produk yang lebih matang Untuk mengatasi ini, ditambahkan checkbox “ikut program early access” di setiap akun pengguna Peserta bisa mencoba fitur terbaru yang belum sepenuhnya selesai lebih dulu dan memberikan feedback Ini berguna sebagai cara menyeimbangkan testing dan feedback Perkenalkan free trial secepat mungkin Belakangan ini nasihat umum yang sering terdengar adalah “free plan terlalu sulit diseimbangkan, jadi jangan lakukan” Namun pada tahap awal, free plan efektif untuk word-of-mouth dan akuisisi pengguna Kekurangannya, jika perbedaan antara free plan dan fitur berbayar terlalu besar, maka harus ada cara agar pengguna bisa mencoba fitur yang bagus Baru 11 bulan setelah mulai, ia menambahkan pertanyaan “Apakah Anda ingin memulai free trial?” dalam proses onboarding Makna sebenarnya seperti ini: > “Apakah Anda ingin mencoba fitur bagus selama 14 hari lalu memutuskan, atau memakai produk selama beberapa bulan dengan fitur terbatas lalu akhirnya kecewa?” Setelah itu, ia bereksperimen dengan memberikan free trial secara default kepada semua pengguna Hanya eksperimen ini saja membuat tingkat pertumbuhan bulanan naik lebih dari 2x Kesimpulannya: Pesan “Ini layanan berbayar. Jika ingin terus memakai fitur yang bagus, kami butuh informasi pembayaran Anda” jauh lebih efektif secara bisnis daripada “Ini layanan gratis. Kalau banyak dipakai mungkin akan berbayar” Dokumentasi adalah produk itu sendiri Dulu sering ada anggapan “developer tidak membaca dokumentasi”, tetapi itu sepenuhnya salah Sebagian pelanggan ideal memuji dokumentasi OnlineOrNot, dan sejak itu ia berinvestasi besar pada dokumentasi Dokumentasi API juga dibangun sendiri agar pengalaman pengguna bisa dikendalikan sepenuhnya Dari pengamatan lewat alat analitik produk: Pengguna mengalami masalah di UI, lalu setelah membuka dokumentasi menemukan fiturnya dan tetap melanjutkan penggunaan produk Jika tidak menemukan informasi yang diinginkan, mereka tidak membuat check dan pergi Kualitas dokumentasi berhubungan langsung dengan retensi pengguna Rancang produk dengan mempertimbangkan lingkungan mobile Bertentangan dengan anggapan umum, pengguna B2B SaaS juga memulai pekerjaan mereka dari smartphone Nyatanya sekitar 50% dari seluruh pengguna mulai menggunakan produk dari mobile Alurnya adalah membuat akun, mendaftarkan beberapa halaman, lalu mengecek lagi dari PC Selama 6 bulan pertama, lingkungan mobile tidak diperhatikan, dan sebagian besar pendaftar dari mobile langsung pergi Setelah UI responsif diperkenalkan, retensi pengguna mobile meningkat secara nyata Tanyakan langsung dari mana pengguna datang Salah satu perubahan kode paling bernilai yang diterapkan di pertengahan tahun pertama adalah menambahkan pertanyaan “Dari mana Anda mengetahui OnlineOrNot?” saat pendaftaran Mengetahui channel akuisisi pengguna sangat penting untuk memaksimalkan efisiensi pemasaran Ada puluhan channel pemasaran, tetapi sumber daya untuk fokus sangat terbatas Setelah channel yang efektif teridentifikasi, fokuslah berinvestasi di channel itu dan lanjutkan sampai responsnya menurun Tidak menggunakan alat analitik yang intrusif Awalnya ia memasang session tracking dan funnel analytics seperti produk SaaS pada umumnya, tetapi efektivitasnya rendah Mungkin bermanfaat untuk tim besar, tetapi pada layanan kecil alat seperti ini mudah disalahartikan sebagai hasil acak Sebagai solo founder yang hanya punya 2 jam setiap pagi, menerima masukan langsung dari kelompok pengguna tepercaya (inner-circle) jauh lebih efektif daripada menganalisis data dalam jumlah besar Ia menerima feedback secara intuitif tentang fitur atau masalah, lalu memperbaiki produk berdasarkan penilaian yang berlandaskan rasa Bicaralah dengan calon pelanggan meski fiturnya belum ada Suatu hari, seorang CTO menanyakan apakah fitur tertentu didukung Awalnya ia berniat mengakhirinya dengan “Maaf, belum ada”, tetapi karena penasaran, ia menanyakan masalah yang mereka hadapi dan tujuan yang ingin mereka capai ia juga bertanya ke pengguna inner-circle apakah mereka menghadapi masalah yang sama lalu berbagi ide tentang bagaimana fitur itu bisa dirancang Hasilnya, CTO ini menjadi pelanggan berbayar keesokan harinya, dan hingga kini masih menjadi pelanggan Fitur tersebut juga dimanfaatkan dengan baik oleh pengguna lain Lebih banyak waktu dihabiskan untuk membangun platform daripada menyelesaikan masalah inti Selama 4 tahun terakhir, lebih dari separuh waktu pengembangan dihabiskan untuk membangun platform SaaS tujuan awal, yaitu “mengecek apakah website down dan mengirim notifikasi”, hanyalah sebagian kecilnya Fitur-fitur yang benar-benar dibutuhkan antara lain: berbagai metode autentikasi dan manajemen pengguna trial, onboarding pekerjaan DB yang berulang, manajemen tim, pemrosesan invoice email lifecycle, dan lain-lain Sebagian dialihdayakan ke layanan seperti Stripe, tetapi ada banyak bagian yang tetap perlu ditangani sendiri atau membutuhkan kustomisasi, sehingga pada akhirnya harus diimplementasikan langsung Menetapkan harga itu benar-benar sulit Jika harga terlalu tinggi, ekspektasi ikut naik atau orang malah enggan mendaftar Jika harga terlalu rendah, pengguna yang hanya membayar $9 bisa saja menuntut seluruh aplikasi diubah sesuai keinginannya Solusinya: pelanggan yang terlalu merepotkan dikembalikan uangnya lalu dipersilakan pergi naikkan harga, lalu lanjutkan terutama pada tahap awal ketika fitur terus berkembang, eksperimen harga yang berkelanjutan itu wajib Jangan terobsesi hanya pada MRR MRR (Monthly Recurring Revenue) bisa menjadi metrik yang kurang tepat untuk mengukur kinerja bisnis Karena apa yang dikerjakan beberapa minggu atau bulan lalu baru memengaruhi MRR saat ini, efek real-time sulit diukur Beberapa produk SaaS bahkan membutuhkan lebih dari 60 hari dari pendaftaran sampai pembayaran nyata Karena itu, perlu melihat metrik lain untuk mengetahui apakah produk benar-benar digunakan dan memberikan nilai Misalnya: jumlah gambar yang dibuat, jumlah form yang dikirim, dan metrik keberhasilan berbasis tindakan lainnya Jangan pernah menawarkan “tak terbatas” Selalu ada whale customer yang akan memaksimalkan penggunaan “tak terbatas” Contohnya: pelanggan yang hanya membayar $250/bulan tetapi memakai resource dalam jumlah sangat besar Jika unit yang dibuat “tak terbatas” itu adalah sesuatu yang menimbulkan biaya, Anda pasti rugi Nasihat ini juga berlaku untuk lifetime deal Jika menjanjikan penggunaan seumur hidup seharga $100, selama bertahun-tahun setelahnya Anda bisa terus menerima permintaan penambahan fitur Jika menggunakan marketplace pihak ketiga, bisa jadi Anda hanya menerima 30% dari pendapatan itu Pada akhirnya, ini justru mengundang pengguna yang menginginkan keuntungan jangka pendek dan bertahan lama, bukan pelanggan yang benar-benar tepat Resource berbayar wajib diberi rate limit Jika memakai API berbayar seperti AI, SMS, atau pengiriman email, pembatasan penggunaan itu wajib “Karena pelanggan berbayar, bukankah seharusnya boleh dipakai tanpa batas?” → mungkin ada pengecualian, tetapi dalam kebanyakan kasus, risikonya adalah tagihan membengkak atau mendapat label spam dari vendor Contoh nyata: Server yang meng-host ratusan situs WordPress mengalami error karena kekurangan RAM Akibatnya ribuan notifikasi SMS terkirim otomatis dan menimbulkan biaya besar Jika memang ada pelanggan yang sungguh membutuhkan penggunaan skala besar, mereka akan menghubungi Anda langsung Jangan mencoba menjelaskan semuanya dalam satu halaman > “Jika Anda mencoba menyampaikan segalanya kepada semua orang, Anda tidak akan menyampaikan apa pun kepada siapa pun” Kalimat ini sangat relevan untuk copywriting landing page Setiap kali fitur ditambahkan ke OnlineOrNot, penjelasan terus ditumpuk di landing page utama sehingga pesannya menjadi berantakan dan pemahaman pengguna ikut menurun Contoh: notifikasi Slack adalah fitur kedua yang dibuat, tetapi banyak orang bahkan tidak tahu fitur itu ada Solusinya: buat landing page terpisah untuk tiap fitur Utama: https://onlineornot.com/ Monitoring uptime: https://onlineornot.com/website-monitoring Monitoring API: https://onlineornot.com/api-monitoring Status page: https://onlineornot.com/status-pages Monitoring cron job: https://onlineornot.com/cron-job-monitoring Dengan begitu, tiap halaman punya ruang yang cukup untuk menjelaskan fungsi dengan jelas Meningkatkan traffic itu sulit, memperbaiki conversion rate bisa dilakukan sekarang juga Mendapat perhatian di internet adalah permainan jangka panjang dan sangat lambat Bahkan dengan content marketing berkualitas yang dilakukan konsisten, butuh berbulan-bulan hingga bertahun-tahun agar pengunjung naik dari 1–2 orang menjadi ratusan Meningkatkan traffic itu sendiri tidak mudah Sebaliknya, perilaku pengguna yang sudah datang bisa diubah segera Misalnya dengan menambahkan opsi login OAuth pada form pendaftaran, yaitu perbaikan yang bisa diterapkan hari ini juga untuk meningkatkan conversion rate Pesaing tidak sepenting itu Alasan hampir tidak ada pembahasan tentang pesaing di sepanjang tulisan ini adalah karena dampaknya memang tidak besar Tentu fitur dasar tetap harus ada agar pelanggan mau mempertimbangkan produk, tetapi pesaing yang sesungguhnya adalah pengguna bahkan tidak tahu bahwa produk ini ada Bukan fitur, melainkan kesadaran dan aksesibilitas yang menjadi elemen kompetisi paling penting

(maxrozen.com)

74 poin oleh xguru 2025-04-14 | 4 komentar | Bagikan ke WhatsApp

OnlineOrNot, yang didirikan oleh Max Rozen, dimulai di pasar yang sudah memiliki lebih dari 200 produk pesaing
Pada awalnya banyak produk sulit digunakan, lalu setelah itu banyak sekali produk pesaing bermunculan dan cepat menghilang
Beberapa produk pesaing menerima pendanaan VC dan diakuisisi perusahaan besar, lalu berkembang ke arah pengalaman pengguna yang makin memburuk
OnlineOrNot menargetkan bisnis yang berkelanjutan dalam jangka panjang dengan pendanaan mandiri
Penulis masih mempertahankan pekerjaan penuh waktu sambil terus mengembangkan SaaS secara konsisten
Ia menulis refleksi tahunan, dan sebagian pelajaran yang dulu diyakini ternyata terbukti salah seiring waktu

Prinsip-prinsip yang tidak berubah

Selama bertahun-tahun menjalankan bisnis, ada banyak hal yang dipelajari, tetapi tetap ada prinsip inti yang tidak berubah dan terus dipertahankan

Menginvestasikan 2 jam setiap hari kerja

Bahkan sebelum memulai OnlineOrNot, ia sudah menghabiskan 2 jam setiap pagi sebelum berangkat kerja untuk fokus pada proyek pribadi
Dengan memanfaatkan waktu ini, ia menyelesaikan ratusan tulisan, satu buku, dan beberapa proyek perangkat lunak
Yang lebih penting daripada berapa banyak waktu yang dihabiskan per hari adalah upaya konsisten setiap hari itu sendiri
Untuk mengamankan waktu ini, ia bangun 2 jam lebih awal dan menyesuaikan rutinitas hariannya

Tidak mengerjakan side project lain

Seperti pepatah “mengejar dua kelinci tidak akan menangkap satu pun”, ia memilih fokus pada satu hal
Ada orang-orang luar biasa yang bisa membuat beberapa proyek sukses, tetapi ia mengakui dirinya berbeda
Proses naik dari $0 ke $500 MRR adalah bagian tersulit dan menurutnya tidak perlu diulang berkali-kali
Ia fokus pada model yang sudah berjalan, dan memilih pendekatan pemasaran dengan sudut pandang yang sama

Prioritas utama adalah menyelesaikan rasa sakit pelanggan

Saat pengguna mendaftar, email otomatis dikirim dengan pertanyaan “Mengapa Anda mendaftar?”
Semua email dibaca dan dibalas langsung, dan inilah yang menjadi insight utama untuk peningkatan produk
Pahami apa yang membuat pengguna tidak nyaman, lalu benar-benar selesaikan itu

Mengulang dengan gigih dan terus memperbaiki

Jika ada pekerjaan yang tidak bisa dirilis dalam 2 jam, ia mengecilkan cakupannya lalu merilis lebih dulu
Memang tidak selalu bisa pas 2 jam, tetapi ia lebih suka merilis versi awal dengan cepat lalu memperluas fiturnya
Jika mencoba membuat semua fitur sekaligus sebelum rilis, motivasi justru hilang dan fokus buyar
Menyelesaikan fitur secara bertahap di balik feature flag jauh lebih efektif

Pelajaran yang dipetik

Baca beberapa buku saja lalu langsung buat

Saat memulai, ia membaca puluhan buku bisnis untuk mengurangi kesalahan
Namun pada akhirnya ia menyadari bahwa belajar dengan melakukan kesalahan sendiri adalah yang paling efektif
Contoh: berhasil masuk halaman depan Hacker News dan mendatangkan 6000 pengunjung, tetapi hanya satu digit pengguna yang benar-benar sampai ke aplikasi
Sebanyak 75% pengguna drop off di form pendaftaran → hanya dengan menambahkan satu opsi login OAuth, tingkat drop-off membaik hingga 50%
Jika harus memulai lagi, ia hanya akan membaca tiga buku ini lalu langsung mulai:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- Jika butuh detail praktis tentang operasional SaaS, ia juga merekomendasikan The SaaS Playbook (Rob Walling)

Menyelesaikan masalah lebih penting daripada menjual langganan

Tujuan SaaS bukan menjual langganan, melainkan menyelesaikan rasa sakit pelanggan
Pola pikir “kalau terus bikin fitur, suatu saat orang akan memakainya” perlu diubah menjadi “mari selesaikan masalah yang menjengkelkan dalam pekerjaan pengguna”
SaaS hanyalah salah satu cara menyelesaikan masalah; selain itu juga ada pendekatan lain seperti screencast, dokumentasi, tulisan, buku, workshop, contoh kode, dan sebagainya

Bangun kecil-kecil dan rilis sesering mungkin

Pengguna memang mengusulkan ide fitur, tetapi pada praktiknya jarang benar-benar dipakai
Orang yang baru memulai SaaS mudah merasa terlalu bersemangat hanya karena ada seseorang yang mau berbicara, lalu langsung membangun fitur begitu saja
Tanyakan dulu bagaimana fitur itu akan digunakan, lalu teliti juga bagaimana pengguna lain menyelesaikan masalah serupa,
- kemudian implementasikan versi minimal dulu untuk melihat responsnya
Pendekatan strategis untuk membangun fitur yang dipakai banyak orang lebih penting daripada membuat “fitur kepingan salju” yang hanya digunakan satu orang
Menghapus fitur yang dibuat dalam beberapa jam memang menyakitkan, tetapi menghapus fitur yang memakan waktu berbulan-bulan jauh lebih menyakitkan

Rilis dulu, pikirkan skalanya nanti

Versi awal OnlineOrNot diluncurkan cepat tanpa optimasi arsitektur
Pada kenyataannya ada bug yang membatasi sistem hanya bisa menangani sekitar 100 pengecekan,
- dan saat masalah terjadi, UI yang ditampilkan ke pengguna hanya sekadar “Error!”, jadi kondisinya sangat belum matang
Namun penulis memilih lebih baik dikritik karena UI yang belum selesai daripada membuang waktu membuat fitur yang tidak perlu
Karena tidak ada jaminan ribuan pengguna akan datang sejak awal, yang lebih penting adalah validasi secepat mungkin
Sebagai langkah sementara, database di-upgrade ke paket yang lebih tinggi untuk menambah kapasitas pengecekan
Dalam beberapa jam, sistem kemudian direfaktor menjadi arsitektur yang bisa menangani jutaan pengecekan, dan layar error juga diperbaiki

Menjalankan program early access

Pada tahap awal pengembangan produk, mayoritas pengguna cukup toleran terhadap fitur yang belum sempurna
Seiring waktu, makin banyak pengguna yang mengharapkan produk yang lebih matang
Untuk mengatasi ini, ditambahkan checkbox “ikut program early access” di setiap akun pengguna
- Peserta bisa mencoba fitur terbaru yang belum sepenuhnya selesai lebih dulu dan memberikan feedback
Ini berguna sebagai cara menyeimbangkan testing dan feedback

Perkenalkan free trial secepat mungkin

Belakangan ini nasihat umum yang sering terdengar adalah “free plan terlalu sulit diseimbangkan, jadi jangan lakukan”
Namun pada tahap awal, free plan efektif untuk word-of-mouth dan akuisisi pengguna
Kekurangannya, jika perbedaan antara free plan dan fitur berbayar terlalu besar, maka harus ada cara agar pengguna bisa mencoba fitur yang bagus
Baru 11 bulan setelah mulai, ia menambahkan pertanyaan “Apakah Anda ingin memulai free trial?” dalam proses onboarding
- Makna sebenarnya seperti ini:
  > “Apakah Anda ingin mencoba fitur bagus selama 14 hari lalu memutuskan, atau memakai produk selama beberapa bulan dengan fitur terbatas lalu akhirnya kecewa?”
Setelah itu, ia bereksperimen dengan memberikan free trial secara default kepada semua pengguna
- Hanya eksperimen ini saja membuat tingkat pertumbuhan bulanan naik lebih dari 2x
Kesimpulannya:
- Pesan “Ini layanan berbayar. Jika ingin terus memakai fitur yang bagus, kami butuh informasi pembayaran Anda”
- jauh lebih efektif secara bisnis daripada “Ini layanan gratis. Kalau banyak dipakai mungkin akan berbayar”

Dokumentasi adalah produk itu sendiri

Dulu sering ada anggapan “developer tidak membaca dokumentasi”, tetapi itu sepenuhnya salah
Sebagian pelanggan ideal memuji dokumentasi OnlineOrNot, dan sejak itu ia berinvestasi besar pada dokumentasi
Dokumentasi API juga dibangun sendiri agar pengalaman pengguna bisa dikendalikan sepenuhnya
Dari pengamatan lewat alat analitik produk:
1. Pengguna mengalami masalah di UI, lalu setelah membuka dokumentasi menemukan fiturnya dan tetap melanjutkan penggunaan produk
2. Jika tidak menemukan informasi yang diinginkan, mereka tidak membuat check dan pergi
Kualitas dokumentasi berhubungan langsung dengan retensi pengguna

Rancang produk dengan mempertimbangkan lingkungan mobile

Bertentangan dengan anggapan umum, pengguna B2B SaaS juga memulai pekerjaan mereka dari smartphone
Nyatanya sekitar 50% dari seluruh pengguna mulai menggunakan produk dari mobile
- Alurnya adalah membuat akun, mendaftarkan beberapa halaman, lalu mengecek lagi dari PC
Selama 6 bulan pertama, lingkungan mobile tidak diperhatikan, dan sebagian besar pendaftar dari mobile langsung pergi
Setelah UI responsif diperkenalkan, retensi pengguna mobile meningkat secara nyata

Tanyakan langsung dari mana pengguna datang

Salah satu perubahan kode paling bernilai yang diterapkan di pertengahan tahun pertama adalah
- menambahkan pertanyaan “Dari mana Anda mengetahui OnlineOrNot?” saat pendaftaran
Mengetahui channel akuisisi pengguna sangat penting untuk memaksimalkan efisiensi pemasaran
Ada puluhan channel pemasaran, tetapi sumber daya untuk fokus sangat terbatas
Setelah channel yang efektif teridentifikasi, fokuslah berinvestasi di channel itu dan lanjutkan sampai responsnya menurun

Tidak menggunakan alat analitik yang intrusif

Awalnya ia memasang session tracking dan funnel analytics seperti produk SaaS pada umumnya, tetapi efektivitasnya rendah
Mungkin bermanfaat untuk tim besar, tetapi pada layanan kecil alat seperti ini mudah disalahartikan sebagai hasil acak
Sebagai solo founder yang hanya punya 2 jam setiap pagi,
- menerima masukan langsung dari kelompok pengguna tepercaya (inner-circle) jauh lebih efektif daripada menganalisis data dalam jumlah besar
Ia menerima feedback secara intuitif tentang fitur atau masalah, lalu memperbaiki produk berdasarkan penilaian yang berlandaskan rasa

Bicaralah dengan calon pelanggan meski fiturnya belum ada

Suatu hari, seorang CTO menanyakan apakah fitur tertentu didukung
Awalnya ia berniat mengakhirinya dengan “Maaf, belum ada”, tetapi
- karena penasaran, ia menanyakan masalah yang mereka hadapi dan tujuan yang ingin mereka capai
- ia juga bertanya ke pengguna inner-circle apakah mereka menghadapi masalah yang sama
- lalu berbagi ide tentang bagaimana fitur itu bisa dirancang
Hasilnya, CTO ini menjadi pelanggan berbayar keesokan harinya, dan hingga kini masih menjadi pelanggan
Fitur tersebut juga dimanfaatkan dengan baik oleh pengguna lain

Lebih banyak waktu dihabiskan untuk membangun platform daripada menyelesaikan masalah inti

Selama 4 tahun terakhir, lebih dari separuh waktu pengembangan dihabiskan untuk membangun platform SaaS
- tujuan awal, yaitu “mengecek apakah website down dan mengirim notifikasi”, hanyalah sebagian kecilnya
Fitur-fitur yang benar-benar dibutuhkan antara lain:
- berbagai metode autentikasi dan manajemen pengguna
- trial, onboarding
- pekerjaan DB yang berulang, manajemen tim, pemrosesan invoice
- email lifecycle, dan lain-lain
Sebagian dialihdayakan ke layanan seperti Stripe, tetapi
- ada banyak bagian yang tetap perlu ditangani sendiri atau membutuhkan kustomisasi, sehingga pada akhirnya harus diimplementasikan langsung

Menetapkan harga itu benar-benar sulit

Jika harga terlalu tinggi, ekspektasi ikut naik atau orang malah enggan mendaftar
Jika harga terlalu rendah, pengguna yang hanya membayar $9 bisa saja menuntut seluruh aplikasi diubah sesuai keinginannya
Solusinya:
- pelanggan yang terlalu merepotkan dikembalikan uangnya lalu dipersilakan pergi
- naikkan harga, lalu lanjutkan
- terutama pada tahap awal ketika fitur terus berkembang, eksperimen harga yang berkelanjutan itu wajib

Jangan terobsesi hanya pada MRR

MRR (Monthly Recurring Revenue) bisa menjadi metrik yang kurang tepat untuk mengukur kinerja bisnis
Karena apa yang dikerjakan beberapa minggu atau bulan lalu baru memengaruhi MRR saat ini, efek real-time sulit diukur
Beberapa produk SaaS bahkan membutuhkan lebih dari 60 hari dari pendaftaran sampai pembayaran nyata
Karena itu, perlu melihat metrik lain untuk mengetahui apakah produk benar-benar digunakan dan memberikan nilai
- Misalnya: jumlah gambar yang dibuat, jumlah form yang dikirim, dan metrik keberhasilan berbasis tindakan lainnya

Jangan pernah menawarkan “tak terbatas”

Selalu ada whale customer yang akan memaksimalkan penggunaan “tak terbatas”
Contohnya: pelanggan yang hanya membayar $250/bulan tetapi memakai resource dalam jumlah sangat besar
Jika unit yang dibuat “tak terbatas” itu adalah sesuatu yang menimbulkan biaya, Anda pasti rugi
Nasihat ini juga berlaku untuk lifetime deal
- Jika menjanjikan penggunaan seumur hidup seharga $100, selama bertahun-tahun setelahnya Anda bisa terus menerima permintaan penambahan fitur
- Jika menggunakan marketplace pihak ketiga, bisa jadi Anda hanya menerima 30% dari pendapatan itu
Pada akhirnya, ini justru mengundang pengguna yang menginginkan keuntungan jangka pendek dan bertahan lama, bukan pelanggan yang benar-benar tepat

Resource berbayar wajib diberi rate limit

Jika memakai API berbayar seperti AI, SMS, atau pengiriman email, pembatasan penggunaan itu wajib
“Karena pelanggan berbayar, bukankah seharusnya boleh dipakai tanpa batas?” → mungkin ada pengecualian, tetapi
- dalam kebanyakan kasus, risikonya adalah tagihan membengkak atau mendapat label spam dari vendor
Contoh nyata:
- Server yang meng-host ratusan situs WordPress mengalami error karena kekurangan RAM
- Akibatnya ribuan notifikasi SMS terkirim otomatis dan menimbulkan biaya besar
Jika memang ada pelanggan yang sungguh membutuhkan penggunaan skala besar, mereka akan menghubungi Anda langsung

Jangan mencoba menjelaskan semuanya dalam satu halaman

> “Jika Anda mencoba menyampaikan segalanya kepada semua orang, Anda tidak akan menyampaikan apa pun kepada siapa pun”

Kalimat ini sangat relevan untuk copywriting landing page
Setiap kali fitur ditambahkan ke OnlineOrNot, penjelasan terus ditumpuk di landing page utama sehingga
- pesannya menjadi berantakan dan pemahaman pengguna ikut menurun
- Contoh: notifikasi Slack adalah fitur kedua yang dibuat, tetapi banyak orang bahkan tidak tahu fitur itu ada
Solusinya: buat landing page terpisah untuk tiap fitur
- Utama: https://onlineornot.com/
- Monitoring uptime: https://onlineornot.com/website-monitoring
- Monitoring API: https://onlineornot.com/api-monitoring
- Status page: https://onlineornot.com/status-pages
- Monitoring cron job: https://onlineornot.com/cron-job-monitoring
Dengan begitu, tiap halaman punya ruang yang cukup untuk menjelaskan fungsi dengan jelas

Meningkatkan traffic itu sulit, memperbaiki conversion rate bisa dilakukan sekarang juga

Mendapat perhatian di internet adalah permainan jangka panjang dan sangat lambat
- Bahkan dengan content marketing berkualitas yang dilakukan konsisten, butuh berbulan-bulan hingga bertahun-tahun agar pengunjung naik dari 1–2 orang menjadi ratusan
Meningkatkan traffic itu sendiri tidak mudah
Sebaliknya, perilaku pengguna yang sudah datang bisa diubah segera
- Misalnya dengan menambahkan opsi login OAuth pada form pendaftaran, yaitu perbaikan yang bisa diterapkan hari ini juga untuk meningkatkan conversion rate

Pesaing tidak sepenting itu

Alasan hampir tidak ada pembahasan tentang pesaing di sepanjang tulisan ini adalah karena dampaknya memang tidak besar
Tentu fitur dasar tetap harus ada agar pelanggan mau mempertimbangkan produk, tetapi
- pesaing yang sesungguhnya adalah pengguna bahkan tidak tahu bahwa produk ini ada
Bukan fitur, melainkan kesadaran dan aksesibilitas yang menjadi elemen kompetisi paling penting

4 komentar

thenewseason 2025-04-22

Dari sudut pandang orang yang menjalankan layanan, banyak hal yang terasa sangat relevan.
Saya juga pernah mengurangi jam tidur sambil terus mengembangkan, dan kesehatan saya jadi memburuk..

Hal yang ingin saya tanyakan kepada orang-orang yang punya pengalaman serupa adalah apakah investasi waktu seperti ini memungkinkan sambil mengasuh anak.
Karena waktu berangkat dan pulang kerja, waktu berada di kantor, dan waktu bersama anak-anak di rumah menghabiskan hampir sebagian besar hari, untuk membangun dan menjalankan layanan seperti ini kita akhirnya harus mengorbankan hal lain, dan saya berharap itu bukan keluarga atau kesehatan..

tsboard 2025-04-15

Ini benar-benar tulisan yang penuh pelajaran. Memanfaatkan 2 jam setiap pagi untuk menulis dan bahkan menyelesaikan berbagai proyek...!

ethanhur 2025-04-14

Ini tulisan yang penuh pelajaran. Pada akhirnya, kita tidak boleh melupakan fakta bahwa SaaS juga merupakan produk yang "dipekerjakan" pelanggan untuk menyelesaikan masalah.

xguru 2025-04-14

Hal yang saya pelajari setelah menjalankan SaaS sendirian selama 1 tahun
Ternyata sudah 3 tahun berlalu, ya haha. Silakan lihat sambil membandingkan apa saja yang berubah!