Belajar Product Manager - Scaling Product Organization
Memahami multi-team product management, alignment lintas tim, dan organizational design — tiga tantangan utama saat produk dan tim tumbuh melebihi satu tim
#Pendahuluan
Setelah di episode 22 kita memahami product-led growth, pada episode ini kita masuk ke tantangan scaling: ketika satu tim menjadi banyak tim, dan satu produk menjadi banyak produk atau area. Scaling bukan soal "lebih banyak orang" — ini soal menjaga alignment, komunikasi, dan kualitas keputusan saat kompleksitas meningkat.
Banyak organisasi yang tumbuh terlalu cepat mengalami "scaling pain": duplicate efforts, misaligned priorities, dan siloed knowledge. PM harus memahami cara mengatasi tantangan ini.
#Multi-Team Product
#Model Organisasi
| Model | Struktur | Kapan Cocok |
|---|---|---|
| Feature team | Tim dibagi berdasarkan fitur | Produk sederhana |
| Stream-aligned | Tim dibagi berdasarkan user journey | Produk dengan user journey jelas |
| Platform team | Tim fokus pada infrastruktur shared | Banyak tim yang membutuhkan platform |
| Enabling team | Tim membantu tim lain meningkatkan capability | Scaling engineering practices |
#Alignment
Alignment lintas tim membutuhkan:
- Shared vision: semua tim memahami arah yang sama.
- Clear ownership: setiap area punya pemilik yang jelas.
- Dependency management: identifikasi dan kelola dependency antar tim.
- Communication rituals: sync points yang teratur (alli-gment reviews, roadmap reviews).
#Org Design
#Spans of Control
Spans of control mengacu pada berapa banyak direct reports yang dimiliki seorang manager. Untuk PM:
| Level | Spans of Control | Ekspektasi |
|---|---|---|
| PM | 1 produk/area | Fokus pada execution |
| Senior PM | 1-2 produk/area | Fokus pada strategy |
| Group PM | 3-5 PM | Fokus pada alignment |
| Director | 5-8 reports | Fokus pada organisasi |
| VP | 8-12 reports | Fokus pada bisnis |
#Conway's Law
Conway's Law menyatakan bahwa arsitektur sistem mencerminkan struktur organisasi. Implikasinya: jika kalian ingin mengubah arsitektur produk, kalian mungkin harus mengubah struktur tim terlebih dahulu.
Struktur tim → Arsitektur sistem
Tim terpisah per area → Microservices terpisah per area
Tim terpusat → Monolith
Tim cross-functional → Modular architecture#Knowledge Management
Scaling membutuhkan knowledge sharing yang efektif:
- Documentation: setiap keputusan didokumentasikan (decision records).
- Communities of practice: kelompok yang punya minat yang sama (PM community, data community).
- Rotation: PM berpindah tim untuk membangun empathy dan knowledge transfer.
- Tooling: single source of truth untuk roadmap, backlog, dan metrics.
Note
Scaling adalah marathon, bukan sprint. Jangan mencoba mengubah semua sekaligus. Mulai dari satu area yang paling sakit, perbaiki, lalu ekstensif ke area lain.
#Penutup
Inti yang harus dibawa pulang:
- Scaling membutuhkan model organisasi yang tepat: feature team, stream-aligned, platform, atau enabling.
- Alignment lintas tim membutuhkan shared vision, clear ownership, dan communication rituals.
- Conway's Law: struktur tim mempengaruhi arsitektur sistem — pertimbangkan ini saat scaling.
- Knowledge management (documentation, communities, rotation) adalah kunci menjaga alignment saat tim tumbuh.
Di episode 24 selanjutnya kita akan membahas AI/LLM product management — prompt/product design, RAG-based features, dan evaluating AI quality. Topik ini relevan untuk PM yang membangun produk berbasis large language models. Tetap semangat!