Bài 30 — Prompt for product — PRD, user story, roadmap

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

Nếu bạn từng làm việc trong một đội sản phẩm (product team) tại Việt Nam, bạn sẽ nhận ra một sự thật hơi phũ phàng: phần lớn thời gian của một Product Manager (PM) không dành cho việc "nghĩ ra ý tưởng thiên tài", mà dành cho việc viết. Viết PRD (Product Requirement Document — tài liệu mô tả yêu cầu sản phẩm), viết user story, viết acceptance criteria, viết release note, cập nhật roadmap, tóm tắt feedback từ khách hàng, chuẩn bị slide cho buổi họp với ban lãnh đạo. Một khảo sát nội bộ của nhiều startup công nghệ cho thấy PM dành 40–60% thời gian cho công việc soạn thảo tài liệu — thứ mà đội kỹ thuật hay đùa là "giấy tờ hành chính của sản phẩm".

Đây chính là nơi prompt engineering tạo ra khác biệt lớn. Không phải để AI thay bạn ra quyết định sản phẩm — đó vẫn là việc của con người, cần trực giác thị trường và hiểu người dùng. Mà để AI gánh phần "cơ bắp" của việc soạn thảo: biến một ý tưởng thô thành user story chuẩn format, biến một mớ feedback lộn xộn thành danh sách yêu cầu có cấu trúc, biến một roadmap trong đầu thành bảng ưu tiên rõ ràng.

Bài này tập trung hẹp và sâu vào ba loại tài liệu cốt lõi của nghề product: user story, PRD, và roadmap. Đây là ba "sản phẩm đầu ra" mà một PM phải tạo đi tạo lại hàng tuần. Khi bạn có bộ prompt chuẩn cho ba loại này, bạn tiết kiệm được vài giờ mỗi tuần và — quan trọng hơn — tài liệu của bạn trở nên nhất quán, đầy đủ, ít lỗ hổng logic hơn.

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

Vì sao product prompt khác các loại prompt khác

Viết prompt cho công việc sản phẩm không giống viết prompt cho marketing hay viết code. Tài liệu sản phẩm có ba đặc điểm khiến prompt phải được thiết kế cẩn thận:

Thứ nhất, tài liệu sản phẩm phải có cấu trúc chặt. Một user story sai format sẽ khiến developer hiểu nhầm phạm vi. Một PRD thiếu phần "success metrics" sẽ khiến cả team không biết khi nào coi là làm xong. Vì vậy, prompt cho product luôn phải chỉ định format đầu ra rõ ràng.

Thứ hai, tài liệu sản phẩm cần bối cảnh (context). AI không biết sản phẩm của bạn là app giao đồ ăn hay phần mềm kế toán, không biết người dùng của bạn là chủ shop hay kế toán trưởng. Nếu bạn không cung cấp persona (chân dung người dùng), mục tiêu kinh doanh và ràng buộc kỹ thuật, AI sẽ viết ra thứ chung chung vô dụng.

Thứ ba, tài liệu sản phẩm cần "độ đầy đủ" chứ không chỉ "đúng". Điểm mạnh lớn nhất của AI ở đây không phải viết hay, mà là không bỏ sót. AI giỏi liệt kê các edge case (trường hợp ngoại lệ), các trạng thái lỗi, các persona ít gặp mà con người hay quên.

User story — công thức và acceptance criteria

User story là đơn vị công việc nhỏ nhất mô tả một tính năng từ góc nhìn người dùng. Công thức kinh điển:

> "Là một [persona], tôi muốn [hành động], để [đạt được giá trị/mục tiêu]."

Nhưng user story chỉ hoàn chỉnh khi đi kèm acceptance criteria (tiêu chí nghiệm thu) — thường viết theo dạng Given/When/Then (Cho trước / Khi / Thì). Đây là phần AI hỗ trợ cực tốt, vì nó buộc bạn nghĩ đến mọi trường hợp.

Prompt mẫu:

Bạn là một Product Manager kỳ cựu. Hãy tạo user story cho tính năng sau:
[mô tả tính năng].
Bối cảnh sản phẩm: [loại sản phẩm, người dùng chính].
Với mỗi user story, xuất ra theo format:
Story: "Là một [persona], tôi muốn [hành động], để [giá trị]."
Acceptance criteria (dạng Given/When/Then, tối thiểu 3 tiêu chí)
Edge case cần lưu ý
Ước lượng độ phức tạp (S/M/L)

