Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Prompt Engineering cho PM tasks

Đã đọc 0/14 mục · còn khoảng 12 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Mở đầu — vì sao bài này quan trọng

Hãy thử hình dung hai Product Manager cùng dùng một công cụ AI giống hệt nhau — cùng ChatGPT, cùng gói trả phí, cùng truy cập một lúc. Người thứ nhất gõ vào: "Viết user story cho tính năng giỏ hàng." Kết quả nhận về là một đoạn văn chung chung, đúng nhưng vô hồn, kiểu mẫu giáo trình, không dùng được ngay. Người thứ hai mất thêm 90 giây để soạn yêu cầu kỹ hơn, và nhận về một bộ user story có đầy đủ acceptance criteria, sát với sản phẩm thật của họ, đúng tông giọng team đang dùng. Cùng một cỗ máy, nhưng khoảng cách kết quả là một trời một vực.

Khác biệt đó không nằm ở công cụ. Nó nằm ở prompt — cách bạn ra lệnh cho AI. Và đây chính là kỹ năng quyết định liệu AI có trở thành một trợ lý thực thụ trong công việc PM của bạn, hay chỉ là một món đồ chơi tạo ra văn bản đẹp mà bạn vẫn phải viết lại từ đầu.

Với PM, prompt engineering không phải là chuyện "phù phép câu chữ" hay học thuộc những mẹo bí truyền. Nó là một kỹ năng giao tiếp có cấu trúc — gần giống cách bạn brief cho một designer mới vào, hay viết một ticket rõ ràng cho engineer. Bạn càng cung cấp đúng bối cảnh và yêu cầu rõ ràng, output càng chính xác. Bài học này tập trung vào bộ khung cốt lõi nhất mà mọi PM nên nằm lòng trước khi nói đến bất cứ kỹ thuật nâng cao nào: cấu trúc Role – Context – Task. Đây là nền móng. Một khi bạn làm chủ ba thành phần này, mọi prompt phức tạp về sau đều chỉ là phần mở rộng.

Khái niệm cốt lõi

Một prompt hiệu quả cho công việc PM gần như luôn xoay quanh ba thành phần. Bạn có thể coi đây như một công thức để nhớ: Ai đang nói chuyện với ai, về cái gì, để làm gì.

1. Role — AI đóng vai gì, và bạn là ai?

Phần đầu tiên là gán vai trò cho AI. Khi bạn nói "Bạn là một Senior Product Manager 10 năm kinh nghiệm trong lĩnh vực fintech tại Đông Nam Á", bạn đang điều chỉnh cách model "căn chỉnh" câu trả lời — nó sẽ chọn từ ngữ, mức độ chuyên môn, và góc nhìn phù hợp với vai đó.

Vì sao điều này quan trọng? Vì AI được huấn luyện trên cả internet — từ bài blog nghiệp dư đến tài liệu chuyên sâu. Khi không có chỉ dẫn, nó trả lời ở mức "trung bình của tất cả". Gán vai trò giống như bạn kéo nó lên đúng kệ sách bạn cần. So sánh nhanh:

  • Không có Role: "Giải thích về churn rate." → Bạn nhận về định nghĩa kiểu Wikipedia.
  • Có Role: "Bạn là Growth PM cho một app gọi xe. Giải thích churn rate theo cách bạn sẽ trình bày cho CEO." → Bạn nhận về góc nhìn vận hành, có liên hệ doanh thu.
Một mẹo ít người để ý: Role cũng nên nói rõ bạn là ai. "Tôi là PM mới, chưa có nền tảng kỹ thuật" sẽ cho ra câu trả lời khác hẳn với "Tôi là PM kỳ cựu, hãy đi thẳng vào phần phức tạp."

2. Context — bối cảnh: sản phẩm, người dùng, tình huống

Đây là phần PM thường bỏ qua nhất, và cũng là phần tạo ra khác biệt lớn nhất. Context là tất cả thông tin nền mà AI cần để câu trả lời "vừa khít" với thực tế của bạn — chứ không phải một sản phẩm tưởng tượng.

Context tốt thường gồm:

  • Sản phẩm: Đang làm gì, mô hình kinh doanh ra sao (B2B/B2C, freemium, marketplace...).
  • Người dùng: Ai dùng, hành vi, nỗi đau, bối cảnh văn hóa.
  • Tình huống hiện tại: Đang ở giai đoạn nào, ràng buộc gì (deadline, ngân sách, nguồn lực kỹ thuật), số liệu liên quan.
  • Ràng buộc đầu ra: Độ dài, tông giọng, định dạng, ngôn ngữ.
