PagerDuty, Inc.

PagerDuty dimulai dengan satu masalah yang sangat spesifik: membangunkan engineer yang tepat saat ada insiden. Bukan platform observability. Bukan analytics. Bukan workflow management. Hanya satu hal: pastikan alert sampai ke orang yang benar, tepat waktu. Kesederhanaan ini menjadi kekuatan. Dari sana, PagerDuty secara bertahap menambahkan event intelligence, automation, dan post-incident analysis — tapi fondasi alerting yang solid menjadi 'wedge' masuk ke organisasi.

Startup yang paling sukses sering dimulai dengan memecahkan satu masalah kecil dengan sangat baik, lalu expand dari sana. Ini kontras dengan pendekatan 'platform-first' yang mencoba membangun segalanya sekaligus. Stripe dimulai dengan payment processing. Slack dimulai sebagai tool chat internal. Twilio dimulai dengan API SMS. Semuanya menjadi platform — tapi setelah menguasai satu wedge.

Mencoba membangun platform end-to-end dari hari pertama. Menambahkan fitur sebelum use case inti benar-benar solid. Mengabaikan feedback 'produk inti kalian bagus, tapi fitur baru ini biasa saja'.

Identifikasi satu masalah yang menyebabkan pain nyata dan terukur. Pecahkan sampai pengguna menganggapnya 'magic'. Baru kemudian perluas. PagerDuty menghabiskan bertahun-tahun menyempurnakan alerting sebelum menjadi Operations Cloud.

PagerDuty memahami sejak awal bahwa mereka memiliki tanggung jawab unik: jika PagerDuty down saat pelanggan mengalami insiden kritis, bukan hanya PagerDuty yang gagal — pelanggan kehilangan kemampuan merespons insiden mereka sendiri. Ini menciptakan standar reliabilitas yang luar biasa tinggi. PagerDuty secara konsisten mempertahankan uptime 99,99%+ (kurang dari 53 menit downtime per tahun). Arsitektur multi-region dan failover otomatis menjadi investasi non-negotiable.

Perusahaan infrastruktur memiliki standar ganda: produk mereka harus bekerja dengan standar yang lebih tinggi daripada produk pelanggan mereka. AWS, Cloudflare, Stripe — semuanya berinvestasi secara massif dalam reliabilitas karena downtime mereka berdampak cascading pada seluruh ekosistem. Ini menciptakan moat yang sangat dalam: membangun sistem yang reliabel pada skala ini membutuhkan bertahun-tahun learning dan investasi.

Mengkompromikan reliabilitas untuk kecepatan fitur. Tidak memiliki incident response plan yang jelas untuk produk incident response. Track record uptime yang buruk untuk perusahaan yang menjual uptime.

Jika produk Anda tentang reliabilitas, investasikan secara tidak proporsional di reliability engineering. PagerDuty menjadikan uptime bukan hanya metrik, tapi identitas merek. Satu insiden downtime bisa menghancurkan kepercayaan yang dibangun bertahun-tahun.

PagerDuty tumbuh melalui model bottom-up: satu tim engineering di perusahaan besar mulai menggunakan PagerDuty (seringkali dengan akun free/low-tier), lalu penggunaan menyebar ke tim lain secara organik. Ketika cukup banyak tim menggunakan PagerDuty, perusahaan akhirnya melakukan enterprise deal. 65% Fortune 100 menggunakan PagerDuty — banyak yang dimulai dari satu engineer yang mendaftar sendiri. Model ini mirip dengan Slack, GitHub, dan Datadog.

Product-led growth di enterprise B2B terjadi ketika produk memecahkan masalah yang cukup menyakitkan sehingga individual contributor bersedia mengadopsinya tanpa persetujuan manajemen. Begitu ada massa kritis pengguna internal, procurement beralih dari 'apakah kita perlu ini?' menjadi 'bagaimana kita mengontrol pengeluaran untuk tool yang sudah dipakai semua orang?'

Langsung menarget CTO/CIO tanpa validasi bahwa engineer individual benar-benar mau menggunakan produk. Pricing yang terlalu mahal untuk tim kecil sehingga menghambat adopsi bottom-up. Proses onboarding yang membutuhkan approval enterprise untuk mulai mencoba.

Desain produk agar satu engineer bisa mulai menggunakannya dalam 5 menit tanpa approval siapa pun. Buat tier gratis yang cukup berguna untuk tim kecil. Ketika ada cukup pengguna internal, tawarkan enterprise plan dengan fitur keamanan, SSO, dan reporting yang dibutuhkan IT/procurement.

Alex Solomon memimpin PagerDuty dari founding hingga memiliki ribuan pelanggan. Pada 2016, ia membuat keputusan yang sulit tapi dewasa: menyerahkan posisi CEO ke Jennifer Tejada — eksekutif enterprise berpengalaman — dan beralih menjadi CTO. Transisi ini bukan tanda kelemahan, melainkan pengakuan bahwa skill yang dibutuhkan untuk membawa PagerDuty ke fase berikutnya (enterprise sales, IPO) berbeda dari skill untuk memulai dan menumbuhkannya. Di bawah Tejada, revenue tumbuh hampir 8x (dari ~US$60 juta ke US$465 juta) dan perusahaan berhasil IPO.

