Làm Product Manager trong thời đại AI: Những bài học thực tế tôi học được

1. Mở đầu: Bối cảnh & lý do viết

Là một Product Manager với hơn một thập kỷ kinh nghiệm, tôi từng nghĩ rằng việc xây dựng sản phẩm xoay quanh nhu cầu người dùng, mô hình kinh doanh và khả năng kỹ thuật đã là đủ. Nhưng khi AI (đặc biệt là các mô hình ngôn ngữ lớn như GPT, Claude, DeepSeek, Grok) bắt đầu bùng nổ, tôi nhận ra mình đang bước vào một “cuộc chơi” hoàn toàn mới — nơi mà công nghệ không chỉ là công cụ hỗ trợ, mà còn là một yếu tố định hình chính sản phẩm.

Giai đoạn đầu khi làm việc trong team phát triển sản phẩm AI, tôi gặp không ít bỡ ngỡ: từ việc hiểu cách mô hình hoạt động, giới hạn mô hình, cách phối hợp với đội AI Engineer cho đến cách đưa AI vào sản phẩm mà vẫn giữ trải nghiệm người dùng đơn giản và rõ ràng.

Bài viết này là tập hợp những bài học thực tế mà tôi đã rút ra được trong quá trình làm việc — hy vọng sẽ giúp ích cho bất kỳ Product Manager nào đang hoặc sẽ bước vào thế giới sản phẩm AI.

2. Tư duy cần thay đổi của một Product Manager khi bước vào thời đại AI

Làm sản phẩm với AI không giống làm sản phẩm thuần túy trước đây.

Trong các dự án thông thường, ta bắt đầu từ user pain points, xác định giải pháp và sau đó hiện thực hóa bằng công nghệ phù hợp. Nhưng với sản phẩm AI, khả năng của mô hình lại đóng vai trò quan trọng ngay từ đầu. Một giải pháp "trông có vẻ tốt" về mặt business có thể lại không khả thi về mặt AI, hoặc ngược lại, một khả năng mới của mô hình (như RAG, multi-agent, few-shot learning...) có thể mở ra trải nghiệm người dùng hoàn toàn mới.

Khi tôi nói khả năng của mô hình đóng vai trò quan trọng ngay từ đầu, tôi không phủ nhận vai trò của user pain points. Hai điều này nên được bắt đầu từ sớm: Product Manager không chỉ build sản phẩm từ insight người dùng, mà còn từ khả năng của mô hình AI.

Product Manager cần thay đổi mindset: Tư duy "what's possible with AI" là kỹ năng quan trọng.

• Từ "Người dùng cần gì?" → thành "Người dùng cần gì" VÀ "AI có thể làm gì tốt và có thể giải quyết vấn đề nào?"
• Từ "Build & Ship feature theo kế hoạch" → thành "Tìm nơi giao thoa giữa khả năng của mô hình – trải nghiệm người dùng – giá trị kinh doanh"

3. Những bài học thực tế tôi học được

Dưới đây là những bài học quan trọng mà tôi rút ra trong quá trình làm sản phẩm AI. Một số đến từ sai lầm, một số đến từ việc thử – sai, và số khác đến từ việc quan sát cách người dùng tương tác với sản phẩm thực tế.

Bài học 1: AI không phải là magic — hãy hiểu rõ giới hạn của nó

Ở giai đoạn đầu, tôi kỳ vọng AI có thể làm đủ thứ: phân tích dữ liệu, gợi ý nội dung, hiểu người dùng… Nhưng khi đưa vào thực tế, tôi phải đối mặt với những giới hạn rõ ràng: hallucination, chi phí cao, output không ổn định, giới hạn context...

Chỉ khi chấp nhận AI là công cụ mạnh nhưng không hoàn hảo, tôi mới biết cách đặt kỳ vọng đúng và thiết kế trải nghiệm hợp lý.

Ví dụ thực tế: Trong một sản phẩm AI audit dành cho merchant Shopify, ban đầu tôi định cho agent phân tích toàn bộ GA4 + heatmap + review để đưa ra gợi ý cải thiện. Nhưng sau khi thử nghiệm, tôi nhận ra chi phí rất cao và kết quả không ổn định. Cuối cùng, tôi pivot sang việc phân tích các section trong store kèm hướng dẫn cụ thể — vừa hiệu quả vừa kiểm soát tốt.

Bài học 2: Prompt Engineering là kỹ năng mà PM cần có