Càng cụ thể, càng tốt. "App của tôi có nhiều người dùng" gần như vô dụng. "App giao đồ ăn của tôi có 200.000 MAU tại TP.HCM và Hà Nội, trong đó 70% đặt đơn vào giờ trưa, retention tháng thứ hai chỉ 18%" mới là context có giá trị.

3. Task — yêu cầu cụ thể, đo lường được

Task là phần bạn nói rõ bạn muốn AI làm gì. Lỗi phổ biến là task quá mơ hồ: "giúp tôi với feature này." Giúp như thế nào? Viết PRD? Liệt kê rủi ro? Đề xuất metric? AI không đọc được suy nghĩ của bạn.

Một task tốt có động từ rõ ràng và phạm vi rõ ràng: "Liệt kê 5 rủi ro lớn nhất khi triển khai", "Viết 3 phương án A/B test với hypothesis cho mỗi cái", "Soạn 8 user story theo định dạng As a / I want / So that, kèm acceptance criteria." Khi task đo lường được (5 rủi ro, 3 phương án, 8 story), bạn dễ kiểm tra AI đã làm đủ chưa, và dễ tinh chỉnh tiếp.

Ghép lại: ba thành phần thành một prompt

Sức mạnh thật sự đến khi bạn ghép cả ba. Hãy nhìn ví dụ:

> [Role] Bạn là Senior PM mảng e-commerce, từng scale sản phẩm tại thị trường Việt Nam. > [Context] Sản phẩm của tôi là sàn TMĐT cho thời trang local brand, 50.000 người dùng, đa số nữ 22–30 tuổi ở thành thị. Conversion từ "xem sản phẩm" sang "thêm giỏ hàng" chỉ 4%, thấp hơn benchmark ngành (~8%). > [Task] Đề xuất 6 giả thuyết về vì sao conversion thấp, sắp xếp theo mức độ dễ kiểm chứng. Với mỗi giả thuyết, gợi ý một cách test nhanh trong 1 tuần.

Prompt này không chỉ ra lệnh — nó brief cho AI như brief cho một cộng sự. Và output sẽ phản ánh đúng độ chỉn chu đó.

Tình huống thực tế

Tình huống 1: PM tại một startup logistics ở TP.HCM — từ output vô dụng đến dùng được ngay

Minh là Associate PM tại một startup giao hàng nội thành (tạm gọi là GiaoNhanh). Sếp yêu cầu Minh chuẩn bị nội dung khảo sát tài xế để tìm hiểu vì sao tỷ lệ tài xế nghỉ việc trong 3 tháng đầu lên tới 40%.

Lần đầu, Minh gõ: "Viết câu hỏi khảo sát cho tài xế giao hàng." AI trả về 10 câu hỏi chung chung kiểu "Bạn có hài lòng với công việc không?" — đúng nhưng nhạt, không khai thác được gốc rễ vấn đề.

Minh áp dụng Role – Context – Task:

> [Role] Bạn là chuyên gia nghiên cứu người dùng chuyên về lao động gig economy tại Việt Nam. > [Context] GiaoNhanh là app giao hàng nội thành TP.HCM. 40% tài xế nghỉ trong 3 tháng đầu. Tài xế phần lớn là nam 25–40 tuổi, thu nhập phụ thuộc số đơn, nhiều người chạy song song với app khác. Nghi ngờ vấn đề nằm ở thu nhập thực nhận, độ phức tạp app, và cách phân bổ đơn. > [Task] Soạn 12 câu hỏi khảo sát, chia 3 nhóm (thu nhập, trải nghiệm app, sự công bằng khi chia đơn). Câu hỏi phải tránh dẫn dắt, ưu tiên thang đo định lượng để dễ phân tích.

Kết quả lần này sát đến mức Minh chỉ chỉnh sửa nhẹ về câu chữ rồi đưa thẳng vào công cụ khảo sát.

Bài học: Cùng một AI, output dở hay tốt phụ thuộc gần như hoàn toàn vào lượng context bạn nạp vào. Context không phải "thông tin thừa" — nó là nguyên liệu để AI nấu đúng món.

Tình huống 2: PM tại Tiki dùng Role để đổi góc nhìn cho cùng một vấn đề

