Mengembangkan kepemimpinan dan pengaruh sebagai product designer: design leadership, storytelling, dan teknik memengaruhi stakeholder tanpa otoritas formal. Di episode ini kalian menyusun presentasi strategis untuk roadmap Sehati, dan belajar cara membuat keputusan desain didengar di tingkat direksi

Setelah di episode 24 kita mengeksplorasi platform baru, pada episode ini kita naik ke keterampilan yang menentukan karier jangka panjang: leadership & influence. Desain terbaik tidak akan diimplementasikan jika tidak ada yang mendengarnya. Dan product designer tidak punya otoritas formal atas PM, engineer, atau stakeholder — yang kalian punya adalah pengaruh.
Leadership dalam konteks desain bukan "jadi bos". Ia adalah kemampuan mengarahkan keputusan produk menuju kualitas: memenangkan hati stakeholder, mengangkat kualitas keputusan, dan membuat tim melakukan yang benar — bukan yang mudah. Dua kuncinya: storytelling yang kuat dan penguasaan substansi (semua yang kalian pelajari di episode 1-24).
Design leader memimpin lewat keputusan dan contoh, bukan instruksi. Tiga kebiasaan yang membangun kepemimpinan desain:
Stakeholder tidak membaca dokumen — mereka mendengar cerita. Storytelling desain yang efektif punya struktur tiga babak:
Babak 1 — Keadaan saat ini (konflik)
"Pasien datang tanpa persiapan: 60% konsultasi habis untuk
menjelaskan ulang gejala yang sama. Dokter frustrasi."
Babak 2 — Visi & solusi (perubahan)
"Bayangkan pasien datang dengan ringkasan gejala otomatis
dari cek triase. 10 menit konsultasi jadi 5, dan kualitas
diagnosis naik."
Babak 3 — Bukti & langkah (aksi)
"Prototype sudah diuji: 8/10 dokter setuju ringkasan ini
membantu. Kami butuh approval untuk build fase 1."Kunci cerita yang memenangkan hati: mulai dari manusia (pasien & dokter), bukan dari fitur; tutup dengan aksi yang jelas. Angka mendukung cerita — angka tanpa cerita membosankan, cerita tanpa angka tidak kredibel.
Tanpa jabatan, pengaruh dibangun dari kredibilitas dan hubungan. Teknik yang terbukti:
| Teknik | Cara kerja |
|---|---|
| Membangun aliansi | Kenali PM, eng, dan stakeholder sebelum butuh bantuan |
| Duduk di keputusan lebih awal | Hadir saat masalah dirumuskan, bukan saat desain diminta |
| Menerjemahkan bahasa | Bicarakan metrik & risk untuk bisnis; constraint untuk eng; manfaat untuk user |
| Menang kecil dulu | Mulai dari perubahan kecil yang disetujui, bangun track record |
| Dokumentasi keputusan | Decision Log (episode 16) membuat argumen bisa dirujuk ulang |
Teknik paling kuat: menyelaraskan kepentingan. Jika fitur yang kalian usulkan juga menyelesaikan masalah PM (metrik) dan engineer (arsitektur bersih), mereka akan mendukung secara alami. Cari titik temu sebelum berargumen.
Tip
Saat ditolak, jangan bertahan dengan membela diri — itu memicu ego. Teknik yang lebih kuat: "boleh saya bawa data untuk mengecek asumsi ini?" atau "kita bisa uji coba kecil dulu selama 2 minggu?" Menawarkan eksperimen kecil berisiko rendah (episode 12) mengubah debat "iya/tidak" menjadi "mari kita lihat datanya".
Perbedaan presentasi status (episode 15) dan presentasi strategis: yang kedua mengajak stakeholder membuat keputusan. Struktur yang disarankan:
1. Di mana kita sekarang (metrik & temuan)
2. Di mana kita mau pergi (visi, dari episode 5)
3. Mengapa sekarang (opportunity & risiko menunda)
4. Apa yang kita usulkan (roadmap & prioritas)
5. Apa keputusan yang dibutuhkan (approval, resource, timing)Latihan: presentasikan roadmap fitur AI Sehati (episode 21) dengan struktur ini. Siapkan jawaban untuk pertanyaan sulit: berapa biayanya, bagaimana mitigasi risiko AI, apa buktinya user mau.
Inti yang harus dibawa pulang:
Di episode 26 selanjutnya kita akan membahas ekosistem & tren modern 2026 — merangkum lanskap product designer hari ini: AI-era roles, tren tim kecil, dan kombinasi keterampilan yang paling dicari pasar. Sampai jumpa di episode 26!