Không cần viết code, nhưng bạn phải biết prompt — vì prompt là cách bạn “giao tiếp” với AI để kiểm thử tính khả thi. Dù không cần viết code, bạn vẫn nên biết viết prompt, test, và debug khi kết quả sai.

Khi team AI Engineer nói “mô hình này đủ mạnh để làm được điều đó”, tôi không dừng lại ở việc gật đầu. Tôi tự mình viết prompt, kiểm tra kết quả, tweak liên tục để đảm bảo rằng trải nghiệm sẽ ổn định.

Tôi thường hỏi:

• Đầu vào thực tế của người dùng sẽ trông thế nào?
• Mô hình phản hồi có consistent không?
• Có cách nào “khóa” output để ổn định sản phẩm?

Bài học 3: Làm việc với team AI khác với team frontend/backend

Frontend/backend thường rõ ràng: bạn viết spec, xác định logic, team build đúng theo yêu cầu. Nhưng với AI, bạn phải làm việc trong môi trường xác suất, nơi output thay đổi nhẹ theo từng lần gọi model.

Tôi phải điều chỉnh cách làm việc:

• Cần chấp nhận mức độ “không ổn định” của AI.
• Không thể viết spec chi tiết như trước.
• Phải chấp nhận “thử rồi sửa”.
• Cần set đúng expectation với stakeholder: "Đây là sản phẩm AI, không phải deterministic system".
• Và quan trọng nhất: cần kiểm tra với data thực tế thật nhiều.

Bài học 4: Người dùng không quan tâm AI — họ chỉ quan tâm kết quả

Một sai lầm lớn của tôi là từng nghĩ "có AI" (AI-Powerd hay là AI Agent) như là lợi điểm bán hàng (selling point). Nhưng qua nhiều lần thử nghiệm cũng như lăn lộn trong các community, tôi nhận ra: Người dùng không quan tâm bạn dùng AI hay không — họ chỉ cần biết sản phẩm có giúp họ tiết kiệm thời gian, tăng doanh số, giải quyết vấn đề nhanh hơn không.

Vì thế:

• Đừng nhấn mạnh quá nhiều vào “AI-powered” trong tâm trí.
• Tập trung vào giá trị đầu ra, giúp người dùng nhận được giá trị rõ ràng.

Bài học 5: Không có dữ liệu tốt, AI chỉ là trò chơi may rủi

AI không thể "ảo diệu" hơn chất lượng dữ liệu bạn đưa vào.

Tôi từng nghĩ rằng chỉ cần chọn mô hình mạnh, viết prompt tốt là đủ. Nhưng sau vài lần test thực tế, tôi nhận ra: Dữ liệu đầu vào và cấu trúc knowledge base mới là nền móng của output chất lượng.

Nếu bạn không kiểm soát đầu vào — đặc biệt là khi dùng RAG — thì output có thể sai hoặc vô dụng.

Ví dụ:

• Nếu bạn làm sản phẩm AI tư vấn cho merchant, mà knowledge base toàn content outdated hoặc quá chung chung → output sẽ mơ hồ.
• Khi dùng RAG, bạn phải quản lý nội dung đưa vào vector store một cách có kiểm soát, gắn tag, versioning rõ ràng.

Bài học là: PM phải quan tâm đến data pipeline. Bạn không cần build, nhưng cần hiểu sơ đồ dữ liệu và quy trình kiểm soát chất lượng.

Bài học 6: Trải nghiệm người dùng với AI cần thiết kế khác

PM truyền thống thường tập trung vào “user flow”, “tối ưu từng click”, “UI rõ ràng”.

UX cho AI không giống UX truyền thống. Bạn phải giúp người dùng hiểu rằng mô hình có thể sai, và luôn tạo cho họ cảm giác kiểm soát được tình huống.

Tôi học được rằng thiết kế tốt cho AI nên có thêm 3 lớp:

1. Thiết lập kỳ vọng đúng với người dùng:
   Người dùng dễ kỳ vọng AI là “biết tuốt”. Bạn cần giúp họ hiểu giới hạn mô hình ngay trong UI.
2. Cơ chế kiểm soát/khôi phục/sửa sai:
   Output của AI không phải lúc nào cũng đúng. Phải có cách cho người dùng "undo", feedback, chỉnh sửa.
3. Cảm giác tin cậy (trust UX):
   Ví dụ: highlight phần nào là do AI sinh ra, cung cấp nguồn tham khảo nếu dùng RAG, hoặc ghi rõ "beta" cho các tính năng chưa ổn định.

Build sản phẩm dùng AI làm nền tảng là làm trong môi trường không chắc chắn — UX phải giúp người dùng cảm thấy kiểm soát được và không bị bỏ rơi trong quá trình trải nghiệm sản phẩm.

AI giỏi, nhưng nếu UX kém, người dùng sẽ mất niềm tin ngay từ lần đầu.

Bài học 7: AI chỉ là một phần — đừng quên sản phẩm là tổng thể

Có một giai đoạn tôi bị cuốn vào phần AI quá nhiều: model, test prompt, tối ưu chi phí... nhưng quên mất một điều:

Người dùng không chỉ dùng AI — họ dùng cả hệ sinh thái sản phẩm.

Đó là khi tôi quên mất những yếu tố "cũ mà sống": onboarding rõ ràng, UX dễ hiểu, pricing minh bạch.

Một sản phẩm AI tốt không thể sống sót nếu:

• Onboarding chưa hiệu quả
• Người dùng không hiểu cách dùng
• UI không thực sự trực quan, tạo sự tin tưởng
• Pricing model không rõ ràng, gây tâm lý bất ổn trong việc xuống tiền
• Output chất lượng thấp, không ổn định

→ Cuối cùng vẫn khiến người dùng rời đi (vì họ không nhận được outcome tương xứng)

Bài học là: PM AI cần giữ góc nhìn toàn cảnh. AI là một module cốt lõi trong sản phẩm, nhưng vẫn chỉ là một phần trong trải nghiệm tổng thể của người dùng.

4. Những điều tôi ước mình biết sớm hơn

• AI có thực sự quá khó để PM học không? Không. Nhưng cũng không hề dễ.
• Việc đọc tài liệu mô hình, chạy thử trên Playground, viết prompt — giúp tôi hiểu sâu hơn rất nhiều so với chỉ nghe AI Engineer trình bày.
• Quan trọng hơn, tôi nhận ra: AI PM có thể không cần code, nhưng cần tò mò, thực hành nhiều và không ngại va chạm với kỹ thuật.

Đó là mức hiểu “đủ để sử dụng một cách có trách nhiệm” — không nông cạn, nhưng cũng không quá học thuật lẫn quá kỹ thuật. Phải hiểu cả technical feasibility lẫn AI constraints.

5. Kết bài

AI đang thay đổi cách chúng ta xây dựng sản phẩm, nhưng vai trò của Product Manager vẫn giữ nguyên cốt lõi: hiểu người dùng, kết nối các mảnh ghép, và mang lại giá trị thực sự.

Tuy nhiên, để làm tốt vai trò này trong thời đại AI, chúng ta cần bổ sung thêm những kỹ năng mới, đặc biệt là tư duy về khả năng mô hình và cách xây dựng sản phẩm xung quanh đó.

Đây không chỉ là “domain knowledge” mới, mà là cách tiếp cận khác với toàn bộ vòng đời sản phẩm.

Xuất phát từ việc định hướng sản phẩm nơi AI là cốt lõi, không chỉ là feature phụ. Từ đó nảy sinh các biến thể job title. Một số công ty (đặc biệt là Big Tech hoặc AI-first startup) tạo ra các job title như:

• AI Product Manager
• AI Agent Owners (tương tự Product Owners)
• Applied AI PM
• Technical PM (AI/ML)
• Machine Learning Product Manager

Ở các startup/scale-up khác, có thể họ vẫn giữ nguyên là Product Manager, nhưng JD ngầm yêu cầu thêm các bộ kỹ năng mới. Vì vậy, tiêu đề không nói lên hết được trách nhiệm, và PM buộc phải tự “nâng cấp” công việc của mình.

Với tôi, “AI Product Manager” là một cách đặt tên. Nhưng điều quan trọng hơn là bạn có đang tiếp cận vấn đề theo mindset của một AI-native PM hay không.

Nếu bạn đang làm PM và cảm thấy AI “khó tiếp cận”, tôi hiểu cảm giác đó. Nhưng hãy bắt đầu từ bước nhỏ: chơi với prompt, đọc vài case study, thử nghiệm một tính năng nhỏ với AI — và bạn sẽ thấy mình tiến bộ rất nhanh.

Bạn đang là PM và muốn chuyển hướng sang AI? Hoặc đang phát triển sản phẩm AI đầu tiên của mình?
Hãy kết nối với tôi, tôi luôn sẵn sàng chia sẻ thêm kinh nghiệm.