Panduan teknikal membangun produk HR dari nol. Bukan cerita filosofi. Ini playbook yang bisa Anda pakai Senin pagi, di meeting room, di depan CEO, saat menulis PRD, saat demo mockup pertama kali. Setiap framework bisa dipakai. Setiap template bisa diisi. Setiap angka bisa dihitung.
A technical playbook for building HR products from scratch. Not philosophy. This is a handbook you can use on Monday morning, in a meeting room, in front of the CEO, when writing the PRD, when demoing the first mockup. Every framework is usable. Every template fillable. Every number computable.
Kesalahan termahal dalam membangun sistem HR bukan salah pilih teknologi. Kesalahan termahal adalah membangun sesuatu yang seharusnya dibeli, atau membeli sesuatu yang seharusnya dibangun. Keputusan ini dibuat di awal, dan sulit dibalik setelah 6 bulan kode sudah ditulis.
The most expensive mistake in building HR systems is not the wrong tech stack. It is building what should have been bought, or buying what should have been built. This decision is made early, and hard to reverse after 6 months of code.
Kalau masalahnya sudah umum (payroll standar, absensi, leave management), kalau vendor sudah matang, kalau regulasi sering berubah (BPJS, PPh21). Build akan membuang 18 bulan untuk menemukan kembali roda yang sudah ada.
When the problem is generic (standard payroll, attendance, leave), when vendors are mature, when regulations change often (statutory taxes). Build will waste 18 months reinventing a wheel that already rolls.
Pola paling sering menang. Payroll engine beli, tapi integrasi koperasi syariah, benefit flex, dan reporting eksekutif dibangun sendiri. Standar di bawah, diferensiasi di atas. Ini adalah pola yang dipakai Nabati, Indofood, dan banyak Indonesian enterprise matang.
The pattern that wins most often. Buy the payroll engine, but build sharia cooperative integration, flex benefits, and executive reporting in-house. Standard at the base, differentiation on top. This is the pattern used by Nabati, Indofood, and many mature Indonesian enterprises.
Kalau proses bisnis Anda adalah keunggulan kompetitif (bonus scheme unik, career path yang tidak ada di vendor mana pun, integrasi ke manufacturing MES). Build saat tidak ada vendor yang bisa mengakomodasi, dan skala Anda membenarkan investasi.
When your business process is your competitive edge (unique bonus schemes, career paths no vendor supports, manufacturing MES integration). Build when no vendor fits, and your scale justifies the investment.
Setiap PM junior jatuh di jebakan yang sama: duduk di meeting room, lihat dashboard, lalu tulis PRD. Hasilnya fitur yang elegan di Figma tapi tidak dipakai di lapangan. Discovery bukan tahap yang bisa di-skip. Ini adalah tahap yang membedakan produk yang dipakai dari produk yang hanya di-demo sekali lalu dilupakan.
Every junior PM falls for the same trap: sit in a meeting room, stare at a dashboard, then write the PRD. The result is features elegant in Figma but unused in the field. Discovery is not a stage you can skip. It is the stage that separates products people use from products demoed once and forgotten.
8 sampai 12 pengguna real, bukan stakeholder. HR Admin yang input data setiap hari. Manager yang approve leave setiap minggu. Karyawan produksi yang download slip gaji di HP. Tanya tentang hari terakhir mereka, bukan pendapat mereka.
8 to 12 real users, not stakeholders. HR Admin who inputs data daily. Manager who approves leave weekly. Factory worker who downloads payslip on phone. Ask about their last day, not their opinions.
Duduk di samping HR Admin selama 3 jam. Lihat mereka kerja tanpa diganggu. Catat setiap klik, setiap file Excel yang dibuka, setiap WhatsApp yang masuk. Anda akan lihat workaround yang tidak pernah mereka sebut di interview.
Sit next to the HR Admin for 3 hours. Watch them work without interrupting. Note every click, every Excel file opened, every WhatsApp message. You will see workarounds they never mentioned in interview.
Setelah interview, Anda punya hipotesis. Sekarang validasi ke 200 sampai 500 orang. Tanyakan frekuensi (seberapa sering), severity (seberapa mengganggu), workaround (sudah akal-akal pakai apa). Data ini yang akan jadi fondasi business case.
After interviews, you have hypotheses. Now validate across 200 to 500 people. Ask frequency (how often), severity (how annoying), workaround (what hack are they using). This data becomes the foundation of your business case.
Kalau ada sistem lama, tariklah log-nya. Berapa klik per hari di modul apa. Di mana drop-off. Di mana orang stuck sampai lebih dari 30 detik. Data ini tidak bohong. Interview bisa bias, analytics tidak.
If there is a legacy system, pull its logs. How many clicks per day per module. Where the drop-off is. Where people are stuck for over 30 seconds. This data does not lie. Interviews can be biased, analytics cannot.
Klik pada setiap pain point untuk memetakannya ke matriks Impact vs Frequency. Pain point di kuadran kanan atas adalah prioritas tertinggi untuk dibangun.
Click each pain point to map it onto the Impact vs Frequency matrix. Pain points in the top-right quadrant are the highest priority to build.
Jangan membangun apa yang paling sering disebut. Bangun apa yang kombinasi impact tinggi dan frekuensi tinggi. Karyawan sering mengeluhkan hal kecil yang terjadi setiap hari, tapi impact finansialnya kecil. Sementara pain point dengan impact besar, seperti kesalahan payroll yang membuat karyawan resign, sering tidak disebut karena sudah "dianggap normal".
Do not build what is complained about most often. Build what combines high impact and high frequency. Employees often complain about small things that happen daily but have tiny financial impact. Meanwhile, high-impact pain points like payroll errors that cause resignations are often unmentioned because they are "considered normal".
Ini adalah pelajaran yang saya pelajari dengan mahal. Di ruangan dengan CEO dan CFO, argumen "sistem kita sudah tua" tidak akan diapprove. Tapi argumen "3% karyawan kita keluar tiap bulan karena payroll salah, itu Rp 840 juta rugi setahun, dan kompetitor sudah pakai sistem yang tidak begitu" akan diapprove sebelum presentasi selesai. Business case yang baik tidak memohon. Business case yang baik menunjukkan risiko dan peluang dalam bahasa uang.
This is a lesson learned the expensive way. In a room with CEO and CFO, "our system is old" will not get approved. But "3% of employees leave monthly due to payroll errors, costing IDR 840M yearly, and competitors already have a system that does not do this" gets approved before the presentation ends. A good business case does not beg. A good business case shows risk and opportunity in the language of money.
Karyawan keluar karena payroll salah. Setiap resign senilai 2-3x gaji bulanan. Ini bocor revenue langsung.
Employees quit due to payroll errors. Each resignation costs 2-3x monthly salary. That is direct revenue leak.
Denda BPJS karena terlambat lapor. Tuntutan hukum dari karyawan yang PHK tidak prosedural. Audit temuan.
Statutory fines from late filing. Lawsuits from improper terminations. Audit findings.
UU PDP. PPh21. BPJS. Regulasi kerja yang terus berubah. Sistem lama tidak kompatibel dengan aturan baru.
Personal Data Protection Law. Income tax. Social security. Ever-changing labor rules. Legacy systems incompatible with new rules.
Kompetitor sudah pakai. Kandidat top memilih mereka karena experience join-nya lebih profesional. Ini tiang branding.
Competitors already have it. Top candidates choose them due to smoother onboarding. This is brand equity.
Saya pernah melihat proposal HRIS senilai 4 miliar ditolak karena sang presenter tidak bisa menjawab satu pertanyaan CFO: "Dari mana angka ROI 240% ini?" Sejak itu, setiap CBA yang saya buat harus bisa di-trace sampai asumsi mentahnya. Kalkulator di bawah bisa Anda pakai untuk latihan. Masukkan angka perusahaan Anda sendiri. Lihat hasilnya.
I once watched a 4-billion HRIS proposal rejected because the presenter could not answer one CFO question: "Where does this 240% ROI come from?" Since then, every CBA I build must be traceable to its raw assumption. The calculator below lets you practice. Plug in your company's numbers. Watch the output.
Catatan penting. Kalkulator ini memakai asumsi standar (ATS bisa menekan biaya recruiter 35% dan time-to-hire 40%, terbukti di banyak studi kasus manufaktur Indonesia). Saat Anda presentasi ke CFO, SIAPKAN sensitivity analysis: "Kalau penghematan turun ke 20%, ROI masih 140%. Kalau turun ke 10%, ROI jadi 60% dan payback jadi 22 bulan." CFO akan selalu tanya ini.
Important note. This calculator uses standard assumptions (ATS typically reduces recruiter cost 35% and time-to-hire 40%, proven across Indonesian manufacturing cases). When presenting to the CFO, PREPARE sensitivity analysis: "If savings drop to 20%, ROI is still 140%. If they drop to 10%, ROI becomes 60% and payback is 22 months." The CFO will always ask.
PRD yang buruk ditulis seperti brosur: fitur, fitur, fitur. PRD yang baik ditulis seperti kontrak hukum: masalah jelas, lingkup jelas, metrik sukses jelas, dan yang tidak masuk scope juga jelas. Saya review lebih dari 200 PRD dalam karir saya. Yang sukses selalu punya 12 bagian ini. Yang gagal selalu kehilangan minimal 3.
A bad PRD reads like a brochure: features, features, features. A good PRD reads like a legal contract: clear problem, clear scope, clear success metrics, and clear non-goals. I have reviewed over 200 PRDs in my career. Successful ones always have these 12 sections. Failed ones always miss at least 3.
Centang bagian yang sudah Anda tulis di PRD Anda. Lihat skor di bawah.
Check off sections you have written in your PRD. See your score below.
2 paragraf. Masalah yang dialami pengguna (bukan masalah HR), di-ground dengan data dari discovery. "HR Admin menghabiskan 43 jam per bulan untuk rekonsiliasi absensi manual" bukan "absensi kurang efisien".
2 paragraphs. The problem users experience (not HR's problem), grounded in discovery data. "HR Admin spends 43 hours monthly on manual attendance reconciliation" not "attendance is inefficient".
3-5 Goal. 3-5 Non-Goal (sama pentingnya). Non-Goal mencegah scope creep. "Non-Goal: tidak akan mengganti payroll engine existing." Tulisan ini akan menyelamatkan Anda bulan depan saat ada stakeholder minta tambah fitur.
3-5 Goals. 3-5 Non-Goals (equally important). Non-Goals prevent scope creep. "Non-Goal: will not replace the existing payroll engine." This line saves you next month when a stakeholder asks for extras.
3-4 persona maksimum. Setiap persona: nama fiktif, role, frequency of use, top 3 goals, top 3 frustrations. Contoh: "Ibu Wati, HR Admin Pabrik 1, pakai sistem 6 jam/hari, frustrasi paling besar: harus buka 4 sistem berbeda."
3-4 personas max. Each: fictional name, role, usage frequency, top 3 goals, top 3 frustrations. Example: "Wati, HR Admin Plant 1, uses the system 6 hrs/day, biggest frustration: 4 separate systems to open."
Format: "Sebagai [persona], saya ingin [action] supaya [outcome]." Lampirkan acceptance criteria: "Given X, When Y, Then Z." Satu PRD bisa punya 30-80 user stories untuk produk ukuran sedang.
Format: "As a [persona], I want [action] so that [outcome]." Attach acceptance criteria: "Given X, When Y, Then Z." One PRD can have 30-80 user stories for a medium product.
Apa yang sistem harus bisa lakukan. Dikelompokkan per modul (Login, Dashboard, Payroll, Reporting). Diprioritaskan dengan MoSCoW: Must, Should, Could, Won't. Jangan sampai ada "nice to have" tanpa prioritas jelas.
What the system must be able to do. Grouped by module (Login, Dashboard, Payroll, Reporting). Prioritized with MoSCoW: Must, Should, Could, Won't. Never let "nice to have" exist without clear priority.
Performance (page load 2 detik), security (OWASP top 10), scalability (3000 concurrent users), availability (99.5% uptime), accessibility (WCAG AA). Bagian ini yang tidak pernah ada di PRD junior tapi selalu ada di PRD senior.
Performance (2-second load), security (OWASP top 10), scalability (3000 concurrent), availability (99.5% uptime), accessibility (WCAG AA). This section is missing in junior PRDs but always present in senior PRDs.
Entity-Relationship Diagram tingkat tinggi. Tidak perlu detail database schema, tapi Employee berhubungan dengan Payroll harus jelas. Sertakan data dictionary: apa arti "active employee" secara formal.
High-level entity-relationship diagram. No need for full database schema, but Employee relates to Payroll must be clear. Include data dictionary: what does "active employee" formally mean.
Happy path, sad path, edge case. Satu diagram untuk setiap workflow utama. Misal: leave request flow, payroll approval flow, hire-to-retire flow. Use BPMN atau swimlane minimal.
Happy path, sad path, edge case. One diagram per major workflow. Example: leave request flow, payroll approval, hire-to-retire. Use BPMN or at least a swimlane diagram.
Sistem lain yang harus dihubungkan. SAP ERP, core banking untuk payroll transfer, BPJS API, biometric devices, Google Workspace SSO, dll. Jelaskan kontrak data per integrasi, siapa PIC di sisi vendor.
Other systems to connect. SAP ERP, core banking for payroll transfer, statutory APIs, biometric devices, Google Workspace SSO, etc. Describe data contract per integration, PIC on the vendor side.
3-5 metrik. Harus measurable. "Time-to-hire turun dari 45 ke 28 hari dalam 6 bulan." "HR Admin task-completion rate naik dari 72% ke 90%." Angka sebelum dan sesudah, dengan tanggal.
3-5 metrics. Must be measurable. "Time-to-hire drops from 45 to 28 days in 6 months." "HR Admin task completion rate rises from 72% to 90%." Before and after numbers, with dates.
Phase 1 ke mana, Phase 2 ke mana. Pilot di pabrik mana, kapan. Kriteria go/no-go antar phase. Change management: training siapa, kapan, oleh siapa. Rollout paling rentan, bukan fitur.
Phase 1 target, Phase 2 target. Which plant pilots, when. Go/no-go criteria between phases. Change management: who trains whom, when, by whom. Rollout is the riskiest stage, not features.
Hal yang belum Anda tahu. Tulis. "Belum clear bagaimana integrasi dengan payroll vendor baru. Dependency pada keputusan legal untuk UU PDP." Kejujuran ini yang membuat stakeholder percaya.
Things you do not yet know. Write them. "Integration with the new payroll vendor unclear. Dependency on legal decision about PDP Law." This honesty earns stakeholder trust.
Sistem HR internal punya pola UX yang berbeda dengan consumer app. Pengguna Anda akan memakai sistem ini 6 jam sehari. Mereka butuh density yang tinggi, bukan ruang kosong. Mereka butuh shortcut keyboard, bukan onboarding tour. Tapi di saat yang sama, tombol-tombol yang mereka klik harus eksplisit, karena mereka melakukan tugas yang konsekuensinya finansial (payroll approval, offer letter, terminasi). Kesalahan satu klik di HR system adalah kesalahan yang mahal.
Internal HR systems follow different UX patterns from consumer apps. Your users will use this 6 hours a day. They need high density, not whitespace. They need keyboard shortcuts, not onboarding tours. But at the same time, the buttons they click must be explicit because they perform tasks with financial consequences (payroll approval, offer letters, terminations). One wrong click in an HR system is an expensive mistake.
Coretan di kertas atau Miro. Tidak ada warna, tidak ada font. Hanya kotak dan panah. Goal: memastikan alur dan struktur informasi.
Scribbles on paper or Miro. No colors, no fonts. Just boxes and arrows. Goal: confirm flow and information architecture.
Figma dengan design system dasar. Warna, font, komponen sudah konsisten. Belum prototype clickable, tapi stakeholder sudah bisa menilai visual language.
Figma with basic design system. Consistent colors, fonts, components. Not yet clickable prototype, but stakeholders can judge the visual language.
Figma Prototype atau Framer. Interaksi nyata. Ini yang dipakai untuk usability test dengan 5-8 pengguna. Test selalu menemukan hal yang tidak pernah terpikir saat di whiteboard.
Figma Prototype or Framer. Real interactions. This is what you use for usability tests with 5-8 users. Tests always find things whiteboarding missed.
Inilah daftar yang saya pakai untuk review desain. Jika salah satu tidak ada, mockup belum siap untuk development.
This is the checklist I use when reviewing designs. If any is missing, the mockup is not ready for development.
Setiap PM junior bisa menggambar alur "karyawan apply cuti, manager approve, selesai". Tapi apa yang terjadi kalau manager sedang cuti? Kalau approval level 2 menolak? Kalau karyawan ingin cancel cuti tapi sudah diapprove? Kalau cuti diambil tapi jumlah sisa cuti ternyata salah di sistem? Edge case inilah yang membuat sistem real berbeda dari demo.
Any junior PM can draw "employee requests leave, manager approves, done". But what happens if the manager is on leave? If level 2 rejects? If the employee wants to cancel an already-approved leave? If leave is taken but the remaining balance was wrong in the system? These edge cases separate real systems from demos.
Prinsip emas. PRD yang hanya menulis happy path akan menghasilkan produk yang bug. Luangkan waktu menulis minimal 5 sad path dan 5 edge case untuk setiap workflow utama. Ini yang membedakan senior PM dari junior.
Golden rule. A PRD that writes only the happy path ships buggy products. Spend the time to write at least 5 sad paths and 5 edge cases per major workflow. This separates senior PMs from juniors.
Saya pernah melihat dashboard dengan 42 chart ditolak, dan 1 grafik sederhana diapprove. Perbedaannya: yang 42 chart menunjukkan semua. Yang 1 grafik membuat argumen. Data storytelling adalah seni memilih angka yang berbicara, merangkainya dalam narasi yang jelas, dan memvisualisasikannya dengan chart yang tepat. Di presentasi ke board, kehilangan perhatian di 30 detik pertama sama dengan kehilangan persetujuan.
I once watched a dashboard with 42 charts get rejected, and one simple graph get approved. The difference: the 42-chart one showed everything. The one-graph one made an argument. Data storytelling is choosing numbers that speak, weaving them into clear narrative, and visualizing with the right chart. In a board presentation, losing attention in the first 30 seconds means losing approval.
Barbara Minto, konsultan McKinsey, mengajarkan: mulai dengan jawaban. Lalu berikan tiga pilar pendukung. Lalu detail per pilar. Ini kebalikan dari cara kita menulis skripsi, tapi cara terbaik untuk management.
Barbara Minto, McKinsey consultant, taught: start with the answer. Then give three supporting pillars. Then detail per pillar. This is the opposite of how we write theses, but the best way for management.
Istilah dari militer. Di email, di memo, di Slack, di presentasi, selalu buka dengan keputusan atau rekomendasi terlebih dulu. Context dan detail datang setelah. Waktu eksekutif mahal, hormati.
A military term. In email, memos, Slack, presentations, always open with the decision or recommendation first. Context and detail come later. Executive time is expensive, respect it.
Membandingkan kategori. Paling jelas, paling sering disalahgunakan untuk time series.
Comparing categories. Clearest chart, most often misused for time series.
Trend over time. Satu garis untuk fokus, maksimal 4 garis kalau memang perlu perbandingan.
Trend over time. One line for focus, max 4 lines if comparison is truly needed.
Proses bertahap dengan drop-off. Recruitment funnel. Hire-to-retire. Paling kuat untuk menunjukkan kebocoran.
Staged process with drop-off. Recruitment funnel. Hire-to-retire. Most powerful for showing leaks.
2 dimensi dengan intensitas. Cocok untuk pola mingguan (hari × jam), engagement matrix, pola absensi.
2 dimensions with intensity. Great for weekly patterns (day × hour), engagement, attendance patterns.
Setiap produk HR punya DNA yang berbeda. ATS mengoptimalkan throughput dan kualitas kandidat. LMS mengoptimalkan completion dan retention pengetahuan. Payroll mengoptimalkan akurasi dan kepatuhan regulasi. Salah apply pola membuat produk yang salah bentuk. Di bawah, klik setiap domain untuk drilldown. Setiap domain berisi: core journey, minimum feature set, tombol yang wajib ada, data entity utama, integrasi kritis, regulasi, dan pitfall umum.
Each HR product has different DNA. ATS optimizes throughput and candidate quality. LMS optimizes completion and knowledge retention. Payroll optimizes accuracy and regulatory compliance. Applying the wrong pattern makes a misshapen product. Click each domain below to drill down. Each contains: core journey, minimum feature set, must-have buttons, core data entities, critical integrations, regulations, and common pitfalls.
Istilah-istilah ini akan muncul di meeting, di JIRA, di email engineer. Memahami bahasa ini membedakan PM yang dihormati tim teknis dari PM yang dikelilingi senyum sopan tapi tidak didengar.
These terms will come up in meetings, in JIRA, in engineer emails. Speaking this language separates PMs the tech team respects from PMs met with polite smiles but unheard.
Setiap fase pembangunan sistem HR menghasilkan dokumen yang berbeda. Tim junior sering menganggap dokumen adalah "bureaucracy". Salah. Dokumen adalah memory perusahaan. Dalam 3 tahun, Anda sudah tidak ingat kenapa tombol itu warnanya merah, tapi tim baru perlu tahu. Dokumen ini yang menjawab.
Each phase of HR system development produces different documents. Junior teams often dismiss them as "bureaucracy". Wrong. Documents are company memory. In 3 years, you will not remember why that button is red, but the new team needs to know. These documents answer that.
9 file terpisah: PRD template, Business Case 1-pager, CBA calculator Excel, User Interview Script, Data Dictionary, User Story Backlog, UAT Script, Glossary, dan Workflow Diagrams. Semua bisa langsung Anda pakai.
9 separate files: PRD template, Business Case 1-pager, CBA calculator Excel, User Interview Script, Data Dictionary, User Story Backlog, UAT Script, Glossary, and Workflow Diagrams. All ready to use.
Di akhir, yang menentukan bukan seberapa elegan PRD Anda, seberapa indah mockup Figma Anda, atau seberapa tinggi ROI di slide Anda. Yang menentukan adalah apakah seorang HR Admin di pabrik mau buka aplikasi Anda besok pagi, dan apakah aplikasi itu membuat hidupnya lebih ringan. Semua framework di lecture ini ada untuk melayani satu hal: manusia yang memakai.
In the end, what matters is not how elegant your PRD, how beautiful your Figma mockup, or how high the ROI on your slide. What matters is whether an HR Admin in a plant opens your app tomorrow morning, and whether that app makes her life lighter. Every framework in this lecture exists to serve one thing: the person using it.
Discovery bukan optional. Talk to users. Watch them. Measure them. Tanpa ini, semua yang Anda bangun adalah tebakan.
Discovery is not optional. Talk to users. Watch them. Measure them. Without this, everything you build is a guess.
Tulis Non-Goal. Apa yang tidak akan Anda bangun. Ini yang menyelamatkan project dari scope creep.
Write Non-Goals. What you will not build. This saves projects from scope creep.
Angka sebelum slide. Business case harus bisa di-trace ke asumsi mentah. Sensitivity analysis wajib.
Numbers before slides. Business cases must be traceable to raw assumptions. Sensitivity analysis mandatory.