Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được bổ nhiệm làm Head of Product cho một ví điện tử đang tăng trưởng nóng tại Việt Nam. Đội ngũ của bạn nghĩ ra một tính năng cho vay tiêu dùng nhanh, code xong trong hai tuần, sẵn sàng bấm nút "ship". Nhưng rồi pháp chế bước vào phòng họp và nói: "Khoan đã. Tính năng này thuộc phạm vi điều chỉnh của Ngân hàng Nhà nước. Nếu phát hành mà chưa có giấy phép trung gian thanh toán phù hợp, công ty có thể bị phạt, thậm chí bị thu hồi giấy phép." Cảm giác hụt hẫng đó — khi một sản phẩm hoàn hảo về mặt kỹ thuật lại không thể ra mắt — là điều mà mọi product leader trong ngành chịu quản lý (regulated industries) đều phải đối mặt.
Ở cấp độ Senior PO hay Head of Product, bạn không còn chỉ tối ưu trải nghiệm người dùng và tốc độ giao hàng. Bạn phải lãnh đạo sản phẩm trong một môi trường nơi luật pháp, cơ quan quản lý và kiểm toán là những "stakeholder" có quyền lực phủ quyết tuyệt đối. Một quyết định sai về tuân thủ không chỉ làm chậm roadmap — nó có thể khiến công ty bị phạt hàng tỷ đồng, mất giấy phép hoạt động, hoặc kéo theo trách nhiệm hình sự cá nhân. Đây là kỹ năng phân biệt một product leader trưởng thành với một người chỉ giỏi xây tính năng.
Bài này tập trung hẹp vào một câu hỏi: làm thế nào để lãnh đạo sản phẩm hiệu quả trong ngành chịu quản lý, mà vẫn giữ được tinh thần agile và empirical của Scrum? Chúng ta sẽ không bàn về crisis management (Bài 26) hay quản trị rủi ro danh mục (Bài 55) — mà tập trung vào đặc thù riêng của môi trường regulated.
Khái niệm cốt lõi
Regulated industry là gì và những lĩnh vực phổ biến
Ngành chịu quản lý là những lĩnh vực mà ở đó nhà nước đặt ra các quy định bắt buộc về cách thiết kế, vận hành và phát hành sản phẩm, vì sản phẩm đó ảnh hưởng trực tiếp đến an toàn, tài chính, sức khỏe hoặc quyền lợi cốt lõi của công dân. Những lĩnh vực phổ biến nhất gồm:
- Tài chính – ngân hàng (financial): ngân hàng, ví điện tử, fintech, bảo hiểm, chứng khoán. Tại Việt Nam chịu sự quản lý của Ngân hàng Nhà nước (NHNN), Bộ Tài chính, Ủy ban Chứng khoán.
- Y tế (healthcare): thiết bị y tế, phần mềm chẩn đoán, hồ sơ bệnh án điện tử, telehealth. Chịu quản lý của Bộ Y tế; ở phương Tây là FDA (Mỹ), EMA (châu Âu).
- Giáo dục (education): cấp chứng chỉ, dữ liệu học sinh vị thành niên, kiểm định chương trình. Chịu quản lý của Bộ Giáo dục & Đào tạo.
- Giao thông – vận tải (transportation): gọi xe, logistics, hàng không, autonomous vehicles.
- Năng lượng (energy): điện, dầu khí, hạ tầng trọng yếu, nơi mọi thay đổi đều gắn với an toàn vận hành.
Khác biệt cốt lõi so với ngành không chịu quản lý
Nếu bạn quen làm product ở một startup SaaS thuần túy, hãy chuẩn bị tinh thần cho ba khác biệt lớn:
1. Approval gates — các cửa phê duyệt bắt buộc. Trong ngành không bị quản lý, bạn quyết định ship khi nào tùy ý. Trong ngành regulated, giữa "code xong" và "lên production" có thể có nhiều cửa: phê duyệt nội bộ của pháp chế (legal), phê duyệt của cơ quan quản lý (regulator), và kiểm toán (audit). Mỗi cửa có thể mất từ vài tuần đến vài năm. Bạn phải thiết kế roadmap quanh những cửa này, chứ không thể giả vờ chúng không tồn tại.
2. Traceability và documentation — truy vết và hồ sơ. Ở ngành thường, "code is the documentation". Ở ngành regulated, bạn phải chứng minh được tại sao mỗi quyết định được đưa ra, ai phê duyệt, dựa trên bằng chứng nào. Audit trail không phải gánh nặng hành chính — nó là điều kiện để sản phẩm được phép tồn tại. Một thay đổi nhỏ trong thuật toán tính lãi suất cũng cần được ghi nhận, kiểm thử và lưu trữ.
3. Tốc độ thay đổi bị ràng buộc. Tinh thần "move fast and break things" là chất độc trong ngành regulated. Bạn vẫn lặp nhanh (iterate) ở những phần không chạm quy định, nhưng những phần chạm quy định phải đi qua quy trình kiểm soát chặt.
Đừng nhầm: compliance không phải là kẻ thù của agile
Đây là hiểu lầm lớn nhất tôi muốn bạn tránh. Nhiều người nghĩ regulated nghĩa là phải quay về waterfall. Sai. Empirical process control — nền tảng của Scrum — thực ra rất hợp với môi trường này, vì nó buộc bạn minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation). Mẹo là phân tách rủi ro: chia sản phẩm thành phần "regulated core" (lõi chịu quản lý, cần kiểm soát chặt) và phần "non-regulated edge" (rìa không chịu quản lý, có thể lặp nhanh). Bạn áp tốc độ khác nhau cho hai phần — điều mà ta sẽ gọi là "two-speed product".
Compliance by design
Nguyên tắc vàng: đưa yêu cầu tuân thủ vào ngay từ giai đoạn khám phá (discovery), không phải vá vào cuối. Khi compliance là một loại "Definition of Done" được tích hợp ngay trong Product Backlog Item, bạn tránh được tình huống thảm họa: làm xong sản phẩm mới phát hiện nó vi phạm luật và phải đập đi làm lại.
Tình huống thực tế
Ví dụ 1: Ví điện tử Việt Nam và cửa phê duyệt NHNN
Một công ty fintech giả định, gọi là PayViet, có 4 triệu người dùng ví điện tử. Đội product muốn ra mắt tính năng "Mua trước trả sau" (Buy Now Pay Later). Về kỹ thuật, đội build xong trong 6 tuần. Nhưng Head of Product nhận ra rằng cấp tín dụng tiêu dùng vượt ngoài phạm vi giấy phép trung gian thanh toán hiện có — nó cần một pháp nhân hoặc đối tác có giấy phép cho vay phù hợp.
Thay vì hủy ý tưởng, Head of Product làm hai việc thông minh. Thứ nhất, bà phân tách sản phẩm: phần UX, luồng đặt hàng, giao diện được tiếp tục hoàn thiện song song (non-regulated edge). Phần "động cơ tín dụng" được tách ra và bắt tay với một công ty tài chính tiêu dùng đã có giấy phép, theo mô hình hợp tác. Thứ hai, bà đưa pháp chế và đại diện làm việc với NHNN vào ngay sprint review, để mỗi vòng lặp đều có "tín hiệu xanh hoặc đỏ" sớm.
Bài học: Trong ngành regulated, đối tác có giấy phép (licensed partner) thường là con đường nhanh hơn việc tự xin giấy phép. Và đừng để pháp chế đứng cuối hàng — kéo họ vào discovery.
Ví dụ 2: Phần mềm y tế và bài học về "minor change"
Một công ty healthtech Đông Nam Á, gọi là MedTrack, làm phần mềm hỗ trợ bác sĩ tính liều thuốc. Phần mềm này được phân loại là thiết bị y tế phần mềm (Software as a Medical Device). Một kỹ sư thấy công thức làm tròn liều lượng hơi "xấu", tự ý sửa để hiển thị đẹp hơn và ship trong một bản hotfix bình thường, không qua quy trình kiểm soát thay đổi.
Vấn đề: thay đổi đó làm sai số làm tròn ở một nhóm thuốc liều cao. Vì không có audit trail và không qua kiểm thử validation, khi sự cố bị phát hiện, công ty không chứng minh được quy trình kiểm soát chất lượng. Cơ quan quản lý y tế tạm đình chỉ sản phẩm trong 3 tháng để rà soát, gây thiệt hại lớn về doanh thu và niềm tin.
Bài học: Trong regulated, không có khái niệm "thay đổi nhỏ vô hại". Mỗi thay đổi chạm vào regulated core phải đi qua change control. Product leader phải thiết lập "ranh giới rõ ràng" để đội biết đâu là vùng được sửa tự do, đâu là vùng phải qua cửa.
Ví dụ 3: Grab và bài toán tuân thủ đa quốc gia
Grab hoạt động ở nhiều nước Đông Nam Á, mỗi nước một bộ quy định về gọi xe, thanh toán và bảo vệ dữ liệu khác nhau. Một tính năng hợp pháp ở Singapore có thể vi phạm quy định tại Indonesia hoặc Việt Nam. Nếu xây một sản phẩm "one size fits all", họ sẽ liên tục vướng luật ở đâu đó.
Cách product leadership xử lý là thiết kế kiến trúc "compliance-aware": tách phần lõi chung khỏi phần "policy layer" có thể cấu hình theo từng quốc gia. Mỗi thị trường có một "compliance owner" địa phương, người này có quyền chặn phát hành tính năng nếu vi phạm luật sở tại. Roadmap toàn cầu được điều phối nhưng việc rollout từng nước phụ thuộc vào tín hiệu phê duyệt địa phương.
Bài học: Khi vận hành đa quốc gia, đừng tập trung hóa hoàn toàn quyết định tuân thủ. Hãy phân quyền cho compliance owner địa phương và thiết kế sản phẩm có thể cấu hình theo vùng pháp lý.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng khi lãnh đạo sản phẩm trong ngành regulated:
Bước 1 — Lập bản đồ quy định (regulatory mapping). Trước khi viết dòng code nào, ngồi với pháp chế để trả lời: Sản phẩm này thuộc phạm vi điều chỉnh của cơ quan nào? Cần giấy phép gì? Có những approval gate nào và mỗi gate mất bao lâu? Vẽ ra thành một sơ đồ trực quan để cả đội thấy.
Bước 2 — Phân tách regulated core và non-regulated edge. Đánh dấu rõ phần nào của sản phẩm chạm quy định. Đây là bước quyết định bạn áp tốc độ "two-speed" như thế nào.
Bước 3 — Đưa compliance vào Definition of Done. Với các backlog item thuộc regulated core, bổ sung tiêu chí: đã có legal review, đã có test bằng chứng, đã ghi audit trail. Compliance trở thành một phần của "xong", không phải việc làm sau.
Bước 4 — Kéo compliance/legal vào nhịp Scrum. Mời pháp chế và (nếu có) chuyên gia quan hệ với cơ quan quản lý tham gia sprint review hoặc backlog refinement. Mục tiêu: nhận tín hiệu đỏ/xanh sớm, không để bất ngờ ở phút chót.
Bước 5 — Thiết lập change control cho regulated core. Định nghĩa quy trình rõ ràng: ai phê duyệt, kiểm thử gì, lưu hồ sơ ở đâu. Tự động hóa audit trail càng nhiều càng tốt để giảm gánh nặng thủ công.
Bước 6 — Lập kế hoạch roadmap quanh approval gates. Thời gian phê duyệt của cơ quan quản lý là biến số bạn không kiểm soát được. Hãy coi nó như dependency bên ngoài: bắt đầu sớm, có phương án dự phòng, và đừng cam kết ngày ra mắt cứng trước khi qua gate.
Bước 7 — Xây quan hệ với cơ quan quản lý. Đừng chỉ tương tác khi cần xin phép. Nhiều cơ quan quản lý có cơ chế "sandbox" (môi trường thử nghiệm có kiểm soát) — như sandbox fintech của NHNN. Chủ động đối thoại giúp bạn được lắng nghe và đôi khi định hình cả quy định.
Lỗi thường gặp & mẹo
Lỗi 1: Coi compliance là việc cần làm ở cuối. Đây là lỗi đắt giá nhất. Khi bạn phát hiện vi phạm sau khi đã build xong, chi phí làm lại gấp nhiều lần. Mẹo: compliance by design — đưa pháp chế vào từ discovery.
Lỗi 2: Dùng compliance làm cái cớ để chậm chạp toàn diện. Một số đội lấy lý do "ngành mình bị quản lý" để biện minh cho mọi sự ì ạch. Sai. Chỉ phần regulated core mới cần chậm và chắc; phần edge vẫn phải nhanh. Mẹo: minh bạch hóa ranh giới hai tốc độ để không ai lạm dụng.
Lỗi 3: Đối đầu với pháp chế. Nhiều PO xem legal là "phòng nói không". Khi quan hệ căng thẳng, pháp chế sẽ mặc định chặn để an toàn cho họ. Mẹo: biến pháp chế thành đồng minh, mời họ cùng tìm cách "làm được" thay vì chỉ liệt kê cái "không được".
Lỗi 4: Bỏ qua audit trail vì thấy phiền. Đến khi bị kiểm toán hoặc sự cố, không có hồ sơ là thảm họa. Mẹo: tự động hóa việc ghi nhận quyết định và phê duyệt ngay trong công cụ làm việc (Jira, Confluence) để không phụ thuộc trí nhớ.
Lỗi 5: Cam kết cứng ngày ra mắt phụ thuộc vào regulator. Bạn không kiểm soát được tốc độ của cơ quan quản lý. Mẹo: với stakeholder nội bộ và board, hãy truyền đạt timeline theo dạng "khoảng" và nêu rõ gate nào đang là rủi ro lớn nhất.
Mẹo nâng cao: Hãy xây một "compliance champion" trong chính đội product — không phải luật sư, mà là một PO/thành viên hiểu sâu quy định liên quan. Người này làm cầu nối, giúp đội tự nhận diện rủi ro sớm thay vì lúc nào cũng phải hỏi pháp chế.
Bài tập thực hành
Bài tập 1 — Regulatory mapping. Chọn một sản phẩm trong ngành regulated mà bạn biết (ví dụ: một ví điện tử, một app telehealth). Vẽ sơ đồ: sản phẩm chịu sự quản lý của cơ quan nào, cần giấy phép gì, có bao nhiêu approval gate từ ý tưởng đến ra mắt, mỗi gate ước tính mất bao lâu.
Bài tập 2 — Phân tách hai tốc độ. Lấy một tính năng cụ thể của sản phẩm đó. Liệt kê các phần thuộc regulated core và các phần thuộc non-regulated edge. Đề xuất nhịp phát hành khác nhau cho hai nhóm này và giải thích lý do.
Bài tập 3 — Viết Definition of Done có compliance. Soạn một Definition of Done cho backlog item thuộc regulated core, bao gồm các tiêu chí về legal review, kiểm thử bằng chứng và audit trail. So sánh với Definition of Done thông thường của một sản phẩm không bị quản lý.
Bài tập 4 — Xử lý tình huống. Pháp chế vừa báo rằng tính năng bạn định ra mắt tuần sau có thể vi phạm một quy định mới. Viết ra kế hoạch hành động 5 điểm của bạn với tư cách Head of Product: bạn nói gì với đội, với board, và làm gì với roadmap.
Tóm tắt
Lãnh đạo sản phẩm trong ngành chịu quản lý không có nghĩa là từ bỏ agile — mà là vận dụng tư duy empirical một cách kỷ luật hơn. Hãy ghi nhớ những điểm cốt lõi:
- Các ngành regulated phổ biến: tài chính, y tế, giáo dục, giao thông, năng lượng — nơi sai sót kéo theo hậu quả pháp lý nghiêm trọng.
- Ba khác biệt lớn so với ngành thường: approval gates (cửa phê duyệt từ regulator, legal, audit), traceability & documentation (truy vết và hồ sơ bắt buộc), và tốc độ thay đổi bị ràng buộc.
- Chiến lược "two-speed product": tách regulated core (chậm, chắc, có change control) khỏi non-regulated edge (nhanh, lặp liên tục).
- Compliance by design: đưa yêu cầu tuân thủ vào ngay discovery và Definition of Done, không vá vào cuối.
- Biến pháp chế và cơ quan quản lý thành đồng minh: kéo họ vào nhịp Scrum, tận dụng sandbox, và phân quyền cho compliance owner địa phương khi vận hành đa quốc gia.