RPS minggu 6 · 2x50 menit

Lean, Agile, dan Design Thinking

Kerangka Eksekusi Inovasi Modern — Strategi Inovasi Korporasi & Kewirausahaan, Magister Manajemen FEB UNDIP

Peta Pembelajaran Hari Ini

Sub-CPMK 6: mahasiswa mampu memilih dan menerapkan kerangka eksekusi inovasi (lean, agile, design thinking) sesuai konteks ketidakpastian proyek.

Jam ke-1

Lean Startup: Build-Measure-Learn & validated learning (Ries, 2011)
MVP sebagai eksperimen, bukan produk kecil
Agile/Scrum: sprint, backlog, iterasi terkendali

Jam ke-2

Design Thinking end-to-end: empathize → define → ideate → prototype → test
Memilih kerangka per kuadran ketidakpastian (Stacey Matrix)
Mini-kasus: eksekusi fitur baru Gojek vs Traveloka

Bagian 1

Lean Startup: Belajar Cepat, Bakar Modal Sedikit

Diskusi kelas: kapan "gagal cepat" justru lebih murah daripada "sukses lambat"?

Build-Measure-Learn: Siklus Inti Lean Startup

Eric Ries (2011) — inovasi korporasi gagal bukan karena eksekusi buruk, tapi karena membangun sesuatu yang tidak dibutuhkan pasar dengan sangat efisien.

Inti bukan kecepatan build, tapi kecepatan validated learning — bukti empiris bahwa hipotesis nilai (value hypothesis) dan hipotesis pertumbuhan (growth hypothesis) benar atau salah.

MVP: Eksperimen, Bukan Produk Versi Kecil

Kesalahan manajerial paling umum: MVP dianggap "produk yang fiturnya dikurangi" — padahal MVP adalah instrumen pengujian hipotesis tercepat & termurah.

Bukan MVP

Versi "ringan" produk final yang sudah diputuskan
Dibangun tanpa hipotesis yang jelas diuji
Sukses diukur dari jumlah fitur yang berhasil dipangkas

MVP Sesungguhnya

Instrumen paling murah untuk menguji satu hipotesis kritis
Bisa berupa landing page, concierge manual, atau video "Wizard of Oz"
Sukses diukur dari kualitas pembelajaran, bukan kualitas produk

Ini titik yang sering disalahpahami manajer senior sekalipun. MVP bukan berarti kita sudah tahu produk akhirnya seperti apa lalu membangun versi murahnya. MVP adalah alat untuk menjawab pertanyaan paling berisiko dalam hipotesis bisnis Anda dengan biaya dan waktu paling minimal. Contoh klasik adalah Zappos di awal berdiri yang hanya memfoto sepatu di toko fisik dan membelinya manual setiap ada pesanan online, untuk menguji apakah orang mau beli sepatu tanpa mencoba dulu — sebelum membangun gudang dan sistem inventori sungguhan. Di konteks Indonesia, sebelum meluncurkan fitur paylater, banyak fintech menguji dengan proses manual approval oleh tim kecil untuk memvalidasi permintaan sebelum membangun sistem credit scoring otomatis penuh. Pertanyaan untuk Anda sebagai manajer proyek: hipotesis apa yang paling berisiko dalam inisiatif inovasi yang sedang Anda tangani, dan MVP semurah apa yang bisa menjawabnya minggu ini juga?

Hitung dari Nol: Runway & Kecepatan Validasi

Kasus ilustrasi — divisi inovasi korporat dengan anggaran Rp 2,4 miliar/tahun mengevaluasi kecepatan siklus Build-Measure-Learn.

Langkah	Perhitungan	Nilai
Anggaran tahunan divisi	diberikan	Rp 2.400.000.000
Biaya operasional per bulan	Rp 2.400.000.000 ÷ 12	Rp 200.000.000/bulan
Biaya rata-rata 1 siklus BML (3 minggu)	Rp 200.000.000 x (3/4,3 minggu)	~Rp 140.000.000
Jumlah siklus mungkin per tahun	12 bulan x 4,3 minggu ÷ 3 minggu	~17 siklus
Jika siklus dipercepat jadi 1 minggu (MVP lebih ramping)	52 minggu ÷ 1 minggu	~52 siklus

Implikasi Manajerial

3x lipat

Memperpendek siklus dari 3 minggu menjadi 1 minggu tidak menambah anggaran, tapi melipatgandakan jumlah hipotesis yang bisa diuji dalam setahun — inilah nilai ekonomi kecepatan validasi, bukan sekadar "budaya gesit".

Bagian 2

