Blog

  • Product discovery trong ngân hàng: cách validate ý tưởng khi ‘sai là sự cố’

    Product discovery trong ngân hàng: cách validate ý tưởng khi ‘sai là sự cố’

    Ở startup, product discovery nghĩa là: làm nhanh một bản thử, thả ra cho vài trăm người dùng, sai thì sửa. Ở ngân hàng, “thả ra thử” một tính năng chuyển tiền bị lỗi có thể thành sự cố toàn hệ thống lên báo. Cùng một từ discovery, nhưng luật chơi khác hẳn.

    Vậy làm product ở ngân hàng thì validate ý tưởng bằng cách nào? Câu trả lời của tôi sau nhiều năm: discovery trong ngân hàng không ít đi, mà phải khéo hơn.

    Thứ nhất, prototype không chạm vào tiền thật. Figma click-through, demo với dữ liệu giả, thử nhanh với đồng nghiệp ở quầy giao dịch — tất cả đều cho insight mà không cần động vào hệ thống production. Nhiều team bỏ qua bước này vì “mất thời gian”, rồi trả giá gấp nhiều lần ở giai đoạn kiểm thử.

    Thứ hai, mượn “sandbox” của thực tế. Thay vì release cho tất cả, chọn một chi nhánh làm pilot, một nhóm khách hàng nội bộ làm beta. Quy mô nhỏ thì sai số cũng nhỏ, mà bài học thì vẫn đầy đủ. Cơ quan quản lý cũng dễ chấp nhận hơn khi phạm vi thử nghiệm được kiểm soát.

    Thứ ba, và quan trọng nhất: đưa risk và compliance vào bàn từ ngày đầu, đừng để họ xuất hiện ở phút cuối như “cửa tử”. Tôi học được rằng một buổi trao đổi sớm với đội pháp chế tiết kiệm cho cả team cả tháng làm lại. Họ không phải kẻ thù của innovation — họ là người giúp ý tưởng của bạn sống sót qua thực tế.

    Discovery trong ngân hàng chậm hơn, nhưng không có nghĩa là không làm. Nó chỉ đòi hỏi PO phải thành thạo một kỹ năng đặc biệt: dám thử, nhưng thử một cách có trách nhiệm.

    Bạn đã từng phải “giết” một ý tưởng hay ở vòng compliance chưa?

  • Onboarding nhân viên mới: 90 ngày đầu quyết định gắn bó hay rời bỏ

    Onboarding nhân viên mới: 90 ngày đầu quyết định gắn bó hay rời bỏ

    Có một thực tế mà dân HR nào cũng biết nhưng ít công ty làm nghiêm túc: phần lớn quyết định “ở lại hay đi” của nhân viên mới được hình thành trong 90 ngày đầu. Vấn đề là 90 ngày đó thường bị bỏ mặc cho may rủi.

    Tôi thấy kịch bản này lặp lại ở nhiều nơi: ngày đầu đi làm, nhân viên mới ngồi chờ cả buổi vì tài khoản hệ thống chưa có, máy tính chưa cài xong, người hướng dẫn thì bận họp. Tuần đầu tiên trôi qua trong những email giới thiệu chung chung. Đến tháng thứ hai, họ vẫn chưa hiểu rõ mình phải làm gì để được đánh giá là “làm tốt”. Rồi một ngày họ nhận offer khác — và chẳng có lý do gì để ở lại.

    Onboarding tốt không phải là buổi orientation hoành tráng. Nó là một chuỗi những việc nhỏ được làm đúng hạn: trước ngày đầu tiên, mọi tài khoản và thiết bị đã sẵn sàng; tuần đầu có người đồng hành cụ thể, không phải kiểu “có gì cứ hỏi anh”; 30 ngày đầu có mục tiêu rõ ràng để nhân viên mới cảm thấy mình đang tiến bộ chứ không phải đang bơi.

    Trong ngân hàng với hàng nghìn nhân viên, chuyện này không thể làm thủ công. Đó là lý do module onboarding trong hệ thống HCM tồn tại: tự động kích hoạt chuỗi công việc khi có nhân sự mới — IT cấp tài khoản, hành chính chuẩn bị chỗ ngồi, quản lý trực tiếp nhận checklist đào tạo. Công nghệ không thay thế sự chào đón của con người, nhưng nó đảm bảo không ai bị bỏ quên chỉ vì ai đó… quên.

    Điều trớ trêu là nhiều công ty đầu tư rất nhiều tiền để tuyển được người giỏi, rồi để họ ra đi vì 90 ngày đầu quá tệ. Tuyển dụng chỉ là một nửa cuộc chơi. Nửa còn lại bắt đầu từ ngày đầu tiên đi làm.

    Còn ở công ty bạn, ngày đầu đi làm của nhân viên mới diễn ra như thế nào?

  • Người làm product có cần biết code không?

    Người làm product có cần biết code không?

    Người ta hỏi tôi câu này trong hầu hết các buổi phỏng vấn PO: “Anh có biết code không?” Và thành thật mà nói, mười năm trước tôi cũng từng nghĩ câu trả lời phải là “có”.

    Nhưng sau hơn mười năm làm product, quan điểm của tôi đã thay đổi. Biết code giúp bạn rất nhiều — đọc được pull request, hiểu vì sao một tính năng “nhỏ” lại tốn hai tuần, không bị ngợp trước thuật ngữ kỹ thuật. Nhưng biết code không phải điều kiện để làm PO giỏi. Điều kiện là hiểu đủ để đặt câu hỏi đúng.

    Tôi từng làm việc với những PO code rất giỏi nhưng viết requirement mơ hồ, và cũng từng gặp PO không biết một dòng code nào nhưng spec của họ rõ đến mức dev chỉ việc làm theo. Sự khác biệt không nằm ở khả năng code, mà ở khả năng tư duy hệ thống: chia nhỏ vấn đề, lường trước edge case, hiểu trade-off giữa tốc độ và chất lượng.

    Trong ngân hàng, câu chuyện còn rõ hơn. Hệ thống core banking mấy chục năm tuổi, mỗi lần chạm vào là một ma trận phụ thuộc. PO ở đây không cần code được, mà cần hiểu kiến trúc đủ để không hứa những thứ không làm được, và đủ để dev tin rằng mình hiểu họ đang đối mặt với điều gì.

    Vậy có nên học code không? Nên — nhưng học để hiểu, không phải để làm. Một khóa cơ bản về cách web hoạt động, API là gì, database lưu trữ ra sao là đủ cho phần lớn công việc PO. Thời gian còn lại, đầu tư vào những kỹ năng khó thay thế hơn: đặt câu hỏi, viết rõ ràng, và ra quyết định khi thông tin chưa đầy đủ.

    Code là công cụ của dev. Còn công cụ của PO là sự rõ ràng.

    Bạn nghĩ sao: PO biết code có lợi thế thật, hay đó chỉ là “nice to have” được thổi phồng?

  • Skills-based hiring: khẩu hiệu hay, triển khai thực tế không dễ

    Skills-based hiring: khẩu hiệu hay, triển khai thực tế không dễ

    “Tuyến theo kỹ năng, đừng tuyển theo bằng cấp” — nghe rất tiến bộ, rất công bằng. Tôi đồng ý với tinh thần của nó. Nhưng sau khi chứng kiến không ít doanh nghiệp hô khẩu hiệu này rồi làm theo cách cũ, tôi nghĩ đã đến lúc nói thẳng về những cái khó.

    Khó đầu tiên: định nghĩa “kỹ năng” thế nào cho dùng được. Với một vị trí Solution Architect, “giỏi về microservices” nghĩa là gì? Thiết kế được hệ thống chịu tải cao, hay chỉ từng đọc tài liệu về nó? Nếu không có khung năng lực rõ ràng với các mức độ cụ thể, skills-based hiring chỉ là cách gọi mới của cảm tính cũ.

    Khó thứ hai: ai là người đánh giá kỹ năng đó. HR không đủ chuyên môn sâu để chấm kỹ thuật, còn hiring manager thì mỗi người một chuẩn. Tôi từng tham gia chấm điểm hàng chục hồ sơ kiến trúc sư, và ngay cả với rubric chi tiết, hai người chấm vẫn có thể cho điểm khác nhau. Không có quy trình đánh giá nhất quán, “tuyển theo kỹ năng” rất dễ biến thành “tuyển theo cảm nhận của sếp”.

    Khó thứ ba, và khó nhất: thói quen. Manager đã quen đọc CV theo trường lớp, theo tên công ty cũ. Bảo họ bỏ qua bằng cấp để nhìn vào năng lực thực chứng là thay đổi văn hóa, không phải thay đổi quy trình. Mà thay đổi văn hóa thì không xong trong một quý.

    Tôi không phản đối skills-based hiring. Ngược lại, tôi tin đó là hướng đi đúng, nhất là khi công nghệ như sourcing agent hay ATS thông minh đang giúp việc đánh giá kỹ năng trở nên có cơ sở hơn. Chỉ là chúng ta nên bớt hô hào và bắt tay vào giải từng cái khó một.

    Còn ở công ty bạn, tuyển dụng đang chạy theo kỹ năng thật, hay mới chỉ đổi tên mẫu đánh giá cũ?

  • Digital banking Việt Nam 2026: hết thời “làm app cho có”

    Digital banking Việt Nam 2026: hết thời “làm app cho có”

    Mở kho ứng dụng lên, bạn sẽ thấy app ngân hàng nào cũng hao hao nhau: chuyển tiền miễn phí, quét QR, thanh toán hóa đơn, thêm cái widget xem số dư. Từng làm digital banking hơn mười năm, tôi nhận ra điểm nghẽn của thị trường không còn là “có app hay không” nữa.

    Vài năm trước, có app riêng với giao diện mượt đã đủ để một ngân hàng lên truyền thông khoe chuyển đổi số. Bây giờ ai cũng có. Cuộc đua dịch chuyển sang một câu hỏi khó hơn nhiều: người dùng có quay lại app mỗi ngày không, và khi quay lại thì họ làm gì ngoài việc… chuyển khoản.

    Trải nghiệm thực tế cho thấy khách hàng Việt Nam chọn ngân hàng bằng tiện ích đi kèm. Ai cho họ quản lý khoản vay online, mở thẻ tín dụng mà không phải ra quầy, nhận được gợi ý chi tiêu đúng lúc, người đó thắng. Những thứ này không làm được bằng một đợt redesign giao diện. Nó đòi hỏi dữ liệu sạch, quy trình tín dụng số thật sự, và sự phối hợp giữa product với risk, với ops — những phần “khô” nhất của một ngân hàng.

    Điều đáng mừng là thị trường đang đi đúng hướng. Một số ngân hàng đã bắt đầu đầu tư vào cá nhân hóa bằng dữ liệu hành vi, vào onboarding số hoàn toàn cho khách hàng doanh nghiệp nhỏ. Còn một số khác vẫn loay hoay với KPI lượt tải app, như thể năm 2018.

    Nếu là người làm product ở ngân hàng hôm nay, bài toán của bạn không còn là xây thêm tính năng. Mà là làm sao để từng tính năng có lý do tồn tại trong đời sống tài chính của khách hàng mỗi ngày.

    Ngân hàng của bạn có đang giữ được khách, hay chỉ đang giữ một chỗ trên màn hình điện thoại của họ?

  • Vì sao dự án CRM nào cũng “sắp xong” mãi không xong

    Vì sao dự án CRM nào cũng “sắp xong” mãi không xong

    Dự án CRM của chúng tôi đã ở trạng thái “sắp xong” được tám tháng. Báo cáo tiến độ tuần nào cũng viết 90%, tháng nào cũng hứa go-live quý sau. Ngồi trong dự án đủ lâu, tôi nhận ra có những nguyên nhân cứ lặp lại ở mọi dự án CRM.

    Nguyên nhân đầu tiên là yêu cầu thay đổi không bao giờ dừng. Hôm nay phòng bán lẻ muốn thêm trường dữ liệu, mai phòng SME đòi báo cáo kiểu khác, mốt lãnh đạo xem demo của đối thủ rồi muốn “làm giống vậy”. Phạm vi dự án phình ra từng tuần trong khi deadline đứng yên, và chẳng ai dám nói “không” với stakeholder.

    Nguyên nhân thứ hai là dữ liệu khách hàng phân mảnh. Cùng một khách hàng nhưng mỗi hệ thống lưu một bản: core banking một kiểu, thẻ một kiểu, e-banking một kiểu nữa. Trùng lặp, sai số, thiếu trường — việc gộp chúng thành một hồ sơ thống nhất ngốn nhiều thời gian hơn cả việc cấu hình CRM.

    Nguyên nhân thứ ba ít ai dám nói thẳng: các phòng ban không chịu nhập liệu. CRM chỉ tốt bằng dữ liệu người ta nhập vào, mà với nhiều nhân viên kinh doanh, nhập liệu là việc “làm cho có” sau khi đã chốt deal. Hệ thống đẹp mà dữ liệu rỗng thì cũng chỉ là cái vỏ.

    Cuối cùng là tích hợp hệ thống cũ. Core banking mấy chục năm tuổi không được thiết kế để nói chuyện với ai, mỗi API là một trận đàm phán với đội vận hành hệ thống cũ.

    Có lẽ câu hỏi đúng không phải “khi nào xong”, mà là “thế nào được gọi là xong”.

  • Product Owner trong ngân hàng khác gì PO ở startup?

    Product Owner trong ngân hàng khác gì PO ở startup?

    Cùng chức danh Product Owner, nhưng một người ở ngân hàng và một người ở startup gần như đang làm hai nghề khác nhau. Tôi đã trải qua cả hai môi trường nên hiểu rất rõ cảm giác “đổi vai” ấy.

    Ở ngân hàng, từ đầu tiên bạn học là compliance. Mỗi tính năng chạm đến tiền của khách hàng đều phải đi qua risk, pháp chế, kiểm toán — một quy trình phê duyệt có thể kéo dài hàng tuần cho thứ mà ở startup chỉ cần một buổi chiều. Stakeholder đông đến mức một buổi họp backlog có thể có mười người, mỗi người một ưu tiên, và ai cũng có lý. Tốc độ chậm, nhưng khi sản phẩm ra mắt, nó chạm đến hàng triệu người dùng trong một đêm. Áp lực không nằm ở tốc độ mà nằm ở độ chính xác: sai một ly là sự cố toàn hệ thống.

    Ở startup, mọi thứ đảo ngược. Bạn được tự quyết gần như tuyệt đối, sáng nghĩ chiều làm, tuần sau đã có số liệu để học. Nhưng resource mỏng đến mức một người làm việc của ba người, và “tự do” đồng nghĩa với “tự chịu” khi quyết định sai. Không có đội pháp chế đứng sau, không có quy trình đỡ lưng — bạn vừa là PO, vừa là QA, đôi khi kiêm luôn chăm sóc khách hàng.

    Không môi trường nào hơn môi trường nào. Ngân hàng rèn cho bạn sự kiên nhẫn, kỹ năng điều phối stakeholder phức tạp và tư duy quản trị rủi ro — những thứ chỉ học được khi sai lầm có giá đắt. Startup rèn tốc độ, khả năng tự xoay xở và sự dũng cảm ra quyết định trong mơ hồ — những thứ chỉ học được khi không ai chỉ tay cho bạn.

    Bạn muốn rèn kỹ năng nào trước: xây thật đúng trong khuôn khổ, hay xây thật nhanh trong hỗn loạn?

  • AI phỏng vấn ứng viên thay HR — nên mừng hay nên lo?

    AI phỏng vấn ứng viên thay HR — nên mừng hay nên lo?

    Năm nay, có ứng viên trải qua ba vòng phỏng vấn mà chưa một lần nói chuyện với con người. AI đọc CV, AI đặt câu hỏi, AI chấm điểm câu trả lời. Nghe thì hiện đại, nhưng tôi vừa mừng vừa lo.

    Mừng vì tốc độ. Một vị trí tuyển dụng nhận hàng nghìn hồ sơ, HR không thể đọc hết trong thời gian hợp lý. AI sàng lọc trong vài giờ những gì con người mất vài tuần, đánh giá nhất quán, không mệt, không bỏ sót vì cảm tính buổi sáng. Với các vị trí mass hiring, đây là cứu cánh thực sự.

    Lo vì những thứ AI không nhìn thấy. Một hệ thống học từ dữ liệu tuyển dụng cũ sẽ lặp lại thiên kiến của quá khứ — ưu tiên những hồ sơ “giống người đã được nhận”, vô tình loại bỏ sự đa dạng. Văn hóa làm việc, động lực nội tại, cách một người xử lý tình huống khó — những thứ quyết định thành công lâu dài lại là thứ AI đánh giá kém nhất.

    Và có một nghịch lý đang hình thành: ứng viên dùng AI viết CV, dùng AI trả lời phỏng vấn AI. Khi cả hai bên đều là máy, chúng ta còn đang đánh giá năng lực thật hay chỉ đang so xem bên nào prompt giỏi hơn? Vòng lặp này khiến quy trình tuyển dụng ngày càng xa rời con người mà nó phục vụ.

    Quan điểm của tôi sau nhiều năm làm product lẫn tham gia tuyển dụng: AI làm rất tốt việc loại bỏ — loại hồ sơ không phù hợp, loại câu hỏi lặp lại, loại công việc hành chính. Nhưng việc lựa chọn — quyết định ai sẽ đồng hành cùng team trong nhiều năm — vẫn cần con người. Công nghệ nên dọn đường cho cuộc trò chuyện có ý nghĩa, chứ không thay thế nó.

    Khi cả hai bên đều dùng AI, chúng ta còn đang tuyển người hay đang tuyển prompt?

  • Agentic AI trong HCM: demo đẹp, thực tế phũ

    82% CEO và hội đồng quản trị tin rằng AI sẽ buộc họ cắt giảm tới 20% nhân sự trong 3 năm tới.

    Con số của Korn Ferry này đang viral khắp LinkedIn tuần rồi. Mình làm product, đang triển khai Oracle HCM Fusion trong ngân hàng, đọc xong chỉ thấy một chữ: vội.

    Vì thực tế mình thấy mỗi ngày nó phũ hơn demo nhiều. Trên sân khấu: AI tự sàng lọc CV, tự đặt lịch phỏng vấn, tự dự đoán ai sắp nghỉ việc. Ngoài đời: mã chức danh mỗi đơn vị đặt một kiểu, lịch sử đánh giá hiệu suất chỗ có chỗ không, dữ liệu nhân sự còn đang dọn dẹp. Đặt con AI “tự ra quyết định” lên đống data đó, nó không thông minh hơn đâu. Nó chỉ sai nhanh hơn, và sai một cách rất tự tin.

    Nên với mình, câu chuyện AI + HCM năm 2026 không nằm ở con agent xịn nhất. Nó nằm ở ba việc chán ngắt: dọn data, chuẩn hóa quy trình, và vạch rõ chỗ nào AI được tự động, chỗ nào con người bắt buộc phải chốt. Tuyển ai, cho ai nghỉ, tăng lương ai — mấy quyết định đó mà giao hẳn cho máy thì không gọi là chuyển đổi số được.

    AI không thay thế HR. Nhưng HR nào không hiểu dữ liệu của chính mình thì sẽ bị thay thế bởi người hiểu.

    Chỗ các bạn thì sao, AI trong HR đang ở giai đoạn demo đẹp hay đã chạy thật rồi?