Gw inget banget waktu gw ambil keputusan nekat hire 5 Product Manager dalam hitungan 6 bulan terakhir tahun lalu. Alasannya logis, kan? Kita mau ekspansi. User base naik 40% quarter-over-quarter. Revenue mulai hijau. Tim opsional udah mulai kewalahan.

Logikanya, tambah resource harusnya ngebut perjalanan kita. Eh, kenyataannya? Justru bikin kita rebahan. Bukan rebahan fisik, tapi progress project rebahan parah. Deadline molor 3 minggu berturut-turut. Mood tim turun drastis. Dan hal paling ngeselin: kita jadi terjebak dalam ritual meeting tanpa output.

Hari ini gw mau cerita brutal tentang kesalahan struktur yang hampir bikin startup gw ambruk secara perlahan. Bukan soal skill PM-nya buruk. Justru sebaliknya. Masalahnya ada di tumpang tindih peran, atau istilah kerennya: lack of clarity.

Kasus Nyata: 5 PM, 6 Bulan, Satu Jebakan

Mari kita bedah dulu skenario mengerikan itu. Gw hire 5 PM dengan latar belakang beda-beda. Tujuannya diversifikasi coverage:

Sarah, senior PM dari unicorn, ditugasin skalabilitas sistem.
 Budi, ex-agency, handle client-facing dan custom req.
Maya, data-driven PM, fokus retention dan churn.
 Raka, fresh tapi energetic, handle growth hack dan experiment.

  • Andi, generalist, "firefighter" buat task gantung yang jatuh.

Awalnya terlihat sempurna. Setiap area covered. Tapi seiring jalan, jebakan mulai muncul. Karena nggak ada ownership matrix yang eksplisit, setiap PM interpretasikan jobdesc-nya sendiri sesuai ego dan pengalaman sebelumnya.

Sarah mikir dia "Product Owner" sejati, jadi dia ikut campur detail UI/UX yang sebenernya domain Maya. Budi takut client marah, jadi dia janji fitur yang belum masuk roadmap ke Andi sebagai firefighter. Raka terus nyoba experiment tanpa validasi business impact dari Maya.

Hasilnya? Jobdesc tumpang tindih sampe berantakan.

Kasus spesifik: Milestone v2.4. Fitur ini butuh integrasi payment gateway baru. Dalam dunia ideal, ini selesai didebat 45 menit, disepakati, dan eksekusi 2 minggu. Di dunia nyata kita?

Pertama, Raka push integrasi itu karena conversion rate naik di test lab. Kedua, Sarah tolak karena concern architectural debt. Ketiga, Budi dorong karena client VIP minta date tertentu. Keempat, Maya ragu karena tracking analytics belum siap. Kelima, Andi confused mau follow who?

Akhirnya, tim gw butuh 3 meeting berbeda cuma buat ambil keputusan go/no-go ini.

Meeting 1: Brainstorming teknis (Raka vs Sarah).
Meeting 2: Validasi bisnis & client (Budi vs Maya).
Meeting 3: Sign-off final (semua orang, tapi putusnya mentok karena nggak ada final decision maker).

Total waktu terbuang: 6 jam. Belum termasuk follow-up email dan chat di Slack yang makin rame. Tim dev jadi korban, mereka stand-by tapi nggak bisa gerak karena PM-nya masih debat politik.

Biarpun Headcount Naik, Output Malah Stagnan

Yang ngeselin banget adalah ketika kita realize penambahan kepala nggak nambah speed. Justru bikin proses makin lambat.

Ini namanya Brooks' Law versi startup Indo. Menambah manpower ke project yang telat hanya akan memperlambatnya lebih jauh—kalau komunikasinya nggak sinkron. Dan di kasus kita, komunikasi kacau total.

PM gw yang merasa kurang diakui mulai perform sotoy. Mereka sibuk ngebela wilayah masing-masing daripada kolaborasi. Sarah bikin channel Slack rahasia buat deal teknis sama tech lead. Budi nge-block kalender gw biar nggak dikontak client lain. Maya bikin dashboard sendiri yang datanya nggak konek sama report Andi.

Manajemen konflik tim yang seharusnya healthy berubah jadi toxic politics. GM gw hampir burnout karena harus jadi arbitrator di setiap decision kecil. Gw habis 80% waktu handling internal friction, cuma 20% buat strategic thinking.

Dan ironisnya, 6 bulan kemudian, revenue naik, tapi margin profit turun karena overhead meeting dan rework tinggi. Tim dev resign 2 orang karena kelelahan revisi akibat perubahan arah mendadak dari PM yang beda pendapat.

Itu wakeup call terbesar gw. Gw pikir masalah kita adalah kurang tenaga. Ternyata masalah kita adalah terlalu banyak tangan tanpa komando yang jelas.

Solusi Gak Harus Rumit: RACI Versi Startup Indo

Setelah kejadian itu, gw stop rekrutmen PM selama 3 bulan. Gw nggak butuh headcount. Gw butuh kejelasan peran tim yang bisa dieksekusi, bukan ditulis di kertas doang.

Gw pilih approach RACI. Banyak founder atau PM senior mungkin sudah familiar. Tapi jujur, template RACI korporat yang 5 kolom, 20 baris, dan terminologi rumit itu mati suri di startup. Tim bakal mager isi dan lupa seminggu kemudian.

