Bài 2 — Tùy biến vs Chuẩn hóa: cuộc chiến định hình lợi nhuận

Vì sao đây là quyết định sống còn

Mỗi lần bạn tùy biến giải pháp cho một khách, bạn tạo ra một "nhánh" (fork) phải bảo trì mãi mãi. Mười khách tùy biến = mười phiên bản, mười bộ bug, chi phí vận hành phình to mà doanh thu không phình theo. Ngược lại, chuẩn hóa cứng nhắc lại làm mất deal vì "không đúng nghiệp vụ của em". AI Solutions PM giỏi là người tối đa hóa phần dùng chung, tối thiểu hóa phần làm riêng — nhưng làm riêng đúng chỗ.

Ba tầng của một giải pháp AI

Hãy tách sản phẩm thành 3 tầng để biết chỗ nào được đụng vào:

• Tầng lõi (core engine): kiến trúc model, pipeline xử lý, hạ tầng. Không tùy biến. Đây là tài sản dùng chung, tối ưu một lần dùng cho mọi khách.
• Tầng cấu hình (configuration): ngưỡng tin cậy, danh mục nhãn, từ điển thuật ngữ ngành, template output. Tùy biến bằng config, không bằng code. Đây là nơi 80% nhu cầu "làm riêng" thực ra có thể đáp ứng.
• Tầng tích hợp (integration): kết nối vào CRM/ERP của khách, định dạng dữ liệu vào/ra. Tùy biến có kiểm soát qua các adapter chuẩn.

Quy tắc vàng: Khi khách đòi tùy biến, hãy đẩy nhu cầu đó xuống tầng cấu hình. Nếu buộc phải chạm vào tầng lõi, đó là tín hiệu đỏ về chi phí.

Ví dụ cụ thể

Bạn có engine chatbot chăm sóc khách hàng. Ba khách yêu cầu:

• Khách A: "Chatbot phải gọi khách là 'Quý anh/chị'." → tầng config (template giọng văn). Dễ.
• Khách B: "Chatbot phải hiểu 200 mã sản phẩm nội bộ của em." → tầng config (từ điển thực thể). Vừa.
• Khách C: "Chatbot phải tự đàm phán giảm giá và chốt hợp đồng." → tầng lõi + rủi ro cao. Đây là lúc nói "không" hoặc tách thành dự án riêng có báo giá riêng.

Khung quyết định: 4 câu hỏi trước khi đồng ý tùy biến

• Có bao nhiêu khách khác cũng sẽ cần cái này? Nếu ≥3 → đưa vào roadmap sản phẩm chuẩn, không làm riêng.
• Có thể đáp ứng bằng config thay vì code không? Luôn ưu tiên config.
• Ai trả chi phí bảo trì dài hạn? Tùy biến sâu phải đi kèm phí duy trì, không chỉ phí làm.
• Tùy biến này có phá vỡ khả năng nâng cấp về sau không? Nếu fork tầng lõi, mọi bản vá tương lai sẽ đau.

Chiến lược "80/20 có kiểm soát"

• Xây một core chuẩn phủ 80% nhu cầu phổ biến.
• Mở một lớp cấu hình phong phú để khách tự "nhận" là được làm riêng.
• Với 20% còn lại: hoặc từ chối lịch sự, hoặc báo giá dự án tùy biến tách bạch, hoặc gom nhu cầu chung từ nhiều khách để nâng cấp core.

Sai lầm thường gặp

• Nói 'yes' với mọi tùy biến để chốt deal. Bạn thắng hợp đồng, thua sản phẩm.
• Tùy biến bằng code khi config làm được. Tạo nợ kỹ thuật vĩnh viễn.
• Không tính phí bảo trì cho phần làm riêng. Lợi nhuận bốc hơi sau 6 tháng.
• Fork tầng lõi cho một khách. Từ đó không bao giờ nâng cấp chung được nữa.
• Không gom nhu cầu. Ba khách xin cùng một thứ mà bạn làm riêng ba lần thay vì đưa vào roadmap.

Checklist khi khách xin tùy biến

• [ ] Đây là tầng nào — lõi, config hay tích hợp?
• [ ] Có khách khác cần không? (tín hiệu roadmap)
• [ ] Config đáp ứng được không?
• [ ] Đã tính phí bảo trì chưa?
• [ ] Có ảnh hưởng khả năng nâng cấp không?

Quyết định tùy biến đúng giúp bạn scale. Nhưng trước khi hứa bất cứ điều gì, bạn phải biết cái gì khả thi — chủ đề bài 3.