Một PM gõ vào ChatGPT: "Viết giúp tôi user story cho tính năng lọc sản phẩm theo giá." Kết quả trả về là một đoạn "As a user, I want to filter products by price, so that I can find what I need" — đúng cú pháp, nhưng vô dụng. Không có acceptance criteria cụ thể, không biết filter áp dụng cho web hay app, không biết có tính đến sản phẩm hết hàng hay không, không có edge case nào được nhắc tới. PM này sau đó phải tự viết lại gần như từ đầu, và kết luận "AI chỉ tạo ra nội dung generic, không dùng được cho việc thật." Vấn đề ở đây không phải AI kém — mà là prompt kém. Một PM khác, với cùng model AI, cùng một câu hỏi nghiệp vụ, nhưng biết cách frame role, cấu trúc task/context/constraints/output format, sẽ nhận về một user story đầy đủ acceptance criteria, có tính tới permission, có gợi ý test case, đúng format Jira mà team đang dùng — sẵn sàng paste vào backlog trong vòng 30 giây. Khác biệt duy nhất giữa hai kết quả này là kiến trúc của prompt.
Prompt architecture (kiến trúc prompt) là kỹ năng thiết kế câu lệnh cho AI một cách có hệ thống, thay vì "chat" ngẫu hứng như nói chuyện với đồng nghiệp. Đây không phải kỹ năng kỹ thuật của developer — nó là kỹ năng nghiệp vụ của chính PM, giống như cách một PM giỏi biết viết brief rõ ràng cho designer hay biết đặt câu hỏi đúng trong buổi discovery interview. Bài này đi sâu vào bốn trụ cột: role framing (định hình vai trò), structured instructions (cấu trúc chỉ dẫn theo khung Task – Context – Constraints – Output Format), output shaping (ép AI xuất ra đúng định dạng bạn cần), và các prompt pattern (khuôn mẫu prompt) tái sử dụng được cho discovery, planning, và giao tiếp với stakeholder.
Role Framing — Vì Sao Nói Với AI "Bạn Là Senior PM" Lại Thay Đổi Chất Lượng Output
Role framing, hay còn gọi là persona prompting (mồi vai trò/nhân vật cho AI), là kỹ thuật gán cho AI một vai trò cụ thể trước khi giao task, thay vì hỏi thẳng câu hỏi trần trụi. Về bản chất kỹ thuật, LLM (Large Language Model) sinh ra câu trả lời bằng cách dự đoán từ tiếp theo dựa trên toàn bộ ngữ cảnh (context) nó đã thấy — và câu "Bạn là một Senior Product Manager có 10 năm kinh nghiệm B2B SaaS" sẽ kéo model vào một vùng "không gian ngôn ngữ" khác hẳn so với câu hỏi trơn không có role. Khi được frame là chuyên gia, model có xu hướng dùng thuật ngữ chính xác hơn, đưa ra giả định thực tế hơn, và bỏ qua những câu trả lời an toàn/chung chung mà nó thường default vào khi không biết "nói cho ai".
Sự khác biệt này không phải là ảo giác tâm lý — nó có cơ sở thực nghiệm rõ ràng. Khi bạn hỏi trực tiếp "làm sao ưu tiên tính năng", AI thường trả lời bằng một bài liệt kê các framework nổi tiếng (RICE, MoSCoW, Kano) mang tính giáo khoa, vì đó là câu trả lời "trung bình" phù hợp với nhiều đối tượng hỏi (sinh viên, PM mới, người tò mò). Nhưng khi bạn frame "bạn là Head of Product tại một startup fintech Series B, đang có 40 feature request nhưng chỉ có 2 sprint trước khi gọi vốn vòng tiếp theo", AI buộc phải suy luận trong bối cảnh cụ thể — nó sẽ ưu tiên theo tiêu chí gắn với gọi vốn (feature nào chứng minh traction, feature nào giảm churn), thay vì liệt kê lý thuyết suông.
Một điểm PM hay bỏ lỡ: role framing không chỉ là gán vai trò cho AI, mà còn nên gán luôn "đối tượng nghe" (audience) mà AI đang viết cho. "Bạn là Senior PM, viết brief này cho một dev team đã quen làm việc với bạn 2 năm" sẽ ra văn phong khác hẳn "Bạn là Senior PM, viết report này để trình bày cho Ban Giám Đốc không có background kỹ thuật." Hai role framing khác nhau cho cùng một nội dung sẽ tạo ra hai output khác nhau về độ dài, mức độ chi tiết kỹ thuật, và tone.
Các Bước Thực Hành
- Trước khi gõ bất kỳ yêu cầu nào, viết một câu role framing riêng biệt, đặt ở đầu prompt: "Bạn là [vai trò cụ thể] với [số năm kinh nghiệm/lĩnh vực chuyên môn]."
- Thêm bối cảnh công ty/sản phẩm ngay sau role: loại sản phẩm (B2B/B2C, SaaS, marketplace, fintech...), giai đoạn (early-stage, scale-up, enterprise), vì cùng một role "Senior PM" sẽ hành xử khác nhau tùy ngành.
- Chỉ định rõ "đối tượng đọc" của output — người sẽ nhận và dùng kết quả này (dev team, stakeholder không kỹ thuật, khách hàng, chính bạn để tự tham khảo).
- Nếu dùng công cụ hỗ trợ hội thoại nhiều lượt như Claude Projects, ChatGPT Custom GPT, hoặc Notion AI, hãy đặt role framing vào phần system prompt/custom instructions một lần, thay vì gõ lại mỗi lần hỏi — điều này giữ "nhân cách" nhất quán suốt cả dự án.
- Test nhanh: hỏi cùng một câu hỏi hai lần — một lần có role framing, một lần không — so sánh độ cụ thể và tính thực dụng (actionable) của hai câu trả lời để tự tin rằng kỹ thuật này thực sự tạo khác biệt trong ngữ cảnh công việc của bạn.
Ví Dụ Prompt
Bạn là một Senior Product Manager có 8 năm kinh nghiệm, hiện đang phụ
trách mảng Growth tại một ứng dụng fintech B2C có 500.000 người dùng
hoạt động hàng tháng (MAU). Sản phẩm đang ở giai đoạn scale-up, vừa
gọi vốn Series A, áp lực chính là tăng retention tháng 2 trở đi (M2
retention hiện chỉ 22%, mục tiêu quý này là 30%).
Tôi cần bạn đóng vai trò cố vấn cho tôi, PM phụ trách trực tiếp tính
năng "nhắc nhở tiết kiệm tự động". Người đọc câu trả lời của bạn là
chính tôi, để tôi tự tổng hợp lại thành đề xuất trình bày cho Head of
Product — vì vậy hãy trả lời với tư duy phản biện, chỉ ra rủi ro thay
vì chỉ đưa ra lời khuyên xuôi chiều.
Câu hỏi: Tính năng nhắc nhở tiết kiệm tự động có thực sự là đòn bẩy
tốt nhất để cải thiện M2 retention, hay có hướng đi nào hiệu quả hơn
mà tôi đang bỏ sót?
Bạn là một Product Owner dày dạn kinh nghiệm làm việc trong mô hình
Scrum, quen thuộc với văn hóa của các đội dev Việt Nam (thường có xu
hướng tự nhận task khi chưa rõ requirement, dẫn đến rework).
Nhiệm vụ: Soạn một user story hoàn chỉnh, viết cho dev team đã làm
việc cùng bạn 1 năm — không cần giải thích khái niệm cơ bản, chỉ cần
đủ chi tiết để họ implement đúng ngay từ lần đầu, không rework.
Ngữ cảnh: tính năng lọc sản phẩm theo khoảng giá trên app thương mại
điện tử (iOS + Android), phiên bản hiện tại chưa hỗ trợ lọc theo giá,
người dùng phản hồi nhiều qua app store review.
Mẹo: Đừng chỉ dừng ở role nghề nghiệp — hãy thêm "tính cách phản biện" vào role framing khi bạn cần AI thách thức ý tưởng của bạn thay vì chiều theo. Câu như "hãy đóng vai một PM khó tính, luôn tìm lỗ hổng trong đề xuất trước khi đồng ý" giúp bạn tránh bẫy AI luôn gật đầu (sycophancy — xu hướng AI có thể chiều theo ý người hỏi thay vì phản biện thật).
Structured Instructions — Cấu Trúc Task, Context, Constraints, Và Output Format
Nếu role framing quyết định "AI nói bằng giọng của ai", thì structured instructions (chỉ dẫn có cấu trúc) quyết định "AI hiểu chính xác bạn cần gì". Đây là phần dễ bị PM bỏ qua nhất, vì trong giao tiếp giữa người với người, chúng ta quen "nói lửng" và để người nghe tự suy luận phần còn thiếu — đồng nghiệp có domain knowledge và context ngầm sẽ tự bù đắp chỗ thiếu đó. AI thì không có context ngầm ấy, trừ khi bạn viết ra tường minh. Một prompt tốt cho công việc PM nên luôn có đủ bốn thành phần, thường gọi tắt là khung TCCF (Task – Context – Constraints – Format):
- Task (nhiệm vụ): hành động cụ thể bạn muốn AI thực hiện — không phải "giúp tôi về tính năng X" (mơ hồ) mà là "viết 5 user story cho tính năng X, mỗi story có acceptance criteria dạng Given-When-Then."
- Context (bối cảnh): mọi thông tin nền AI cần để không phải đoán — sản phẩm là gì, đối tượng người dùng, dữ liệu/nghiên cứu đã có, các quyết định đã chốt trước đó, các ràng buộc kỹ thuật đã biết.
- Constraints (ràng buộc): giới hạn về phạm vi, độ dài, những gì KHÔNG được đưa vào, timeline, ngân sách, hoặc các quy tắc nghiệp vụ bắt buộc phải tuân theo (ví dụ: "không đề xuất giải pháp cần sửa database schema vì team backend đã full Q này").
- Output Format (định dạng đầu ra): hình thức cụ thể của kết quả — bảng Markdown, danh sách đánh số, format PRD chuẩn công ty, JSON để import vào tool khác, độ dài tối đa.
Khung TCCF giống như một "prompt template" (mẫu prompt) mà bạn xây một lần và tái sử dụng cho hàng chục task khác nhau — brainstorming tính năng, viết PRD, phân tích feedback khách hàng, soạn báo cáo sprint. Điểm mấu chốt là: càng thiếu một trong bốn thành phần, AI càng phải "đoán", và phần đoán đó chính là nguồn gốc của output generic mà nhiều PM phàn nàn. Ngược lại, nhồi quá nhiều context không liên quan (ví dụ paste nguyên cả một tài liệu 20 trang khi chỉ cần 2 đoạn) cũng phản tác dụng — AI dễ bị "loãng" và bỏ sót chi tiết quan trọng ở giữa. Nguyên tắc là: context phải đủ và đúng, không phải nhiều.
Các Bước Thực Hành
- Trước khi gõ prompt, viết nháp bốn dòng riêng biệt: Task / Context / Constraints / Output Format — kể cả khi sau đó bạn gộp lại thành đoạn văn liền mạch, việc tách riêng giúp bạn không quên thành phần nào.
- Với Context, chỉ đưa vào những gì thực sự ảnh hưởng đến câu trả lời — tự hỏi "nếu bỏ dòng này, AI có trả lời khác không?" Nếu không, bỏ nó ra.
- Với Constraints, luôn liệt kê rõ ràng "không được làm gì" bên cạnh "phải làm gì" — AI có xu hướng đề xuất giải pháp lý tưởng nếu không bị giới hạn, dễ ra những gợi ý không khả thi trong thực tế (ví dụ đề xuất cần 3 tháng dev trong khi bạn chỉ có 2 tuần).
- Với Output Format, luôn cho ví dụ cụ thể (few-shot example) nếu định dạng phức tạp — thay vì mô tả bằng lời "dạng bảng có các cột...", hãy vẽ luôn khung bảng trống hoặc show 1 dòng mẫu để AI bắt chước chính xác cấu trúc.
- Lưu prompt template TCCF đã dùng tốt vào một nơi cố định (Notion, Google Doc, hoặc snippet trong Claude Projects) để tái sử dụng, chỉ thay phần nội dung cụ thể mỗi lần dùng — đừng viết lại từ đầu mỗi lần.
Ví Dụ Prompt
[TASK]
Phân tích 40 phản hồi khách hàng dưới đây (thu thập qua khảo sát NPS
quý 2) và tổng hợp thành 5 chủ đề (theme) chính, mỗi theme kèm 2-3
câu trích dẫn tiêu biểu.
[CONTEXT]
Sản phẩm là app quản lý chi tiêu cá nhân, đối tượng người dùng chính
là nhân viên văn phòng 25-35 tuổi. Khảo sát được gửi sau khi người
dùng dùng app tối thiểu 30 ngày. Điểm NPS trung bình quý này là 18,
giảm so với 32 của quý trước — team đang cố xác định nguyên nhân sụt
giảm.
[DỮ LIỆU PHẢN HỒI]
[PASTE 40 CÂU TRẢ LỜI KHẢO SÁT VÀO ĐÂY]
[CONSTRAINTS]
- Không suy diễn nguyên nhân nếu không có bằng chứng trực tiếp trong
câu trả lời (không tự bịa lý do).
- Không gộp các phản hồi về bug kỹ thuật vào chung theme với phản hồi
về trải nghiệm/UX — tách riêng hai loại.
- Bỏ qua các câu trả lời chỉ có 1-2 từ không mang thông tin ("ok",
"tốt", "bình thường").
[OUTPUT FORMAT]
Bảng Markdown với các cột: Theme | Số lượng phản hồi nhắc tới | Mức độ
nghiêm trọng (Cao/Trung/Thấp, dựa trên tần suất và cường độ ngôn từ) |
Trích dẫn tiêu biểu | Đề xuất hành động ngắn gọn (1 câu).
Sắp xếp theo mức độ nghiêm trọng giảm dần.
Mẹo: Khi một prompt bạn viết ra kết quả tốt, đừng để nó trôi đi trong lịch sử chat — copy ngay thành một "prompt template" có chỗ trống để điền biến số (ví dụ [TÊN TÍNH NĂNG], [SỐ LƯỢNG NGƯỜI DÙNG]), lưu lại như một tài sản quy trình của riêng bạn. Sau vài tháng, bạn sẽ có một thư viện prompt cho từng loại việc PM lặp lại hàng tuần — đó chính là năng suất thật sự của prompt architecture, không phải chỉ một lần dùng tốt.
Output Shaping — Bắt AI Tạo Bảng, Danh Sách Ưu Tiên, User Story, Và Decision Matrix
Output shaping (định hình đầu ra) là kỹ thuật ép AI trả về đúng cấu trúc bạn cần để dùng ngay, thay vì một đoạn văn xuôi phải tự tay chuyển đổi lại. Đây là phần biến AI từ "công cụ brainstorm" thành "công cụ sản xuất tài liệu" thực thụ trong công việc PM hàng ngày — vì phần lớn output của PM (backlog, roadmap, báo cáo) đều có định dạng chuẩn hóa, không phải văn xuôi tự do.
Nguyên tắc cốt lõi để output shaping hiệu quả: mô tả cấu trúc mong muốn càng cụ thể càng tốt, và tốt nhất là cho AI một ví dụ mẫu (few-shot) thay vì chỉ mô tả bằng lời. Với PM, có bốn dạng output xuất hiện thường xuyên nhất đáng để thành thạo:
Bảng Markdown là định dạng linh hoạt nhất — dùng cho so sánh, tổng hợp, phân loại. Chìa khóa là luôn chỉ định rõ tên từng cột và thứ tự sắp xếp mong muốn (sắp theo priority giảm dần, theo alphabet, theo ngày...), nếu không AI có thể sắp xếp ngẫu nhiên theo thứ tự nó xử lý dữ liệu đầu vào.
Danh sách ưu tiên theo RICE (Reach – Impact – Confidence – Effort, công thức tính điểm ưu tiên = Reach × Impact × Confidence ÷ Effort) là một trong những use case AI làm tốt nhất, vì nó vừa cần tính toán (thứ AI làm chính xác nếu bạn cho công thức rõ ràng) vừa cần suy luận định tính (ước lượng impact dựa trên mô tả tính năng). Điểm PM cần lưu ý: luôn yêu cầu AI show rõ số liệu ước lượng cho từng thành phần (Reach, Impact, Confidence, Effort) trước khi ra điểm tổng, để bạn có thể tranh luận/chỉnh sửa từng con số thay vì chỉ nhận một kết quả "hộp đen".
User story kèm acceptance criteria cần một khuôn cố định để tránh AI viết lan man — format Given-When-Then (Cho trước – Khi – Thì) là chuẩn phổ biến nhất, dễ đưa thẳng vào Jira/Azure DevOps mà không cần chỉnh sửa.
Decision matrix (ma trận quyết định) cho các bài toán build-vs-buy hoặc so sánh trade-off giữa nhiều phương án feature, cần một cấu trúc trọng số (weighted criteria) rõ ràng — không chỉ liệt kê ưu nhược điểm định tính mà phải có điểm số theo từng tiêu chí đã thống nhất trước, để quyết định cuối cùng có thể giải trình được với stakeholder bằng con số, không chỉ cảm tính.
Các Bước Thực Hành
- Xác định trước "hình dạng" (shape) output bạn cần trước khi viết prompt — bảng, danh sách, JSON, hay văn bản có heading — vì việc này quyết định toàn bộ cách bạn mô tả yêu cầu.
- Với bảng, luôn viết rõ tên cột theo đúng thứ tự trong prompt, dùng ký hiệu
|để AI hiểu ngay đây là yêu cầu Markdown table. - Với RICE hoặc bất kỳ điểm số công thức nào, luôn nhắc lại công thức tính trong prompt (đừng giả định AI "nhớ đúng" công thức bạn dùng nội bộ, vì có nhiều biến thể RICE khác nhau giữa các công ty).
- Với user story, cho AI một ví dụ mẫu định dạng Given-When-Then của chính team bạn (nếu có convention riêng) để AI bắt chước đúng văn phong/độ chi tiết quen thuộc, thay vì dùng convention chung chung.
- Với decision matrix, luôn tự chốt trước danh sách tiêu chí và trọng số (%) mỗi tiêu chí trước khi đưa vào AI — đừng để AI tự chọn tiêu chí, vì tiêu chí phải phản ánh đúng ưu tiên chiến lược của công ty bạn, không phải tiêu chí "trung bình" mà AI mặc định.
- Sau khi nhận output có cấu trúc, luôn kiểm tra lại phần tính toán/con số bằng tay ít nhất một lần — AI có thể suy luận định tính tốt nhưng đôi khi tính sai phép nhân/cộng đơn giản, đặc biệt với bảng nhiều dòng.
Ví Dụ Prompt
Tôi có danh sách 8 tính năng đang chờ ưu tiên cho roadmap quý tới.
Hãy tính điểm RICE cho từng tính năng theo công thức:
RICE Score = (Reach × Impact × Confidence) ÷ Effort
Trong đó:
- Reach: số người dùng bị ảnh hưởng mỗi quý (đơn vị: số người).
- Impact: mức độ ảnh hưởng trên thang 0.25 (nhỏ) / 0.5 (trung bình) /
1 (lớn) / 2 (rất lớn), theo chuẩn RICE gốc của Intercom.
- Confidence: độ tự tin vào ước lượng, thang 50% / 80% / 100%.
- Effort: số người-tháng cần để hoàn thành (đơn vị: person-month).
Danh sách tính năng và dữ liệu ước lượng ban đầu của tôi:
[PASTE DANH SÁCH 8 TÍNH NĂNG + REACH/EFFORT ƯỚC LƯỢNG SẴN CÓ]
Với các tính năng tôi CHƯA có ước lượng Impact/Confidence, hãy tự đề
xuất dựa trên mô tả tính năng, và giải thích rõ lý do đề xuất mức đó
để tôi có thể phản biện.
Output dạng bảng Markdown: Tính Năng | Reach | Impact | Confidence |
Effort | RICE Score | Ghi chú lý do Impact/Confidence.
Sắp xếp theo RICE Score giảm dần.
Viết 4 user story cho tính năng "xuất báo cáo chi tiêu theo tháng
dạng PDF" trên app quản lý tài chính cá nhân. Định dạng bắt buộc theo
mẫu sau (đúng convention team đang dùng trên Jira):
Title: [Tên ngắn gọn]
As a [vai trò người dùng cụ thể, không chung chung "user"]
I want to [hành động cụ thể]
So that [giá trị/lợi ích cụ thể]
Acceptance Criteria (định dạng Given-When-Then):
- Given [điều kiện ban đầu]
When [hành động]
Then [kết quả mong đợi]
(liệt kê tối thiểu 3 AC cho mỗi story, bao gồm ít nhất 1 negative
case hoặc edge case — ví dụ không có dữ liệu giao dịch trong tháng,
lỗi khi xuất file, giới hạn dung lượng.)
Tách 4 story theo: (1) xuất PDF cơ bản, (2) tùy chỉnh khoảng thời
gian xuất báo cáo, (3) chia sẻ file qua email, (4) xử lý trường hợp
không có dữ liệu để xuất.
Tôi cần quyết định build in-house hay mua giải pháp third-party cho
tính năng chatbot hỗ trợ khách hàng trong app.
Tiêu chí đánh giá đã chốt với team (kèm trọng số):
- Chi phí triển khai trong 6 tháng đầu (trọng số 25%)
- Thời gian ra mắt (time-to-market) (trọng số 25%)
- Khả năng tùy biến theo nhu cầu riêng của sản phẩm (trọng số 20%)
- Rủi ro phụ thuộc vào bên thứ ba (vendor lock-in) (trọng số 15%)
- Khả năng maintain lâu dài bởi team hiện tại (trọng số 15%)
Hai phương án đang cân nhắc: (1) Build in-house dùng LLM API tự tích
hợp, (2) Mua giải pháp SaaS chatbot có sẵn tích hợp qua API.
[PASTE THÔNG TIN CHI TIẾT VỀ CHI PHÍ, THỜI GIAN CỦA MỖI PHƯƠNG ÁN]
Hãy tạo decision matrix dạng bảng: Tiêu Chí | Trọng Số | Điểm Build
(1-10) | Điểm Buy (1-10) | Điểm có trọng số Build | Điểm có trọng số
Buy | Ghi chú. Cuối bảng tính tổng điểm có trọng số của mỗi phương án
và đưa ra khuyến nghị kèm 2 rủi ro lớn nhất của phương án được chọn.
Mẹo: Khi cần một định dạng phức tạp hoặc bất thường (không phải bảng/danh sách chuẩn), hãy tự tay viết một dòng mẫu (one example row) rồi yêu cầu AI "hãy làm theo đúng cấu trúc dòng mẫu này cho các mục còn lại" — kỹ thuật few-shot prompting này gần như luôn cho kết quả nhất quán hơn là chỉ mô tả cấu trúc bằng lời, vì AI bắt chước pattern cụ thể tốt hơn diễn giải trừu tượng.
Prompt Pattern Cho Discovery, Planning, Và Giao Tiếp Sản Phẩm
Sau khi thành thạo role framing, cấu trúc TCCF, và output shaping, bước tiếp theo là đóng gói chúng thành các prompt pattern (khuôn mẫu prompt) tái sử dụng cho ba nhóm việc PM lặp lại thường xuyên nhất: tổng hợp discovery interview, lập kế hoạch roadmap, và giao tiếp/báo cáo với stakeholder. Một prompt pattern tốt không phải là prompt bạn nhớ thuộc lòng, mà là một "khung có chỗ trống" bạn điền biến số mỗi lần dùng — giống như một macro trong Excel, chỉ khác là macro này chạy trên ngôn ngữ tự nhiên.
Tổng hợp discovery interview là việc PM tốn nhiều thời gian nhất nhưng lại dễ tự động hóa nhất bằng AI, vì bản chất công việc là đọc nhiều văn bản phi cấu trúc (transcript, ghi chú) và trích xuất pattern lặp lại. Điểm mấu chốt khi dùng AI cho việc này: đừng chỉ hỏi "tóm tắt interview này" — hãy chỉ định rõ khung phân tích bạn muốn (Jobs To Be Done, Pain Point theo mức độ nghiêm trọng, hoặc theo persona), vì "tóm tắt" chung chung sẽ ra một đoạn văn kể lại nội dung, không phải insight có thể hành động.
Lập kế hoạch roadmap đòi hỏi AI xử lý đồng thời nhiều ràng buộc (capacity team, dependency giữa các feature, deadline kinh doanh) — đây là việc AI hỗ trợ tốt ở khâu tạo phương án nháp (draft nhiều kịch bản sắp xếp khác nhau để bạn so sánh), nhưng quyết định cuối luôn phải là của PM vì roadmap gắn liền với đánh đổi chiến lược mà chỉ con người mới nắm đủ bối cảnh chính trị nội bộ, cam kết đã lỡ hứa với khách hàng lớn, v.v.
Giao tiếp và báo cáo trạng thái (status update) là nơi output shaping và role framing kết hợp rõ nhất: cùng một tiến độ sprint, báo cáo gửi cho dev team cần chi tiết kỹ thuật, còn báo cáo gửi cho Ban Giám Đốc cần rút gọn về business impact — AI có thể tạo ra cả hai phiên bản từ cùng một nguồn dữ liệu nếu bạn frame đúng đối tượng đọc cho từng bản.
Các Bước Thực Hành
- Với discovery interview, luôn paste transcript gốc (hoặc ghi chú thô) kèm câu hỏi cụ thể về khung phân tích bạn muốn — đừng yêu cầu "tóm tắt" mà yêu cầu "trích xuất pain point theo mức độ nghiêm trọng và tần suất nhắc tới."
- Chạy tổng hợp discovery theo từng interview riêng lẻ trước, sau đó dùng một prompt thứ hai để tổng hợp chéo (cross-analysis) nhiều bản tóm tắt lại với nhau — tránh nhồi 5-6 transcript dài vào một lần vì dễ khiến AI bỏ sót chi tiết ở giữa.
- Với roadmap planning, luôn cho AI đầy đủ ràng buộc capacity (số người, số sprint khả dụng) và dependency đã biết giữa các feature trước khi hỏi thứ tự sắp xếp — nếu không, AI sẽ đề xuất một roadmap "lý tưởng" bỏ qua thực tế nguồn lực.
- Yêu cầu AI tạo tối thiểu 2 phương án roadmap khác nhau (ví dụ: một phương án ưu tiên retention, một phương án ưu tiên acquisition) kèm đánh đổi rõ ràng của mỗi phương án, thay vì chỉ một đáp án duy nhất — việc so sánh giúp bạn ra quyết định có ý thức hơn là chấp nhận gợi ý đầu tiên.
- Với status update, luôn tạo một prompt gốc chứa đầy đủ dữ liệu tiến độ (số liệu thật, không tóm gọn trước), sau đó dùng nhiều prompt "biến thể" khác nhau chỉ đổi phần audience/role framing để sinh ra nhiều bản báo cáo từ cùng một nguồn — tiết kiệm thời gian viết lại thủ công cho từng đối tượng.
- Lưu các prompt pattern đã hoạt động tốt vào Claude Projects, Notion AI database, hoặc một thư mục "Prompt Library" riêng — gắn tag theo loại việc (discovery/roadmap/report) để tìm lại nhanh khi cần dùng lại ở sprint sau.
Ví Dụ Prompt
Bạn là một UX Researcher kiêm Product Manager, chuyên phân tích dữ
liệu discovery interview theo khung Jobs To Be Done (JTBD).
Dưới đây là transcript phỏng vấn khách hàng số 4 trong chuỗi 8 buổi
phỏng vấn về thói quen tiết kiệm tiền của người dùng app tài chính:
[PASTE TRANSCRIPT PHỎNG VẤN]
Hãy phân tích theo các bước:
1. Xác định "job" chính người dùng đang cố hoàn thành (không phải
tính năng họ muốn, mà là mục tiêu/nhu cầu sâu xa đằng sau).
2. Liệt kê các pain point được nhắc tới, mỗi pain point gắn với trích
dẫn cụ thể từ transcript, phân loại mức độ nghiêm trọng (Cao/Trung/
Thấp) dựa trên cường độ cảm xúc và tần suất lặp lại trong lời kể.
3. Chỉ ra các "workaround" hiện tại người dùng đang tự làm để giải
quyết vấn đề (dấu hiệu cơ hội sản phẩm rõ ràng nhất).
4. Đừng suy diễn giải pháp sản phẩm — chỉ tổng hợp insight, để tôi tự
brainstorm giải pháp ở bước sau.
Output dạng bảng: Job cần hoàn thành | Pain Point | Trích dẫn | Mức độ
nghiêm trọng | Workaround hiện tại.
Bạn là Head of Product tại một công ty SaaS B2B quy mô 60 người, đang
lập roadmap quý 3 cho một sản phẩm quản lý dự án.
Context:
- Team dev có capacity 3 sprint x 2 tuần trong quý, 6 dev full-time.
- Backlog hiện có 12 feature request đã qua discovery, đã ước lượng
effort (person-sprint) và RICE score (đính kèm bên dưới).
- Ràng buộc kinh doanh: công ty vừa ký hợp đồng với 1 khách hàng
enterprise lớn, cam kết giao tính năng SSO (Single Sign-On) và audit
log trước cuối quý, nếu không sẽ mất hợp đồng 200 triệu/năm.
[PASTE BẢNG 12 FEATURE: TÊN, RICE SCORE, EFFORT ƯỚC LƯỢNG]
Hãy đề xuất 2 phương án roadmap quý 3:
Phương án A: Ưu tiên tuyệt đối cam kết enterprise (SSO + audit log)
trước, phần capacity còn lại phân bổ theo RICE score giảm dần.
Phương án B: Cân bằng giữa cam kết enterprise và feature có RICE cao
nhất, chấp nhận rủi ro trễ nhẹ cam kết enterprise nếu cần.
Với mỗi phương án, trình bày: danh sách feature theo từng sprint,
tổng RICE score đạt được trong quý, rủi ro chính, và đánh đổi cụ thể
so với phương án còn lại.
Bạn là Senior PM, cần viết 2 phiên bản báo cáo tiến độ sprint từ cùng
một dữ liệu, cho hai đối tượng khác nhau.
Dữ liệu sprint (Sprint 14, kết thúc hôm nay):
- 8/10 story hoàn thành đúng hạn, 2 story bị đẩy sang sprint sau (lý
do: phụ thuộc API bên thứ ba ZaloPay chưa sẵn sàng).
- Velocity: 34 story point (trung bình 5 sprint gần nhất: 31).
- 1 bug nghiêm trọng (Sev-1) phát hiện ở tính năng thanh toán, đã fix
và deploy hotfix trong ngày.
- Tính năng "nhắc nhở tiết kiệm" đã release, dữ liệu 3 ngày đầu cho
thấy 12% người dùng bật tính năng này.
Phiên bản 1 — gửi cho dev team + Scrum Master trong buổi retro:
đầy đủ chi tiết kỹ thuật, gọi tên story cụ thể, nêu rõ nguyên nhân
trễ để rút kinh nghiệm, tối đa 200 từ, giọng văn thẳng thắn nội bộ.
Phiên bản 2 — gửi email cho Ban Giám Đốc (không có background kỹ
thuật): tối đa 100 từ, tập trung vào business impact và số liệu
người dùng, không nhắc chi tiết kỹ thuật (API, story point), có 1 câu
khuyến nghị hành động tiếp theo nếu cần quyết định từ ban lãnh đạo.
Mẹo: Xây một "prompt library" (thư viện prompt) cá nhân ngay từ tuần đầu áp dụng — mỗi khi một prompt pattern chạy tốt cho discovery/roadmap/report, lưu lại kèm ghi chú ngắn về ngữ cảnh nó phù hợp nhất. Sau 2-3 tháng, thư viện này sẽ tiết kiệm cho bạn nhiều giờ hơn bất kỳ mẹo prompt đơn lẻ nào, vì phần lớn công việc PM lặp lại theo chu kỳ sprint/quý — bạn chỉ cần thay biến số, không cần nghĩ lại cấu trúc từ đầu mỗi lần.
Những Điểm Chính Cần Nhớ
- Role framing không phải trang trí prompt — gán vai trò + bối cảnh ngành + đối tượng đọc cụ thể sẽ kéo AI ra khỏi vùng trả lời "trung bình, an toàn, chung chung" và vào đúng bối cảnh nghiệp vụ của bạn.
- Khung TCCF (Task – Context – Constraints – Output Format) là công cụ kiểm tra nhanh trước khi gửi bất kỳ prompt nào: thiếu một trong bốn thành phần, AI phải đoán, và phần đoán đó chính là nguồn gốc của output generic.
- Output shaping biến AI từ công cụ brainstorm thành công cụ sản xuất tài liệu thật — dùng few-shot example (dòng mẫu cụ thể) luôn hiệu quả hơn mô tả cấu trúc bằng lời, đặc biệt với bảng, RICE, user story, decision matrix.
- Prompt pattern tái sử dụng cho discovery, roadmap, và báo cáo giúp bạn không phải "phát minh lại" cấu trúc prompt mỗi sprint — xây thư viện prompt cá nhân là khoản đầu tư năng suất dài hạn lớn nhất từ bài học này.
- AI luôn cần con người xác nhận cuối — dù prompt có kiến trúc tốt đến đâu, quyết định ưu tiên roadmap, đánh giá đúng/sai của RICE score, hay chọn phương án build-vs-buy vẫn phải qua tư duy phản biện của chính PM, không phải chấp nhận nguyên văn output đầu tiên AI đưa ra.
Mẹo: In hoặc lưu khung TCCF này ở nơi bạn dễ thấy nhất trong ngày làm việc (sticky note trên màn hình, pinned note trong Notion) trong 2-3 tuần đầu luyện tập — sau đó nó sẽ trở thành phản xạ tự nhiên mỗi khi bạn mở một cửa sổ chat AI mới, không cần nhìn lại tài liệu tham khảo nữa.