Agile & Scrum: Mengelola Eksekusi yang Kompleks

Diskusi kelas: apakah Agile cocok diterapkan di luar tim IT/produk digital — misalnya di divisi keuangan atau operasi pabrik?

Anatomi Sprint: Ritme Eksekusi Terkendali

Scrum (Schwaber & Sutherland) membagi eksekusi jadi iterasi pendek (1-4 minggu) dengan ritual disiplin untuk menjaga fokus dan transparansi.

Perhatikan lima elemen kunci Scrum: product backlog sebagai daftar prioritas kerja, sprint planning untuk memilih porsi backlog yang realistis dikerjakan dalam satu iterasi, daily scrum sebagai sinkronisasi harian singkat lima belas menit untuk mendeteksi hambatan lebih awal, sprint review untuk mendemokan hasil ke stakeholder, dan retrospective untuk evaluasi proses tim itu sendiri — bukan evaluasi produk. Yang membedakan Agile dari manajemen proyek tradisional adalah frekuensi umpan balik: setiap dua sampai empat minggu Anda punya increment yang bisa dievaluasi ulang prioritasnya, bukan menunggu proyek selesai satu tahun baru tahu arahnya salah. Sebagai manajer lintas fungsi, Anda tidak perlu jadi Scrum Master, tapi Anda harus paham bahwa product backlog yang berubah setiap sprint bukan tanda tim tidak disiplin — justru itu mekanisme adaptasi yang disengaja.

Lean vs Agile: Dua Kerangka, Dua Pertanyaan Berbeda

Sering dicampuradukkan — padahal menjawab pertanyaan manajerial yang berbeda dan justru saling melengkapi dalam satu siklus inovasi.

Lean Startup

Pertanyaan inti: "Apakah kita membangun hal yang tepat?"
Fokus: validasi hipotesis bisnis & product-market fit
Unit kerja: eksperimen

Agile/Scrum

Pertanyaan inti: "Apakah kita membangun hal itu dengan benar & cepat?"
Fokus: kualitas eksekusi & kecepatan delivery
Unit kerja: sprint/increment

Dalam praktik korporasi Indonesia (mis. divisi digital BCA/Mandiri), keduanya digabung: Lean menentukan apa yang divalidasi, Agile mengatur bagaimana tim mengeksekusinya sprint demi sprint.

Kesalahan manajerial yang sering terjadi adalah menganggap Lean dan Agile sebagai pilihan "salah satu saja". Padahal keduanya beroperasi di level berbeda. Lean Startup menjawab pertanyaan strategis: apakah kita sedang membangun sesuatu yang benar-benar dibutuhkan pasar? Agile menjawab pertanyaan operasional: apakah tim mengeksekusi pembangunan itu dengan efisien dan responsif terhadap perubahan? Dalam praktik nyata di divisi digital bank-bank besar Indonesia, sebuah tim bisa memakai lensa Lean untuk memutuskan fitur apa yang layak divalidasi lebih dulu, lalu memakai ritme Scrum dua mingguan untuk benar-benar membangun dan merilis fitur tersebut secara bertahap. Pertanyaan diskusi: di organisasi Anda, apakah kegagalan proyek inovasi lebih sering terjadi karena salah memvalidasi ide, atau karena eksekusi yang lambat dan tidak terkoordinasi? Jawaban Anda menentukan kerangka mana yang perlu diperkuat lebih dulu.

Bagian 3

Design Thinking End-to-End & Memilih Kerangka yang Tepat

Diskusi kelas: apakah design thinking, lean, dan agile bisa dijalankan bersamaan dalam satu proyek — atau harus berurutan?

Design Thinking: Lima Tahap Berulang, Bukan Linear

IDEO/Stanford d.school — pendekatan human-centered yang menyatu dengan Lean (validasi) dan Agile (eksekusi), bukan pesaingnya.

Panah putus-putus: Test sering melempar balik ke Define, bukan hanya ke Ideate — temuan pengujian kerap mengubah pemahaman kita atas masalahnya sendiri, bukan cuma solusinya.

Lima tahap ini bukan resep linear yang dijalankan sekali dari kiri ke kanan. Empathize adalah riset mendalam terhadap kebutuhan dan perilaku pengguna nyata, bukan asumsi tim internal. Define merumuskan pernyataan masalah yang tajam dari hasil riset tersebut. Ideate adalah tahap divergen menghasilkan banyak alternatif solusi tanpa menghakimi dulu. Prototype membentuk representasi cepat dan murah dari solusi — bisa berupa wireframe kertas, bukan produk jadi. Test menguji prototipe ke pengguna nyata. Yang perlu Anda tekankan ke tim: hasil pengujian sering memaksa kita kembali ke tahap Define karena ternyata masalah yang kita rumuskan di awal keliru, bukan sekadar solusinya yang perlu diperbaiki. Ini mirip sekali dengan pivot dalam Lean Startup — keduanya mengakui bahwa pemahaman awal terhadap masalah sering salah dan harus direvisi berdasarkan bukti.

