Hal yang paling berbahaya dalam pengembangan produk bukanlah kekurangan sebuah ide. Karena ide dapat ditemukan di mana saja. Baik dari tim sales, customer support, arahan atasan, maupun langsung dari user. Product Manager yang baik mampu mengatur serta memprioritaskan setiap ide yang masuk ke dalam backlog yang terstruktur.
Di sinilah pemahaman PM terhadap framework dan metode menjadi aset paling berharga.
Metode atau kerangka kerja bukan sesuatu yang kaku. PM menggunakan cara ini untuk memprioritaskan ide mana yang akan mereka eksekusi lebih awal. Berikut enam kerangka kerja yang sering Product Manager terapkan.
Lugas & Langsung:
Berdasarkan prioritas: Memilih apa yang dieksekusi
Kerangka Kerja RICE (Rice Framework)
RICE merupakan metode kuantatif untuk mengevaluasi item backlog secara objektif. PM memanfaatkan empat variabel (reach, impact, confidence, dan effort) pada metode ini untuk menekan pertimbangan emosional saat mengambil keputusan.
- Reach: Berapa jumlah user yang menggunakan fitur tersebut?
- Impact: Seberapa besar dampak dari user experience atau bisnis goal?
- Confidence: Seberapa besar keyakinan PM tentang ide ini?
- Effort: Seberapa banyak/lama untuk pengembangan ide ini, baik dari desain, engineering, dan testing.
contoh kasus:
Product Manager mengevaluasi opsi untuk menghadirkan “Mode Gelap” bagi pengguna atau menyelesaikan “Pengekspor CSV Kustom” yang kompleks. RICE akan mengabarkan ke stakeholder bahwa implementasi “Mode Gelap” cukup mudah dan sangat menguntungkan dari segi efisiensi jam kerja tim pengembang.
Kerangka kerja MoSCoW (MoSCoW Framework)
Kerangka kerja MoSCoW menjamin penyelesaian proyek tepat waktu dengan membaginya ke dalam empat kategori utama. Product Manager memanfaatkan kategori tersebut untuk memetakan seluruh rencana pengembangan produk.
Kategori pada MoSCoW adalah:
- Must-Have: Fitur utama yang wajib ada dan memengaruhi penyelesaian seluruh proses pengembangan.
- Should-Have: Fitur yang mampu meningkatkan nilai fungsi utama, tetapi tim tetap bisa meluncurkan produk tanpa fitur ini.
- Could-Have: Fitur tambahan yang sangat baik untuk tim kerjakan jika masih memiliki sisa waktu pengembangan.
- Won’t-Have: Elemen yang telah disetujui untuk tidak dikerjakan dalam proses pengembangan saat ini.
Contoh kasus:
Dalam pembuatan halaman pendaftaran yang baru, “email input” dan “Password Creation” adalah hal yang Must-Have. “Sign with Google” adalah sesuatu yang Should-have. Sedangkan “custom-profile” merupakan sesuatu yang Could-have. dan “Phone-number” untuk pengembangan saat ini akan menjadi Won’t-Have
Baca Juga: A Needed Documentation: PRD, BRD, and SRD Explained
Kerangka kerja Kano (Kano Model)
Kano Model memetakan pengembangan fitur berdasarkan emosi dari user dan membandingkannya dengan effort dalam proses pengerjaannya. Dengan menggunakan kanon model ini, Product Manager dapat menyeimbangkan kebutuhan operational dan inovasi.
Kano mengunakan tiga variabel:
Dasar: Sesuatu hal yang biasanya menjadi hal lumrah, tetapi tanpa adanya fitur ini, user akan merasa kebingungan ataupun marah.
Kinerja: sebuah fungsi yang lebih banyak ada, maka lebih baik
Menyenangkan: fungsi yang akan memicu kesenangan user walaupun user tidak membutuhkannya.
Contoh kasus:
Dalam Gojek/Grab, mengetahui pengemudi adalah hal dasar. Informasi kedatangan adalah fitur Kinerja. Kemampuan untuk memilih preferensi kendaraan dalam aplikasi adalah hal yang menyenangkan.
baca juga: From Junior to Senior PM: The 2026 Roadmap to Leveling Up
Discovery & Growth Frameworks: Memahami niat dan siklus pengembangan
Jobs To Be Done (JTBD)
Pada framework JTBD fokus pada demographic user yang kita miliki dan maksud dari mereka. User tidak membeli sebuah produk atau fitur, tetapi mereka menggunakan product atau fitur dikarenakan situasi yang terjadi.
Rumus dalam JTBD adalah: Ketika User [Situasi], user ingin [Motivasi], dan user akan [mendapatkan]
Jika melihat dari rumus, kita dapat mengetahui kenapa user menggunakan produk yang kita kembangkan.
Contohnya: Pengguna memanfaatkan aplikasi kalender demi menghindari bentrok jadwal meeting dan tampil profesional di mata klien, bukan karena faktor visual semata.
AARRR Funnel (The Pirate Metrics)
PM menggunakan AARRR funnel untuk membagi Customer Lifecycle ke dalam lima tahapan terukur agar dapat menganalisis penurunan kinerja serta peluang pengembangan produk.
lima tahapan tersebut adalah:
- Acquisition: Bagaimana user mengenal produk,
- Activation: Bagaimana user dapat menggunakan produk,
- Retention: Apakah user kembali menggunakan produk,
- Referral: Bagaimana user mengundang user lain untuk menggunakan produk,
- Revenue: Bagaimana user secara efektif mendatangkan sebuah revanue,
Dengan metode AARRR ini, Product Manager dapat mengetahui kekurangan atau permasalahan yang terjadi pada produk yang mereka kembangkan.
Strategic Frameworks: Penyesuaian dengan kenyataan pasar.
SWOT Analysis
SWOT merupakan matrix yang sering digunakan dalam perencanaan strategis untuk mengevaluasi kemampuan produk terhadap kenyataan di lapangan. Metode SWOT melihat secara internal (Strength, dan Weaknesses) dan secara eksternal (Opportunities dan Threats).
Strength (Internal): Melihat kemampuan secara bisnis atau teknologi untuk mengetahui kekuatan dari produk yang kita miliki
Weaknesses (Internal): Menganalisis kekurangan produk demi menetapkan solusi dan langkah eksekusi selanjutnya.
Opportunities (Eksternal): Melihat kemampuan atau kondisi pasar, teknologi, ataupun ekonomi yang akan memengaruhi user.
Threats(Eksternal): Perubahan regulasi, penetapan harga pesaing yang agresif, ketergantungan platform.
Setelah Anda mengenal framework dasar Product Manager, pembahasan berikut mengulas kebutuhan dan langkah penggunaannya secara singkat.