Banyak founder teknis brilian tapi bukan eksekutor terbaik di fase enterprise/public company. Founder yang sadar diri — yang tahu kapan perusahaan membutuhkan pemimpin berbeda — sering menghasilkan outcome lebih baik daripada founder yang memaksakan diri memimpin melalui semua fase. Contoh klasik: Eric Schmidt di Google, Sheryl Sandberg di Facebook (Meta), Satya Nadella di Microsoft (bukan founder, tapi transisi CEO). Yang penting: founder tetap terlibat di area kekuatannya.

Founder teknis yang memaksakan diri menjalankan enterprise sales padahal tidak punya keahliannya. Sebaliknya: founder yang sepenuhnya lepas tangan setelah transisi, kehilangan pengaruh teknis. Board yang memaksa transisi saat founder masih mampu — atau sebaliknya, menolak transisi saat sudah jelas dibutuhkan.

Evaluasi secara jujur: apa fase perusahaan saat ini, dan apakah skill Anda sebagai founder masih cocok? Jika tidak, cari CEO yang melengkapi — bukan menggantikan — Anda. Solomon tetap menjadi CTO dan memiliki pengaruh besar di produk. Transisi terbaik mempertahankan founder di zona kekuatannya.

PagerDuty mengalami akselerasi pertumbuhan signifikan selama pandemi (FY2021 tumbuh 39%) saat transformasi digital dipercepat oleh remote work masif. Namun setelah pandemi, pertumbuhan melambat secara bertahap ke ~8% (FY2025). Harga saham turun lebih dari 70% dari puncak. Investor yang awalnya menilai PagerDuty berdasarkan growth rate pandemi harus menyesuaikan ekspektasi. PagerDuty merespons dengan PHK 7%, fokus profitabilitas, dan pivot ke AI.

Banyak perusahaan SaaS mengalami 'post-pandemic hangover': pertumbuhan yang ditarik ke depan (pulled forward) selama pandemi menciptakan base effect yang membuat pertumbuhan berikutnya terlihat lemah secara komparatif. Zoom, Peloton, Shopify, dan PagerDuty semuanya mengalami pola ini. Pasar sering menghukum perusahaan yang 'hanya' tumbuh 8-10% meskipun secara absolut bisnis tetap sehat.

Memperlakukan pertumbuhan pandemi sebagai 'new normal'. Hiring masif berdasarkan revenue growth rate yang tidak sustainable. Gagal membangun 'durable growth engine' yang independen dari tailwind makro. Tidak bersiap untuk skenario di mana pertumbuhan melambat.

Bedakan antara pertumbuhan organik (permintaan nyata) dan pertumbuhan yang ditarik oleh event luar biasa (pandemi). Bangun struktur cost yang fleksibel — jangan hire untuk growth rate puncak. PagerDuty akhirnya menemukan keseimbangan melalui PHK dan fokus efisiensi, tapi prosesnya menyakitkan.

PagerDuty diluncurkan pada 2009 — tepat di awal revolusi DevOps dan cloud computing. Saat itu, infrastruktur monitoring masih primitif (Nagios, shell script, email alert) dan tidak ada solusi on-call yang dedicated. PagerDuty masuk ke pasar yang hampir kosong dan menjadi sinonim dengan 'on-call management' — seperti Kleenex untuk tissue. Ketika kompetitor (Opsgenie, VictorOps, xMatters) masuk, PagerDuty sudah menjadi default choice. Nama 'PagerDuty' sendiri menjadi verb di kalangan engineer: 'Are you on PagerDuty this week?'

First-mover advantage nyata ketika produk menempel pada kebiasaan profesional sehari-hari. Begitu engineer terbiasa dengan workflow tertentu dan membawanya ke perusahaan berikutnya, switching cost menjadi sangat tinggi — bukan karena lock-in teknis, tapi karena lock-in kebiasaan. Ini menciptakan moat yang sulit direplikasi oleh pendatang baru, meskipun produk mereka secara teknis bisa jadi lebih baik.

Mencoba masuk ke pasar incident management sekarang tanpa diferensiasi yang sangat jelas. Menganggap bahwa timing tidak penting — 'siapa saja bisa membangun alerting tool'. Mengabaikan bahwa nama merek dan kebiasaan profesional sudah terbentuk.

Cari kategori baru yang sedang terbentuk, bukan kategori yang sudah punya pemain dominan. PagerDuty tidak bersaing dengan solusi existing — mereka menciptakan kategori baru. Tanyakan: apa masalah yang saat ini diselesaikan dengan spreadsheet, email, atau tidak diselesaikan sama sekali?