Kerangka Analisis: Stacey Matrix untuk Memilih Metode Eksekusi

Ralph Stacey (1996, diadaptasi manajemen proyek) — pilihan kerangka bergantung pada dua sumbu ketidakpastian, bukan preferensi tim atau tren industri.

Langkah Analisis	Pertanyaan yang Diajukan	Implikasi
1. Nilai ketidakpastian kebutuhan	Apakah kita tahu persis apa yang diinginkan pengguna/pasar?	Rendah → requirement jelas; Tinggi → perlu riset dulu
2. Nilai ketidakpastian teknologi/eksekusi	Apakah cara membangunnya sudah terbukti & dikuasai tim?	Rendah → metode terbukti; Tinggi → perlu eksperimen teknis
3. Petakan ke kuadran	Kombinasi dua sumbu di atas → 4 zona keputusan	Simple / Complicated / Complex / Chaotic
4. Pilih kerangka sesuai kuadran	Kuadran mana yang cocok kerangka apa?	Complex → Lean+Design Thinking; Complicated → Agile; Simple → Waterfall/SOP

Kesimpulan Manajerial

Diagnosa dulu, baru pilih alat

Memaksakan Agile pada proyek dengan requirement sudah pasti (mis. migrasi sistem akuntansi wajib regulasi) hanya menambah birokrasi ritual tanpa manfaat; memaksakan waterfall pada proyek dengan ketidakpastian pasar tinggi (mis. fitur baru super-app) berisiko gagal total di akhir.

Ini kerangka analisis yang paling saya harapkan Anda bawa pulang dari sesi hari ini. Alih-alih memilih metode berdasarkan tren atau selera tim, gunakan dua pertanyaan diagnostik: seberapa jelas kebutuhan pengguna, dan seberapa terbukti cara teknis membangunnya. Jika keduanya jelas, Anda berada di zona simple dan cukup pakai prosedur standar atau waterfall — tidak perlu ritual Agile yang justru memperlambat. Jika kebutuhan jelas tapi cara eksekusi rumit, itu zona complicated, cocok dengan Agile/Scrum yang mengelola kompleksitas eksekusi lewat iterasi. Jika kebutuhan pasar sendiri belum jelas, itu zona complex, di sinilah Lean Startup dan Design Thinking paling relevan karena keduanya dirancang untuk memvalidasi asumsi yang belum terbukti. Kesalahan paling mahal yang sering saya lihat di korporasi Indonesia adalah menjalankan proyek regulasi wajib — yang requirement-nya sudah pasti dari OJK atau BI — dengan ritual Agile penuh, padahal itu justru zona simple yang butuh kepastian jadwal, bukan iterasi.

Mini-Kasus: Gojek — Validasi Fitur GoPay Later

Ilustrasi keputusan manajerial (angka non-publik ditandai ilustrasi) — bagaimana tim produk memilih kerangka untuk fitur kredit mikro baru.

Konteks Keputusan

Kebutuhan pasar: belum jelas — apakah mitra driver & UMKM mau produk kredit mikro dalam ekosistem Gojek?
Teknologi: credit scoring & manajemen risiko kredit belum pernah dikuasai tim internal
Kuadran Stacey: Complex — dua sumbu sama-sama tinggi

Kerangka yang Dipilih (ilustrasi)

Tahap 1: Design Thinking — empathize ke mitra driver untuk memahami kebutuhan likuiditas harian
Tahap 2: Lean MVP — uji manual approval skala kecil sebelum bangun sistem scoring otomatis
Tahap 3: Agile sprint 2 mingguan untuk membangun & menskalakan sistem setelah tervalidasi

Urutan ini bukan kebetulan: ketidakpastian tinggi memaksa validasi (Design Thinking + Lean) sebelum investasi eksekusi besar (Agile) — kebalikan urutan ini adalah resep pemborosan modal.