Một PM mảng thanh toán (lấy bối cảnh giả định tại một sàn TMĐT lớn như Tiki) cần đánh giá ý tưởng thêm tính năng "mua trước trả sau" (BNPL). Thay vì hỏi chung, cô dùng một context cố định nhưng đổi Role nhiều lần để soi vấn đề từ nhiều phía:

  • Role = "CFO khắt khe về rủi ro tài chính" → AI nêu bật rủi ro nợ xấu, chi phí vốn, tỷ lệ vỡ nợ kỳ vọng.
  • Role = "Trưởng phòng Pháp chế" → AI cảnh báo về quy định cho vay tiêu dùng, yêu cầu giấy phép, bảo vệ người tiêu dùng.
  • Role = "Growth Lead" → AI tập trung vào tác động lên giá trị đơn hàng trung bình và conversion.
Chỉ trong 15 phút, cô có được ba góc nhìn mà bình thường phải họp với ba phòng ban mới thu thập được — đủ để chuẩn bị một bản đánh giá cân bằng trước khi thật sự đi họp.

Bài học: Role không chỉ để "nâng chất lượng". Nó là công cụ để chủ động chuyển góc nhìn. Một PM giỏi dùng AI như một bàn tròn nhiều chuyên gia, không phải một cái máy trả lời duy nhất.

Tình huống 3: Task mơ hồ làm hỏng cả buổi chiều

Hà, PM tại một công ty SaaS B2B, cần tóm tắt 30 cuộc phỏng vấn khách hàng. Cô gõ: "Tóm tắt các insight từ những cuộc phỏng vấn này" rồi dán toàn bộ transcript. AI trả về một đoạn tóm tắt dài, lan man, trộn lẫn mọi thứ, không phân biệt được đâu là vấn đề lặp lại nhiều lần, đâu là ý kiến cá biệt.

Hà sửa lại Task cho cụ thể và có cấu trúc đầu ra:

> [Task] Phân tích các transcript và trả về theo bảng: (1) Pain point — (2) Số lần được nhắc — (3) Trích dẫn tiêu biểu — (4) Mức độ ưu tiên gợi ý (cao/trung/thấp). Chỉ liệt kê pain point được nhắc từ 3 khách hàng trở lên.

Lần này output là một bảng gọn gàng, có thể đưa thẳng vào buổi prioritization với team.

Bài học: Khi bạn không nói rõ định dạng đầu ra và tiêu chí lọc, AI buộc phải đoán — và nó thường đoán theo hướng an toàn nhất là viết dài, viết chung. Một Task chỉ định rõ cấu trúc giúp bạn tiết kiệm vòng lặp chỉnh sửa.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng cho gần như mọi tác vụ PM hằng ngày:

Bước 1 — Xác định kết quả cuối bạn muốn. Trước khi gõ chữ nào, tự hỏi: "Tôi cần cầm cái gì trong tay sau khi AI trả lời?" Một bảng? Một danh sách 5 mục? Một bản nháp PRD? Biết đích đến giúp bạn viết Task rõ ràng.

Bước 2 — Viết Role. Gán vai cho AI phù hợp với tác vụ, và nói rõ bạn là ai. Một câu là đủ: "Bạn là [chuyên môn]. Tôi là [vai trò, mức kinh nghiệm]."

Bước 3 — Nạp Context. Liệt kê thông tin nền: sản phẩm, người dùng, số liệu, ràng buộc. Nguyên tắc vàng: nếu một đồng nghiệp mới chưa biết gì về dự án đọc context này, họ có hiểu đủ để giúp bạn không? Nếu chưa, bổ sung tiếp.

Bước 4 — Viết Task cụ thể. Dùng động từ rõ ràng, nêu số lượng, chỉ định định dạng đầu ra (bảng, danh sách, đoạn văn), và tiêu chí lọc nếu cần.

Bước 5 — Đọc output và tinh chỉnh. Hiếm khi prompt đầu tiên cho kết quả hoàn hảo. Đọc kỹ, rồi phản hồi: "Phần 3 quá chung, hãy cụ thể hơn với ví dụ từ ngành TMĐT" hoặc "Rút ngắn còn một nửa, bỏ phần lý thuyết." Coi đây là một cuộc đối thoại, không phải một lệnh duy nhất.

Bước 6 — Lưu lại prompt tốt. Khi một prompt cho kết quả xuất sắc, hãy lưu nó vào một file ghi chú. Lần sau chỉ cần thay context là dùng lại được. Đây là cách bạn xây dần "thư viện prompt" cá nhân.

Lỗi thường gặp & mẹo