Gw modifikasi jadi RACI Sederhana yang muat 1 lembar A4 dan bahasa sehari-hari. Gw print, tempel di dinding ruang meeting, dan jadikan sumber kebenaran selama 3 bulan.

Intinya, setiap tugas atau milestone harus punya jawaban pasti buat 4 pertanyaan ini:

1. Siapa yang Eksekusi? (Responsible)

Ini orang yang nggerakin kerjaan. Nggak boleh cuma satu di sini, atau bakal overloaded. Misalnya di fitur payment gateway, eksekutor teknis ya Tech Lead, tapi eksekutor user flow testing ya Maya.

2. Siapa Pemegang Kunci? (Accountable)

Ini poin paling kritis. Cuma BOLEH SATU ORANG yang jawab "Ya" atau "Tidak". Orang ini yang nerima tembakan kalau meledak, dan yang dapet pujian kalau sukses. Di kasus payment gateway tadi, nih adalah posisi kosong yang bikin deadlock. Setelah RACI, gw tetapkan ini: Lead PM (Sarah). Tidak ada deliberasi. Kalau Sarah bilang go, kita go. Kalau Sarah bilang no, kita stop. Point discussed.

3. Siapa yang Harus Dikasih Tau Dulu? (Consulted)

Orang yang opininya wajib didenger sebelum keputusan diambil. Biasanya ini technical expert atau stakeholder dekat. Buat payment gateway, yang consult adalah Budi (client req) dan Maya (analytics). Tapi ingat, konsultasi bukan veto power. Opini mereka input, keputusan tetap di Accountable.

4. Siapa yang Tinggal Nonton? (Informed)

Orang-orang yang perlu update setelah keputusan diambil. Biasa ini tim marketing, CS, atau stakeholder lain. Mereka nggak dilibatkan dalam diskusi, tapi perlu tahu hasilnya buat persiapan kerjaan mereka.

Dengan format begini, diskusi di meeting berubah drastis. Daripada saling serang argument, kita tanya: "Budi, ini masuk kategori Consulted atau Informed?" Kalau Informed, berarti jangan interrupt, nanti aja broadcast hasilnya. Kalau Consulted, kita dengerin input dia, tapi akhir keputusan tetep di Sarah.

Cara Roll-out Tanpa Bikin Tim Mager

Ngomong-ngomong soal RACI, tantangan terbesar bukan di design-nya, tapi di adoption-nya.

Jangan cuma kirim PDF via email trus berharap tim ngerti. Gw lakukan session workshop 1 jam bareng seluruh tim. Gw ajak mapping satu milestone aktif saat itu juga. Biar mereka merasakan langsung sensasi mana yang ambiguous.

Gunakan tool yang udah lo pake sehari-hari. Di SatuTim, misalnya, kita biasanya abisin PR-an di fitur Discussion. Nah, konsep RACI ini bisa lo tanam di situ.

Gw saranin, di setiap task besar atau sprint planning, tambahkan kolom metadata "Owner Keputusan" di kartu task lo. Atau bikin section pinned di Discussion utama tim yang berisi tabel RACI ringkas buat project berjalan. Jadi kapanpun ada perdebatan, anggota tim bisa klik link RACI itu dan langsung sadar posisinya.

Contoh praktikal di SatuTim Discussion:

Task: Launch Promo Ramadan

- Owner Keputusan (A): Maya (Head of Growth)
- Eksekutor (R): Raka & Tim Creative
- Konsultasi (C): Finance (budget approval), CS (kesiapan response)
- Informasi (I): Sales Team, Dev Team*

Dengan begini, Raka nggak perlu tanyafinance berkali-kali, cukup input ke Maya. Finance tinggal kasih feedback di thread, Maya yang filter dan approve. Hemat waktu. Hemat emosi.

Hasil Setelah Implementasi

Apa yang terjadi 3 bulan setelah gw pasang RACI sederhana?

  1. Rapat milestone turun drastis. Dari yang awalnya butuh 3 sesi panjang, sekarang cukup 1 sesi 45 menit. Karena roles udah jelas, diskusi fokus ke problem solving, bukan negosiasi wewenang.
  2. PM gw happier. Mereka punya kejelasan peran tim yang kuat. Sarah fokus strategizing tanpa mikirin detail client daily. Budi aman karena scope client-nya dibatasi oleh boundary RACI. Raka bebas experiment asal lolos filter Maya.
  3. Decision velocity naik. Lead time feature development turun 30%. Bukan karena coding cepet, tapi karena waiting time buat approval berkurang.

Tambahan PM berikutnya gw pause sampai struktur ini stabil. Sekarang, tiap kali gw mau hire PM baru, gw nggak tanya dulu "berapa tahun pengalaman lo?". Gw tanya: "Lo punya contoh bagaimana lo resolve conflict wewenang di tim sebelumnya?"

Karena pengalaman gw buktiin, tambah kepala di tengah kekacauan cuma bikin deadlock makin dalam.

Kejelasan peran tim itu aset invisible. Pas lo punya, lo berasa ringan banget. Pas lo hilang, lo nggak sadar sedalam apa lo tenggelam sampai deadline hampir meleset.

Jadi, coba minggu ini: buka dokumentasi jobdesc semua PM di tim lo. Highlight bagian yang jawab "Ya" buat pertanyaan yang sama. Kalau ada double highlight, itu tanda lo butuh percakapan keras soal ownership. Atau, tinggalin komentar di bawah: berapa lama rata-rata meeting decision-making tim lo sekarang?