Perhatikan bagaimana ketiga kerangka yang kita pelajari hari ini dipakai berurutan sesuai fungsinya masing-masing, bukan dipilih salah satu. Karena baik kebutuhan pasar maupun kapabilitas teknis sama-sama belum pasti, tim harus mulai dari riset empatik untuk memahami betul persoalan likuiditas harian mitra driver — bukan menebak dari kantor pusat. Setelah masalah dipahami, Lean MVP dipakai untuk menguji hipotesis dengan proses manual berskala kecil, jauh lebih murah daripada langsung membangun sistem credit scoring otomatis penuh yang bisa menghabiskan miliaran rupiah tanpa terbukti diminati. Baru setelah validasi menunjukkan sinyal positif, tim beralih ke ritme Agile untuk membangun dan menskalakan sistem sesungguhnya. Sebagai manajer, tanyakan ke tim Anda: apakah kita sudah cukup yakin terhadap masalah dan solusi teknisnya sebelum melompat langsung ke sprint eksekusi penuh?

Mini-Kasus: Traveloka — Eksekusi Fitur pada Domain Sudah Terbukti

Ilustrasi kontras — fitur baru pada domain yang requirement dan teknologinya sudah dikuasai tim.

Konteks Keputusan

Kebutuhan pasar: jelas — menambah rute maskapai baru pada fitur pemesanan tiket yang sudah mapan
Teknologi: integrasi API maskapai sudah dikuasai tim dari puluhan integrasi sebelumnya
Kuadran Stacey: Complicated — kebutuhan jelas, eksekusi teknis yang perlu dikelola

Kerangka yang Dipilih (ilustrasi)

Langsung masuk backlog Agile — tanpa siklus Lean/Design Thinking penuh
Sprint 2 mingguan: integrasi, testing, rilis bertahap per maskapai
Validasi ringan lewat A/B test kecil, bukan riset pengguna mendalam

Menjalankan siklus empathize-define-ideate penuh untuk fitur seperti ini adalah pemborosan waktu tim — masalah dan solusinya sudah diketahui, yang dibutuhkan hanya eksekusi rapi & cepat.

Bandingkan dengan kasus Gojek sebelumnya. Di sini kebutuhan pasar sudah sangat jelas — pengguna ingin lebih banyak pilihan rute penerbangan — dan tim sudah punya rekam jejak puluhan integrasi API maskapai sebelumnya sehingga risiko teknisnya rendah. Dalam situasi seperti ini, memaksakan seluruh siklus design thinking dari empati sampai pengujian prototipe hanya membuang waktu, karena masalah dan solusinya sudah dipahami dengan baik. Yang dibutuhkan tim adalah eksekusi Agile yang rapi: masukkan ke backlog, kerjakan dalam sprint, uji dengan A/B test kecil untuk memastikan tidak ada bug, lalu rilis bertahap. Ini poin penting untuk Anda sebagai manajer: jangan menerapkan satu kerangka favorit untuk semua situasi. Pertanyaan diskusi: pernahkah Anda melihat tim di organisasi Anda menjalankan proses yang terlalu berat — misalnya workshop design thinking berhari-hari — untuk masalah yang sebenarnya sudah jelas solusinya?

Anti-Pola: Kegagalan Umum Eksekusi Inovasi Korporat

Manajer inovasi paling sering gagal bukan karena tidak tahu kerangka, tapi karena salah menerapkannya.

Anti-Pola 1

"Agile Theater"

Ritual sprint & stand-up dijalankan, tapi keputusan tetap top-down dan backlog tidak pernah benar-benar berubah berdasar data.

Anti-Pola 2

MVP Jadi Alibi

"MVP" dipakai untuk merilis produk setengah jadi ke publik tanpa hipotesis jelas apa yang sedang diuji — merusak reputasi merek.

Anti-Pola 3

Design Thinking Sekali Jalan

Workshop empati dilakukan sekali di awal proyek, hasilnya "dibekukan" — padahal seharusnya diulang saat asumsi terbukti salah.

Tiga anti-pola ini saya kumpulkan dari observasi implementasi di berbagai korporasi Indonesia, dan kemungkinan besar Anda pernah mengalami salah satunya. Agile theater terjadi ketika tim menjalankan seremoni Scrum — daily stand-up, sprint planning, retrospective — tapi keputusan strategis tetap ditentukan sepihak oleh manajemen tanpa mempertimbangkan data dari sprint sebelumnya, sehingga Agile hanya jadi kosmetik. MVP jadi alibi terjadi ketika istilah MVP disalahgunakan untuk membenarkan merilis produk yang sebenarnya belum layak, tanpa ada hipotesis jelas yang sedang diuji, sehingga pengguna kecewa dan reputasi merek rusak. Design thinking sekali jalan terjadi ketika riset empati dilakukan sekali di awal proyek sebagai formalitas, lalu tim melupakan bahwa design thinking seharusnya berulang setiap kali asumsi awal terbukti keliru di lapangan. Sebagai manajer, tugas Anda memastikan tim tidak sekadar meniru ritual permukaan dari ketiga kerangka ini, tapi benar-benar menginternalisasi filosofinya.