Lỗi 1 — Bỏ qua Context vì lười. Đây là lỗi số một. PM bận, nên hay gõ task cụt lủn rồi than "AI trả lời chung chung." 80% chất lượng output đến từ context. Bỏ ra thêm 60 giây nạp context tiết kiệm cho bạn nhiều vòng sửa.

Lỗi 2 — Nhồi nhét quá nhiều cùng lúc. Ngược lại, đừng yêu cầu AI vừa nghiên cứu, vừa viết PRD, vừa lập kế hoạch test trong một prompt. Tách thành các bước. Một prompt nên có một mục tiêu chính.

Lỗi 3 — Không chỉ định định dạng đầu ra. Nếu bạn muốn bảng, hãy nói "trả về dạng bảng." Nếu muốn ngắn gọn, nói "tối đa 150 từ." AI không tự biết bạn sẽ paste kết quả này vào đâu.

Lỗi 4 — Bỏ cuộc sau prompt đầu. Output đầu tiên là bản nháp, không phải bản cuối. Người dùng AI giỏi tinh chỉnh qua 2–3 vòng; người mới thì bỏ ngang và kết luận "AI dở."

Mẹo — Yêu cầu AI hỏi ngược lại bạn. Thêm câu: "Trước khi trả lời, hãy hỏi tôi 3 câu để làm rõ những thông tin còn thiếu." Cách này biến AI thành đối tác chủ động và thường cho kết quả tốt hơn nhiều.

Mẹo — Nói rõ ngôn ngữ và bối cảnh Việt Nam. Nếu cần output tiếng Việt tự nhiên hoặc phù hợp văn hóa Việt, hãy nêu thẳng trong context: "Trả lời bằng tiếng Việt, văn phong dùng cho team người Việt, tránh dịch máy cứng nhắc."

Bài tập thực hành

Chọn một tác vụ thật bạn đang làm tuần này (ví dụ: viết user story, chuẩn bị câu hỏi phỏng vấn người dùng, tóm tắt feedback, hay đánh giá một ý tưởng tính năng) và thực hành:

  • Viết phiên bản "lười": Gõ một prompt cụt lủn như bạn thường làm. Lưu lại kết quả.
  • Viết phiên bản Role – Context – Task: Soạn lại prompt đầy đủ ba thành phần. Trong Context, ép mình ghi ít nhất 4 thông tin nền cụ thể (có số liệu càng tốt). Trong Task, chỉ định rõ số lượng và định dạng đầu ra.
  • So sánh hai output cạnh nhau. Ghi ra: phiên bản đầy đủ tốt hơn ở những điểm cụ thể nào?
  • Thử đổi Role trên cùng một context (ví dụ đổi từ "Growth PM" sang "kỹ sư bảo mật") và quan sát góc nhìn thay đổi ra sao.
  • Lưu prompt tốt nhất vào file ghi chú cá nhân, kèm tên tác vụ, để tái sử dụng.
Mục tiêu không phải làm cho xong, mà là cảm nhận tận tay sự khác biệt mà cấu trúc tạo ra. Khi bạn đã thấy chênh lệch chất lượng bằng chính mắt mình, bạn sẽ không bao giờ quay lại lối gõ prompt cụt lủn nữa.

Tóm tắt

Prompt engineering cho PM không phải là một bộ mánh khóe bí truyền — nó là kỹ năng giao tiếp có cấu trúc, giống cách bạn brief cho đồng đội. Hãy ghi nhớ bộ khung cốt lõi:

  • Role: AI đóng vai gì, và bạn là ai — điều này căn chỉnh giọng điệu và độ chuyên sâu của câu trả lời, đồng thời cho phép bạn đổi góc nhìn linh hoạt.
  • Context: Bối cảnh sản phẩm, người dùng, tình huống, số liệu, ràng buộc — đây là nguyên liệu quyết định 80% chất lượng output.
  • Task: Yêu cầu cụ thể, có số lượng, có định dạng đầu ra, có tiêu chí lọc rõ ràng.
Ba ví dụ trong bài — từ khảo sát tài xế GiaoNhanh, đánh giá BNPL bằng cách đổi Role, đến tóm tắt phỏng vấn có cấu trúc — đều cho thấy một sự thật: công cụ AI ai cũng có như nhau, nhưng kết quả thì không. Khác biệt nằm ở người biết ra lệnh đúng cách. Hãy luyện bộ khung Role – Context – Task cho đến khi nó trở thành phản xạ, rồi tinh chỉnh qua đối thoại nhiều vòng. Đó là nền tảng cho mọi kỹ thuật prompt nâng cao bạn sẽ học sau này.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi