Notebook tuần 2: Ideation → Product Brief → PRD

Workbook tuần 2 của khoá Vibe Coding, đi từ ý tưởng đến PRD 1 trang
Author

Duy NHM

Notebook tuần 2: Ideation → Product Brief → PRD

Tuần 2 thuộc khoá Vibe Coding Thực Chiến Cùng BMAD (V3). Tuần này bạn sẽ đi từ một ý tưởng sơ khai đến một bản PRD 1 trang đã được “chịu đòn” phản biện. Mentor sẽ demo toàn bộ flow trên HRIS (hệ thống quản lý nhân sự nội bộ) vào buổi học live. Bạn áp dụng cùng flow vào đề bạn đã chọn từ Buổi 1.

🎯 Mục tiêu tuần này

Sau ~6h tự học tại nhà + 3h trên Zoom, bạn sẽ có:

  • ✅ product-brief.md — 1 trang A4, đã qua 2 lớp phản biện AI
  • ✅ PRD.md — 1 trang A4, có đủ 5 trường bắt buộc (Problem, Persona, Goals + Success Metrics, MVP scope, Out-of-scope)
  • ✅ party-mode-debate.md — log 3 nhân vật BMAD cãi nhau về PRD của bạn
  • ✅ pomodoro-brief.md — warm-up
  • ✅ Tất cả đã push lên repo cá nhân + mở PR cho mentor review

✅ Trước khi bắt đầu — checklist

🗺️ Bảng tra “Project Context” — tìm dòng đề bạn đã chọn ở Buổi 1

Cả notebook này dùng 5 placeholder: {ENTITY}, {ACTOR_PRIMARY}, {ACTOR_SECONDARY}, {DOMAIN}, {PAIN_PRIMARY}. Trước khi vào Step 01, bạn copy dòng đề mình ra giấy nhớ dán cạnh màn hình.

# Đề {ENTITY} {ACTOR_PRIMARY} {ACTOR_SECONDARY} {DOMAIN} {PAIN_PRIMARY}
Demo của mentor HRIS employee HR manager department head HR / nhân sự nội bộ “hồ sơ nhân viên rải rác, không biết ai đang onboard đến bước nào”
1 HireFlow Lite candidate recruiter hiring manager HR / tuyển dụng SMB “CV rải rác qua Gmail/Zalo, quên reply ứng viên”
2 PipeTrack deal sales rep sales manager B2B sales nhỏ “Excel deal bị sửa đè, quên follow-up”
3 ShipBoard order warehouse staff customer (tracking) logistics / e-com “khách hỏi ‘đơn em tới đâu’ không trả lời được”
4 Content Cal post content writer marketing manager marketing multi-channel “lên lịch post Sheets thô, post sai giờ”
5 ExpenseFlow expense request nhân viên đề xuất accountant + line manager finance / kế toán “đề xuất chi đang ở đâu trong chuỗi duyệt?”
6 MeetRoom booking nhân viên đặt phòng office admin hành chính văn phòng “trùng lịch phòng họp, hỏi nhau qua Zalo”
7 TrainTrack course enrollment nhân viên học L&D specialist đào tạo nội bộ “nhiều file Excel rời rạc, mất nửa ngày tổng hợp”
9 StockRoom inventory item warehouse staff purchasing kho văn phòng phẩm “tồn kho VLOOKUP lỗi, không cảnh báo hết hàng”
10 TaskSprint task developer / contributor team lead project management team nhỏ “không thấy ai đang quá tải”

⚠️ Nếu đề bạn không nằm trong bảng → bạn đã chọn sai/đổi đề trái phép. Quay lại Discord #project-pick ngay.

📚 PHẦN 1 — Brainstorming (Step 01–08, ~1h)

Tổng quan phần 1: Dùng kỹ thuật SCAMPER (Substitute, Combine, Adapt, Modify, Put-to-other-use, Eliminate, Reverse) để liệt kê 15 tính năng tiềm năng cho đề của bạn. Mục đích không phải chọn cái nào, mà mở rộng không gian giải pháp trước khi đóng khung MVP.

Bước 01/35: Khởi tạo phiên Brainstorming

Mục tiêu: Mở session bmad-brainstorming đúng cách, không nhảy thẳng vào ý tưởng.

Hành động: 1. Mở Cursor / Claude Code, vào thư mục dự án. 2. Tạo thư mục mới: mkdir week-02-brief && cd week-02-brief. 3. Gõ prompt mở phiên: Tôi muốn dùng bmad-brainstorming để generate ý tưởng tính năng cho một sản phẩm. Hãy bắt đầu phiên session-setup giúp tôi. 4. Skill bmad-brainstorming sẽ chạy step-01-session-setup.md và hỏi bạn 3–4 câu setup (chủ đề, mục tiêu, deliverable mong muốn).

Áp dụng cho đề của bạn: Khi BMAD hỏi “Chủ đề brainstorming là gì?”, trả lời: > “Một ứng dụng quản lý {ENTITY} cho {ACTOR_PRIMARY} trong {DOMAIN}, giải quyết pain point chính: {PAIN_PRIMARY}.”

Ví dụ mentor đang chạy trên HRIS: > “Một ứng dụng quản lý hồ sơ nhân viên cho HR manager trong quản lý nhân sự nội bộ, giải quyết pain point chính: hồ sơ nhân viên rải rác, không biết ai đang onboard đến bước nào.” > → Xem commit hris-demo/buoi-02/step-01.

Kết quả mong đợi: AI trả lời bằng file brainstorm-session-init.md chứa: chủ đề chốt + mục tiêu chốt + deliverable chốt.