Sintesis: Satu Kerangka Terintegrasi untuk Portofolio Inovasi

Bagi manajer yang mengawasi banyak proyek inovasi sekaligus — bukan memilih satu kerangka permanen, tapi mendiagnosis tiap proyek secara berkala.

Diagnosa ketidakpastian (Stacey) → pilih kerangka dominan → re-diagnosa tiap milestone, karena ketidapastian bisa berubah seiring waktu

Praktik terbaik: proyek yang lahir di zona Complex (Lean + Design Thinking) sering "lulus" ke zona Complicated (Agile murni) setelah validated learning tercapai — pergeseran kerangka adalah tanda kematangan proyek, bukan inkonsistensi.

Sebagai penutup bagian konseptual, saya ingin Anda membawa pulang satu prinsip sintesis: jangan menikahi satu kerangka kerja untuk seluruh siklus hidup proyek. Diagnosa ulang tingkat ketidakpastian proyek Anda di setiap milestone penting, karena proyek yang lahir dalam ketidakpastian tinggi — sehingga memakai Lean dan Design Thinking di awal — secara alami akan bergeser ke ketidakpastian lebih rendah setelah tim mengumpulkan cukup validated learning, dan pada titik itu Agile murni menjadi kerangka yang lebih efisien. Ini bukan tanda tim tidak konsisten, justru tanda proyek sedang matang. Sebagai manajer portofolio inovasi, laporan yang Anda minta dari setiap project owner sebaiknya bukan hanya "status proyek", tapi juga "di kuadran ketidakpastian mana proyek ini sekarang, dan apakah kerangka eksekusinya masih sesuai".

Latihan Kelas: Diagnosa & Rekomendasi Kerangka

Kerjakan berpasangan (10 menit), lalu 3 pasangan presentasi singkat di depan kelas.

Instruksi

Pilih satu inisiatif inovasi nyata dari organisasi tempat Anda bekerja (boleh disamarkan namanya).
Nilai dua sumbu Stacey Matrix: kejelasan kebutuhan pasar & kematangan teknologi/eksekusi.
Tentukan kuadran, lalu rekomendasikan kombinasi kerangka (Lean/Agile/Design Thinking) beserta urutannya.
Identifikasi satu anti-pola dari slide sebelumnya yang paling berisiko terjadi pada proyek Anda, dan cara mencegahnya.

Siapkan argumen: mengapa kerangka yang Anda pilih lebih tepat dibanding alternatif lain untuk kasus spesifik ini — bukan sekadar "karena sedang tren".

Ringkasan & Jembatan ke Pertemuan Berikutnya

Poin Kunci Hari Ini

Lean Startup memvalidasi apa yang dibangun lewat Build-Measure-Learn & MVP
Agile/Scrum mengeksekusi bagaimana membangunnya lewat sprint iteratif
Design Thinking menyatukan riset manusia dengan validasi & eksekusi
Stacey Matrix: diagnosa ketidakpastian dulu, baru pilih kerangka

Pertemuan 7

Kekayaan intelektual (paten, merek, rahasia dagang) sebagai pelindung hasil eksekusi inovasi
Inovasi model bisnis: bagaimana kerangka eksekusi hari ini melindungi/dilindungi strategi IP
Bawa satu contoh produk/fitur yang menurut Anda punya keunggulan IP kuat

Mari kita rangkum perjalanan dua jam kita hari ini. Lean Startup mengajarkan kita memvalidasi apa yang seharusnya dibangun lewat siklus Build-Measure-Learn dan MVP sebagai instrumen eksperimen. Agile dan Scrum mengajarkan kita mengeksekusi pembangunan itu secara iteratif dan responsif lewat sprint. Design Thinking menyatukan keduanya dengan menempatkan riset kebutuhan manusia di pusat proses. Dan yang terpenting, Stacey Matrix memberi Anda alat diagnostik untuk memilih kombinasi kerangka yang tepat sesuai tingkat ketidakpastian proyek, bukan berdasarkan tren industri semata. Minggu depan kita membahas bagaimana hasil eksekusi inovasi ini dilindungi lewat kekayaan intelektual — paten, merek, dan rahasia dagang — serta bagaimana strategi IP mempengaruhi model bisnis inovasi itu sendiri. Silakan bawa satu contoh produk atau fitur yang menurut Anda punya keunggulan kekayaan intelektual yang kuat untuk didiskusikan.