Menguasai hypothesis-driven development, A/B test design yang valid, dan statistik dasar — p-value, confidence interval, sample size — untuk membuat keputusan produk berdasarkan bukti, bukan tebakan

Setelah di episode 7 kita memahami metrik dan KPI, pada episode ini kita belajar cara mengubah metrik secara sistematis. Experimentation adalah proses menguji hipotesis dengan metode ilmiah — bukan menebak, tetapi membuktikan. A/B testing adalah bentuk paling umum dari experimentation, tetapi bukan satu-satunya.
Banyak PM menganggap A/B testing hanya soal "split traffic 50/50." Realitanya, A/B testing yang valid membutuhkan pemahaman statistik yang memadai. Tanpa ini, kalian akan mengambil keputusan berdasarkan noise, bukan signal.
Sebelum menjalankan experiment, kalian harus punya hipotesis yang jelas. Struktur hipotesis yang efektif:
Jika [perubahan], maka [metrik] akan [perubahan] untuk [segmen user],
dikarenakan [alasan/insight].Contoh: "Jika kita menambahkan one-click checkout, maka conversion rate akan meningkat 15% untuk merchant baru, dikarenakan merchant baru sering drop di tahap checkout multi-step."
Hipotesis yang baik harus:
| Komponen | Penjelasan | Contoh |
|---|---|---|
| Control | Kondisi saat ini (tanpa perubahan) | Checkout 3 langkah |
| Variant | Kondisi yang diuji | Checkout 1 langkah |
| Metric | Apa yang diukur | Conversion rate |
| Sample size | Berapa banyak user yang dibutuhkan | 5.000 per grup |
| Duration | Berapa lama experiment berjalan | 2 minggu |
Salah satu kesalahan terbesar: menjalankan experiment terlalu pendek atau dengan sample terlalu kecil. Jika sample terlalu kecil, kalian tidak akan bisa membedakan signal dari noise.
Minimum sample size untuk A/B test:
- 1.000 users per grup (untuk metrik binary seperti conversion)
- 10.000+ users per grup (untuk metrik continuous seperti revenue)
- Duration minimal 1-2 minggu (untuk menangkap weekly patterns)Warning
Statistical significance bukan practical significance. Jika A/B test menunjukkan peningkatan 0.1% dengan p-value 0.01, itu mungkin tidak cukup untuk membenarkan biaya engineering. Selalu tanyakan: "apakah perubahan ini cukup besar untuk mempengaruhi user?"
Inti yang harus dibawa pulang:
Di episode 9 selanjutnya kita akan membahas PRD & requirement writing — bagaimana menulis Product Requirement Document yang jelas, acceptance criteria, dan user stories. Topik ini menghubungkan eksperimen dengan spesifikasi yang bisa dieksekusi engineering. Tetap semangat!