Bài 1 — AI Solutions PM là ai? Bức tranh nghề nghiệp và khác biệt cốt lõi

AI Solutions PM khác gì PM thường?

Một Product PM sở hữu một sản phẩm dùng chung cho hàng nghìn khách hàng: một tính năng ship ra là mọi người dùng được. Còn AI Solutions PM làm việc trong bối cảnh B2B giải pháp — bạn thường mang một nền tảng AI (ví dụ engine trích xuất hóa đơn, chatbot tổng đài, mô hình dự báo tồn kho) đến từng khách hàng doanh nghiệp và phải làm nó chạy được với dữ liệu, quy trình và kỳ vọng riêng của họ.

Điều này tạo ra ba khác biệt lớn:

• Đầu ra mang tính xác suất, không phải logic cứng. Một nút bấm luôn làm đúng một việc. Một model thì "đúng khoảng 92%". Bạn phải quản lý sản phẩm mà bản thân nó không đảm bảo 100% chính xác — và khách hàng thường không quen với điều đó.
• Dữ liệu là nguyên liệu, không phải chỉ là log. Chất lượng giải pháp phụ thuộc vào dữ liệu của khách hàng nhiều hơn phụ thuộc vào code của bạn. Dữ liệu bẩn có thể giết chết một dự án tốt.
• Mỗi khách hàng kéo bạn về phía tùy biến. Sales hứa, khách đòi "làm riêng cho em", và bạn liên tục phải quyết định: chuẩn hóa để scale hay tùy biến để chốt deal?

Bốn vai trò bạn phải cân bằng

• Người dịch (translator): chuyển nhu cầu nghiệp vụ thành yêu cầu ML, và chuyển giới hạn kỹ thuật thành ngôn ngữ business.
• Người gác cổng khả thi (feasibility gatekeeper): biết nói "cái này AI làm được, cái kia thì chưa".
• Người quản trị kỳ vọng: đặt mục tiêu độ chính xác, phạm vi, và định nghĩa "thành công" trước khi ký.
• Người quản trị rủi ro: bảo mật dữ liệu, ai sở hữu model, điều gì xảy ra khi model sai.

Ví dụ cụ thể

Một ngân hàng muốn "AI đọc hợp đồng tự động". Nghe thì gọn. Nhưng AI Solutions PM giỏi sẽ hỏi ngay:

• Đọc để làm gì — trích xuất field, phân loại, hay tóm tắt? (3 bài toán ML khác nhau)
• Hợp đồng ở định dạng nào — PDF gốc chữ, hay ảnh scan mờ? (quyết định có cần OCR không)
• Sai một field thì hậu quả gì — cảnh báo hay từ chối khoản vay? (quyết định ngưỡng chấp nhận)
• Ai review kết quả — có human-in-the-loop không?

Bốn câu hỏi này biến một lời hứa mơ hồ thành một phạm vi có thể ước lượng.

Khung tư duy: "Value–Feasibility–Data–Risk" (VFDR)

Với mọi yêu cầu AI, chấm nhanh 4 trục:

• Value: giải quyết nỗi đau thật hay chỉ là "cho oai"? Đo được bằng tiền/thời gian không?
• Feasibility: công nghệ hiện tại làm được đến đâu?
• Data: khách có dữ liệu đủ lượng, đủ chất, đủ quyền dùng không?
• Risk: sai thì ai chịu, bảo mật thế nào?

Dự án lý tưởng: Value cao, Feasibility rõ, Data sẵn, Risk kiểm soát được. Nếu một trục đỏ, hãy dừng lại thương lượng phạm vi.

Checklist khởi động một dự án AI Solutions

• [ ] Xác định rõ bài toán ML (phân loại / trích xuất / dự báo / sinh nội dung)?
• [ ] Định nghĩa "thành công" bằng con số đo được?
• [ ] Biết dữ liệu đến từ đâu và ai sở hữu?
• [ ] Biết hậu quả khi model sai?
• [ ] Có người nghiệp vụ (SME) đồng hành để đánh giá đúng/sai?

Sai lầm thường gặp

• Nhận mọi yêu cầu là khả thi vì "AI mà, cái gì chả làm được". Sự thật: nhiều bài toán chưa đủ dữ liệu hoặc quá mơ hồ.
• Bỏ qua bước định nghĩa thành công, để rồi cuối dự án khách và bạn cãi nhau xem thế nào là "đủ tốt".
• Coi mình là kỹ sư ML. Vai trò của bạn là kết nối value–feasibility–data–risk, không phải tự train model.

Bài sau chúng ta đi vào bài toán kinh điển và khó nhất của nghề: tùy biến vs chuẩn hóa.