Nếu kẹt: - AI bỏ qua step setup → ép lại: “Hãy chạy step-01 trong workflow.md của bmad-brainstorming trước khi đi tiếp.” - AI hỏi quá nhiều → trả lời ngắn gọn, đừng kể lể.

Checkpoint: Có file brainstorm-session-init.md với 3 trường được điền đầy đủ.

Bước 02/35: Phát biểu Problem Statement chuẩn

Mục tiêu: Viết 1 câu Problem Statement đúng template “User—Need—Insight” trước khi sinh ý tưởng. Tránh việc brainstorm ra 15 ý tưởng nhưng giải sai bài toán.

Hành động: 1. Gõ prompt: Trước khi đi vào kỹ thuật brainstorming, giúp tôi viết Problem Statement theo template: "[User] cần [need] vì [insight], nhưng hôm nay họ [current workaround đau khổ]". Hỏi tôi từng phần. 2. Trả lời từng câu hỏi AI đặt ra, dùng dòng đề của bạn trong Bảng Project Context.

Áp dụng cho đề của bạn (ví dụ template điền sẵn): > “{ACTOR_PRIMARY} cần một cách quản lý {ENTITY} tập trung vì hiện tại họ {PAIN_PRIMARY}, nhưng hôm nay họ phải dùng Excel + Zalo thủ công, dẫn đến mất thời gian + sai sót.”

Ví dụ mentor (HRIS): > “HR manager cần một cách quản lý hồ sơ nhân viên tập trung vì hiện tại họ không biết nhân viên nào đang ở bước onboarding nào, nhưng hôm nay họ phải lùng email + Excel rời rạc, dẫn đến bỏ sót thông tin quan trọng.”

Kết quả mong đợi: File problem-statement.md 3 dòng.

Nếu kẹt: Problem Statement của bạn dài > 2 câu → AI đã không ép bạn cô đọng. Yêu cầu lại: “Cô đọng thành đúng 1 câu, tối đa 30 từ.”

Checkpoint: Đọc problem-statement.md to lên — nghe có giống pain thật không? Nếu cảm thấy “abstract quá”, quay lại playbook đồ án của bạn để bắt được nỗi đau cụ thể hơn.

Bước 03/35: Chọn kỹ thuật SCAMPER

Mục tiêu: Yêu cầu BMAD chạy đúng kỹ thuật SCAMPER (1 trong ~60 phương pháp brainstorming).

Hành động: 1. Gõ prompt: Bây giờ chạy step-02a-user-selected: tôi muốn dùng kỹ thuật SCAMPER. Áp dụng SCAMPER lên Problem Statement vừa viết. Tôi sẽ trả lời từng trong 7 chữ S-C-A-M-P-E-R, không nhảy cóc. 2. BMAD sẽ chạy step-03-technique-execution.md và lần lượt hỏi 7 góc nhìn.

Áp dụng cho đề của bạn: Mỗi chữ trong SCAMPER áp vào {ENTITY} của bạn: - Substitute: Thay {ENTITY} bằng cái gì khác? (vd. Thay “deal” bằng “opportunity”? Thay “ticket” bằng “incident”?) - Combine: Gộp {ENTITY} với khái niệm nào? (vd. Gộp “order” + “shipment” thành “fulfillment”?) - Adapt: Mượn ý tưởng từ ngành khác? (vd. Mượn “Kanban” của Toyota?) - Modify: Phóng to / thu nhỏ thuộc tính nào của {ENTITY}? - Put-to-other-use: {ENTITY} còn dùng cho mục đích nào khác? - Eliminate: Bỏ thuộc tính nào của {ENTITY} thì sản phẩm vẫn dùng được? - Reverse: Đảo ngược thứ tự nào trong luồng?

Ví dụ mentor (HRIS, chỉ chữ S): > “Substitute: Thay ‘hồ sơ nhân viên’ bằng ‘contractor profile’ → mở rộng cho freelancer/CTV. Thay ‘HR manager nhập tay’ bằng ‘AI auto-fill’ → tự động điền thông tin từ CV upload.”

Kết quả mong đợi: AI trả 7 câu hỏi tuần tự, bạn trả lời từng câu trong 5–10 phút.

Nếu kẹt: Bí chữ nào → trả lời “skip” → AI tự generate gợi ý cho bạn pick.

Checkpoint: Có 7 ô SCAMPER được điền, mỗi ô ít nhất 2 ý.

Bước 04/35: Lấy 5 ý tưởng cho S + C

Mục tiêu: Khoanh tròn được 5 ý tưởng “có vẻ” làm được cho 2 chữ đầu (Substitute, Combine).

Hành động: 1. Gõ prompt: Từ 7 ô SCAMPER, giúp tôi rút ra 5 ý tưởng feature đầu tiên — ưu tiên các ý từ Substitute và Combine. Mỗi ý 1 câu (≤ 15 từ), kèm 1 chú thích ngắn "có thể làm trong MVP?". Áp dụng cho đề của bạn: Đọc lại các ô S, C bạn đã trả lời → AI sẽ rút 5 ý.

Ví dụ mentor (HRIS): - “Auto-tag nhân viên theo phòng ban khi tạo hồ sơ — MVP yes.” - “Gộp hồ sơ + onboarding checklist vào 1 trang employee detail — MVP yes.” - “Cho phép nhân viên xem và cập nhật thông tin cá nhân của mình — MVP yes.” - “Slack-bot báo nhân viên mới onboard — MVP no, để phase 2.” - “AI phân tích hiệu suất từ hồ sơ — MVP no, quá phức tạp.”

Kết quả mong đợi: 5 dòng feature, mỗi dòng có “MVP yes/no”.

Nếu kẹt: AI list nhiều > 5 → “Giảm xuống đúng 5, prioritize impact cao nhất.”