Hãy tạo cho cả persona chính lẫn ít nhất 1 persona phụ.

PRD — cấu trúc chuẩn để prompt

PRD là tài liệu tổng thể mô tả một tính năng hoặc sản phẩm sẽ được xây dựng như thế nào và tại sao. Một PRD tốt thường có các phần: Problem statement (vấn đề đang giải quyết), Goals & non-goals (mục tiêu và điều KHÔNG làm), User personas, User stories, Success metrics (chỉ số đo thành công), Requirements (functional & non-functional), và Open questions (câu hỏi chưa có lời giải).

Phần "non-goals" và "open questions" chính là hai phần con người hay quên nhất — và là nơi AI phát huy giá trị. Khi prompt, hãy yêu cầu AI điền đủ khung này.

Roadmap — ưu tiên hóa có cấu trúc

Roadmap không phải danh sách tính năng, mà là câu chuyện về thứ tự và lý do. Prompt cho roadmap nên yêu cầu AI áp dụng một framework ưu tiên cụ thể — phổ biến nhất là RICE (Reach - độ phủ, Impact - tác động, Confidence - độ chắc chắn, Effort - công sức) hoặc MoSCoW (Must/Should/Could/Won't have). Ép AI dùng framework giúp roadmap có lý do rõ ràng thay vì cảm tính.

Tình huống thực tế

Tình huống 1 — Startup giao đồ ăn ở TP.HCM viết user story cho tính năng "đặt trước"

Anh Tuấn là PM tại một startup giao đồ ăn giả định tên BếpNhanh, quy mô khoảng 30 người, phục vụ khu vực TP.HCM. Sếp anh muốn thêm tính năng "đặt món trước" (pre-order) để người dùng đặt bữa trưa từ tối hôm trước, giúp nhà bếp chuẩn bị sớm và giảm thời gian chờ.

Ban đầu Tuấn tự viết được 3 user story trong 20 phút, nhưng khi đưa cho team dev, bạn lead backend hỏi liền: "Nếu quán đóng cửa đúng giờ giao thì sao? Nếu user hủy đơn đặt trước lúc 6h sáng thì có được hoàn tiền không?". Tuấn nhận ra mình bỏ sót nhiều trường hợp.

Anh viết lại prompt, cung cấp bối cảnh (app giao đồ ăn, persona là dân văn phòng bận rộn và chủ quán ăn), yêu cầu AI liệt kê edge case và acceptance criteria Given/When/Then. Kết quả: AI trả về 8 user story, bao gồm cả những trường hợp Tuấn quên — như "quán tạm hết nguyên liệu vào phút chót", "user đặt trước nhưng app mất kết nối lúc thanh toán", "giờ giao trùng giờ cao điểm nên tài xế quá tải".

Bài học: Giá trị của AI ở đây không phải viết câu chữ đẹp, mà là lấp đầy các lỗ hổng logic. Tuấn dùng danh sách edge case của AI làm checklist thảo luận với team, biến buổi refinement (họp làm rõ yêu cầu) từ 90 phút xuống còn 40 phút vì không phải nghĩ tại chỗ.

Tình huống 2 — PM một fintech Đông Nam Á viết PRD cho tính năng "chia hóa đơn"

Chị Linh làm PM tại một ví điện tử giả định tên VíChung, hoạt động ở Việt Nam và Philippines. Team muốn xây tính năng "chia hóa đơn nhóm" (split bill) cho nhóm bạn đi ăn chung. Chị được yêu cầu viết PRD trong 2 ngày để kịp trình hội đồng sản phẩm.

Thay vì mở trang trắng, chị dùng prompt sau:

Bạn là Senior PM của một ví điện tử tại Đông Nam Á.
Viết PRD cho tính năng "chia hóa đơn nhóm".
Bối cảnh: người dùng là Gen Z và millennial thành thị, hay đi ăn nhóm,
đã có ví điện tử. Ràng buộc: phải tuân thủ quy định KYC, không lưu
thông tin thẻ ngân hàng ngoài phạm vi cho phép.
Xuất ra PRD theo khung:
Problem statement
Goals & Non-goals (nêu rõ điều KHÔNG làm trong phiên bản 1)
Target personas (2-3 persona)
User stories chính (kèm acceptance criteria)
Success metrics (chỉ số cụ thể, đo được)
Functional & non-functional requirements
Open questions cần làm rõ với legal và engineering

Với mỗi success metric, đề xuất con số mục tiêu hợp lý cho 3 tháng đầu.

AI trả về bản nháp PRD khá đầy đủ. Phần "Non-goals" giúp Linh chốt được với sếp rằng phiên bản 1 sẽ không làm chia hóa đơn với người chưa có tài khoản ví — tránh scope creep (phình phạm vi). Phần "Open questions" nhắc chị hỏi legal về giới hạn số tiền mỗi giao dịch khi chia bill, điều mà bản nháp tự viết chị đã quên.

Quan trọng: Linh không dùng thẳng bản AI viết. Chị sửa lại success metrics theo dữ liệu thật của công ty (AI đề xuất "30% người dùng thử tính năng trong tháng đầu", chị điều chỉnh xuống 12% cho sát thực tế thị trường Việt Nam). PRD hoàn thành trong 1 ngày thay vì 2.

Bài học: Prompt cho PRD hiệu quả nhất khi bạn ép AI điền vào một khung có sẵn và bổ sung ràng buộc pháp lý/kỹ thuật đặc thù. AI cho bạn bản nháp 70%, bạn dồn năng lượng vào 30% quan trọng nhất — những con số và quyết định cần hiểu biết nội bộ.

Tình huống 3 — Solo founder dùng RICE để sắp xếp roadmap quý

Anh Đức là founder một SaaS nhỏ giả định — công cụ quản lý phòng khám nha khoa tên NhaKhoaPro. Một mình anh vừa làm sản phẩm vừa bán hàng, và anh có một danh sách 15 tính năng khách hàng yêu cầu, không biết làm cái nào trước.

Anh liệt kê 15 tính năng vào prompt, kèm ước lượng thô về số khách hàng bị ảnh hưởng và độ khó, rồi yêu cầu AI tính điểm RICE và sắp xếp thành roadmap 3 tháng:

Tôi là founder của phần mềm quản lý phòng khám nha khoa.
Dưới đây là 15 tính năng đang cân nhắc, kèm ước lượng của tôi:
[dán danh sách, mỗi dòng: tên tính năng | số phòng khám cần | tác động | độ khó].
Hãy:
Tính điểm RICE cho từng tính năng (Reach x Impact x Confidence / Effort).
Xếp hạng và chia thành 3 nhóm: làm ngay (Now), làm sau (Next), để dành (Later).
Giải thích ngắn gọn lý do cho top 5.
Cảnh báo nếu tính năng nào có vẻ bị định giá quá cao/thấp.

AI không chỉ tính điểm, mà còn cảnh báo rằng tính năng "tích hợp bảo hiểm y tế" anh xếp Effort thấp thực ra rất phức tạp về pháp lý và nên tăng Effort lên — điều Đức chưa lường trước. Roadmap cuối cùng giúp anh tự tin trả lời khách hàng "tính năng của anh/chị nằm trong nhóm Next, dự kiến quý sau".

Bài học: AI biến ưu tiên hóa từ cảm tính thành có hệ thống. Nhưng con số RICE đầu vào vẫn do bạn cung cấp — "rác vào thì rác ra". Giá trị bổ sung là AI thách thức lại ước lượng của bạn, đóng vai một cố vấn phản biện.

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

Đây là quy trình 5 bước để dùng prompt tạo tài liệu sản phẩm chất lượng:

Bước 1 — Gán vai và cung cấp bối cảnh sản phẩm. Luôn mở đầu bằng "Bạn là một Product Manager kỳ cựu trong lĩnh vực [X]" và mô tả sản phẩm, người dùng, giai đoạn (startup mới hay sản phẩm trưởng thành). Bối cảnh càng rõ, đầu ra càng ít chung chung.

Bước 2 — Chỉ định format đầu ra chính xác. Đừng để AI tự chọn cấu trúc. Với user story, chỉ rõ công thức "Là một... tôi muốn... để...". Với PRD, dán khung 7 phần. Với roadmap, nêu tên framework (RICE/MoSCoW) và cấu trúc bảng.

Bước 3 — Cung cấp ràng buộc và persona thật. Nêu rõ persona (tên, nghề, nhu cầu), ràng buộc kỹ thuật (nền tảng, tích hợp), ràng buộc pháp lý (KYC, bảo mật dữ liệu). Đây là thứ tách một prompt chuyên nghiệp khỏi prompt nghiệp dư.

Bước 4 — Yêu cầu phần "dễ quên". Chủ động yêu cầu AI liệt kê edge case, non-goals, open questions, và các trạng thái lỗi. Đây là nơi AI tạo giá trị lớn nhất — bù đắp điểm mù của con người.

Bước 5 — Kiểm chứng và tinh chỉnh. Không bao giờ dùng thẳng đầu ra. Sửa lại con số theo dữ liệu thật, cắt bỏ tính năng không phù hợp bối cảnh, và hỏi lại AI để đào sâu ("Hãy viết chi tiết acceptance criteria cho story số 3"). Coi AI là cộng sự nháp bản đầu, bạn là người biên tập cuối.

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

Lỗi 1 — Prompt quá chung chung. "Viết user story cho tính năng đăng nhập" sẽ cho ra story sáo rỗng. Hãy thêm: đăng nhập bằng gì (số điện thoại, Google, sinh trắc học), người dùng là ai, có ràng buộc bảo mật nào. Bối cảnh cụ thể tạo ra story dùng được.

Lỗi 2 — Tin tưởng con số AI bịa ra. AI rất tự tin khi đề xuất success metrics ("tăng 40% retention"). Những con số này thường là con số đẹp vô căn cứ. Luôn thay bằng con số dựa trên dữ liệu thật hoặc benchmark ngành của bạn.

Lỗi 3 — Để AI quyết định ưu tiên thay bạn. AI tính RICE dựa trên input bạn đưa, nó không biết chiến lược công ty, không biết áp lực từ nhà đầu tư. Dùng kết quả AI làm đầu vào cho thảo luận, không phải quyết định cuối.

Lỗi 4 — Bỏ qua non-goals và open questions. Đây là hai phần chống scope creep tốt nhất, mà nhiều người xóa đi vì thấy "thừa". Giữ lại chúng — chúng cứu bạn khỏi những cuộc họp cãi nhau về phạm vi.

Mẹo hay: Xây một "prompt template" cố định cho mỗi loại tài liệu và lưu lại. Lần sau chỉ cần điền phần tính năng mới. Điều này đảm bảo mọi PRD trong team có cùng cấu trúc — cực kỳ hữu ích khi làm việc nhóm. Ngoài ra, hãy để AI đóng vai "developer khó tính" phản biện lại user story của bạn: "Với vai trò một developer, hãy chỉ ra những chỗ mơ hồ trong các story sau" — cách này lộ ra lỗ hổng trước khi đưa vào sprint.

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

Bài 1 — User story. Chọn một tính năng bạn quen thuộc (ví dụ: "lưu địa chỉ giao hàng" trên app mua sắm). Viết prompt yêu cầu AI tạo 5 user story cho ít nhất 2 persona, mỗi story kèm 3 acceptance criteria dạng Given/When/Then và ít nhất 2 edge case. Sau đó tự đánh giá: AI có tìm ra edge case nào bạn chưa nghĩ tới không?

Bài 2 — PRD. Viết prompt tạo PRD cho một tính năng của sản phẩm giả định của bạn, ép AI điền đủ 7 phần (đặc biệt là Non-goals và Open questions). Sau khi có bản nháp, sửa lại phần Success metrics bằng con số bạn cho là thực tế và giải thích vì sao bạn đổi.

Bài 3 — Roadmap. Liệt kê 8 tính năng bất kỳ với ước lượng Reach/Impact/Confidence/Effort của riêng bạn. Yêu cầu AI tính RICE, sắp xếp Now/Next/Later, và cảnh báo các ước lượng đáng ngờ. Ghi lại một cảnh báo mà bạn thấy hợp lý và một cảnh báo bạn không đồng ý — kèm lý do.

Tóm tắt

Prompt cho công việc sản phẩm không nhằm thay PM ra quyết định, mà giúp PM soạn thảo nhanh và đầy đủ hơn ba loại tài liệu cốt lõi: user story, PRD và roadmap. Ba nguyên tắc vàng: (1) luôn cung cấp bối cảnh sản phẩm và persona thật; (2) luôn chỉ định format đầu ra chính xác — công thức user story, khung 7 phần của PRD, framework RICE/MoSCoW cho roadmap; (3) chủ động yêu cầu những phần con người hay quên như edge case, non-goals, open questions. Sức mạnh lớn nhất của AI ở đây là không bỏ sót và phản biện lại ước lượng của bạn. Nhưng con số, quyết định ưu tiên và hiểu biết thị trường vẫn là việc của bạn — AI viết bản nháp 70%, bạn làm chủ 30% quan trọng nhất. Hãy xây template prompt cố định cho từng loại tài liệu để tiết kiệm hàng giờ mỗi tuần và giữ sự nhất quán cho cả team.