Bối cảnh thật của một Product Owner
Cuối sprint, Jira báo 23 ticket đã chuyển sang Done. Bạn cần: (1) release notes cho khách hàng, (2) một bản tóm tắt cho Sales/CS, (3) một dòng cập nhật cho ban lãnh đạo, và (4) changelog kỹ thuật cho team nội bộ. Bốn đối tượng, bốn giọng văn, bốn kênh. Bạn mở từng ticket, đọc mô tả do dev viết theo kiểu "Fix NPE in checkout service", tự dịch sang ngôn ngữ người dùng, rồi copy-paste vào email, Slack, Confluence, và banner in-app.
Kết quả: mất 2–3 tiếng mỗi lần release, làm trễ deadline, và thường xuyên quên báo cho một nhóm nào đó. Đây không phải việc tạo ra giá trị sản phẩm — đây là việc biên tập và phân phối thông tin lặp đi lặp lại. Chính loại việc này AI làm rất tốt.
Vấn đề cốt lõi
- Nguồn dữ liệu lộn xộn: mô tả ticket viết cho dev, không viết cho khách hàng.
- Đa đối tượng: cùng một thay đổi phải kể theo 4 góc nhìn khác nhau (giá trị, rủi ro, kỹ thuật, thương mại).
- Đa kênh: mỗi kênh có định dạng riêng (email dài, Slack ngắn, banner 1 câu).
- Lặp lại mỗi sprint: công sức không giảm dần theo thời gian.
AI thay đổi việc này thế nào
Thay vì bạn viết, AI trở thành biên tập viên đa đối tượng: bạn đưa danh sách ticket đã done → AI phân loại (tính năng mới / cải tiến / sửa lỗi), dịch sang ngôn ngữ theo đối tượng, và xuất ra đúng định dạng cho từng kênh. Bạn chuyển từ người viết thành người duyệt.
Ví dụ cụ thể
Đầu vào (3 ticket thô):
- PROJ-812: "Add SSO login via Google"
- PROJ-799: "Fix slow loading on report page (>8s)"
- PROJ-830: "Update tooltip copy on dashboard"
Prompt mẫu khởi động
Bạn là biên tập viên release notes cho sản phẩm SaaS B2B tiếng Việt.
Tôi đưa danh sách ticket đã hoàn thành (mô tả kỹ thuật do dev viết).
Nhiệm vụ:
1. Phân loại mỗi ticket: [Tính năng mới] / [Cải tiến] / [Sửa lỗi].
2. Bỏ qua ticket nội bộ không ảnh hưởng người dùng (refactor, CI, test).
3. Với mỗi mục còn lại, viết 1 câu theo góc nhìn LỢI ÍCH của người dùng cuối,
không dùng thuật ngữ kỹ thuật.
Ticket:
- PROJ-812: Add SSO login via Google
- PROJ-799: Fix slow loading on report page (>8s)
- PROJ-830: Update tooltip copy on dashboard
Trả về dạng bảng: | Loại | Câu mô tả cho người dùng |
Các bước bắt đầu (numbered)
- Liệt kê nguồn: xác định bạn lấy ticket từ đâu (Jira export CSV, Linear, GitHub PR).
- Xác định đối tượng: viết ra 3–5 nhóm cần cập nhật và họ quan tâm điều gì.
- Xác định kênh: mỗi đối tượng nhận qua kênh nào, độ dài bao nhiêu.
- Chạy prompt phân loại (như trên) trên một sprint cũ để kiểm chứng.
- So sánh kết quả AI với bản bạn từng viết tay — chỉnh prompt cho khớp giọng công ty.
- Ghi lại prompt vào một nơi tái dùng (sẽ dựng thành agent ở các bài sau).
Template: Bản đồ Đối tượng × Kênh (tái dùng)
| Đối tượng | Họ quan tâm gì | Kênh | Độ dài | Giọng văn |
|---|---|---|---|---|
| Khách hàng cuối | Lợi ích, cách dùng | Email, in-app | Trung bình | Thân thiện |
| Sales / CS | Bán được gì, xử lý ticket nào | Slack, wiki | Ngắn | Thực dụng |
| Ban lãnh đạo | Tác động kinh doanh, rủi ro | Email tóm tắt | 3–5 dòng | Súc tích |
| Team nội bộ | Chi tiết kỹ thuật, breaking change | Confluence | Đầy đủ | Chính xác |
Sai lầm thường gặp
- Đưa nguyên mô tả kỹ thuật cho khách hàng: khách không hiểu "NPE", "race condition". Luôn yêu cầu AI dịch sang lợi ích.
- Tin AI 100% không kiểm chứng (ảo giác): AI có thể bịa ra tính năng không hề release, hoặc phóng đại "nhanh hơn 10 lần" khi ticket chỉ nói ">8s". Luôn đối chiếu từng câu với ticket gốc.
- Rò rỉ dữ liệu: đừng dán tên khách hàng thật, số liệu doanh thu nội bộ, hay khóa API vào prompt trên công cụ AI công cộng. Ẩn danh trước khi đưa vào.
- Phụ thuộc quá mức: AI soạn nháp, nhưng bạn là người chịu trách nhiệm cuối cùng. Đừng gửi thẳng bản AI ra cho khách mà không đọc lại.
Điều rút ra
Release notes và cập nhật stakeholder là việc "dịch và phân phối" — đúng sở trường của AI. Nhiệm vụ của bạn trong 7 bài tới là biến quy trình thủ công 3 tiếng thành một agent chạy trong vài phút mà bạn chỉ cần duyệt.