Checkpoint: ≥ 3/5 dòng có “MVP yes”.

Bước 05/35: Lấy 5 ý tưởng cho A + M

Mục tiêu: Tương tự Bước 04, nhưng tập trung vào Adapt + Modify.

Hành động: Lặp prompt Bước 04, đổi “Substitute và Combine” thành “Adapt và Modify”.

Áp dụng: Adapt thường ra ý “mượn pattern từ ngành khác”. Modify thường ra ý “phóng to/thu nhỏ thuộc tính”.

Ví dụ mentor (HRIS): - “Mượn ‘Kanban stages’ từ Trello (New → In Progress → Done) cho onboarding checklist — MVP yes, dùng 4 bước.” - “Modify ‘ngày vào làm’ = hiển thị countdown ‘còn X ngày để hoàn thành onboarding’ — MVP yes.” - “Mượn ‘Employee of the Month’ của HR truyền thống — MVP no, phase 2.”

Checkpoint: Thêm 5 dòng, lý tưởng tổng đã có 10 ý.

Bước 06/35: Lấy 5 ý tưởng cho P + E + R

Mục tiêu: Hoàn tất 15 ý tưởng tổng bằng 3 chữ cuối (Put-to-other-use, Eliminate, Reverse).

Hành động: Lặp prompt, “Put-to-other-use, Eliminate, và Reverse”.

Lưu ý quan trọng: Eliminate thường ra ý âm (“Bỏ tính năng X”) — đây cực kỳ giá trị để định nghĩa Out-of-scope ở Bước 32.

Ví dụ mentor (HRIS): - “Eliminate: Bỏ upload nhiều loại file — chỉ PDF/JPG — MVP yes.” - “Eliminate: Bỏ approval workflow phức tạp — HR tự duyệt trực tiếp — MVP yes.” - “Reverse: Nhân viên không chờ HR nhập liệu, tự điền form onboarding trước ngày vào làm — MVP no, phase 2.”

Checkpoint: Có tổng 15 ý — lưu vào file 15-feature-candidates.md.

Bước 07/35: Phân nhóm 15 ý theo MoSCoW

Mục tiêu: Áp khung MoSCoW (Must / Should / Could / Won’t) lên 15 ý.

Hành động: 1. Gõ prompt: Đọc file 15-feature-candidates.md. Phân nhóm 15 ý theo MoSCoW. Bắt buộc: - Must: 4–5 ý (cốt lõi để MVP có giá trị) - Should: 3–4 ý (đáng có nhưng dời được) - Could: 3–4 ý (nice-to-have) - Won't (phase 1): 3–4 ý (cố tình loại để giữ scope) Output: file moscow.md với 4 section.

Áp dụng cho đề của bạn: MoSCoW phải đối chiếu lại pain point chính {PAIN_PRIMARY} của bạn — Must thực sự must là gì.

Ví dụ mentor (HRIS, chỉ Must): - M1: Tạo hồ sơ nhân viên (form có validation) - M2: Danh sách nhân viên với filter (phòng ban, status) - M3: Onboarding checklist theo từng nhân viên - M4: Cập nhật thông tin hồ sơ - M5: Deadline onboarding + cảnh báo trễ hạn

Kết quả mong đợi: moscow.md 15 dòng phân thành 4 section.

Checkpoint: Tổng Must + Should ≤ 9 ý — nếu > 9 là bạn đang scope creep, ép AI cắt.

Bước 08/35: Tổng kết phiên Brainstorming

Mục tiêu: Tổng hợp lại thành 1 file gọn để feed vào bmad-product-brief ở Bước 09.

Hành động: 1. Gõ prompt: Chạy step-04-idea-organization của bmad-brainstorming. Output 1 file tổng kết tên brainstorm-summary.md, chứa: Problem Statement, top 5 ý Must, top 3 ý Should, và 4 ý Won't (out-of-scope dự kiến).

Checkpoint: Có file brainstorm-summary.md ≤ 30 dòng. Đây là input chính cho Phần 2.

📚 PHẦN 2 — Product Brief (Step 09–15, ~1.5h)

Tổng quan phần 2: Dùng skill bmad-product-brief (/Users/dz/cowork/.claude/skills/bmad-product-brief/) để biến brainstorm thành Product Brief có cấu trúc, đã qua 2 lớp phản biện (skeptic + opportunity reviewer).

Bước 09/35: Khởi tạo bmad-product-brief

Mục tiêu: Triệu hồi skill với input đã có sẵn.

Hành động: 1. Gõ prompt: Chạy bmad-product-brief. Input: brainstorm-summary.md. Bắt đầu từ contextual-discovery rồi sang guided-elicitation. Tôi sẽ trả lời từng câu hỏi. 2. BMAD sẽ chạy theo prompts/contextual-discovery.md.

Áp dụng cho đề của bạn: Khi AI hỏi “Đối tượng người dùng chính là ai?” → trả lời chính xác {ACTOR_PRIMARY} của bạn, không trả lời “mọi nhân viên” (quá rộng).

Ví dụ mentor (HRIS): “Đối tượng chính: HR manager, 28–45 tuổi, làm việc trong công ty 30–200 người, đang dùng Excel + email để quản lý hồ sơ nhân viên.”

Checkpoint: AI đã nắm được 3 thông tin: Persona / Pain / Context.

Bước 10/35: Contextual Discovery — Persona sâu

Mục tiêu: Đào thật sâu 1 Persona — đừng dừng ở “agent” mà tả được “agent điển hình là Hoàng, 28 tuổi, đang dùng Excel + sticky note”.

Hành động: 1. Khi AI hỏi về Persona, đáp như sau: Hãy hỏi tôi 5 câu liên tiếp để vẽ ra một Persona cụ thể (có tên, tuổi, tools đang dùng, frustration lớn nhất, định nghĩa "thành công" của họ trong 1 ngày làm việc).

Áp dụng cho đề của bạn: Trả lời theo {ACTOR_PRIMARY}. Đặt tên Persona là tên tiếng Việt cụ thể (Lan, Hoàng, Mai…) — sẽ giúp bạn nhớ dễ hơn ở Bước 19 khi John phỏng vấn.

Ví dụ mentor: “Linh, 32, HR manager cty 80 người. Tools: Google Sheets + Drive + Zalo. Frustration: ‘Nhân viên mới vào không biết cần nộp giấy tờ gì, hỏi Zalo liên tục’. Thành công 1 ngày: hoàn thành onboarding đúng checklist cho ≥ 2 nhân viên mới.”

Checkpoint: File persona.md có đủ 5 trường trên.

Bước 11/35: Guided Elicitation — Goals & Constraints

Mục tiêu: Liệt kê 3 Goals đo được + 3 Constraints (time, budget, kỹ thuật).

Hành động: 1. Gõ prompt: Chuyển sang prompts/guided-elicitation. Hỏi tôi về Goals (đo được) và Constraints. Goals phải có con số. Constraints phải có ngày/tiền cụ thể.

Áp dụng cho đề của bạn: Goals đo được — ví dụ: - “Giảm 50% thời gian xử lý 1 {ENTITY}” - “Hoàn thành MVP trong 4 tuần” - “Free tier cho ≤ 20 user nội bộ”

Ví dụ mentor (HRIS): “Goal: tỷ lệ onboarding hoàn thành đúng hạn ≥ 85%; Constraint: chi phí = 0 (free tier Supabase + Vercel).”

Checkpoint: File goals-constraints.md đủ 3+3 dòng, mọi Goal có con số.

Bước 12/35: Draft Product Brief lần 1

Mục tiêu: Có bản nháp Product Brief đầu tiên — chưa sửa, chỉ để 2 reviewer cắn.

Hành động: 1. Gõ prompt: Chạy prompts/draft-and-review. Sinh bản nháp product-brief-v1.md theo template resources/brief-template.md. Tuyệt đối ngắn — toàn bộ ≤ 1 trang A4. 2. Mở file kết quả, đọc to lên — nghe có “fluff” không (từ kiểu “đột phá”, “tối ưu trải nghiệm”)?

Áp dụng cho đề của bạn: Mọi câu trong brief phải nêu được tên {ENTITY} ít nhất 1 lần. Nếu brief quá generic (đọc lên thấy có thể là bất kỳ app nào) → bạn đang viết sai.

Checkpoint: product-brief-v1.md xuất hiện, ≤ 60 dòng markdown.

Bước 13/35: Skeptic Review — gắt nhất

Mục tiêu: Triệu hồi agents/skeptic-reviewer.md đập brief.

Hành động: 1. Gõ prompt: Chạy agent skeptic-reviewer (trong .claude/skills/bmad-product-brief/agents/ skeptic-reviewer.md). Đập product-brief-v1.md không thương tiếc. Tìm 5 lỗ hổng nghiêm trọng nhất: assumption chưa kiểm chứng, metric mơ hồ, persona quá rộng, scope phình to, competitor đã làm rồi.

Áp dụng: Đọc skeptic feedback bằng tư duy “Tôi sai chỗ nào?” thay vì “Phản biện lại”. Mỗi đập đều có lý do.

Ví dụ mentor (HRIS): Skeptic phát hiện “Goal ‘onboarding đúng hạn 85%’ — sao biết 85% chứ không phải 70%? Có data baseline chưa?” → mentor phải sửa Goal thành “Onboarding đúng hạn 85% (baseline hiện tại: 60% — từ khảo sát 10 nhân viên mới gần nhất).”

Checkpoint: File skeptic-feedback.md có ≥ 5 đập rõ ràng.

Bước 14/35: Opportunity Review — góc nhìn ngược lại

Mục tiêu: Triệu hồi agents/opportunity-reviewer.md tìm cơ hội mở rộng (cẩn thận: cơ hội ≠ scope creep!).

Hành động: 1. Gõ prompt: Chạy agent opportunity-reviewer. Đọc product-brief-v1.md + skeptic-feedback.md. Tìm 3 cơ hội bị bỏ lỡ (có thể là segment, tính năng, kênh phân phối). Mỗi cơ hội kèm note "phase 1 hay phase 2".

Lưu ý: Cơ hội đa số nên ở phase 2, không phải nhét vào MVP. Đây là kỷ luật.

Ví dụ mentor (HRIS): Opportunity tìm ra “Có thể mở rộng thành self-service portal cho nhân viên tự xem và cập nhật thông tin cá nhân → giảm tải HR team × 3 lần.” Nhưng note “phase 2”.

Checkpoint: File opportunity-feedback.md có ≥ 3 cơ hội với phase label.

Bước 15/35: Finalize Product Brief

Mục tiêu: Trộn 2 feedback → bản product-brief.md final, lưu thành deliverable Phần 2.

Hành động: 1. Gõ prompt: Chạy prompts/finalize. Merge product-brief-v1.md + skeptic-feedback.md (sửa các đập gắt) + opportunity-feedback.md (chỉ note cơ hội phase 2 ở cuối brief, không thêm vào MVP). Output: product-brief.md final, tuyệt đối ≤ 1 trang A4.

Áp dụng: Đếm dòng cuối (wc -l product-brief.md) — phải ≤ 70 dòng markdown (~ 1 trang A4 in).

Kết quả mong đợi: Có file product-brief.md chuyên nghiệp, ai đọc cũng hiểu trong 3 phút.

Checkpoint: Đưa file cho buddy đọc trong Discord. Buddy hiểu được Persona + Pain + MVP scope trong < 3 phút → pass.

📚 PHẦN 3 — John phỏng vấn ngược (Step 16–25, ~1.5h)

Tổng quan phần 3: Triệu hồi bmad-agent-pm (John). John sẽ phỏng vấn ngược bạn — hỏi “Why?” liên tục 8–12 câu để làm rõ những giả định mơ hồ trong Product Brief. Đây là step quan trọng nhất tuần này.

Bước 16/35: Triệu hồi John

Mục tiêu: Đưa John “vào vai” trước khi đặt câu hỏi đầu tiên.

Hành động: 1. Gõ prompt: Chạy bmad-agent-pm. Bạn là John (xem .claude/skills/bmad-agent-pm/SKILL.md). Đọc product-brief.md của tôi. Sau đó, hỏi tôi 8–12 câu phỏng vấn ngược theo style "ask WHY relentlessly". Không tổng kết, không đề xuất — chỉ hỏi.

Lưu ý: Nếu John bắt đầu nhả tổng kết / khuyên → cắt: “Stay in character. Chỉ hỏi, không khuyên.”

Checkpoint: John đặt câu hỏi đầu tiên. Nếu là câu kiểu “Tôi đã hiểu, bạn muốn tôi giúp gì?” → chưa vào vai, ép lại.

Bước 17/35: Trả lời 3 câu đầu của John

Mục tiêu: Trả lời thành thật, không bịa data.

Hành động: John sẽ hỏi 3 câu kiểu này (mẫu, sẽ khác cho từng đề): - “Tại sao {ACTOR_PRIMARY} chưa giải quyết vấn đề này bằng tool A/B/C đã có?” - “Bạn lấy con số [Goal X%] từ đâu? Có user research nào không?” - “Persona <tên> của bạn có thật không, hay là composite?”

Áp dụng cho đề của bạn: Trả lời ngắn (3–5 câu). Nếu bạn không biết → nói “tôi không biết” thay vì bịa. John sẽ giúp tìm cách verify.

Ví dụ mentor (HRIS): > John hỏi: “Tại sao HR không dùng BambooHR / Workday?” > Mentor: “Vì BambooHR đắt (~$6/user/tháng × 50 nhân viên = $300/tháng, SMB không có ngân sách). Workday dành cho enterprise. Giải pháp hiện tại là Google Sheets + email — không tracking được tiến độ onboarding.” > John: “Vậy thì sản phẩm của bạn cạnh tranh trực tiếp với ‘không dùng gì’ chứ không phải BambooHR. Bạn có chắc HR manager sẽ rời ‘Sheets + Zalo’ để học tool mới không?” > → Câu này đáng giá hơn cả khoá học UX trả tiền!

Checkpoint: Đã trả 3 câu đầu, mỗi câu < 100 từ.

Bước 18/35: Trả lời 3 câu tiếp theo

Mục tiêu: Tiếp tục trả lời, ghi nhận câu nào làm bạn “nói lắp” — đó là câu sẽ cần kiểm chứng thực tế.

Hành động: Tương tự Bước 17. Các câu tầm này thường khoét sâu vào acceptance criteria, success metric, edge case.

Lưu ý: Mỗi khi nói lắp → mở một file assumptions-to-verify.md và ghi: “Câu hỏi X của John, tôi không có data → cần verify bằng [cách Y].”

Ví dụ mentor: “Cần verify ‘HR manager thực sự muốn nhận cảnh báo onboarding trễ hạn’ — sẽ phỏng vấn 3 HR manager thật trong tuần 3.”

Checkpoint: File assumptions-to-verify.md có ≥ 2 giả định cần kiểm chứng.

Bước 19/35: John đào “Hardest user case”

Mục tiêu: John sẽ hỏi “Trường hợp user khó chiều nhất là gì?” — ép bạn nghĩ về edge case sớm.

Hành động: Khi John hỏi, đáp theo công thức: > “User khó chiều nhất là <persona phụ>, vì họ <động cơ ngược>. Họ sẽ phá MVP bằng cách <hành vi cụ thể>.”

Áp dụng cho đề của bạn: - HireFlow Lite: Hiring Manager bận, không vào app comment → workaround: app email họ link inline reply. - PipeTrack: Sales rep ghét nhập data → workaround: auto-import từ Gmail. - ShipBoard: Khách hàng không nhớ mã đơn → workaround: tra cứu bằng SĐT cuối 4 số. - ExpenseFlow: Trưởng phòng quên duyệt → workaround: nhắc email mỗi 24h.

Ví dụ mentor (HRIS): “Nhân viên mới không biết cần nộp giấy tờ gì, upload sai file → workaround: mỗi bước onboarding có tooltip mô tả yêu cầu + ví dụ file mẫu.”

Checkpoint: File hardest-user-case.md có 1 persona phụ + 1 workaround.

Bước 20/35: John đào “Success in 90 days”

Mục tiêu: John hỏi “Sau 90 ngày launch, dấu hiệu nào cho bạn biết app này thành công?” — ép bạn đo được, không phải mơ hồ “cải thiện trải nghiệm”.

Hành động: Trả lời theo công thức: > “Sau 90 ngày, nếu app thành công: (1) <số liệu adoption>, (2) <số liệu retention>, (3) <số liệu impact>.”

Áp dụng cho đề của bạn: Mỗi số đều phải có baseline so sánh + mục tiêu cụ thể.

Ví dụ mentor (HRIS): “(1) Adoption: HR manager login ≥ 4/5 ngày làm việc/tuần (baseline: 0). (2) Retention: tuần 12 vẫn dùng (đo bằng login activity). (3) Impact: tỷ lệ onboarding đúng hạn ≥ 85% (baseline: 60% — từ khảo sát nhân viên gần nhất).”

Checkpoint: File success-90-days.md có 3 metrics với baseline + target.

Bước 21/35: John challenge MVP scope

Mục tiêu: John sẽ ép bạn cắt MVP nhỏ hơn nữa. Theo nguyên tắc của John: “Ship the smallest thing that validates the assumption.”

Hành động: Khi John bảo “MVP của bạn vẫn to. Cắt còn 60%”, bạn: 1. Đem MoSCoW (file moscow.md ở Bước 07) ra. 2. Cho phép John gạch 2 ý từ Must xuống Should. 3. Đừng cãi — chỉ note lại “Lý do được Must là gì” cho lần đối thoại sau.

Ví dụ mentor (HRIS): John gạch “M5 Deadline onboarding + cảnh báo trễ hạn” → xuống Should. Lý do: “MVP cần validate là ‘HR manager có dùng app để quản lý hồ sơ hàng ngày không?’ — cảnh báo deadline chỉ nice-to-have, không quyết định adoption ban đầu.”

Checkpoint: File moscow-v2.md có 3 Must (giảm từ 5). Đau lòng nhưng đúng.

Bước 22/35: John challenge Success Metrics

Mục tiêu: John sẽ chất vấn “Metric của bạn lag indicator hay leading indicator?”

Hành động: Khi John hỏi, kiểm tra từng metric: - Lag (đo sau khi xảy ra): retention, NPS, revenue. - Leading (báo trước): adoption tuần 1, daily active.

Đảm bảo có ít nhất 1 leading indicator để biết app đang đúng hướng trước 90 ngày.

Ví dụ mentor: Bổ sung “Leading: ≥ 2 hồ sơ nhân viên được tạo/tuần trong tháng đầu launch.”

Checkpoint: success-90-days.md được cập nhật v2 với 1 leading + 2 lag.

Bước 23/35: John định nghĩa Out-of-scope rõ

Mục tiêu: Buộc John liệt kê 5 thứ không làm (để chống scope creep sau này).

Hành động: 1. Gõ prompt: John, dựa vào toàn bộ đối thoại của chúng ta, liệt kê 5 thứ rõ ràng KHÔNG nằm trong MVP của tôi — kèm lý do tại sao loại.

Áp dụng cho đề của bạn: 5 thứ Out-of-scope nên gồm cả các “cám dỗ” rõ ràng (AI feature, mobile app, SSO, multi-language, white-label).

Ví dụ mentor (HRIS): “Out: (1) AI phân tích CV tự động, (2) mobile app native, (3) integration Slack/email tự động, (4) payroll/bảng lương, (5) performance review module — phase 2.”

Checkpoint: File out-of-scope.md có 5 dòng + lý do.

Bước 24/35: Đóng phiên John

Mục tiêu: Yêu cầu John tổng kết “3 điểm bạn cần fix trong PRD”.

Hành động: 1. Gõ prompt: John, đóng phiên phỏng vấn. Tổng kết đúng 3 điểm tôi cần fix trong Product Brief trước khi sang viết PRD. Mỗi điểm 1 câu.

Áp dụng: 3 điểm này sẽ là “công việc bắt buộc” trước Bước 26.

Checkpoint: File john-summary.md có 3 fix items.

Bước 25/35: Cập nhật Product Brief lần cuối

Mục tiêu: Sửa product-brief.md theo 3 điểm John tổng kết.

Hành động: 1. Gõ prompt: Đọc john-summary.md. Cập nhật product-brief.md để fix đúng 3 điểm này. Giữ tuyệt đối ≤ 1 trang A4. Tạo bản v2. 2. Diff với bản v1 để chắc chắn không phình.

Checkpoint: product-brief.md được commit lần 2 với message: docs(brief): apply John's feedback.

📚 PHẦN 4 — Tạo PRD chính thức (Step 26–32, ~1.5h)

Tổng quan phần 4: Dùng bmad-create-prd (.claude/skills/bmad-create-prd/) để biến Product Brief thành PRD chuẩn BMAD (có Discovery, Vision, Executive Summary, Journeys, Functional reqs).

Bước 26/35: Khởi tạo bmad-create-prd

Mục tiêu: Mở bmad-create-prd với input là Product Brief đã hoàn thiện.

Hành động: 1. Gõ prompt: Chạy bmad-create-prd. Input: product-brief.md (v2). Đi qua tất cả các step trong steps-c/ tuần tự, không nhảy cóc. Bắt đầu từ step-01.

Lưu ý: Skill này có ≥ 9 step (step-01b-continue, step-02-discovery, step-02b-vision, …, step-09-functional). Mỗi step ngắn nhưng đừng skip.

Checkpoint: AI in ra “Starting step-01…” — vào flow.

Bước 27/35: Discovery (step-02)

Mục tiêu: Khẳng định lại Problem + Persona + Goals ở định dạng PRD chính thức.

Hành động: AI sẽ hỏi 4–5 câu confirm. Trả lời nhanh — dữ liệu đã có sẵn từ Phần 2 + 3.

Áp dụng cho đề của bạn: Copy-paste từ problem-statement.md + persona.md + goals-constraints.md.

Checkpoint: Section “Discovery” trong PRD đã được điền.

Bước 28/35: Vision (step-02b)

Mục tiêu: Viết 1 câu Vision Statement — Northstar của app.

Hành động: Trả lời theo template: > “Trở thành cách đơn giản nhất để {ACTOR_PRIMARY} quản lý {ENTITY} trong {DOMAIN} — không cần Excel, không cần training.”

Ví dụ mentor (HRIS): “Trở thành cách đơn giản nhất để HR manager quản lý hồ sơ nhân viên trong cty SMB — không BambooHR đắt đỏ, không Google Sheets rời rạc.”

Checkpoint: Section “Vision” có 1 câu < 25 từ.

Bước 29/35: Executive Summary (step-02c)

Mục tiêu: Section đầu PRD — sếp đọc 30 giây hiểu app.

Hành động: AI sẽ tự sinh từ Vision + Discovery. Đọc và sửa chỉ những chỗ AI bịa.

Áp dụng: Đảm bảo trong 5 dòng đầu có cả: tên app + Persona + Pain + Approach + Differentiator.

Checkpoint: Section “Executive Summary” ≤ 8 dòng.

Bước 30/35: User Journeys (step-04)

Mục tiêu: Vẽ luồng người dùng cho 3 use case chính, dạng numbered steps.

Hành động: 1. Gõ prompt: Chạy step-04-journeys. Sinh 3 journey: J1: <happy path chính của ACTOR_PRIMARY> J2: <happy path của ACTOR_SECONDARY> J3: <error/edge case path> Mỗi journey 5–8 step. Dùng Mermaid nếu cần.

Áp dụng cho đề của bạn: Mỗi đề có 3 journey khác nhau, xem playbook đề bạn để biết journey nào quan trọng.

Ví dụ mentor (HRIS): - J1: HR tạo hồ sơ nhân viên mới: vào trang Add Employee → điền thông tin → gắn phòng ban → tạo onboarding checklist → lưu. - J2: HR theo dõi tiến độ onboarding: mở danh sách → lọc “In Progress” → xem checklist từng nhân viên → đánh dấu hoàn thành từng bước. - J3: Edge — onboarding quá hạn: deadline qua → highlight đỏ trong danh sách → HR nhận cảnh báo → cập nhật trạng thái.

Checkpoint: Section “User Journeys” có 3 journey, mỗi cái có numbered list.

Bước 31/35: Functional Requirements (step-09)

Mục tiêu: List các yêu cầu function dạng “Hệ thống PHẢI / NÊN / CÓ THỂ” + Acceptance Criteria.

Hành động: 1. Gõ prompt: Chạy step-09-functional. Sinh 10–15 Functional Requirement đánh số FR-01...FR-15. Mỗi FR theo template: - ID: FR-01 - Statement: "Hệ thống PHẢI <hành động đo được>" - Acceptance: ≥ 2 acceptance criteria - Priority: Must / Should / Could (lấy từ moscow-v2.md)

Áp dụng cho đề của bạn: FR-01 luôn là tạo {ENTITY} (CRUD Create). FR cuối luôn là Out-of-scope reference.

Ví dụ mentor (HRIS, 3 FR đầu): - FR-01: Hệ thống PHẢI cho phép HR manager tạo hồ sơ nhân viên mới với các trường bắt buộc (tên, phòng ban, ngày vào làm). - FR-02: Hệ thống PHẢI hiển thị danh sách nhân viên với filter theo phòng ban và trạng thái onboarding. - FR-03: Hệ thống NÊN highlight đỏ nhân viên có onboarding checklist chưa hoàn thành quá deadline.

Checkpoint: Section “Functional Requirements” có 10–15 FR, đánh số sạch.

Bước 32/35: Tổng hợp + Validate PRD

Mục tiêu: Xuất PRD.md final + chạy bmad-validate-prd (nếu có).

Hành động: 1. Gõ prompt: Tổng hợp tất cả section đã làm thành PRD.md final. Cấu trúc: 1. Executive Summary 2. Problem & Persona 3. Vision 4. Goals & Success Metrics (lag + leading) 5. MVP Scope (Must) + Out-of-scope 6. User Journeys (3 journeys) 7. Functional Requirements (10–15 FR) Tuyệt đối ≤ 1 trang A4 in (~120 dòng markdown). Sau đó chạy bmad-validate-prd để check thiếu sót. 2. Đếm dòng (wc -l PRD.md) — nếu > 130 dòng, ép AI cắt.

Checkpoint: PRD.md final đã commit, validate pass.

📚 PHẦN 5 — Party Mode phản biện chéo (Step 33–35, ~30’)

Tổng quan phần 5: Mời 3 nhân vật BMAD (John = PM, Sally = UX, Winston = Architect) vào “phòng họp ảo” cãi nhau về PRD của bạn. Skill: bmad-party-mode (.claude/skills/bmad-party-mode/).

Bước 33/35: Khởi tạo Party Mode

Mục tiêu: Mở phòng họp 3 agent chạy song song độc lập.

Hành động: 1. Gõ prompt: Chạy bmad-party-mode. Invite: John (PM), Sally (UX Designer), Winston (Architect). Đề tài tranh luận: PRD.md của tôi vừa hoàn thành. Yêu cầu mỗi người đọc xong tự đưa ra 2 phản biện gay gắt nhất từ góc nhìn của họ. Không đồng hoá tư duy.

Lưu ý: Party Mode có thể chạy 3 instance song song. Đừng để 1 instance trả lời cho cả 3.

Checkpoint: Có 3 block phản biện riêng biệt từ John, Sally, Winston.

Bước 34/35: Capture Debate

Mục tiêu: Ghi log cãi nhau vào party-mode-debate.md.

Hành động: 1. Gõ prompt: Tổng hợp toàn bộ debate vào file party-mode-debate.md. Cấu trúc: ## John (PM) phản biện - 2 phản biện ## Sally (UX) phản biện - 2 phản biện ## Winston (Architect) phản biện - 2 phản biện ## 5 phản biện gay gắt nhất (mức ưu tiên fix) - Top 5

Ví dụ mentor (HRIS, 1 phản biện thật): > Winston: “Bạn nói ‘Magic Link login’ cho HR manager, nhưng FR-07 lại cho phép nhân viên xem checklist onboarding của mình. Vậy hai loại user này có cùng auth flow không? Nếu không, cần 2 role khác nhau trong DB — chưa định nghĩa rõ là sẽ vỡ schema.” > → Mentor sửa: “HR manager login bằng Magic Link (có tài khoản); nhân viên xem checklist qua link token gắn với employee_id — không cần tài khoản riêng trong phase 1.”

Checkpoint: party-mode-debate.md có ≥ 5 phản biện gay gắt.

Bước 35/35: Cập nhật PRD theo Top 5 phản biện

Mục tiêu: Sửa PRD.md lần cuối, commit clean.

Hành động: 1. Gõ prompt: Đọc party-mode-debate.md. Cập nhật PRD.md để fix Top 5 phản biện gay gắt nhất. Mỗi fix kèm 1 comment markdown "<!-- Fix from <Agent> -->". Giữ tuyệt đối ≤ 1 trang A4. 2. Commit cuối: docs(prd): apply party-mode feedback (v3). 3. Push lên repo + mở PR cho mentor review.

Checkpoint cuối tuần: - [ ] PRD.md có 5 comment <!-- Fix from ... -->. - [ ] PR đã mở trên GitHub. - [ ] Đã đăng update vào kênh Zalo #wins (Google Classroom hoặc Zalo nhóm khoá).

🎨 Warm-up exercise: Product Brief cho Pomodoro Timer (≤ 1.5h)

Tách rời khỏi đề chính — để bạn thử cảm giác viết brief mà không áp lực.

Yêu cầu: 1. Mở thư mục mới warmup-week-02/. 2. Lặp chỉ Phần 2 (Step 09–15) với đề tưởng tượng: “Pomodoro Timer cá nhân có báo cáo cuối ngày”. 3. Persona: chính bạn — sinh viên / freelancer. 4. Time: ≤ 1.5h tổng.

Deliverable: pomodoro-brief.md (≤ 1 trang).

Note: Đừng đầu tư > 1.5h — đây chỉ là cảm giác, không phải đồ án thật.

📦 Tổng kết Deliverable cuối tuần 2

Trong repo week-02-brief/, bạn cần có:

week-02-brief/
├── brainstorm-session-init.md
├── problem-statement.md
├── 15-feature-candidates.md
├── moscow.md
├── moscow-v2.md                ← sau khi John cắt
├── brainstorm-summary.md
├── persona.md
├── goals-constraints.md
├── product-brief-v1.md
├── skeptic-feedback.md
├── opportunity-feedback.md
├── product-brief.md            ← FINAL (sau Bước 25)
├── assumptions-to-verify.md
├── hardest-user-case.md
├── success-90-days.md
├── out-of-scope.md
├── john-summary.md
├── PRD.md                      ← FINAL (sau Bước 35)
├── party-mode-debate.md
└── pomodoro-brief.md           ← warm-up

19 file. Nghe nhiều nhưng đa số rất ngắn (< 30 dòng). Tổng thời gian: ~6h tự học + 1.5h warm-up = ~7.5h.

✅ Tiêu chí pass tuần 2 (cho mentor review PR)

# Tiêu chí Cách đo
1 PRD ≤ 1 trang A4 wc -l PRD.md ≤ 130 dòng
2 Có ≥ 5 fix comment từ Party Mode grep <!-- Fix from PRD.md
3 Success Metrics có baseline + target Section 4 PRD
4 Có ≥ 1 leading indicator Section 4 PRD
5 Out-of-scope có 5 dòng Section 5 PRD
6 Functional Reqs 10–15 cái đánh số Section 7 PRD
7 Persona có tên cụ thể (Hoàng, Lan, …) Section 2 PRD
8 Tất cả 19 file trong cấu trúc trên ls week-02-brief/
9 Pomodoro warm-up hoàn thành File pomodoro-brief.md tồn tại
10 PR mở + đăng #wins Zalo GitHub + Zalo activity

Pass ≥ 8/10 tiêu chí → đủ điều kiện vào Notebook tuần 3.

🆘 Kẹt ở đâu?

  • AI không “vào vai” John / Sally / Winston → quote lại đúng câu trong .claude/skills/bmad-agent-pm/SKILL.md, paste vào prompt.
  • Product Brief phình > 1 trang → bạn chưa cắt đủ. Quay lại Bước 21 (John cắt MoSCoW) và làm gắt hơn.
  • Bí ý SCAMPER chữ R (Reverse) → đảo vai trò: thay vì {ACTOR_PRIMARY} chủ động, để {ENTITY} đến tự động (vd. “ticket tự assign” thay vì “agent pick ticket”).
  • Party Mode chỉ ra 1 phản biện chung chung → ép từng agent: “Sally, bạn là UX designer — bạn không quan tâm schema. Đập vào màn hình Inbox của tôi: empty state thiếu gì?”
  • Buddy không phản hồi trong 24h → tag mentor trong Zalo #project-help, mentor sẽ pair lại.

🔮 Chuẩn bị cho tuần 3

Sau khi pass tuần 2, đọc trước: - nb03-readings/postgres-101.md (45’) - nb03-readings/next-app-router.md (45’) - nb03-readings/api-rest-basics.md (30’) - nb03-readings/ux-4-states.md (15’)

Tuần 3 sẽ vẽ schema + wireframe. PRD tuần 2 là input chính → giữ kỹ.

Notebook 02 — biên soạn theo curriculum V3 (2026-05-11). Skill folders dùng trong notebook: bmad-brainstorming, bmad-product-brief, bmad-agent-pm, bmad-create-prd, bmad-party-mode (/Users/dz/cowork/.claude/skills/).