Bộ 50 Prompt Quản lý Sản phẩm và Vận hành chuyên nghiệp

Thực tế thì, làm quản lý sản phẩm (Product Management) chưa bao giờ là một công việc dễ dàng. Hằng ngày, bạn phải đứng giữa hàng trăm yêu cầu từ ban giám đốc, các phản hồi dồn dập từ khách hàng, và áp lực bàn giao đúng hạn từ đội ngũ kỹ thuật. Thú thật là, nhiều lúc chúng ta cảm thấy kiệt sức chỉ vì phải viết đi viết lại những vé Jira, soạn thảo lộ trình phát triển (roadmap), hay tìm cách hòa giải những xung đột muôn thuở giữa thiết kế và lập trình.

Vấn đề là, sự xuất hiện của các mô hình trí tuệ nhân tạo như ChatGPT, Claude hay Gemini được kỳ vọng sẽ giải phóng sức lao động cho PM. Nhưng nếu bạn hỏi mình rằng công cụ AI có thực sự thay đổi hiệu suất của bạn hay không, câu trả lời nằm ở cách bạn đặt câu hỏi và sử dụng các prompt quản lý sản phẩm. Một câu lệnh (prompt) mơ hồ chỉ nhận lại một kết quả chung chung, vô thưởng vô phạt. Đó là lý do mình biên soạn bộ tài liệu này.

Bài viết này giới thiệu chi tiết bộ 50 prompt quản lý sản phẩm quản lý sản phẩm và vận hành chuyên nghiệp, được chia làm 5 danh mục cốt lõi từ thiết lập roadmap, tối ưu Kanban, quản lý đội ngũ, đo lường KPIs cho đến chiến lược ra mắt thị trường. Từng prompt đều được thiết kế sẵn cấu trúc, bạn chỉ cần điền thông tin thực tế của dự án để nhận lại kết quả phân tích sâu sắc từ AI.

Tại sao bạn cần một bộ prompt quản lý sản phẩm được thiết kế chuẩn?

Có một chi tiết thú vị là, hầu hết các PM hiện tại khi bắt đầu ứng dụng AI thường viết các câu lệnh rất bản năng và ngắn ngủi. Nhưng thực tế thì, để AI hiểu được bối cảnh kinh doanh lẫn kỹ thuật phức tạp của một phần mềm, câu lệnh cần được xây dựng theo cấu trúc chuyên gia có phân vai, chỉ rõ nhiệm vụ cốt lõi, tiêu chí nghiệm thu và định dạng đầu ra cụ thể.

Sử dụng một bộ prompt quản lý sản phẩm chuyên biệt giúp bạn chuyển hóa các mô tả thô thành các tài liệu chuyên nghiệp. Việc này tương tự như cách chúng ta dùng các prompt chiến lược marketing để hoạch định kế hoạch ra mắt hay xây dựng các kịch bản prompt chatbot marketing tương tác tự động với khách hàng. Khi câu lệnh có cấu trúc, AI sẽ trở thành một người trợ lý có chuyên môn thay vì chỉ trả lời những thông tin chung chung.

Quản lý Roadmap & Backlog

Một lộ trình sản phẩm rõ ràng và một backlog được sắp xếp khoa học là xương sống của bất kỳ dự án thành công nào. Việc ứng dụng product roadmap prompt AI (một trong những prompt quản lý sản phẩm quan trọng nhất) phù hợp trong phần này giúp bạn lượng hóa mức độ ưu tiên của tính năng nhờ các câu lệnh ưu tiên backlog chuẩn, phân bổ nguồn lực MVP và thiết lập kế hoạch phát hành sản phẩm chặt chẽ.

1. Thiết lập Lộ trình phát triển sản phẩm (Roadmap)

Tình huống áp dụng thực tế: Khi bước vào chu kỳ lập kế hoạch năm mới, ban giám đốc đòi hỏi một tầm nhìn rõ ràng nhưng đội phát triển lại cần các mốc thời gian chi tiết. PM thường kẹt ở giữa.

Hướng dẫn sử dụng: Điền chính xác tên sản phẩm và các chủ đề chiến lược lớn của từng quý (ví dụ: tối ưu onboarding, nâng cấp bảo mật). Claude 3.5 Sonnet xử lý prompt này cực tốt để tạo ra khung sườn roadmap ban đầu.

Bạn là một Product Director & Strategic Product Planner.

Nhiệm vụ của bạn là: Thiết lập lộ trình phát triển sản phẩm (Product Roadmap) thời hạn [1 năm] chia theo 4 quý (Q1 - Q4) cho sản phẩm: '[Tên sản phẩm]'.

Hãy tuân thủ các hướng dẫn sau:
1. Xác định tầm nhìn sản phẩm tổng quát và các mục tiêu chiến lược cốt lõi trong năm để định hình hướng đi chung.
2. Phân bổ lộ trình tính năng bám sát chủ đề chiến lược lớn của từng quý (Ví dụ: Q1: Tối ưu hóa onboarding người dùng; Q2: Nâng cấp bảo mật & thanh toán; Q3: Tăng cường tính năng tương tác xã hội; Q4: Mở rộng tính năng cá nhân hóa AI).
3. Trong mỗi quý, mô tả chi tiết ít nhất 3 tính năng/dự án lớn bàn giao đi kèm lợi ích kinh doanh mục tiêu (Business Value) và chỉ số đo lường thành công (KPIs/Metrics) tương ứng.
4. Đánh giá sơ bộ về rủi ro kỹ thuật hoặc nguồn lực tiềm ẩn cho từng giai đoạn và đề xuất giải pháp giảm thiểu rủi ro sơ bộ.
5. Đề xuất kế hoạch truyền thông/giao tiếp lộ trình này một cách hiệu quả với hai đối tượng chính: Ban giám đốc (chú trọng vào ROI, tính khả thi tài chính) và Đội ngũ lập trình nội bộ (chú trọng vào kiến trúc kỹ thuật, tài nguyên hệ thống).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

2. Sắp xếp độ ưu tiên Backlog bằng RICE

Tình huống áp dụng thực tế: Backlog của bạn phình to với hàng tá ý tưởng từ Sales, Support và khách hàng. Ai cũng nghĩ tính năng của mình là quan trọng nhất.

Hướng dẫn sử dụng: Cung cấp danh sách tính năng thô kèm ước lượng sơ bộ. Việc sử dụng prioritization RICE prompt này giúp bạn áp dụng khung điểm ưu tiên RICE một cách khách quan, tránh việc tranh cãi dựa trên cảm tính.

Bạn là một Data-driven Product Manager & Prioritization Expert.

Nhiệm vụ của bạn là: Áp dụng khung điểm ưu tiên RICE (Reach, Impact, Confidence, Effort) để xếp hạng mức độ ưu tiên cho danh sách tính năng sản phẩm sau: 
[Danh sách các ý tưởng tính năng và mô tả ngắn gọn]

Hãy tuân thủ các hướng dẫn sau:
1. Phân tích từng ý tưởng tính năng trong danh sách được cung cấp.
2. Thiết lập và giải thích rõ ràng cơ sở ước tính cho từng chỉ số thành phần của khung RICE:
   - **Reach (Độ phủ):** Ước tính số lượng người dùng hoặc giao dịch sẽ chịu tác động trực tiếp bởi tính năng này trong một khoảng thời gian nhất định (ví dụ: mỗi tháng hoặc mỗi quý).
   - **Impact (Tác động):** Đánh giá mức độ đóng góp vào mục tiêu chiến lược cốt lõi. Sử dụng thang điểm chuẩn của RICE: 3 = Tác động cực kỳ lớn (massive), 2 = Tác động lớn (high), 1 = Tác động trung bình (medium), 0.5 = Tác động thấp (low), 0.25 = Tác động tối thiểu (minimal).
   - **Confidence (Độ tin cậy):** Xác định phần trăm độ tin cậy dựa trên tính sẵn có và chất lượng của dữ liệu hỗ trợ (ví dụ: 100% = Rất tự tin, có dữ liệu người dùng/thử nghiệm thực tế; 80% = Tự tin vừa phải, có phản hồi khách hàng; 50% = Thấp, dựa trên giả định hoặc trực giác; dưới 50% = Rất mơ hồ, cần nghiên cứu thêm).
   - **Effort (Công sức):** Ước tính lượng tài nguyên cần thiết để triển khai (tính theo Person-months/Man-months - số tháng làm việc của một kỹ sư/thành viên đội ngũ).
3. Áp dụng công thức chuẩn: RICE Score = (Reach x Impact x Confidence) / Effort để tính điểm cho từng tính năng.
4. Trình bày kết quả dưới dạng bảng Markdown được sắp xếp giảm dần theo điểm RICE (từ cao xuống thấp). Bảng phải chứa các cột: Tên tính năng, Reach, Impact, Confidence (%), Effort, RICE Score, và Xếp hạng.
5. Cung cấp một báo cáo phân tích ngắn gọn lý giải lý do vì sao một số tính năng có điểm số cao/thấp bất ngờ, và đề xuất các bước hành động tiếp theo (ví dụ: tính năng nào nên làm ngay trong Sprint tới, tính năng nào cần nghiên cứu thêm trước khi làm).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

3. Sắp xếp độ ưu tiên Backlog bằng MoSCoW

Tình huống áp dụng thực tế: Đội ngũ chuẩn bị chạy sprint phát triển sản phẩm khả dụng tối thiểu (MVP) nhưng phạm vi công việc vẫn quá rộng và có nguy cơ trễ hạn.

Hướng dẫn sử dụng: Đưa danh sách tính năng và yêu cầu AI phân loại nghiêm ngặt theo phương pháp MoSCoW. Hãy giới hạn tỷ lệ Must-have dưới 60% để tạo biên độ an toàn cho sprint.

Bạn là một Agile Product Owner & Project Manager.

Nhiệm vụ của bạn là: Áp dụng kỹ thuật MoSCoW để phân loại sắp xếp độ ưu tiên cho danh sách yêu cầu tính năng của dự án '[Tên dự án]' chuẩn bị bước vào giai đoạn phát triển:
[Danh sách yêu cầu/tính năng thô của dự án]

Hãy tuân thủ các hướng dẫn sau:
1. Phân loại rõ ràng danh sách yêu cầu tính năng vào 4 nhóm của phương pháp MoSCoW:
   - **Must-have (Bắt buộc phải có):** Các tính năng cốt lõi bắt buộc để sản phẩm vận hành (MVP). Nếu thiếu bất kỳ tính năng nào trong nhóm này, sản phẩm không thể bàn giao hoặc không thể sử dụng.
   - **Should-have (Nên có):** Các tính năng quan trọng nhưng không mang tính sinh tử trong giai đoạn đầu. Có thể tạm thời xử lý bằng các giải pháp thủ công hoặc thay thế khác nếu cần thiết.
   - **Could-have (Có thể có):** Các tính năng hữu ích, cải thiện trải nghiệm người dùng nhưng không ảnh hưởng lớn đến giá trị cốt lõi. Chỉ triển khai khi đội ngũ còn dư thời gian và nguồn lực sau khi đã hoàn thành các nhóm trên.
   - **Won't-have (Không phát triển trong đợt này):** Các yêu cầu hoặc ý tưởng sẽ không được triển khai trong đợt phát hành/Sprint này (được lưu lại trong backlog để xem xét cho các đợt sau).
2. Đối với mỗi tính năng được phân loại, cung cấp lời giải thích logic và chi tiết (Rationales) cho quyết định xếp nhóm đó dựa trên giá trị kinh doanh, trải nghiệm khách hàng và tính khả thi kỹ thuật.
3. Đưa ra tỷ lệ phân bổ ước tính giữa các nhóm (khuyến nghị phân bổ hợp lý trong Agile thường là Must-have chiếm không quá 60% tổng nguồn lực) để đảm bảo kế hoạch có biên độ an toàn cho các rủi ro phát sinh.
4. Trình bày kết quả rõ ràng dưới dạng danh sách phân loại có cấu trúc hoặc bảng tổng hợp.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

4. Kế hoạch phát hành sản phẩm (Release Planning)

Tình huống áp dụng thực tế: Một phiên bản cập nhật lớn sắp được triển khai lên Production. Nếu không có kế hoạch kỹ lưỡng, chỉ một lỗi nhỏ cũng có thể làm sập hệ thống và gây hoảng loạn cho CS/Sales.

Hướng dẫn sử dụng: Thay thế phiên bản v[Số phiên bản] và tên sản phẩm của bạn. Prompt này sẽ thiết lập cả Go/No-Go Checklist lẫn phương án rollback kỹ thuật chi tiết.

Bạn là một Release Manager & DevOps Lead.

Nhiệm vụ của bạn là: Xây dựng Kế hoạch phát hành sản phẩm (Release Plan) cho phiên bản cập nhật v[Số phiên bản] của sản phẩm '[Tên sản phẩm]'.

Hãy tuân thủ các hướng dẫn sau:
1. Xây dựng một Dòng thời gian phát hành (Release Timeline) chi tiết và hợp lý, xác định rõ trình tự: Đóng băng mã nguồn (Code Freeze) -> Kiểm thử hồi quy (Regression Testing) -> Triển khai môi trường thử nghiệm & Nghiệm thu (Staging/UAT Deployment & Sign-off) -> Phát hành Production (Production Release) -> Giám sát sau phát hành (Post-release Monitoring) trong [số ngày/giờ].
2. Xác định các vai trò chịu trách nhiệm chính (Release Owner, QA Lead, DevOps Engineer, Support Lead) và các tiêu chí sẵn sàng phát hành (Release Readiness Criteria/Go-NoGo Checklist).
3. Thiết lập Kế hoạch Rollback chi tiết trong trường hợp khẩn cấp (xảy ra sự cố nghiêm trọng ảnh hưởng đến hệ thống): định nghĩa tiêu chí kích hoạt rollback (Rollback Criteria), quy trình thực hiện kỹ thuật (Deploy lại bản cũ, khôi phục DB, chuyển đổi DNS/Routing), và quy trình thông báo nội bộ/khách hàng.
4. Xây dựng kế hoạch truyền thông sau phát hành:
   - Một bản nháp Ghi chú phát hành (Release Notes) dành cho người dùng cuối (tập trung vào giá trị tính năng mới, sửa lỗi bằng ngôn từ dễ hiểu).
   - Một bản cập nhật nội bộ ngắn gọn cho đội CS (Customer Support) và Sales (bao gồm các lỗi đã biết và cách xử lý tạm thời nếu khách hàng phản ánh).
5. Đảm bảo cấu trúc kế hoạch rõ ràng, phân mục mạch lạc, chuyên nghiệp và có thể áp dụng ngay vào thực tế dự án phần mềm.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

5. Lập bản đồ câu chuyện người dùng (User Story Mapping)

Tình huống áp dụng thực tế: Đội ngũ lập trình chỉ nhìn thấy các tác vụ nhỏ trên Jira mà không hiểu được bức tranh lớn về hành trình trải nghiệm của khách hàng.

Hướng dẫn sử dụng: Điền tên sản phẩm. Prompt tạo ra khung sườn bản đồ câu chuyện người dùng đi từ Backbone (hoạt động chính) xuống các câu chuyện nhỏ cho từng đợt release.

Bạn là một Agile Product Consultant & UX Architect.

Nhiệm vụ của bạn là: Thiết lập Bản đồ câu chuyện người dùng (User Story Map) cho sản phẩm mới: '[Tên sản phẩm]'.

Hãy tuân thủ các hướng dẫn sau:
1. Thiết kế phần Xương sống (Backbone) của bản đồ: Xác định các hoạt động lớn của người dùng (User Activities) và các bước hành động cốt lõi (User Tasks) theo dòng thời gian từ trái sang phải phản ánh toàn bộ hành trình người dùng (ví dụ: Đăng ký/Onboarding -> Tìm kiếm/Lọc sản phẩm -> Xem thông tin/So sánh -> Đặt hàng/Thanh toán -> Theo dõi đơn hàng -> Chăm sóc khách hàng).
2. Phát triển các Epic và các User Stories tương ứng dưới mỗi bước hành động chính theo chiều dọc, sắp xếp theo thứ tự mức độ ưu tiên giảm dần từ trên xuống dưới (càng lên trên càng quan trọng và cấp bách).
3. Sử dụng các Đường cắt phát hành (Release Slices / Swimlanes) để phân định rõ ràng phạm vi triển khai:
   - **Release 1 (MVP - Minimum Viable Product):** Chỉ chứa các câu chuyện tối thiểu cần thiết để người dùng có thể hoàn thành một hành trình cơ bản khép kín.
   - **Release 2 & Phase tiếp theo (Post-MVP):** Các tính năng nâng cao trải nghiệm, tối ưu hóa và tự động hóa.
4. Mỗi User Story được viết theo cấu trúc tiêu chuẩn Agile: "Là một [loại người dùng], tôi muốn [hành động] để [lợi ích]".
5. Đảm bảo cấu trúc bản đồ dễ theo dõi, trực quan và có phần phân tích/chú giải ngắn gọn về lý do phân bổ câu chuyện cho MVP.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

6. Viết vé công việc Jira chuẩn chuyên nghiệp

Tình huống áp dụng thực tế: Lập trình viên thường xuyên phàn nàn rằng vé Jira viết quá sơ sài, thiếu tiêu chí nghiệm thu rõ ràng dẫn đến việc hiểu sai yêu cầu.

Hướng dẫn sử dụng: Điền tên nhiệm vụ kỹ thuật hoặc mô tả lỗi. Điểm hay của prompt này là ép AI viết Acceptance Criteria theo chuẩn Scenario Given-When-Then.

Bạn là một Business Analyst & QA Engineer chuyên nghiệp.

Nhiệm vụ của bạn là: Viết chi tiết một vé công việc Jira (Jira Ticket / Issue Description) cho nhiệm vụ: '[Tên nhiệm vụ kỹ thuật / Bug sửa lỗi]'.

Hãy tuân thủ các hướng dẫn sau:
1. Xác định rõ loại vé: Câu chuyện người dùng (User Story), Cải tiến (Improvement), hay Lỗi hệ thống (Bug).
2. Xây dựng cấu trúc vé Jira chuẩn chỉnh, bao gồm các phần bắt buộc sau:
   - **Jira Summary (Tiêu đề):** Đặt tên rõ ràng, theo định dạng chuẩn (ví dụ: `[Feature] [Tên module] - Hành động` hoặc `[Bug] [Môi trường] - Mô tả lỗi`).
   - **Description (Mô tả):** Bối cảnh (Background), Lý do tại sao cần làm việc này (Why), và Giá trị mang lại cho người dùng/hệ thống. Nếu là User Story, viết dưới dạng: "As a..., I want..., So that...".
   - **Technical Details / Specifications (Chi tiết kỹ thuật):** Mô tả các API liên quan, cấu trúc cơ sở dữ liệu hoặc logic xử lý cần lưu ý (nếu có).
   - **Steps to Reproduce (Các bước tái hiện) & Expected/Actual Result (Kết quả kỳ vọng/thực tế):** Chỉ áp dụng khi vé là Bug.
   - **Acceptance Criteria (Tiêu chí nghiệm thu):** Viết theo định dạng Scenario-based "Given - When - Then" để QA/Dev dễ dàng kiểm thử.
   - **Environment (Môi trường phát triển & kiểm thử):** Phiên bản HĐH, Trình duyệt, Thiết bị.
   - **Out of Scope (Ngoài phạm vi):** Làm rõ những phần KHÔNG thuộc phạm vi xử lý của vé này để tránh phình to phạm vi (Scope Creep).
3. Sử dụng các ký tự định dạng Markdown tương thích tốt nhất với Jira (sử dụng các thẻ tiêu đề, danh sách, đoạn code, bảng biểu khi cần thiết để tăng tính trực quan).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

7. Sắp xếp độ ưu tiên bằng mô hình Kano

Tình huống áp dụng thực tế: Bạn muốn tạo ra các tính năng đột phá khiến khách hàng thích thú (Wow effect) nhưng lại không biết nên ưu tiên cái nào để tối ưu nguồn lực.

Hướng dẫn sử dụng: Liệt kê các tính năng đề xuất. Prompt giúp bạn phân loại chúng thành các nhóm Basic, Performance và Attractive theo tâm lý học hành vi.

Bạn là một Product Strategist & Consumer Psychologist.

Nhiệm vụ của bạn là: Áp dụng Mô hình Kano để phân tích và sắp xếp độ ưu tiên cho danh sách tính năng sản phẩm: [Danh sách các tính năng đề xuất].

Hãy tuân thủ các hướng dẫn sau:
1. Phân tích từng tính năng được đề xuất và phân loại chúng vào các danh mục của Mô hình Kano:
   - **Must-be / Basic (Yêu cầu cơ bản):** Các tính năng bắt buộc phải có để sản phẩm có thể hoạt động tối thiểu. Khách hàng xem chúng là mặc nhiên, nếu không có họ sẽ cực kỳ không hài lòng, nhưng nếu có họ cũng không đánh giá cao.
   - **One-dimensional / Performance (Tính năng hiệu năng):** Sự hài lòng của khách hàng tỷ lệ thuận với mức độ đáp ứng của tính năng này (ví dụ: tốc độ xử lý, dung lượng lưu trữ, tiết kiệm năng lượng).
   - **Attractive / Delighters (Tính năng gây thích thú):** Các tính năng mang lại sự bất ngờ và trải nghiệm vượt mong đợi (cảm giác "Wow"). Nếu thiếu họ sẽ không phàn nàn (vì không biết hoặc không kỳ vọng), nhưng nếu có sẽ làm tăng mạnh sự hài lòng và lòng trung thành.
   - **Indifferent (Tính năng không ảnh hưởng):** Các tính năng mà khách hàng không quan tâm hoặc không ảnh hưởng đến mức độ hài lòng của họ (cần xem xét loại bỏ để tiết kiệm nguồn lực).
   - **Reverse (Tính năng đảo ngược):** Các tính năng có thể gây tác dụng ngược (khách hàng không thích hoặc cảm thấy phiền phức khi có chúng).
2. Đối với mỗi tính năng, giải thích chi tiết lý do tại sao nó lại được xếp vào nhóm đó dựa trên tâm lý học người tiêu dùng và hành vi người dùng.
3. Đề xuất phương án thiết kế bảng câu hỏi Kano (Kano Questionnaire) gồm câu hỏi chức năng (Functional question) và câu hỏi phi chức năng (Dysfunctional question) cho một tính năng tiêu biểu trong danh sách để đội ngũ có thể tiến hành khảo sát thực tế.
4. Đưa ra đề xuất phân bổ nguồn lực phát triển (Resource Allocation) tối ưu giữa các nhóm tính năng (ví dụ: giải quyết 100% nhóm Must-be, nâng cấp nhóm Performance dựa trên ngân sách, và chọn lọc 1-2 tính năng Attractive để tạo điểm nhấn cạnh tranh).
5. Trình bày kết quả dưới dạng bảng phân loại trực quan và chuyên nghiệp.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

8. Quản lý nợ kỹ thuật trong Backlog (Tech Debt)

Tình huống áp dụng thực tế: Hệ thống ngày càng chậm chạp, lỗi phát sinh liên tục vì nợ kỹ thuật tích tụ quá lâu, nhưng Product Owner lại chỉ muốn làm tính năng mới để tăng doanh số.

Hướng dẫn sử dụng: Thay thế tỷ lệ % tài nguyên mong muốn dành cho refactoring. Prompt biên dịch các vấn đề kỹ thuật khó hiểu thành tác động kinh doanh (business impact) để thuyết phục PO.

Bạn là một Tech Lead & Software Architect chuyên quản lý nợ kỹ thuật.

Nhiệm vụ của bạn là: Lập đề xuất xử lý nợ kỹ thuật (Technical Debt Backlog Proposal) cho hệ thống phần mềm của doanh nghiệp nhằm thuyết phục Product Owner dành [Số %] tài nguyên của Sprint tới để refactor code.

Hãy tuân thủ các hướng dẫn sau:
1. Nhận diện và phân loại các khoản nợ kỹ thuật (Technical Debt) hiện tại của hệ thống thành các nhóm rõ ràng (ví dụ: Nợ mã nguồn/Refactoring, Nợ kiến trúc/Design, Nợ kiểm thử/Testing, Nợ hạ tầng/DevOps, Nợ tài liệu/Documentation).
2. Xây dựng một "Ma trận nợ kỹ thuật" đánh giá từng khoản nợ dựa trên hai trục:
   - **Mức độ ảnh hưởng (Impact):** Tác động tiêu cực của khoản nợ đối với hiệu năng hệ thống hoặc tốc độ làm việc của đội ngũ nếu không được giải quyết.
   - **Công sức khắc phục (Effort):** Thời gian và tài nguyên cần thiết để tái cấu trúc (refactor).
3. Biên dịch các vấn đề kỹ thuật phức tạp thành ngôn ngữ kinh doanh (Business Impact) để Product Owner/Stakeholders dễ thấu hiểu, bao gồm:
   - Tốc độ đưa sản phẩm ra thị trường bị giảm (Time-to-market).
   - Chi phí bảo trì tăng cao (Maintenance Cost).
   - Rủi ro về bảo mật, tính ổn định của hệ thống (System Downtime).
   - Tác động tiêu cực đến tinh thần làm việc của đội ngũ lập trình (Developer Burnout).
4. Đề xuất một chiến lược phân bổ nguồn lực Sprint cụ thể (ví dụ: mô hình 70/20/10 hoặc 80/20, trong đó dành [Số %] tài nguyên Sprint cho việc xử lý nợ kỹ thuật đã chọn lọc).
5. Phác thảo quy trình giám sát và đo lường nợ kỹ thuật lâu dài (ví dụ: theo dõi qua các chỉ số Code Coverage, Bug Rate, Cycle Time).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

9. Sắp xếp danh mục dự án sản phẩm

Tình huống áp dụng thực tế: Doanh nghiệp có nhiều dòng sản phẩm khác nhau và đang gặp khó khăn trong việc quyết định phân bổ ngân sách: nên tập trung nuôi sản phẩm nào hay nên khai tử sản phẩm nào.

Hướng dẫn sử dụng: Cung cấp danh sách dòng sản phẩm kèm doanh thu và tốc độ tăng trưởng. Prompt áp dụng ma trận BCG để đưa ra khuyến nghị phân bổ nguồn lực tối ưu.

Bạn là một Chief Product Officer (CPO) & Portfolio Manager.

Nhiệm vụ của bạn là: Phân tích và sắp xếp danh mục sản phẩm (Product Portfolio Prioritization) cho công ty [Tên công ty] đang sở hữu [Số lượng sản phẩm] dòng sản phẩm khác nhau:
[Danh sách dòng sản phẩm kèm mô tả doanh thu và tốc độ tăng trưởng]

Hãy tuân thủ các hướng dẫn sau:
1. Đánh giá kỹ lưỡng thông tin từng dòng sản phẩm được cung cấp (thị phần tương đối, tốc độ tăng trưởng thị trường, doanh thu, lợi nhuận).
2. Phân loại các dòng sản phẩm này vào đúng 4 nhóm của Ma trận BCG (Boston Consulting Group):
   - **Stars (Ngôi sao):** Sản phẩm có thị phần lớn trong thị trường tăng trưởng nhanh. Cần chiến lược để duy trì vị thế dẫn đầu.
   - **Cash Cows (Bò sữa):** Sản phẩm có thị phần lớn trong thị trường tăng trưởng chậm. Đây là nguồn tạo ra dòng tiền chính để nuôi dưỡng các sản phẩm khác.
   - **Question Marks (Dấu hỏi):** Sản phẩm có thị phần nhỏ trong thị trường tăng trưởng nhanh. Cần phân tích tiềm năng để quyết định đầu tư lớn hay thoái vốn.
   - **Dogs (Con chó):** Sản phẩm có thị phần nhỏ trong thị trường tăng trưởng chậm hoặc suy thoái. Cần xem xét loại bỏ hoặc tối thiểu hóa chi phí duy trì.
3. Đề xuất chiến lược hành động cụ thể cho từng dòng sản phẩm: Đầu tư để phát triển (Build), Duy trì (Hold), Khai thác dòng tiền (Harvest), hay Thoái vốn/Khai tử (Divest).
4. Thiết lập kế hoạch phân bổ nguồn lực (vốn đầu tư phát triển, đội ngũ lập trình/R&D, chiến dịch marketing) tối ưu giữa các sản phẩm này để đảm bảo cân bằng giữa lợi nhuận ngắn hạn và tăng trưởng dài hạn.
5. Cung cấp báo cáo phân tích rủi ro và các chỉ số đo lường hiệu quả danh mục sản phẩm (Portfolio Health Metrics) cần theo dõi định kỳ.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

10. Lập bản đồ phụ thuộc tính năng (Dependencies)

Tình huống áp dụng thực tế: Dự án bị chậm trễ dây chuyền vì Module A chưa xong khiến Module B không thể test, và đội ngũ không lường trước được sự phụ thuộc chéo này.

Hướng dẫn sử dụng: Điền danh sách các module. Prompt sẽ phân tích đường găng (Critical Path) và tạo mã Mermaid để bạn vẽ sơ đồ trực quan.

Bạn là một Technical Program Manager & Systems Architect.

Nhiệm vụ của bạn là: Thiết lập Bản đồ phụ thuộc tính năng (Dependency Map) cho dự án phần mềm phức tạp gồm các cấu phần: [Danh sách các tính năng/Module chính].

Hãy tuân thủ các hướng dẫn sau:
1. Nhận diện và phân loại các loại phụ thuộc (Dependency Types) trong dự án phần mềm (ví dụ: Phụ thuộc kỹ thuật/Technical, Phụ thuộc tài nguyên/Resource, Phụ thuộc dữ liệu/Data flow, Phụ thuộc vào bên thứ ba/External APIs).
2. Xây dựng Bản đồ phụ thuộc (Dependency Map) chi tiết, chỉ ra rõ chiều phụ thuộc (ví dụ: Module B phụ thuộc vào Module A - tức là Module A phải xong trước Module B).
3. Đề xuất một Thứ tự phát triển (Sequencing/Development Order) tối ưu nhất dựa trên việc giải quyết các phụ thuộc có độ rủi ro hoặc mức độ ưu tiên cao trước (Sử dụng các kỹ thuật như phương pháp Đường găng - Critical Path Method để tìm ra các điểm nghẽn).
4. Đề xuất các giải pháp giảm thiểu rủi ro (Risk Mitigation Strategies) khi xảy ra sự trễ hạn ở một module quan trọng (ví dụ: Mocking API, chia nhỏ User Stories, hoặc chuyển giao tài nguyên chéo).
5. Trình bày kết quả trực quan bằng cách sử dụng các bảng Markdown hoặc sơ đồ biểu diễn bằng chữ (Text-based Diagram / Mermaid Code) để nhóm phát triển có thể dễ dàng nắm bắt.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

Tối ưu hóa Vận hành & Kanban

Hiệu suất bàn giao của đội ngũ phụ thuộc rất lớn vào cách dòng công việc (workflow) di chuyển. Dưới đây là các prompt quản lý sản phẩm giúp bạn tối ưu hóa Kanban, tính toán giới hạn WIP khoa học, phân tích CFD và loại bỏ triệt để các lãng phí nhằm mục tiêu vận hành sản phẩm chuyên nghiệp nhất trong quy trình phát triển phần mềm.

11. Thiết lập bảng Kanban hiệu quả

Tình huống áp dụng thực tế: Bảng Kanban của nhóm hoạt động kém hiệu quả, công việc bị dồn ứ ở khâu QA và không ai biết khi nào một task thực sự được coi là hoàn thành.

Hướng dẫn sử dụng: Prompt này hướng dẫn chi tiết cách thiết lập các cột, làn bơi (Swimlanes) và Definition of Done rõ ràng cho từng bước chuyển giao.

Bạn là một Kanban Facilitator & Agile Operations Coach.

Nhiệm vụ của bạn là: Thiết kế cấu trúc bảng Kanban (Kanban Board Layout) cho quy trình làm việc của đội ngũ phát triển phần mềm và tối ưu hóa chuyển giao công việc.

Hãy tuân thủ các hướng dẫn sau:
1. Thiết kế các cột trạng thái (Columns/Workflow Stages) trên bảng Kanban bám sát dòng giá trị (Value Stream) thực tế (ví dụ: Backlog, Ready to Develop, In Development, Code Review, QA Testing, UAT/Staging, Ready to Release, Done). Chỉ rõ điều kiện để chuyển một thẻ công việc qua cột tiếp theo (Definition of Done/Exit Criteria cho từng cột).
2. Xác định và thiết lập Giới hạn công việc đang xử lý (WIP Limits - Work In Progress) cho từng cột dựa trên quy mô và năng lực của đội ngũ (ví dụ: đội ngũ 5 lập trình viên thì cột "In Development" giới hạn WIP là bao nhiêu để đảm bảo sự tập trung). Giải thích logic toán học hoặc vận hành đằng sau việc đề xuất WIP Limits đó.
3. Thiết lập các làn bơi ngang (Swimlanes) để quản lý trực quan và phân cấp độ ưu tiên (ví dụ: Làn "Expedite" cho các lỗi nghiêm trọng/Hotfix cần xử lý ngay lập tức, Làn "Features/User Stories" cho các tính năng mới, Làn "Tech Debt/Maintenance" cho bảo trì hệ thống).
4. Định nghĩa các quy tắc cốt lõi (Policies/Working Agreements) của bảng: Cách xử lý thẻ công việc bị tắc nghẽn (Blocked cards), cách thức kéo việc (Pull system) thay vì đẩy việc (Push system), và thời gian tổ chức các buổi họp Kanban (Daily Kanban, Replenishment, Retrospective).
5. Trình bày dưới dạng tài liệu hướng dẫn vận hành bảng chi tiết, dễ hiểu cho cả thành viên mới tham gia đội ngũ.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

12. Tối ưu hóa giới hạn WIP (Work In Progress)

Tình huống áp dụng thực tế: Đội ngũ làm việc vất vả, lúc nào cũng bận rộn với hàng chục task đang mở nhưng số lượng task thực tế bàn giao (Done) mỗi tuần lại cực kỳ ít.

Hướng dẫn sử dụng: Thay thế số lượng thành viên nhóm của bạn. Prompt áp dụng Định luật Little để tính toán giới hạn công việc dở dang (WIP Limits) khoa học.

Bạn là một Operations Research Analyst & Lean Specialist.

Nhiệm vụ của bạn là: Tối ưu hóa giới hạn WIP (Work In Progress Limits) cho nhóm phát triển [Số lượng thành viên] người đang gặp tình trạng nhiều việc dở dang nhưng chậm hoàn thành.

Hãy tuân thủ các hướng dẫn sau:
1. Giải thích Định luật Little (Little's Law) trong quản trị vận hành một cách thực tiễn và dễ hiểu cho đội ngũ kỹ thuật (Công thức: Lead Time = WIP / Throughput). Nhấn mạnh tại sao việc giảm WIP lại trực tiếp cải thiện Lead Time và tăng tốc độ bàn giao giá trị.
2. Phân tích bối cảnh của nhóm phát triển gồm [Số lượng thành viên] người để đề xuất công thức và con số giới hạn WIP tối ưu cho từng cột (ví dụ: In Development, Code Review, Testing) với lập luận khoa học (ví dụ: hệ số nhân tải 1.0 đến 1.5 dựa trên kỹ năng chéo - cross-functional của nhóm).
3. Thiết lập các quy tắc ứng phó cụ thể của nhóm khi một cột công việc chạm trần WIP (WIP Limit reached):
   - Kỹ thuật "Swarming" (Tập trung toàn lực để giải quyết thẻ công việc bị tắc nghẽn).
   - Quy tắc "Stop Starting, Start Finishing" (Ngừng kéo việc mới từ backlog, tập trung kéo việc ở các bước sau về trạng thái Done).
   - Cách thức hỗ trợ chéo giữa các vai trò (ví dụ: Developer chuyển sang hỗ trợ QA kiểm thử hoặc Code Review).
4. Đề xuất quy trình theo dõi và điều chỉnh WIP Limits định kỳ dựa trên các chỉ số hiệu suất (ví dụ: thông qua các buổi Retro hoặc họp Kanban định kỳ).
5. Trình bày kết quả rõ ràng, mang tính thực tế cao và dễ áp dụng cho Scrum Master/Agile Coach.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

13. Phân tích điểm nghẽn bằng biểu đồ CFD

Tình huống áp dụng thực tế: Bạn nhìn vào biểu đồ dòng chảy tích lũy (CFD) trên Jira nhưng không biết cách phân tích để phát hiện sớm các tắc nghẽn trong quy trình.

Hướng dẫn sử dụng: Mô tả hình dáng biểu đồ CFD hiện tại của nhóm bạn. AI sẽ chỉ ra nguyên nhân gốc rễ và đề xuất giải pháp khơi thông dòng chảy công việc.

Bạn là một Agile Delivery Lead & Process Analyst.

Nhiệm vụ của bạn là: Phân tích Biểu đồ Dòng chảy Tích lũy (Cumulative Flow Diagram - CFD) của dự án để phát hiện và đề xuất giải pháp xử lý điểm nghẽn (Bottlenecks) dựa trên tình trạng:
[Mô tả hình dáng/dữ liệu biểu đồ CFD hiện tại]

Hãy tuân thủ các hướng dẫn sau:
1. Giải thích ngắn gọn cách đọc biểu đồ CFD (ví dụ: các dải màu song song biểu thị dòng chảy ổn định; dải màu phình rộng biểu thị tích lũy công việc quá mức/điểm nghẽn; dải màu thu hẹp cảnh báo nguy cơ thiếu việc cho bước tiếp theo).
2. Phân tích hiện trạng dựa trên mô tả biểu đồ CFD được cung cấp để xác định:
   - Cột/Trạng thái nào đang xảy ra điểm nghẽn (Bottleneck).
   - Nguyên nhân gốc rễ (Root Cause) khả thi dựa trên hành vi dòng chảy (ví dụ: mất cân bằng năng lực giữa các khâu, quy trình phê duyệt cồng kềnh, tiêu chí chuyển trạng thái không rõ ràng).
3. Đánh giá tác động định lượng và định tính của điểm nghẽn này đối với:
   - Cycle Time (Thời gian hoàn thành một thẻ công việc).
   - WIP (Lượng công việc dở dang trong toàn hệ thống).
   - Khả năng hoàn thành mục tiêu release đúng hạn.
4. Đề xuất 3-4 giải pháp hành động khắc phục tức thời (Short-term Actions) để khơi thông dòng chảy (ví dụ: Swarming, điều phối nhân lực tạm thời, điều chỉnh tạm thời WIP limits) và giải pháp lâu dài (Long-term Systemic Improvements) nhằm ngăn ngừa tái diễn.
5. Định nghĩa các chỉ số vận hành cần tiếp tục giám sát sau khi áp dụng giải pháp để đánh giá tính hiệu quả.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

14. Tối ưu hóa Lead Time & Cycle Time

Tình huống áp dụng thực tế: Khách hàng phàn nàn vì từ lúc họ yêu cầu một tính năng đến khi nhận được thực tế mất quá nhiều thời gian, dù dev khẳng định code rất nhanh.

Hướng dẫn sử dụng: Điền chỉ số Lead/Cycle Time hiện tại nếu có. Prompt giúp bạn tính toán hiệu suất dòng chảy (Flow Efficiency) và loại bỏ các lãng phí trung gian.

Bạn là một Lean Six Sigma Black Belt & Agile Coach.

Nhiệm vụ của bạn là: Xây dựng chiến lược cải tiến dòng chảy để rút ngắn thời gian bàn giao (Lead Time & Cycle Time Improvement Strategy) cho dự án [Tên dự án] với chỉ số hiện tại là: [Mô tả chỉ số Lead Time/Cycle Time hiện tại hoặc các vấn đề nghẽn dòng chảy].

Hãy tuân thủ các hướng dẫn sau:
1. Định nghĩa ngắn gọn và phân biệt rõ ràng giữa hai khái niệm:
   - **Lead Time:** Tính từ thời điểm yêu cầu xuất hiện trong Backlog đến khi bàn giao giá trị cho người dùng.
   - **Cycle Time:** Tính từ thời điểm đội ngũ thực sự bắt tay vào xử lý yêu cầu đến khi nó đạt trạng thái hoàn thành (Done).
2. Phân tích các loại lãng phí (Lean Wastes / Muda) điển hình gây chậm trễ dòng chảy công việc trong dự án phần mềm (ví dụ: Chờ đợi - Waiting, Chuyển giao trung gian - Handoffs, Làm lại - Rework do thiếu thông tin, Xử lý thừa - Extra processing).
3. Đề xuất công thức và cách tính **Hiệu suất dòng chảy (Flow Efficiency %)**:
   Flow Efficiency % = (Active Work Time / Total Lead Time) x 100%. Giải thích ý nghĩa của chỉ số này đối với năng suất của đội ngũ.
4. Đề xuất ít nhất 3 giải pháp cải tiến thực tế ở cả hai khía cạnh:
   - **Quy trình vận hành (Operational):** Ví dụ như giảm thiểu bàn giao công việc chéo, thống nhất Definition of Ready, tự động hóa quy trình phê duyệt.
   - **Kỹ thuật phát triển (Technical):** Ví dụ như tích hợp liên tục (CI/CD), tự động hóa kiểm thử (Automation Testing), lập trình cặp (Pair Programming) để tránh tắc nghẽn Code Review.
5. Xây dựng kế hoạch hành động cụ thể (Action Plan) bao gồm các bước triển khai thử nghiệm và đánh giá định kỳ chỉ số Lead Time & Cycle Time (ví dụ: thông qua biểu đồ Cycle Time Scatterplot).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

15. Thiết lập quy trình cải tiến liên tục Kaizen

Tình huống áp dụng thực tế: Bạn muốn xây dựng văn hóa chủ động cải tiến trong nhóm nhưng các ý tưởng đưa ra thường rơi vào quên lãng và không được triển khai thực tế.

Hướng dẫn sử dụng: Điền tên bộ phận và doanh nghiệp. Prompt giúp thiết lập bảng Kaizen và quy trình PDCA 4 bước để thử nghiệm nhanh các cải tiến nhỏ.

Bạn là một Kaizen Practitioner & Operational Excellence Manager.

Nhiệm vụ của bạn là: Thiết lập chương trình cải tiến liên tục Kaizen (Continuous Improvement Framework) cho bộ phận [Tên bộ phận/Đội ngũ] của [Tên doanh nghiệp].

Hãy tuân thủ các hướng dẫn sau:
1. Thiết kế Bảng ý tưởng Kaizen (Kaizen Idea Board) trực quan, xác định rõ cấu trúc các trường thông tin cần điền (ví dụ: Vấn đề hiện tại -> Ý tưởng cải tiến -> Người đề xuất -> Người thực hiện -> Kết quả thực tế).
2. Xây dựng quy trình 4 bước PDCA (Plan - Do - Check - Act) chi tiết để triển khai thử nghiệm các đề xuất Kaizen:
   - **Plan:** Xác định vấn đề, tìm nguyên nhân gốc rễ (sử dụng kỹ thuật 5 Whys), lên kế hoạch giải quyết.
   - **Do:** Triển khai thử nghiệm giải pháp trên phạm vi nhỏ.
   - **Check:** Đánh giá kết quả thu được dựa trên các số liệu thực tế so với mục tiêu đề ra.
   - **Act:** Chuẩn hóa quy trình nếu cải tiến thành công; rút bài học và bắt đầu chu trình mới nếu thất bại.
3. Thiết lập chính sách thúc đẩy văn hóa Kaizen trong đội ngũ, bao gồm:
   - Cách thức tổ chức các buổi thảo luận Kaizen định kỳ (Kaizen Events / Kaizen Blitz).
   - Quy tắc ghi nhận ý tưởng: Khuyến khích cải tiến nhỏ, liên tục thay vì chỉ tập trung vào các phát kiến lớn.
   - Cơ chế vinh danh phi tài chính và phần thưởng nhỏ (Kaizen Rewards & Recognition) nhằm thúc đẩy sự chủ động đóng góp của nhân viên.
4. Đề xuất các chỉ số đo lường hiệu quả chương trình Kaizen (ví dụ: số lượng cải tiến được đề xuất/triển khai thành công mỗi tháng, tỷ lệ nhân viên tham gia).
5. Trình bày dưới dạng một khung chính sách (Framework) vận hành bài bản, dễ hiểu và dễ truyền thông.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

16. Loại bỏ 7 lãng phí trong phát triển phần mềm

Tình huống áp dụng thực tế: Quy trình làm việc của nhóm chứa đầy những bước thừa thãi như chờ đợi phê duyệt từ sếp, viết code cho các tính năng không ai dùng, hay họp hành vô bổ.

Hướng dẫn sử dụng: Mô tả ngắn gọn bối cảnh dự án. Prompt sẽ soi rà soát quy trình dưới góc nhìn Lean để loại bỏ 7 loại lãng phí kinh điển trong phần mềm.

Bạn là một Lean Software Development Specialist & Process Auditor.

Nhiệm vụ của bạn là: Thực hiện rà soát quy trình phát triển sản phẩm để phát hiện và loại bỏ 7 loại lãng phí (Lean Wastes in Software) trong dự án: [Tên dự án/Sản phẩm] với bối cảnh: [Mô tả ngắn gọn bối cảnh dự án hoặc các nút thắt hiện tại].

Hãy tuân thủ các hướng dẫn sau:
1. Định nghĩa và chỉ rõ các biểu hiện thực tế của 7 loại lãng phí Lean trong bối cảnh phát triển phần mềm:
   - **Partially Done Work (Công việc dở dang):** Code viết xong chưa được test, tài liệu chưa review, tính năng chưa deploy.
   - **Extra Features (Tính năng thừa):** Các tính năng xây dựng dựa trên giả định mà không có dữ liệu chứng minh nhu cầu người dùng.
   - **Relearning / Lost Knowledge (Tái học hỏi / Mất mát tri thức):** Thiếu tài liệu hướng dẫn, không chia sẻ kiến thức dẫn đến một người nghỉ việc là hệ thống bị tắc nghẽn.
   - **Handoffs (Bàn giao trung gian):** Sự thiếu đồng bộ khi chuyển giao công việc giữa Business Analyst -> Developer -> QA -> DevOps.
   - **Delays (Chờ đợi):** Chờ duyệt thiết kế, chờ deploy môi trường test, chờ phản hồi API từ bên thứ ba.
   - **Task Switching (Chuyển đổi bối cảnh):** Lập trình viên bị ngắt quãng liên tục bởi các cuộc họp hoặc phải làm quá nhiều dự án cùng lúc.
   - **Defects / Rework (Lỗi và làm lại):** Phát hiện lỗi muộn ở production dẫn đến việc phải sửa đổi mã nguồn nhiều lần.
2. Dựa trên bối cảnh dự án được cung cấp, phân tích và chọn ra 2 loại lãng phí đang gây ảnh hưởng nghiêm trọng nhất đến tiến độ bàn giao sản phẩm.
3. Đề xuất một Kế hoạch loại bỏ lãng phí (Waste Elimination Plan) chi tiết cho 2 loại lãng phí được chọn, bao gồm:
   - Các hành động khắc phục cụ thể (ví dụ: tự động hóa CI/CD, chuẩn hóa tài liệu API, áp dụng WIP limits để giảm Task Switching, cải tiến tiêu chí Definition of Done để giảm Defects).
   - Người chịu trách nhiệm chính và thời gian dự kiến.
4. Đề xuất phương pháp đo lường hiệu quả sau khi loại bỏ lãng phí (ví dụ: thông qua các chỉ số Lead Time, Cycle Time, Escaped Defect Rate).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

17. Thiết lập cam kết mức dịch vụ Kanban (SLE)

Tình huống áp dụng thực tế: Khách hàng yêu cầu một cam kết rõ ràng về thời gian hoàn thành cho các yêu cầu hỗ trợ kỹ thuật, nhưng đội ngũ không có dữ liệu lịch sử để dự báo.

Hướng dẫn sử dụng: Cung cấp dữ liệu Cycle Time lịch sử (nếu có). Prompt giúp bạn thiết lập SLE (Service Level Expectation) dựa trên xác suất thống kê.

Bạn là một Flow Metrics Expert & Kanban Trainer.

Nhiệm vụ của bạn là: Thiết lập Cam kết mức dịch vụ (Service Level Expectation - SLE) cho bảng Kanban của nhóm phát triển dựa trên biểu đồ phân tán thời gian chu kỳ (Cycle Time Scatterplot) lịch sử sau:
[Dữ liệu Cycle Time lịch sử hoặc mô tả biểu đồ phân tán Cycle Time Scatterplot]

Hãy tuân thủ các hướng dẫn sau:
1. Định nghĩa rõ khái niệm SLE (Service Level Expectation) trong Kanban và phân biệt nó với SLA (Service Level Agreement) truyền thống (SLA là cam kết ràng buộc pháp lý/hợp đồng với bên ngoài, trong khi SLE là kỳ vọng nội bộ dựa trên năng lực thực tế để tự cải tiến và dự báo).
2. Phân tích dữ liệu Cycle Time lịch sử được cung cấp để xác định chỉ số SLE phù hợp cho các mốc phần trăm xác suất (ví dụ: mốc 50%, 85%, và 95% số lượng task hoàn thành). Ví dụ: "Chúng tôi kỳ vọng hoàn thành 85% công việc trong vòng [X] ngày hoặc ít hơn."
3. Hướng dẫn chi tiết cách sử dụng SLE để:
   - Dự báo thời gian bàn giao (Forecasting) cho khách hàng hoặc các Stakeholder dựa trên phương pháp xác suất.
   - Quản lý công việc hàng ngày trong buổi họp Daily Standup (tập trung vào các task có nguy cơ vi phạm SLE).
4. Thiết lập quy trình Cảnh báo tuổi thọ công việc (Work Item Aging):
   - Cách tính toán "Tuổi" (Age) hiện tại của một task trên bảng (Task Age = Thời gian hiện tại - Thời điểm bắt đầu kéo vào trạng thái In Progress).
   - Thiết lập các tín hiệu cảnh báo trực quan (ví dụ: đổi màu thẻ trên bảng điện tử Jira/Trello khi tuổi của task vượt quá 50%, 85% SLE).
   - Quy trình xử lý cụ thể khi một task vi phạm hoặc sắp vi phạm SLE.
5. Đảm bảo kết quả đầu ra có cấu trúc rõ ràng, lập luận chặt chẽ, mang tính thực tế cao và có thể đưa trực tiếp vào cẩm nang làm việc của đội ngũ Agile.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

18. Quản lý rủi ro vận hành quy trình

Tình huống áp dụng thực tế: Buổi họp Standup hàng ngày kéo dài lê thê 30-40 phút, mọi người chỉ báo cáo trạng thái một cách đối phó và không giải quyết được các vấn đề cản trước.

Hướng dẫn sử dụng: Prompt này giúp bạn tái cấu trúc Standup, tập trung vào việc quản trị dòng chảy của các thẻ công việc thay vì chỉ trả lời 3 câu hỏi truyền thống.

Bạn là một Operational Risk Manager & ITSM (IT Service Management) Specialist.

Nhiệm vụ của bạn là: Xây dựng Kế hoạch quản lý rủi ro vận hành quy trình (Operational Risk Management Plan) cho bộ phận phát triển sản phẩm của công ty [Tên công ty] khi làm việc từ xa (Remote/Hybrid).

Hãy tuân thủ các hướng dẫn sau:
1. Nhận diện và phân tích ít nhất 5 rủi ro vận hành lớn (Operational Risks) khi làm việc trong mô hình từ xa/hỗn hợp (Remote/Hybrid), ví dụ:
   - Rủi ro kỹ thuật (mất điện, đường truyền Internet không ổn định).
   - Rủi ro bảo mật thông tin (rò rỉ dữ liệu nhạy cảm của khách hàng, tấn công phishing qua thiết bị cá nhân).
   - Rủi ro quản lý và truyền thông (lệch múi giờ, thiếu đồng bộ thông tin giữa các thành viên, thất thoát thông tin qua các kênh không chính thức).
   - Rủi ro sức khỏe tinh thần và tính kết nối (cô lập xã hội, kiệt sức do ranh giới công việc - cuộc sống bị xóa nhòa).
2. Xây dựng một Ma trận Đánh giá Rủi ro (Risk Assessment Matrix) phân cấp rủi ro dựa trên Xác suất xảy ra (Likelihood) và Mức độ ảnh hưởng (Impact).
3. Đề xuất các biện pháp kiểm soát và phòng ngừa chủ động (Mitigation Strategies) chi tiết ở cả ba cấp độ: Quy trình (Process), Công nghệ (Technology) và Con người (People).
4. Thiết lập Quy trình Ứng phó Sự cố (Incident Response Workflow) khẩn cấp cho bộ phận IT Helpdesk nhằm hỗ trợ nhân viên khi gặp sự cố phần cứng/phần mềm tại nhà (bao gồm SLA thời gian phản hồi ban đầu, quy trình mượn thiết bị thay thế tạm thời và các bước báo cáo leo thang).
5. Đảm bảo kế hoạch có cấu trúc rõ ràng, chuyên nghiệp, có các hành động đo lường và theo dõi định kỳ tính hiệu quả của kế hoạch (Risk Review Cycle).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

19. Thiết lập sơ đồ chuỗi giá trị (VSM)

Tình huống áp dụng thực tế: Các buổi Retrospective cuối kỳ trở nên nhàm chán, các thành viên ngại chia sẻ thật lòng và không có hành động cải tiến nào được thực hiện sau đó.

Hướng dẫn sử dụng: Prompt thiết lập kịch bản họp Retro sinh động, áp dụng các kỹ thuật như Start-Stop-Continue và cam kết hành động cụ thể cho sprint tiếp theo.

Bạn là một Value Stream Mapping (VSM) Facilitator & Operations Specialist.

Nhiệm vụ của bạn là: Thiết lập Sơ đồ chuỗi giá trị (Value Stream Map - VSM dạng chữ hoặc Mermaid) cho quy trình phát triển sản phẩm [Tên sản phẩm] từ bước lên ý tưởng đến khi deploy Production, dựa trên bối cảnh: [Mô tả quy trình hoặc dữ liệu các bước hiện tại nếu có].

Hãy tuân thủ các hướng dẫn sau:
1. Thiết lập Sơ đồ chuỗi giá trị (Value Stream Map) trực quan (dưới dạng văn bản phân cấp hoặc biểu đồ mã Mermaid) biểu diễn toàn bộ các bước từ khi tiếp nhận yêu cầu -> Lên ý tưởng -> Đặc tả yêu cầu -> Thiết kế UI/UX -> Lập trình (Development) -> Kiểm thử (QA) -> Triển khai UAT -> Phát hành Production.
2. Dưới mỗi bước trong quy trình, xác định rõ các thông số vận hành:
   - **Processing Time (PT - Thời gian xử lý thực tế):** Thời gian kỹ sư thực sự làm việc tập trung để hoàn thành thẻ công việc đó.
   - **Queue Time / Delay Time (QT - Thời gian chờ):** Thời gian thẻ công việc phải nằm chờ trong hàng đợi trước khi được chuyển sang bước kế tiếp.
   - **Percent Complete & Accurate (%C&A):** Tỷ lệ phần trăm công việc được chuyển giao cho khâu tiếp theo mà không cần phải làm lại (Rework).
3. Thực hiện tính toán các chỉ số cốt lõi của VSM:
   - **Total Lead Time (LT):** Tổng thời gian từ đầu đến cuối quy trình (bao gồm tổng PT và tổng QT).
   - **Total Processing Time (PT):** Tổng thời gian làm việc thực tế tạo ra giá trị trực tiếp.
   - **Hiệu suất chuỗi giá trị (Activity Ratio / Flow Efficiency):** Tính bằng công thức (Tổng PT / Total LT) x 100%.
4. Nhận diện các hoạt động không tạo ra giá trị (Non-Value-Added - NVA) nhưng bắt buộc (ví dụ: một số khâu tuân thủ bảo mật) và các hoạt động lãng phí hoàn toàn (Waste) cần loại bỏ ngay lập tức để tối ưu hóa hiệu suất dòng chảy.
5. Đề xuất Bản đồ chuỗi giá trị tương lai (Future State Map) tinh gọn kèm theo lộ trình các hành động cụ thể để cải tiến từ trạng thái hiện tại.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

20. Báo cáo hiệu quả vận hành định kỳ

Tình huống áp dụng thực tế: Bạn muốn đánh giá xem đội ngũ của mình thực sự đang ở mức độ trưởng thành Agile nào để lên kế hoạch cải tiến năng lực vận hành lâu dài.

Hướng dẫn sử dụng: Prompt này cung cấp bộ câu hỏi tự đánh giá đa chiều trên các khía cạnh: Lập kế hoạch, Giao tiếp, Kỹ thuật và Tư duy cải tiến.

Bạn là một Operations Director & Chief of Staff.

Nhiệm vụ của bạn là: Viết báo cáo hiệu quả vận hành hàng tháng (Monthly Operational Efficiency Report) cho bộ phận Phát triển Sản phẩm của doanh nghiệp [Tên công ty] trong tháng [Tháng/Năm báo cáo], dựa trên các số liệu thực tế sau:
[Dán dữ liệu/Số liệu thô về tiến độ, lỗi, thời gian chu kỳ, và hạ tầng hệ thống]

Hãy tuân thủ các hướng dẫn sau:
1. Xây dựng Báo cáo Hiệu quả Vận hành (Monthly Operational Efficiency Report) chuẩn executive-level với các phần sau:
   - **Executive Summary (Tóm tắt điều hành):** Đánh giá tổng quan hiệu suất vận hành của tháng bằng 3-4 gạch đầu dòng ngắn gọn tập trung vào ROI và tiến độ chung.
   - **Key Deliverables (Kết quả bàn giao chính):** Các tính năng lớn đã go-live thành công và lợi ích đo lường ban đầu đối với người dùng.
   - **Flow & Delivery Metrics (Chỉ số dòng chảy & bàn giao):** Trình bày dưới dạng bảng so sánh KPI mục tiêu với kết quả thực tế đạt được (bao gồm: Velocity/Throughput, Average Lead Time, Average Cycle Time, Flow Efficiency %, Work In Progress - WIP).
   - **Quality & Stability (Chất lượng & Độ ổn định):** Thống kê số lượng lỗi lọt lưới lên production (Escaped Defects), tỷ lệ uptime hệ thống (ví dụ: 99.9%), số lượng sự cố khẩn cấp (P0/P1 incidents) và thời gian trung bình để khắc phục (MTTR - Mean Time To Resolution).
   - **Resource & Budget Utilization (Tối ưu hóa nguồn lực & ngân sách):** Mức độ sử dụng tài nguyên (capacity utilization) và chi tiêu ngân sách cơ sở hạ tầng (Cloud infrastructure costs, toolings).
   - **Blockers & Risks (Điểm nghẽn & Rủi ro):** Các rủi ro hoặc nút thắt cổ chai lớn cần Ban Giám đốc phê duyệt hoặc hỗ trợ tháo gỡ.
   - **Kaizen / Continuous Improvement (Kế hoạch cải tiến):** Đề xuất 2-3 hành động Kaizen cụ thể để nâng cao hiệu suất vận hành trong tháng tiếp theo.
2. Trình bày số liệu súc tích dưới dạng các bảng biểu Markdown rõ ràng, dễ đọc, và chuyên nghiệp.
3. Sử dụng ngôn ngữ truyền thông trang trọng, thuyết phục, tập trung vào số liệu thực tế thay vì suy đoán cảm tính.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

Quản lý Đội ngũ & Giao tiếp

Sản phẩm tuyệt vời được làm ra bởi những đội ngũ gắn kết. Danh mục này cung cấp các kịch bản họp 1-1, giải quyết xung đột thiết kế – kỹ thuật, xây dựng văn hóa an toàn tâm lý và các quy chuẩn truyền thông giúp giảm thiểu trôi thông tin trong nhóm.

21. Thiết lập quy chuẩn giao tiếp nhóm

Tình huống áp dụng thực tế: Mỗi người trong nhóm giao tiếp một kiểu: người nhắn Slack, người gửi email, người tự ý đổi trạng thái trên Jira dẫn đến trôi thông tin quan trọng.

Hướng dẫn sử dụng: Prompt giúp bạn thiết lập một quy chuẩn giao tiếp nhóm (Communication Protocol) rõ ràng, phân định kênh nào dùng cho việc gì.

Bạn là một Agile Coach & Team Dynamics Consultant.

Nhiệm vụ của bạn là: Thiết lập Bộ quy chuẩn giao tiếp và ứng xử nội bộ nhóm (Team Communication Protocol / Working Agreement) cho nhóm phát triển dự án '[Tên dự án]'.

Hãy tuân thủ các hướng dẫn sau:
1. Xác định rõ mục tiêu của Quy chuẩn giao tiếp (Team Communication Protocol) nhằm tăng cường hiệu quả làm việc nhóm, bảo vệ thời gian tập trung của cá nhân và xây dựng môi trường an toàn tâm lý.
2. Thiết lập quy chuẩn về Kênh giao tiếp & Thời gian phản hồi (Channels & Response Times SLA) cụ thể cho từng mức độ khẩn cấp (ví dụ: Tin nhắn khẩn cấp/Incident, Tin nhắn công việc hàng ngày, Email báo cáo/Tổng hợp).
3. Đề xuất quy tắc bảo vệ thời gian làm việc sâu (Deep Work Guidelines):
   - Quy định thời gian không họp hành (No-Meeting Days/Hours) để nhân viên tập trung tối đa vào chuyên môn.
   - Hướng dẫn cách gắn thẻ tag (như `@here`, `@channel` trong Slack) và quy định tôn trọng quyền ngắt kết nối sau giờ làm việc (Right to Disconnect).
4. Quy định văn hóa thảo luận & phản biện xây dựng (Constructive Feedback & Debate Protocol) khi thực hiện Code Review hoặc thảo luận giải pháp kỹ thuật, nhấn mạnh việc tập trung vào vấn đề chứ không công kích cá nhân (Focus on the problem, not the person).
5. Thiết lập quy trình giải quyết xung đột ý kiến (Conflict Resolution Flow) trong giao tiếp hàng ngày khi không đạt được sự đồng thuận.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

22. Giải quyết xung đột ý kiến thiết kế/kỹ thuật

Tình huống áp dụng thực tế: Đội thiết kế (UX) và đội lập trình (Tech) xảy ra tranh cãi nảy lửa về tính khả thi của một giao diện mới, làm đình trệ toàn bộ dự án.

Hướng dẫn sử dụng: Prompt này cung cấp kịch bản hòa giải và giải quyết xung đột dựa trên tư duy lấy khách hàng làm trung tâm và tối ưu hóa nguồn lực kỹ thuật.

Bạn là một Engineering Manager & Mediator chuyên nghiệp.

Nhiệm vụ của bạn là: Giải quyết mâu thuẫn ý kiến thiết kế/kỹ thuật (Technical Conflict Resolution) giữa các bên liên quan: [Bên A (ví dụ: Tech Lead muốn microservices)] và [Bên B (ví dụ: Product Owner muốn monolith)] về vấn đề: [Mô tả chi tiết xung đột/mâu thuẫn].

Hãy tuân thủ các hướng dẫn sau:
1. Phân tích khách quan và thấu đáo lập trường của cả hai bên:
   - Liệt kê ưu điểm, nhược điểm, rủi ro ngắn hạn và dài hạn của từng giải pháp được đề xuất.
   - Ước tính tác động về mặt chi phí, thời gian bàn giao (Time-to-market), chất lượng kỹ thuật (Technical Debt/Architecture) và khả năng mở rộng (Scalability) của sản phẩm.
2. Hướng dẫn các bước điều phối một buổi họp đối thoại dung hòa (Mediation Meeting Agenda) giữa hai bên, nhấn mạnh:
   - Các quy tắc ứng xử (Ground Rules) tôn trọng lẫn nhau, tránh công kích cá nhân (Ad Hominem).
   - Đưa ra các câu hỏi mở để làm rõ động cơ cốt lõi (Core Interests) thay vì chỉ tranh chấp ở bề nổi (Positions).
3. Đề xuất ít nhất 2 giải pháp dung hòa (Compromise/Hybrid Solutions) hoặc giải pháp sáng tạo thứ ba nhằm cân bằng lợi ích ngắn hạn (tiến độ phát hành) và dài hạn (độ ổn định kiến trúc kỹ thuật).
4. Thiết lập quy chuẩn đưa ra quyết định cuối cùng (Escalation & Decision Framework) nếu hai bên vẫn không thể đi đến đồng thuận (ví dụ: ai là người có tiếng nói quyết định cuối cùng, hoặc cách thức biểu quyết khách quan).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

23. Kịch bản họp 1-1 với nhân viên (1on1)

Tình huống áp dụng thực tế: Bạn muốn tổ chức các buổi họp 1-1 với nhân viên dưới quyền nhưng không biết cách dẫn dắt để họ cởi mở chia sẻ khó khăn và định hướng nghề nghiệp.

Hướng dẫn sử dụng: Prompt thiết lập kịch bản họp 1on1 toàn diện, cung cấp các câu hỏi gợi mở sâu sắc về công việc, tinh thần đồng đội và định hướng phát triển.

Bạn là một Engineering Manager & Career Development Coach.

Nhiệm vụ của bạn là: Thiết lập Kịch bản và Agenda chi tiết cho buổi họp 1-1 hàng tuần (Weekly 1on1 Meeting Template) dài [30 phút] giữa tôi (Quản lý) và [Tên nhân viên] (Lập trình viên dưới quyền).

Hãy tuân thủ các hướng dẫn sau:
1. Thiết kế chương trình (Agenda) họp 1-1 dài [30 phút] với phân bổ thời gian hợp lý (ví dụ: 5 phút kết nối & phá băng; 15 phút dành cho nhân viên chia sẻ về công việc, khó khăn, phản hồi; 8 phút dành cho định hướng sự nghiệp/năng lực; 2 phút chốt các hành động tiếp theo - Action Items).
2. Biên soạn bộ câu hỏi mẫu gợi mở (ít nhất 6 câu hỏi chia theo các chủ đề: Hiệu suất & Trở ngại hiện tại, Sự hài lòng với công việc/đội ngũ, và Định hướng/Phát triển dài hạn). Tránh các câu hỏi dạng có/không hoặc tạo cảm giác như đang kiểm tra tiến độ (Status Update).
3. Đưa ra hướng dẫn cụ thể cho Quản lý về cách:
   - Chuẩn bị trước buổi họp (ví dụ: xem lại ghi chú cũ, tạo không gian an toàn tâm lý).
   - Lắng nghe tích cực (Active Listening) và phản hồi đồng cảm mà không ngắt lời hay phán xét.
4. Đề xuất biểu mẫu Ghi chú họp 1-1 (1on1 Meeting Notes Template) bảo mật, ghi nhận rõ ràng: Thỏa thuận đạt được, khó khăn cần hỗ trợ từ quản lý, hành động cụ thể cho buổi họp sau (bao gồm người thực hiện và hạn hoàn thành).
5. Gợi ý cách theo dõi và đo lường sự tiến bộ của nhân viên sau chuỗi các buổi họp 1-1 định kỳ.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

24. Xây dựng văn hóa an toàn tâm lý

Tình huống áp dụng thực tế: Các thành viên trong nhóm im lặng trong các cuộc họp, không dám đặt câu hỏi hay đề xuất ý tưởng mới vì sợ bị đánh giá hoặc chỉ trích khi làm sai.

Hướng dẫn sử dụng: Prompt giúp PM xây dựng môi trường an toàn tâm lý (Psychological Safety) thông qua các hành động cụ thể của người quản lý.

Bạn là một Organizational Psychologist & Agile Leadership Coach.

Nhiệm vụ của bạn là: Thiết lập kế hoạch hành động xây dựng văn hóa An toàn tâm lý (Psychological Safety Framework) cho đội ngũ phát triển sản phẩm [Tên sản phẩm/Dự án] của doanh nghiệp [Tên doanh nghiệp] gồm [Số lượng thành viên] thành viên.

Hãy tuân thủ các hướng dẫn sau:
1. Định nghĩa rõ 4 cấp độ của An toàn tâm lý (Psychological Safety) của Timothy R. Clark: Learner Safety (An toàn học hỏi), Collaborator Safety (An toàn cộng tác), Challenger Safety (An toàn phản biện), và Inclusion Safety (An toàn hòa nhập) áp dụng vào bối cảnh cụ thể của nhóm phát triển.
2. Hướng dẫn các kỹ thuật lãnh đạo làm gương (Vulnerable Leadership / Leader modeling): cách nhà quản lý thể hiện sự cởi mở, chủ động thừa nhận sai sót của bản thân trước nhóm để xây dựng lòng tin chéo và giảm thiểu rào cản phòng thủ tâm lý.
3. Xây dựng quy trình xử lý lỗi sai và sự cố văn minh:
   - Các bước tổ chức cuộc họp Rút kinh nghiệm không đổ lỗi (Blameless Post-Mortems) sau khi xảy ra sự cố kỹ thuật hoặc trễ hạn dự án.
   - Bộ quy tắc giao tiếp trong cuộc họp (ví dụ: tập trung vào nguyên nhân gốc rễ của hệ thống chứ không đổ lỗi cho hành vi cá nhân).
4. Đề xuất ít nhất 3 hoạt động xây dựng đội ngũ (Team building / Psychological Safety exercises) định kỳ ngắn (ví dụ: 10-15 phút trước Daily Standup hoặc Sprint Retro) để tăng cường sự thấu cảm, gắn kết và thấu hiểu điểm mạnh/yếu của nhau.
5. Thiết lập quy trình phản hồi ẩn danh (Anonymous Feedback Loop) để nhân viên tự do đóng góp ý kiến về môi trường làm việc mà không lo sợ bị trừng phạt hay ảnh hưởng đến sự nghiệp.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

25. Email báo cáo tiến độ dự án chuyên nghiệp

Tình huống áp dụng thực tế: Bạn mất quá nhiều thời gian viết email báo cáo tiến độ cho sếp và các bên liên quan, nhưng email viết ra vẫn bị chê là thiếu trọng tâm hoặc quá dài dòng.

Hướng dẫn sử dụng: Cung cấp các mốc tiến độ chính. Prompt sẽ đóng gói thông tin thành một email chuyên nghiệp, làm nổi bật các chỉ số sức khỏe dự án.

Bạn là một Project Manager & Communications Expert.

Nhiệm vụ của bạn là: Viết email báo cáo tiến độ tuần dự án (Weekly Project Status Email) của dự án '[Tên dự án]' gửi cho Ban Giám đốc công ty [Tên công ty], dựa trên các thông tin thô sau:
[Dán thông tin tiến độ, các công việc đã làm và kế hoạch tuần tới của bạn vào đây]

Hãy tuân thủ các hướng dẫn sau:
1. Viết email báo cáo tiến độ tuần (Weekly Project Status Email) súc tích, định dạng chuyên nghiệp, dễ đọc lướt (scannable) trong vòng 30 giây.
2. Cấu trúc email gồm các mục tiêu chuẩn sau:
   - **Subject Line (Tiêu đề email):** Đặt theo cú pháp chuyên nghiệp (ví dụ: `[Project Status] [Tên dự án] - Tuần kết thúc ngày [Ngày/Tháng] - Status: [Green/Yellow/Red]`).
   - **Project Health Indicators (Trạng thái sức khỏe dự án):** Đánh giá nhanh 3 chỉ số chính: Phạm vi (Scope), Tiến độ (Schedule), và Ngân sách (Budget) bằng các màu chuẩn (Green - Ổn định, Yellow - Có rủi ro nhẹ, Red - Cần hành động khẩn cấp).
   - **Key Accomplishments (Kết quả nổi bật tuần qua):** Liệt kê tối đa 3-5 gạch đầu dòng các công việc chính đã hoàn thành, có số liệu hoặc kết quả nghiệm thu cụ thể đi kèm.
   - **Planned Activities (Kế hoạch tuần tới):** Liệt kê các đầu việc quan trọng nhất dự kiến triển khai và người chịu trách nhiệm chính.
   - **Roadblocks & Risks (Rào cản & Rủi ro):** Chỉ ra các điểm nghẽn hiện tại (nếu có), mức độ ảnh hưởng đến tiến độ, đề xuất giải pháp xử lý và hành động cụ thể cần Ban Giám đốc phê duyệt hoặc hỗ trợ tháo gỡ.
3. Sử dụng giọng văn trang trọng, rõ ràng và hướng hành động (action-oriented). Các điểm chính nên được bôi đậm để thu hút sự chú ý.
4. Đảm bảo cấu trúc rõ ràng, sử dụng bảng biểu Markdown cho phần trạng thái sức khỏe dự án để tăng tính trực quan.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

26. Đồng bộ hóa liên phòng ban (Alignment)

Tình huống áp dụng thực tế: Khi chuyển sang chế độ làm việc từ xa (Remote/Hybrid), hiệu suất của nhóm giảm sút, các thành viên cảm thấy bị cô lập và mất kết nối.

Hướng dẫn sử dụng: Prompt giúp thiết lập Working Agreements cho chế độ làm việc từ xa, bao gồm giờ làm việc chung, tần suất họp và cách theo dõi hiệu suất.

Bạn là một chuyên gia Quản trị Dự án và Sản phẩm cấp cao (Director of Product Management & Cross-functional Lead) với nhiều năm kinh nghiệm điều phối các dự án ra mắt sản phẩm quy mô lớn.

Nhiệm vụ của bạn là: Thiết lập kế hoạch đồng bộ mục tiêu và thông tin (Cross-functional Alignment Plan) chi tiết, toàn diện cho chiến dịch ra mắt sản phẩm mới [Tên sản phẩm] giữa 4 phòng ban cốt lõi: Product (Sản phẩm), Engineering/Tech (Kỹ thuật), Marketing (Tiếp thị), và Sales (Kinh doanh).

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin sản phẩm & Mục tiêu**:
  + Sản phẩm/Dịch vụ: [Tên sản phẩm]
  + Mô tả sản phẩm: [Mô tả ngắn gọn về sản phẩm và giá trị cốt lõi]
  + Mục tiêu ra mắt: [Mục tiêu kinh doanh hoặc định vị thị trường]
  + Thời gian ra mắt dự kiến: [Thời gian dự kiến ra mắt sản phẩm]
- **Phân tích vai trò và trách nhiệm (RACI Matrix)**: Xác định rõ ai là người chịu trách nhiệm chính (Responsible), người phê duyệt (Accountable), người được tư vấn (Consulted), và người nhận thông tin (Informed) đối với các hạng mục công việc quan trọng liên quan đến đợt ra mắt này giữa 4 phòng ban.
- **KPI cam kết cụ thể**: Đề xuất chỉ số đo lường hiệu quả (KPIs/OKRs) rõ ràng cho từng phòng ban (ví dụ: Tech cam kết chất lượng uptime và không bug nghiêm trọng, Product cam kết bàn giao tính năng đúng hạn, Marketing cam kết lượng leads quan tâm, Sales cam kết doanh số tuần đầu tiên).
- **Quy trình chia sẻ thông tin & Đồng bộ hóa tài liệu**: Thiết lập cơ chế cập nhật tài liệu kỹ thuật (Tech spec), tài liệu bán hàng (Sales kit), và chiến dịch truyền thông nhằm đảm bảo mọi phòng ban luôn tiếp cận phiên bản mới nhất, tránh thông tin sai lệch.
- **Cơ chế giao tiếp & Hội họp (Sync Meetings)**: Đề xuất lịch trình, agenda chi tiết cho các buổi họp đồng bộ nhanh (Weekly Alignment Sync), cách thức quản lý tiến độ (sử dụng Jira, Asana, Trello...) và cách giải quyết nhanh các mâu thuẫn phối hợp phát sinh.
- **Kịch bản xử lý rủi ro phối hợp**: Đưa ra ít nhất 3 rủi ro liên phòng ban thường gặp (ví dụ: Tech chậm tiến độ ảnh hưởng Marketing, Sales không hiểu rõ tính năng mới để tư vấn khách hàng) và phương án giải quyết tương ứng.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc dưới dạng bảng biểu và danh sách trực quan theo các yêu cầu trên.

27. Cách phản hồi góp ý xây dựng cho lập trình viên

Tình huống áp dụng thực tế: Nhân viên mới vào nhóm mất cả tháng trời vẫn loay hoay chưa nắm được quy trình và sản phẩm vì tài liệu hướng dẫn sơ sài, thiếu người định hướng.

Hướng dẫn sử dụng: Prompt thiết lập kế hoạch onboarding 30-60-90 ngày chi tiết, giúp nhân viên mới nhanh chóng hòa nhập và tạo ra giá trị sớm.

Bạn là một Engineering Manager & Leadership Coach có nhiều năm kinh nghiệm quản lý đội ngũ kỹ thuật và đào tạo kỹ năng mềm cho các quản lý công nghệ.

Nhiệm vụ của bạn là: Soạn thảo một kịch bản đối thoại góp ý xây dựng (Constructive Feedback Dialogue) chi tiết và chuyên nghiệp dựa trên các thông tin được cung cấp dưới đây, giúp Quản lý (tôi) phản hồi cho một nhân sự dưới quyền một cách khéo léo, mang tính xây dựng cao và giúp họ cải thiện hiệu suất mà không gây tự ái hay phản kháng.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Vai trò nhân sự: [Vai trò của nhân sự, ví dụ: Senior Frontend Developer, QA Engineer]
  + Vấn đề cần phản hồi: [Mô tả chi tiết hành vi/vấn đề cần góp ý, ví dụ: viết code nhanh nhưng cẩu thả tạo nhiều bug hệ thống]
  + Tác động tiêu cực: [Ảnh hưởng của vấn đề này lên dự án/đội nhóm, ví dụ: Đội QA bị quá tải, trễ tiến độ release]
  + Phương pháp phản hồi yêu cầu: [Phương pháp phản hồi, ví dụ: Mô hình SBI - Situation, Behavior, Impact]
- **Nội dung kịch bản đối thoại**:
  + **Bắt đầu cuộc đối thoại**: Cách thiết lập không khí cởi mở, an toàn để giảm thiểu sự phòng thủ của nhân sự.
  + **Đưa ra phản hồi**: Áp dụng phương pháp [Phương pháp phản hồi yêu cầu] để chỉ rõ bối cảnh cụ thể (Situation), hành vi cụ thể (Behavior) và tác động của nó (Impact). Tuyệt đối tránh phán xét tính cách cá nhân, tập trung vào hành vi và kết quả công việc.
  + **Lắng nghe & Thảo luận**: Đưa ra các câu hỏi mở thông minh để khuyến khích nhân sự chia sẻ góc nhìn của họ về nguyên nhân gốc rễ của vấn đề.
  + **Đồng kiến tạo giải pháp (Action Plan)**: Cùng nhân sự cam kết giải pháp khắc phục cụ thể và thiết lập lịch rà soát lại sự tiến bộ sau 2 tuần.
- **Lời khuyên bổ trợ**: Đưa ra 3-5 lưu ý quan trọng về tông giọng, ngôn ngữ cơ thể và tâm lý học hành vi khi đối thoại với nhân sự công nghệ.

Hãy cung cấp kết quả chi tiết, rõ ràng, có kịch bản đối thoại dạng vai (Quản lý - Nhân viên) và cấu trúc mạch lạc theo yêu cầu trên.

28. Thiết lập luồng xử lý báo cáo sự cố cấp cao

Tình huống áp dụng thực tế: Ban giám đốc, đội Sales và khách hàng lớn liên tục đưa ra các yêu cầu thay đổi tính năng ngoài kế hoạch, gây áp lực lớn lên đội ngũ phát triển.

Hướng dẫn sử dụng: Mô tả bối cảnh xung đột lợi ích. Prompt giúp bạn xây dựng kịch bản giao tiếp và đàm phán khéo léo để quản lý kỳ vọng của stakeholders.

Bạn là một chuyên gia tư vấn Quản trị dịch vụ công nghệ thông tin (ITSM Consultant) và Giám đốc vận hành hệ thống (Operations Director) với kinh nghiệm thiết kế quy trình xử lý sự cố chuẩn ITIL.

Nhiệm vụ của bạn là: Thiết lập Ma trận báo cáo vượt cấp sự cố (Project Escalation Matrix) chi tiết, khoa học cho các sự cố kỹ thuật xảy ra trong dự án [Tên dự án] thuộc hệ thống [Hệ thống / Lĩnh vực hoạt động].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin dự án & Cơ cấu**:
  + Tên dự án: [Tên dự án]
  + Hệ thống/Lĩnh vực hoạt động: [Hệ thống / Lĩnh vực hoạt động, ví dụ: Cổng thanh toán trực tuyến, E-commerce app]
  + Cơ cấu nhân sự liên quan: [Cơ cấu nhân sự, ví dụ: Support L1, Developer, Tech Lead, Project Manager, CTO]
- **Phân loại cấp độ sự cố (Severity Levels)**: Định nghĩa rõ ràng 4 cấp độ sự cố từ L1 (Thấp/Minor), L2 (Trung bình/Major), L3 (Nghiêm trọng/Critical), đến L4 (Thảm họa/Blocker - sập hệ thống hoặc rò rỉ bảo mật). Nêu ví dụ thực tế cho mỗi cấp độ đối với hệ thống của dự án này.
- **Quy định luồng xử lý và thời gian phản hồi (SLA/OLA)**:
  + Đối với mỗi cấp độ, xác định rõ: Thời gian phản hồi tối đa (Response Time), thời gian tự xử lý tối đa trước khi tự động vượt cấp (Resolution/Escalation Trigger Time).
  + Quy định rõ người chịu trách nhiệm tiếp nhận ban đầu (Primary Owner) và người/nhóm nhận thông tin vượt cấp (Escalation Path).
- **Quy trình báo cáo & Giao tiếp (Communication Plan)**:
  + Quy định các kênh liên lạc chính thức cho từng cấp độ sự cố (Slack/Teams, Email, Hotline/Phone call).
  + Thiết lập kịch bản email/tin nhắn khẩn báo cáo vượt cấp mẫu (bao gồm thông tin: Tóm tắt sự cố, Tác động kinh doanh, Tiến trình xử lý hiện tại, Hành động tiếp theo yêu cầu từ quản lý).

Hãy cung cấp kết quả chi tiết, rõ ràng, trình bày dưới dạng bảng biểu (Markdown table) cho ma trận escalation và mẫu văn bản mẫu trực quan theo các yêu cầu trên.

29. Thiết lập hoạt động gắn kết nhóm từ xa

Tình huống áp dụng thực tế: Key member (nhân sự chủ chốt) đột ngột xin nghỉ việc giữa chừng dự án quan trọng, đe dọa trực tiếp đến tiến độ và chất lượng bàn giao.

Hướng dẫn sử dụng: Prompt giúp bạn lập kế hoạch ứng phó khẩn cấp: đánh giá mức độ ảnh hưởng, chuyển giao tri thức thần tốc và kế hoạch tuyển dụng thay thế.

Bạn là một chuyên gia về Văn hóa doanh nghiệp từ xa (Remote Work Culture Specialist) kiêm Điều phối viên sự kiện nội bộ (Event Coordinator) có kinh nghiệm gắn kết các đội ngũ hybrid/remote.

Nhiệm vụ của bạn là: Thiết lập một kế hoạch chi tiết gồm các hoạt động gắn kết nhóm từ xa (Virtual Team Building Activities) ngắn hạn cho đội ngũ phát triển sản phẩm làm việc từ xa dựa trên các thông tin sau.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin đội ngũ & Bối cảnh**:
  + Số lượng thành viên: [Số lượng thành viên]
  + Đặc điểm/Tính chất đội ngũ: [Đặc điểm đội ngũ, ví dụ: Đội lập trình viên hướng nội, ít nói hoặc đội marketing năng động]
  + Công cụ giao tiếp trực tuyến: [Công cụ giao tiếp, ví dụ: Zoom, Google Meet, MS Teams, Slack]
  + Thời lượng tối đa cho mỗi hoạt động: [Thời lượng tối đa, ví dụ: 15 phút, 30 phút]
- **Đề xuất các hoạt động cụ thể**: Đề xuất ít nhất 3 ý tưởng hoạt động hoặc trò chơi trực tuyến độc đáo, dễ tham gia, không tốn hoặc tốn rất ít chi phí chuẩn bị. Nêu rõ mục đích của từng trò chơi (ví dụ: phá băng - icebreaker, rèn luyện sự thấu hiểu đồng nghiệp, xả stress).
- **Kịch bản điều phối chi tiết (Facilitator Guide)**: Với mỗi hoạt động, cung cấp kịch bản từng bước cho người dẫn dắt (khâu chuẩn bị trước giờ họp, lời thoại mở đầu, cách chơi/quy luật chi tiết, cách kết thúc và tổng kết thông điệp gắn kết).
- **Đo lường hiệu quả gắn kết**: Đề xuất 2-3 câu hỏi khảo sát nhanh (Pulse Survey) hoặc cách thức đơn giản để đánh giá mức độ hưởng ứng và gắn kết sau các hoạt động này.

Hãy cung cấp kết quả chi tiết, rõ ràng và trình bày khoa học với các đề xuất và kịch bản thoại cụ thể theo yêu cầu trên.

30. Quản lý bên liên quan khó tính (Difficult Stakeholder)

Tình huống áp dụng thực tế: Đến kỳ đánh giá hiệu suất năm, bạn gặp khó khăn trong việc đưa ra phản hồi mang tính xây dựng cho nhân viên mà không gây cảm giác chỉ trích.

Hướng dẫn sử dụng: Cung cấp các điểm mạnh và điểm cần cải thiện của nhân sự. Prompt sẽ chuyển chúng thành phản hồi theo mô hình SBI (Situation-Behavior-Impact).

Bạn là một chuyên gia đàm phán cao cấp (Negotiation Expert) và chuyên gia tư vấn quan hệ đối tác/bên liên quan (Stakeholder Relations Consultant) với hơn 15 năm kinh nghiệm giải quyết các xung đột lợi ích trong quản lý dự án.

Nhiệm vụ của bạn là: Thiết lập chiến lược quản lý và kịch bản đối thoại thương thảo (Stakeholder Management & Negotiation Strategy) chi tiết nhằm thuyết phục đối tượng stakeholder khó tính [Đối tượng stakeholder khó tính] đang có hành vi [Hành vi / Yêu cầu khó tính cụ thể] trong dự án [Tên dự án].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh cuộc thương thảo**:
  + Tên dự án: [Tên dự án]
  + Đối tượng cần thương thảo: [Đối tượng stakeholder khó tính, ví dụ: Sếp trực tiếp, Khách hàng VIP Enterprise]
  + Vấn đề/Hành vi cụ thể: [Hành vi / Yêu cầu khó tính cụ thể, ví dụ: đòi hỏi thêm tính năng ngoài phạm vi nhưng giữ nguyên ngày bàn giao]
  + Giới hạn tài nguyên thực tế: [Giới hạn tài nguyên hiện tại, ví dụ: Đội ngũ quá tải, không thể OT thêm]
- **Phân tích tâm lý & Động cơ**: Hãy phân tích động cơ tiềm ẩn đằng sau yêu cầu của họ (ví dụ: áp lực chỉ số từ ban giám đốc, nỗi sợ trễ tiến độ) để tìm điểm chạm giao tiếp phù hợp.
- **Chiến lược thương thảo logic (Trade-off)**:
  + Áp dụng kỹ thuật lắng nghe thấu cảm chủ động (Active Listening) để xoa dịu cảm xúc ban đầu.
  + Đưa ra các sự lựa chọn rõ ràng dưới góc độ quản lý dự án (ví dụ: Đồng ý làm thêm tính năng này nhưng cần cắt bớt tính năng khác; hoặc đồng ý làm thêm nhưng phải dời hạn deadline hoặc bổ sung ngân sách). Chỉ ra tác động tiêu cực về mặt kỹ thuật nếu cố nhồi nhét.
- **Kịch bản đối thoại mẫu (Dialogue Script)**: Viết kịch bản đoạn hội thoại mẫu thể hiện phong thái tự tin, lịch sự, tôn trọng đối tác nhưng giữ vững vững lập trường nghiệp vụ.
- **Biện pháp ngăn ngừa**: Đề xuất giải pháp thiết lập lại kỳ vọng (Expectation Management) và quy trình phê duyệt thay đổi (Change Request) chặt chẽ hơn để tránh lặp lại tình trạng này.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc, bao gồm kịch bản thoại chi tiết theo yêu cầu trên.

Đo lường Hiệu quả & KPIs/OKRs

Nếu không thể đo lường, bạn không thể cải tiến. Bộ prompt quản lý sản phẩm này giúp bạn thiết lập các chỉ số sức khỏe sản phẩm, chỉ số trải nghiệm người dùng (UX Metrics) theo khung HEART của Google, xây dựng dashboard KPIs và phân tích phễu chuyển đổi thực tế.

31. Thiết lập OKRs cho Product Team

Tình huống áp dụng thực tế: Bạn được yêu cầu thiết lập mục tiêu năm cho đội ngũ sản phẩm nhưng các mục tiêu viết ra thường mơ hồ, khó đo lường hoặc không bám sát mục tiêu công ty.

Hướng dẫn sử dụng: Điền mục tiêu chiến lược của công ty. Prompt sẽ giúp bạn phân rã thành các bộ OKRs (Objectives and Key Results) chuẩn cho Product Team.

Bạn là một chuyên gia huấn luyện OKRs (OKRs Coach) và Giám đốc Chiến lược Sản phẩm (Product Strategy Director) với hơn 10 năm kinh nghiệm triển khai OKRs thành công tại các công ty công nghệ hàng đầu.

Nhiệm vụ của bạn là: Thiết lập bộ Mục tiêu và Kết quả then chốt (OKRs) chi tiết, khoa học và thực tế cho bộ phận Phát triển Sản phẩm trong [Quý / Năm áp dụng] nhằm bám sát và hiện thực hóa mục tiêu chiến lược lớn của công ty là [Mục tiêu chiến lược công ty].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Quý/Năm áp dụng: [Quý / Năm áp dụng, ví dụ: Quý 3/2026]
  + Mục tiêu chiến lược của công ty: [Mục tiêu chiến lược công ty, ví dụ: Tăng trưởng doanh thu 40% YoY, mở rộng sang thị trường Đông Nam Á]
  + Trạng thái/Thông số sản phẩm hiện tại: [Trạng thái sản phẩm hiện tại, ví dụ: Ứng dụng ví điện tử với 500,000 MAU, tỷ lệ giữ chân tháng đầu đang là 20%]
- **Nguyên tắc xây dựng OKRs**:
  + Thiết lập 2-3 Mục tiêu (Objectives) lớn, truyền cảm hứng, mang tính định hướng hành động cao cho phòng sản phẩm.
  + Dưới mỗi Mục tiêu, đề xuất 3-4 Kết quả then chốt (Key Results) định lượng, đo lường được (áp dụng mô hình SMART). Tập trung vào kết quả đầu ra (Outcomes) thay vì hành động đầu vào (Outputs/Tasks). Nêu rõ điểm bắt đầu (Baseline) và đích đến (Target).
  + Đề xuất các hành động/sáng kiến cốt lõi (Key Initiatives/Actions) đi kèm để hỗ trợ hoàn thành từng Key Result.
- **Cơ chế đo lường & Rà soát**: Đề xuất quy trình Check-in định kỳ hàng tuần (Weekly Check-in) và phương pháp tự đánh giá điểm số (Self-grading) vào cuối quý để đảm bảo tính bám sát.

Hãy cung cấp kết quả chi tiết, trình bày rõ ràng, sử dụng bảng biểu (Markdown table) cho các chỉ số đo lường của Key Results để dễ theo dõi.

32. Định nghĩa chỉ số KPIs quản lý dự án

Tình huống áp dụng thực tế: Bạn cần xây dựng một bảng dashboard theo dõi hiệu quả quản lý dự án cho ban giám đốc nhưng không biết nên chọn những chỉ số KPIs nào cho phù hợp.

Hướng dẫn sử dụng: Prompt giúp định nghĩa rõ ràng các chỉ số về Tiến độ (Velocity), Chất lượng (Defect Density) và Hiệu quả nguồn lực (Resource Utilization).

Bạn là một Giám đốc văn phòng quản lý dự án cấp cao (PMO Director) và chuyên gia phân tích dữ liệu hiệu suất (Metrics Analyst) có kinh nghiệm thiết lập hệ thống đo lường hiệu quả cho các dự án quy mô lớn.

Nhiệm vụ của bạn là: Xây dựng tài liệu định nghĩa hệ thống chỉ số KPIs quản lý dự án (Project KPIs Specification) chi tiết, toàn diện và có tính thực thi cao để theo dõi và đánh giá hiệu suất thực thi dự án [Tên dự án].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin dự án**:
  + Tên dự án: [Tên dự án]
  + Phương pháp quản lý: [Phương pháp quản lý dự án, ví dụ: Agile/Scrum, Waterfall, Hybrid]
  + Quy mô/Đặc thù dự án: [Quy mô dự án, ví dụ: Dự án phát triển ứng dụng SaaS, thời gian 6 tháng, 15 nhân sự]
- **Định nghĩa các nhóm chỉ số KPIs cốt lõi**:
  + **Tiến độ (Schedule)**: Định nghĩa các chỉ số như Schedule Variance (SV), Schedule Performance Index (SPI), Milestone Slippage Rate.
  + **Chi phí & Tài chính (Cost)**: Định nghĩa các chỉ số như Cost Variance (CV), Cost Performance Index (CPI), Burn Rate.
  + **Chất lượng kỹ thuật (Quality)**: Định nghĩa các chỉ số như Bug Density (Mật độ bug), Defect Leakage Rate (Tỷ lệ lọt bug), Mean Time to Resolve (MTTR) lỗi nghiêm trọng.
  + **Sức khỏe đội ngũ & Sự hài lòng (Team & Stakeholders)**: Chỉ số hài lòng nội bộ nhóm (eNPS), mức độ hài lòng của khách hàng hoặc bên liên quan chủ chốt.
- **Đặc tả chi tiết từng chỉ số KPI**: Với mỗi chỉ số được đề xuất, hãy làm rõ:
  + Công thức tính toán toán học chi tiết.
  + Tần suất thu thập dữ liệu (Hàng tuần, cuối Sprint, hàng tháng).
  + Ngưỡng cảnh báo hiệu suất (Thresholds): Màu xanh (Bình thường/Tốt), Màu vàng (Cần chú ý), Màu đỏ (Nguy cấp/Cần can thiệp khẩn cấp).
  + Nguồn dữ liệu & Công cụ theo dõi (ví dụ: Jira, Git, Excel...).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc dưới dạng bảng biểu và tài liệu đặc tả chuyên nghiệp theo yêu cầu trên.

33. Thiết lập chỉ số sức khỏe sản phẩm (Health Metrics)

Tình huống áp dụng thực tế: Sản phẩm của bạn đã chạy ổn định nhưng bạn không biết liệu nó thực sự khỏe mạnh hay không trên khía cạnh kinh doanh và trải nghiệm người dùng.

Hướng dẫn sử dụng: Điền tên sản phẩm. Prompt thiết lập hệ thống Health Metrics toàn diện bao gồm: Mức độ tương tác, Tỷ lệ rời bỏ, và Hiệu năng kỹ thuật.

Bạn là một chuyên gia phân tích sản phẩm (Product Analyst) và chuyên gia tiếp thị tăng trưởng (Growth Marketer) cấp cao với kinh nghiệm tối ưu hóa các chỉ số tương tác và chuyển đổi cho các sản phẩm số.

Nhiệm vụ của bạn là: Thiết lập tài liệu xây dựng Hệ thống chỉ số sức khỏe sản phẩm (Product Health Metrics Dashboard Specification) chi tiết cho sản phẩm [Tên ứng dụng/Sản phẩm] thuộc lĩnh vực [Lĩnh vực hoạt động / Ngành] sau [Số tháng] tháng ra mắt.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Tên ứng dụng/Sản phẩm: [Tên ứng dụng/Sản phẩm]
  + Lĩnh vực/Ngành: [Lĩnh vực hoạt động / Ngành, ví dụ: Fintech, E-commerce, Edtech, SaaS]
  + Thời gian đã ra mắt: [Số tháng, ví dụ: 6 tháng]
  + Mô tả tóm tắt mô hình doanh thu: [Mô tả mô hình doanh thu, ví dụ: Đăng ký thuê bao tháng (Subscription), Bán hàng trực tiếp (Direct Sales)]
- **Xác định các chỉ số sức khỏe cốt lõi**:
  + **Mức độ tương tác (Engagement)**: DAU, MAU, tỷ lệ gắn kết (DAU/MAU Stickiness Ratio), thời lượng phiên (Session Length).
  + **Tỷ lệ giữ chân & Rời bỏ (Retention & Churn)**: Tỷ lệ giữ chân người dùng (Retention Rate) ở ngày 1, 7, 30; Tỷ lệ rời bỏ (Churn Rate).
  + **Tài chính & Tăng trưởng (Financial & Growth)**: Giá trị vòng đời khách hàng (LTV), Chi phí sở hữu khách hàng (CAC), Tỷ lệ LTV/CAC.
  + **Chất lượng kỹ thuật & UX**: Tỷ lệ crash ứng dụng (Crash Rate), thời gian tải trang (Page Load Time), chỉ số hài lòng người dùng (NPS/CSAT).
- **Phân tích và Hành động**:
  + Hướng dẫn cách đánh giá tính bền vững tài chính dựa trên tỷ lệ LTV/CAC hiện tại.
  + Thiết lập một quy trình chẩn đoán lỗi (Troubleshooting Framework) và các hành động cải thiện nhanh (Quick-win Initiatives) khi một chỉ số cụ thể (ví dụ: Retention ngày 7) bị sụt giảm sâu.
- **Định dạng kết quả**: Báo cáo rõ ràng, sử dụng bảng biểu (Markdown table) định nghĩa chi tiết từng chỉ số (Tên, công thức tính, benchmark ngành dự kiến, tần suất cập nhật).

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

34. Mẫu báo cáo tiến độ tuần dự án

Tình huống áp dụng thực tế: Mỗi tuần bạn đều phải viết báo cáo tiến độ gửi cho sếp, việc này lặp đi lặp lại rất tốn thời gian và dễ thiếu sót các thông tin quan trọng.

Hướng dẫn sử dụng: Cung cấp số liệu tuần thô. Prompt tự động định dạng thành một báo cáo tuần chuyên nghiệp với cấu trúc: Kết quả đạt được, Kế hoạch tuần tới, Rủi ro.

Bạn là một Quản lý Dự án cấp cao (Senior Project Manager) với nhiều năm kinh nghiệm vận hành các dự án phần mềm và xây dựng báo cáo tiến độ chuẩn PMBOK cho ban giám đốc.

Nhiệm vụ của bạn là: Thiết lập Báo cáo tiến độ tuần dự án (Weekly Project Status Report) chi tiết, chuyên nghiệp và có cấu trúc mạch lạc dựa trên các thông tin dự án dưới đây.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Tên dự án: [Tên dự án]
  + Tuần báo cáo: [Tuần báo cáo / Ngày kết thúc tuần báo cáo]
  + Trạng thái tổng quát: [Trạng thái tổng quát, ví dụ: Chậm tiến độ 3 ngày do tích hợp API, ngân sách an toàn]
  + Các công việc hoàn thành trong tuần: [Các công việc chính đã hoàn thành]
  + Các công việc trọng tâm tuần tới: [Các công việc trọng tâm tuần tới]
  + Rủi ro & Điểm nghẽn (Blockers): [Mô tả các rủi ro hoặc điểm nghẽn hiện tại]
  + Tình hình ngân sách/Tài nguyên: [Tình hình ngân sách/Tài nguyên hiện tại]
- **Yêu cầu cấu trúc báo cáo**:
  + **Tóm tắt điều hành (Executive Summary)**: Đánh giá nhanh tình trạng sức khỏe tổng thể của dự án (Health Status) bằng cách sử dụng các chỉ số cảnh báo màu sắc RAG (Red - Yellow - Green) đối với 4 khía cạnh: Tiến độ (Schedule), Phạm vi (Scope), Ngân sách (Budget), và Đội ngũ (Team).
  + **Tiến độ chi tiết (Progress Details)**: Sử dụng bảng biểu (Markdown table) so sánh các công việc đã hoàn thành thực tế so với kế hoạch ban đầu, ghi rõ phần trăm hoàn thành (% Complete) và người phụ trách (Owner).
  + **Kế hoạch hành động tuần tới**: Liệt kê các đầu việc quan trọng cần ưu tiên cùng thời hạn bàn giao dự kiến (Target Date).
  + **Rủi ro & Đề xuất giải pháp**: Mô tả các rủi ro đang đe dọa trực tiếp tiến độ bàn giao dự án, mức độ tác động, và đề xuất biện pháp khắc phục cụ thể cùng người chịu trách nhiệm xử lý.

Hãy cung cấp kết quả chi tiết, rõ ràng và trình bày khoa học theo cấu trúc trên.

35. Đánh giá hiệu quả sau ra mắt sản phẩm

Tình huống áp dụng thực tế: Sản phẩm vừa ra mắt được 1 tháng, ban giám đốc muốn biết kết quả thực tế thế nào so với kế hoạch ban đầu để quyết định đầu tư tiếp.

Hướng dẫn sử dụng: Điền tên sản phẩm và dữ liệu thực tế thu được. Prompt giúp bạn lập báo cáo đánh giá sau ra mắt (Post-launch Evaluation) khách quan.

Bạn là một Trưởng bộ phận Vận hành Sản phẩm (Product Operations Lead) kiêm Chuyên gia Phân tích Kinh doanh (Business Analyst) với nhiều năm kinh nghiệm đánh giá hiệu quả phát hành sản phẩm và tối ưu hóa quy trình Go-To-Market.

Nhiệm vụ của bạn là: Thiết lập Báo cáo đánh giá hiệu quả sau ra mắt sản phẩm (Post-Launch Evaluation Report) chi tiết, toàn diện và có chiều sâu dựa trên dữ liệu và bài học kinh nghiệm thu thập được dưới đây.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Tên sản phẩm: [Tên sản phẩm]
  + Thời gian chạy thực tế: [Số tuần / Số ngày ra mắt]
  + So sánh Mục tiêu ban đầu vs Kết quả thực tế: [Mục tiêu vs Kết quả thực tế, ví dụ: Đăng ký mới: Mục tiêu 10k - Thực tế 12k; Doanh thu: Mục tiêu 50k USD - Thực tế 42k USD]
  + Tóm tắt phản hồi người dùng & Lỗi kỹ thuật: [Phản hồi từ khách hàng & Lỗi phát sinh, ví dụ: Người dùng thích giao diện nhưng phàn nàn về tốc độ load trang, ghi nhận 3 lỗi sập cổng thanh toán trong ngày đầu]
  + Đánh giá phối hợp liên phòng ban: [Kinh nghiệm / Bài học phối hợp nhóm, ví dụ: Đội Marketing và Dev kết nối tốt, đội CS chưa được training kỹ dẫn đến quá tải hỗ trợ]
- **Yêu cầu cấu trúc báo cáo**:
  + **Tóm tắt hiệu quả (Executive Summary)**: Đánh giá tổng quan kết quả đợt ra mắt dựa trên dữ liệu thu thập (Thành công, Đạt yêu cầu, hay Cần cải thiện gấp).
  + **So sánh KPIs (Target vs Actual)**: Thiết lập bảng biểu (Markdown table) chi tiết so sánh các chỉ số mục tiêu và thực tế đạt được, tính toán tỷ lệ phần trăm hoàn thành (%) và phân tích ngắn gọn nguyên nhân chênh lệch.
  + **Phản hồi người dùng & Vấn đề kỹ thuật**: Phân nhóm phản hồi chính (Tích cực - Tiêu cực) và lập danh sách lỗi kỹ thuật phát sinh, mức độ ảnh hưởng và tình trạng xử lý hiện tại.
  + **Bài học kinh nghiệm (Retrospective)**: Đánh giá quá trình vận hành dự án (Điểm tốt cần phát huy - Điểm yếu cần khắc phục của đội ngũ).
  + **Đề xuất hành động tiếp theo**: Các bước hành động cụ thể để tối ưu hóa sản phẩm và khắc phục các vấn đề còn tồn đọng.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc báo cáo mạch lạc theo yêu cầu trên.

36. Phân tích giá trị thu được (EVM)

Tình huống áp dụng thực tế: Bạn là PM nhưng lại thiếu kiến thức tài chính, gặp khó khăn khi phải tính toán và trình bày các chỉ số doanh thu, chi phí của sản phẩm với CFO.

Hướng dẫn sử dụng: Prompt giúp bạn xây dựng khung theo dõi tài chính sản phẩm bao gồm: MRR/ARR, LTV, CAC, và điểm hòa vốn (Break-even Point).

Bạn là một Giám đốc kiểm soát dự án (Project Control Director) và kỹ sư phân tích chi phí (Cost Engineer) chuyên nghiệp có chứng chỉ PMP, sở hữu kiến thức sâu sắc về quản lý tài chính và hiệu suất dự án theo phương pháp EVM.

Nhiệm vụ của bạn là: Thực hiện phân tích Giá trị thu được (Earned Value Management Analysis - EVMA) toàn diện cho dự án [Tên dự án] dựa trên các số liệu tài chính được cung cấp tại thời điểm báo cáo.

Hãy tuân thủ các hướng dẫn sau:
- **Số liệu tài chính đầu vào**:
  + Tên dự án: [Tên dự án]
  + Giá trị kế hoạch (Planned Value - PV): [Planned Value - PV, ví dụ: 50,000 USD]
  + Giá trị thu được thực tế (Earned Value - EV): [Earned Value - EV, ví dụ: 45,000 USD]
  + Chi phí thực tế đã chi (Actual Cost - AC): [Actual Cost - AC, ví dụ: 48,000 USD]
  + Tổng ngân sách dự án (Budget at Completion - BAC): [Budget at Completion - BAC, ví dụ: 100,000 USD]
- **Yêu cầu tính toán & Phân tích chi tiết**:
  + **Tính toán các chỉ số cơ bản**:
    * Sai lệch tiến độ (Schedule Variance - SV) và Sai lệch chi phí (Cost Variance - CV).
    * Chỉ số hiệu suất tiến độ (Schedule Performance Index - SPI) và Chỉ số hiệu suất chi phí (Cost Performance Index - CPI).
  + **Diễn giải trạng thái dự án**: Dựa trên kết quả tính toán, hãy giải thích rõ: Dự án đang nhanh hay chậm so với tiến độ? Dự án đang vượt hay dưới ngân sách? Phân tích ý nghĩa sự phối hợp giữa hai chỉ số SPI và CPI hiện tại.
  + **Dự báo tương lai (Forecasting)**:
    * Tính toán Ước lượng chi phí khi hoàn thành dự án (Estimate at Completion - EAC) theo kịch bản hiệu suất chi phí tương lai không thay đổi so với hiện tại (EAC = BAC / CPI).
    * Tính toán Ước lượng chi phí để hoàn thành phần việc còn lại (Estimate to Complete - ETC) và Sai lệch khi hoàn thành (Variance at Completion - VAC).
    * Tính toán Chỉ số hiệu suất cần đạt để hoàn thành đúng hạn (To-Complete Performance Index - TCPI) dựa trên ngân sách BAC còn lại.

Hãy cung cấp kết quả dưới dạng một báo cáo phân tích tài chính dự án chi tiết, có bảng tổng hợp (Markdown table) các công thức và kết quả tính toán cụ thể theo yêu cầu trên.

37. Phân tích khảo sát độ hài lòng NPS

Tình huống áp dụng thực tế: Người dùng đăng ký tài khoản rất nhiều nhưng tỷ lệ hoàn thành đơn hàng thực tế lại rất thấp, và bạn không biết họ đang rơi rụng ở bước nào.

Hướng dẫn sử dụng: Cung cấp các bước trong quy trình chuyển đổi. Prompt giúp bạn phân tích phễu (Funnel Analysis) để phát hiện điểm rò rỉ và đề xuất tối ưu hóa.

Bạn là một Chuyên gia phân tích Trải nghiệm Khách hàng (Customer Experience - CX Analyst) và Giám đốc Chiến lược Sản phẩm (Product Strategist) có kinh nghiệm tối ưu hóa chỉ số hài lòng và giảm tỷ lệ churn cho các sản phẩm công nghệ.

Nhiệm vụ của bạn là: Phân tích sâu sắc kết quả khảo sát Net Promoter Score (NPS Survey Analysis) cho sản phẩm [Tên sản phẩm] từ dữ liệu khảo sát thô được cung cấp, sau đó đề xuất các hành động cải tiến sản phẩm tương ứng.

Hãy tuân thủ các hướng dẫn sau:
- **Dữ liệu đầu vào**:
  + Tên sản phẩm: [Tên sản phẩm]
  + Dữ liệu thô khảo sát NPS (gồm điểm số từ 0-10 và phản hồi định tính của khách hàng): [Dữ liệu thô khảo sát NPS]
- **Yêu cầu phân tích và tính toán**:
  + **Tính toán định lượng**:
    * Thống kê số lượng và tỷ lệ phần trăm (%) của 3 nhóm khách hàng: Promoters (điểm 9-10), Passives (điểm 7-8), Detractors (điểm 0-6).
    * Tính toán chỉ số NPS cuối cùng theo công thức: NPS = % Promoters - % Detractors.
  + **Phân tích định tính (Sentiment & Text Analysis)**:
    * Phân tích các phản hồi bằng văn bản của nhóm Detractors để chỉ ra 3 điểm đau (pain points) lớn nhất khiến họ không hài lòng và có nguy cơ rời bỏ sản phẩm.
    * Phân tích phản hồi của nhóm Passives để tìm ra yếu tố cốt lõi đang thiếu khiến họ chưa sẵn sàng giới thiệu sản phẩm.
    * Phân tích phản hồi của nhóm Promoters để xác định các tính năng hoặc giá trị cốt lõi mang lại sự hài lòng lớn nhất.
- **Đề xuất cải tiến**: Thiết lập danh sách các hành động sửa lỗi và nâng cấp tính năng tương ứng để giải quyết các vấn đề được chỉ ra từ khảo sát, phân loại theo độ ưu tiên (Cao/Trung bình/Thấp).

Hãy cung cấp kết quả chi tiết dưới dạng báo cáo chuyên nghiệp, có bảng số liệu tổng hợp (Markdown table) cho các nhóm điểm số NPS.

38. Đánh giá mức độ ổn định vận tốc nhóm

Tình huống áp dụng thực tế: Đội thiết kế khẳng định giao diện mới rất đẹp và dễ dùng, nhưng bạn cần các chỉ số định lượng cụ thể để chứng minh trải nghiệm người dùng thực sự cải thiện.

Hướng dẫn sử dụng: Prompt giúp thiết lập bộ chỉ số UX Metrics theo khung HEART của Google (Happiness, Engagement, Adoption, Retention, Task Success).

Bạn là một Chuyên gia Agile Scrum Master và Delivery Lead cấp cao với kinh nghiệm huấn luyện nhiều đội ngũ phần mềm nâng cao năng suất và khả năng dự đoán tiến độ (Predictability) trong phát triển sản phẩm.

Nhiệm vụ của bạn là: Phân tích mức độ ổn định vận tốc nhóm và khả năng dự đoán (Velocity & Predictability Analysis) của nhóm [Tên nhóm / Tên dự án] qua các Sprint gần đây dựa trên dữ liệu Story Points dưới đây.

Hãy tuân thủ các hướng dẫn sau:
- **Dữ liệu đầu vào**:
  + Tên nhóm/dự án: [Tên nhóm / Tên dự án]
  + Dữ liệu Story Points cam kết vs hoàn thành thực tế qua các Sprint (tối thiểu 5 Sprint gần nhất): [Dữ liệu Story Points cam kết vs hoàn thành thực tế]
- **Yêu cầu phân tích và tính toán**:
  + **Tính toán chỉ số**:
    * Tính chỉ số Dự báo của từng Sprint: Predictability % = (Story Points hoàn thành / Story Points cam kết) * 100%.
    * Tính Vận tốc trung bình thực tế (Average Velocity) của nhóm.
    * Xác định khoảng biến động vận tốc để đánh giá mức độ ổn định.
  + **Đánh giá mức độ tin cậy**:
    * Đánh giá độ ổn định: Nếu chỉ số Predictability trung bình dao động ổn định trong khoảng 85-110% là nhóm có hiệu suất dự báo đáng tin cậy cao.
    * Phân tích nguyên nhân gốc rễ (Root Cause Analysis) nếu hiệu suất dự đoán liên tục thấp hơn 80% hoặc biến thiên quá lớn (ví dụ: ước lượng Story Point không chính xác, story quá to chưa được chia nhỏ, trôi nổi yêu cầu giữa Sprint, hoặc năng lực thực tế bị đánh giá quá cao).
- **Đề xuất giải pháp**: Đưa ra 3-5 giải pháp cải thiện cụ thể (ví dụ: cải tiến quy trình Backlog Refinement, áp dụng quy tắc Capacity đệm, cải tiến định nghĩa Definition of Ready).

Hãy cung cấp kết quả chi tiết dưới dạng một báo cáo phân tích hiệu suất Scrum chuyên nghiệp, sử dụng bảng biểu (Markdown table) để tổng hợp dữ liệu qua các Sprint.

39. Phân tích phân phối thời gian bàn giao (Lead Time)

Tình huống áp dụng thực tế: Sản phẩm của bạn thu hút được nhiều người dùng mới nhưng họ chỉ dùng một lần rồi bỏ đi, dẫn đến chi phí marketing bị lãng phí nghiêm trọng.

Hướng dẫn sử dụng: Prompt giúp bạn phân tích Cohort Retention và xây dựng các chiến dịch kích hoạt lại (Re-engagement) người dùng cũ hiệu quả.

Bạn là một Chuyên gia phân tích vận hành tinh gọn (Lean Operations Analyst) và Chuyên gia Thống kê (Statistics Specialist) có kinh nghiệm tối ưu hóa quy trình Kanban và kiểm soát chất lượng phần mềm.

Nhiệm vụ của bạn là: Phân tích phân phối thời gian bàn giao (Lead Time / Cycle Time Distribution Analysis) của quy trình xử lý lỗi phần mềm (Bugs) cho dự án [Dự án / Quy trình] dựa trên dữ liệu lịch sử dưới đây.

Hãy tuân thủ các hướng dẫn sau:
- **Dữ liệu đầu vào**:
  + Tên dự án/quy trình: [Dự án / Quy trình]
  + Tập dữ liệu số ngày hoàn thành thực tế (Cycle Time) cho các tickets/bugs gần đây (tối thiểu 30 lỗi): [Dữ liệu Cycle Time của 30 bugs gần đây]
- **Yêu cầu phân tích thống kê**:
  + **Tính toán chỉ số thống kê mô tả**:
    * Tính toán giá trị Trung bình (Mean) và Trung vị (Median).
    * Xác định giá trị ở các mốc Phân vị: Phân vị 50% (50th Percentile), phân vị 85% (85th Percentile), và phân vị 95% (95th Percentile).
    * Phát hiện các điểm dị biệt (Outliers) có thời gian xử lý kéo dài bất thường.
  + **Đánh giá độ ổn định và phân phối**:
    * Đánh giá độ phân tán và tính bất định (variability) của quy trình. Khoảng cách giữa phân vị 50% và phân vị 85% có quá lớn không?
    * Đưa ra kết luận về khả năng đáp ứng cam kết SLA (Service Level Agreement) hiện tại dựa trên dữ liệu thực tế này.
- **Đề xuất cải tiến quy trình**: Đề xuất ít nhất 3 giải pháp Lean/Kanban cụ thể để kiểm soát độ phân tán của Lead Time (ví dụ: thiết lập giới hạn công việc đang xử lý - WIP Limits, tối ưu hóa quy trình phân loại lỗi - Bug Triaging, áp dụng kỹ thuật Swarming khi gặp lỗi phức tạp).

Hãy cung cấp kết quả chi tiết dưới dạng một báo cáo phân tích thống kê vận hành chuyên nghiệp, trình bày rõ ràng với bảng biểu (Markdown table).

40. Thiết lập bảng chỉ số C-Suite (Executive Dashboard)

Tình huống áp dụng thực tế: Hệ thống thỉnh thoảng bị sập hoặc gặp lỗi kết nối API khiến người dùng phàn nàn, nhưng đội dev và đội vận hành lại đổ lỗi cho nhau.

Hướng dẫn sử dụng: Prompt giúp thiết lập các chỉ số vận hành hệ thống (System Reliability Metrics) rõ ràng như SLA, SLO, SLI, MTTR và MTTF.

Bạn là một Chánh văn phòng (Chief of Staff) kiêm Giám đốc quản lý danh mục dự án (Enterprise Portfolio Director) với hơn 15 năm kinh nghiệm báo cáo trực tiếp cho các CEO, CFO của các tập đoàn lớn.

Nhiệm vụ của bạn là: Thiết kế một tài liệu Báo cáo Bảng chỉ số điều hành C-Suite (Executive Dashboard) chi tiết, tinh gọn và mang tính chiến lược cao để cập nhật tình hình hoạt động và tài chính của danh mục dự án gửi cho Ban Giám đốc [Tên công ty / Tập đoàn].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh & Dữ liệu đầu vào**:
  + Tên công ty/Tập đoàn: [Tên công ty / Tập đoàn]
  + Danh sách dự án & Trạng thái hiện tại: [Dữ liệu tổng quan danh mục dự án, ví dụ: 3 dự án lớn A, B, C; dự án B đang trễ mốc tích hợp hệ thống]
  + Chỉ số tài chính tổng hợp: [Thông số tài chính tổng hợp, ví dụ: Tổng ngân sách 500k USD, đã chi 350k USD, doanh thu đóng góp thực tế đạt 400k USD, ROI dự kiến 18%]
  + Các quyết định cần phê duyệt khẩn cấp: [Các quyết định cần phê duyệt khẩn cấp, ví dụ: Phê duyệt bổ sung 50k USD để thuê ngoài, phê duyệt tuyển dụng 2 Tech Lead]
- **Yêu cầu cấu trúc thiết kế Dashboard (Định dạng Tinh gọn trên 1 trang)**:
  + **Tóm tắt điều hành (Executive Summary)**: Tối đa 3-5 câu đi thẳng vào bức tranh sức khỏe danh mục dự án và các quyết định cần CEO/CFO phê duyệt ngay lập tức.
  + **Báo cáo Tài chính Danh mục (Financial Health)**: Trình bày dạng bảng (Markdown table) so sánh Ngân sách kế hoạch vs Thực tế đã chi, Doanh thu thực tế, chỉ số hiệu suất chi phí (CPI) và Lợi tức đầu tư dự kiến (ROI).
  + **Tiến độ các Dự án Chiến lược (Strategic Project Milestones)**: Liệt kê các dự án lớn cùng trạng thái RAG (Đỏ/Vàng/Xanh) dựa trên tiến độ các cột mốc quan trọng tiếp theo.
  + **Đề xuất & Kiến nghị khẩn cấp (Escalation & Approvals)**: Trình bày rõ ràng vấn đề, tác động nếu trì hoãn phê duyệt, và đề xuất cụ thể để C-Suite ra quyết định nhanh chóng.
- **Phong cách ngôn ngữ**: Chuyên nghiệp, súc tích, tập trung vào số liệu tài chính và rủi ro kinh doanh, không đưa các chi tiết kỹ thuật vụn vặt vào báo cáo.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

Ra mắt sản phẩm & Phát triển thị trường

Đưa sản phẩm từ môi trường thử nghiệm đến tay người dùng thành công đòi hỏi sự chuẩn bị đa diện. Các prompt dưới đây hỗ trợ bạn thiết kế chiến lược Go-To-Market (GTM), lập kế hoạch Beta Test, tối ưu hóa ASO cho ứng dụng di động và xây dựng chính sách giá tối ưu.

41. Chiến lược đưa sản phẩm ra thị trường (GTM)

Tình huống áp dụng thực tế: Sản phẩm sắp hoàn thiện phần kỹ thuật nhưng bạn chưa có một kế hoạch bài bài bản để đưa nó tiếp cận thị trường và khách hàng mục tiêu.

Hướng dẫn sử dụng: Điền tên sản phẩm và phân khúc khách hàng. Prompt giúp bạn xây dựng chiến lược GTM (Go-To-Market) toàn diện từ định vị đến kênh phân phối.

Bạn là một chuyên gia Tiếp thị Sản phẩm (Product Marketing Manager - PMM) và Chuyên gia xây dựng chiến lược Go-To-Market (GTM Strategist) có kinh nghiệm đưa hàng trăm sản phẩm công nghệ tiếp cận thị trường thành công.

Nhiệm vụ của bạn là: Xây dựng một Kế hoạch Chiến lược đưa sản phẩm ra thị trường (Go-To-Market Strategy Plan) chi tiết, toàn diện và có tính thực thi cao cho sản phẩm mới [Tên sản phẩm mới] hướng đến đối tượng [Phân khúc khách hàng mục tiêu].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin sản phẩm & Bối cảnh**:
  + Tên sản phẩm/dịch vụ mới: [Tên sản phẩm mới]
  + Mô tả sản phẩm & Điểm độc bản (USP): [Mô tả sản phẩm & USP, ví dụ: Phần mềm quản lý kho sử dụng AI tự động dự báo lượng hàng tồn kho chính xác 95%]
  + Phân khúc khách hàng mục tiêu: [Phân khúc khách hàng mục tiêu, ví dụ: Chủ doanh nghiệp bán lẻ vừa và nhỏ tại Việt Nam]
  + Đối thủ cạnh tranh trực tiếp: [Đối thủ cạnh tranh trực tiếp, ví dụ: KiotViet, Sapo]
- **Yêu cầu chi tiết nội dung GTM Strategy**:
  + **Định vị & Thông điệp cốt lõi (Positioning & Messaging)**: Xác định rõ định vị thương hiệu sản phẩm và thiết lập ma trận thông điệp truyền thông chính cho từng đối tượng khách hàng mục tiêu. Làm rõ lý do tại sao họ phải mua sản phẩm này thay vì của đối thủ.
  + **Chân dung Khách hàng Lý tưởng (ICP - Ideal Customer Profile)**: Phác họa rõ ràng chân dung khách hàng lý tưởng bao gồm: Nhân khẩu học, điểm đau (Pain points), hành vi mua sắm và rào cản từ chối mua hàng phổ biến.
  + **Chiến lược giá (Pricing Strategy)**: Đề xuất mô hình định giá phù hợp (ví dụ: Freemium, Subscription, Pay-as-you-go, Tiered Pricing) kèm mức giá dự kiến cụ thể và lý do lựa chọn.
  + **Kênh tiếp cận & Phân phối (Acquisition Channels)**: Xác định các kênh tiếp thị cốt lõi (online & offline) phù hợp nhất với ICP và ngân sách, đưa ra chiến thuật tiếp cận cho từng kênh.
  + **Lộ trình chiến dịch ra mắt (Launch Plan)**: Chia kế hoạch thành 3 giai đoạn rõ ràng: Trước ra mắt (Pre-launch), Ngày ra mắt (Launch Day), và Sau ra mắt (Post-launch) kèm theo KPI đo lường thành công cốt lõi cho từng giai đoạn.

Hãy cung cấp kết quả chi tiết, rõ ràng và trình bày khoa học với các đề xuất chiến lược thực tế theo yêu cầu trên.

42. Lập kế hoạch thử nghiệm Beta (Beta Test)

Tình huống áp dụng thực tế: Bạn muốn tổ chức chương trình Beta Test để thu thập phản hồi sớm từ người dùng thực tế trước khi ra mắt chính thức, nhưng chưa biết quy trình thế nào.

Hướng dẫn sử dụng: Prompt giúp bạn lập kế hoạch thử nghiệm Beta: tiêu chí chọn người test, kịch bản test, cách thu thập feedback và đo lường mức độ sẵn sàng.

Bạn là một Giám đốc chương trình thử nghiệm sản phẩm (Beta Program Manager) kiêm Kỹ sư đảm bảo chất lượng cấp cao (QA Lead) với kinh nghiệm tổ chức các đợt Closed Beta và Open Beta cho các sản phẩm công nghệ lớn.

Nhiệm vụ của bạn là: Lập một Kế hoạch Thử nghiệm Beta (Beta Testing Plan) chi tiết, toàn diện và có tính thực tế cao cho ứng dụng/sản phẩm [Tên ứng dụng] nhằm thu thập phản hồi hữu ích và kiểm soát lỗi trước khi chính thức phát hành.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh chương trình**:
  + Tên ứng dụng/sản phẩm: [Tên ứng dụng]
  + Số lượng người thử nghiệm (Beta Testers): [Số lượng người thử]
  + Chân dung người thử nghiệm mục tiêu: [Chân dung beta tester mục tiêu, ví dụ: Nhân viên văn phòng tuổi từ 22-35 có nhu cầu quản lý tài chính]
  + Thời lượng thử nghiệm dự kiến: [Thời lượng thử nghiệm, ví dụ: 2 tuần]
  + Ngân sách & Quà tặng khuyến khích: [Ngân sách quà tặng / Incentive, ví dụ: Voucher mua sắm trị giá 200,000 VND cho top 10 người báo cáo nhiều lỗi nhất]
- **Yêu cầu chi tiết nội dung Kế hoạch**:
  + **Tuyển chọn & Onboarding**: Quy trình tuyển dụng người dùng thử nghiệm phù hợp, cách thức gửi email mời, cung cấp tài liệu hướng dẫn và điều khoản bảo mật thông tin (NDA) nếu cần.
  + **Nhiệm vụ kiểm thử (Test Scenarios)**: Đề xuất danh sách các nhiệm vụ cụ thể mà người thử nghiệm cần thực hiện (ví dụ: đăng ký tài khoản mới, thử tính năng thanh toán, đổi mật khẩu) để đảm bảo các luồng chức năng chính được kiểm tra kỹ.
  + **Kênh thu thập phản hồi & Báo lỗi**: Thiết lập cơ chế và công cụ thu thập phản hồi (như TestFlight, Google Play Beta, Slack/Discord, Typeform) và biểu mẫu báo lỗi đơn giản cho người dùng.
  + **Tiêu chí phát hành chính thức (Go-live Criteria)**: Định nghĩa rõ ràng các điều kiện cần đạt để kết thúc giai đoạn Beta và sẵn sàng phát hành chính thức (ví dụ: không còn lỗi nghiêm trọng Blocker/Critical nào tồn đọng, tỷ lệ crash ứng dụng dưới 0.1%, điểm hài lòng CSAT của người dùng beta đạt trên 4/5).

Hãy cung cấp kết quả chi tiết dưới dạng một tài liệu kế hoạch thử nghiệm chuyên nghiệp, trình bày khoa học bằng bảng biểu và các danh sách nhiệm vụ rõ ràng.

43. Tài liệu hướng dẫn sử dụng sản phẩm (User Guide)

Tình huống áp dụng thực tế: Khách hàng liên tục gửi ticket hỗ trợ vì không biết cách sử dụng các tính năng mới của sản phẩm, làm quá tải đội ngũ Customer Support.

Hướng dẫn sử dụng: Điền tên tính năng và quy trình hoạt động. Prompt sẽ biên soạn một tài liệu hướng dẫn sử dụng (User Guide) cực kỳ trực quan và dễ hiểu.

Bạn là một Chuyên gia viết tài liệu kỹ thuật (Technical Writer) và Chuyên gia giáo dục khách hàng (Customer Education Specialist) có nhiều năm kinh nghiệm thiết kế các tài liệu hướng dẫn sử dụng sản phẩm phần mềm (User Guides/Knowledge Base) trực quan, dễ hiểu.

Nhiệm vụ của bạn là: Thiết lập tài liệu Hướng dẫn sử dụng nhanh (Quick Start Guide) chi tiết, trực quan cho tính năng mới [Tên tính năng mới] của ứng dụng [Tên ứng dụng] để giúp người dùng mới dễ dàng thao tác thành công ngay từ lần đầu tiên.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin tính năng & Bối cảnh**:
  + Tên ứng dụng: [Tên ứng dụng]
  + Tên tính năng mới: [Tên tính năng mới]
  + Mục đích & Lợi ích của tính năng: [Mục đích/Giá trị của tính năng, ví dụ: Quét hóa đơn tự động bằng camera để ghi chép thu chi nhanh chóng]
  + Các bước thao tác cốt lõi: [Các bước thao tác cốt lõi, ví dụ: Mở app -> Nhấp nút "+" -> Chọn "Quét hóa đơn" -> Chụp ảnh hóa đơn -> Xác nhận và lưu]
- **Yêu cầu chi tiết cấu trúc tài liệu**:
  + **Giới thiệu**: Giải thích ngắn gọn tính năng này làm được gì và mang lại giá trị gì trong 2-3 câu.
  + **Chuẩn bị (Prerequisites)**: Liệt kê các điều kiện cần có (ví dụ: Cấp quyền truy cập camera, cập nhật ứng dụng lên phiên bản mới nhất).
  + **Hướng dẫn từng bước (Step-by-Step)**: Trình bày chi tiết, tuần tự các bước thao tác (Bước 1, Bước 2, Bước 3...). Với mỗi bước, nêu rõ hành động của người dùng (sử dụng động từ cụ thể như Click, Chạm, Kéo), giao diện hiển thị và kết quả mong đợi.
  + **Mẹo nhỏ & Lưu ý (Pro Tips)**: Các lưu ý quan trọng để tối ưu hóa thao tác hoặc tránh lỗi.
  + **Câu hỏi thường gặp (FAQ)**: Thiết kế 3-4 câu hỏi và giải đáp ngắn gọn cho các thắc mắc phổ biến nhất.
- **Phong cách viết**: Thân thiện, trực quan, dễ hiểu, tránh các thuật ngữ kỹ thuật sâu và tập trung vào trải nghiệm thực hiện hành động của người dùng.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc theo yêu cầu trên.

44. Danh sách kiểm tra trước ngày ra mắt (Launch Checklist)

Tình huống áp dụng thực tế: Chỉ còn 1 tuần nữa là đến ngày ra mắt chính thức. Bạn lo lắng đội ngũ sẽ bỏ sót những việc quan trọng ở các khâu kỹ thuật, pháp lý hay truyền thông.

Hướng dẫn sử dụng: Prompt cung cấp một Launch Checklist đa chiều, bao gồm kiểm tra hạ tầng, tài liệu pháp lý, chuẩn bị CS và kế hoạch dự phòng sự cố.

Bạn là một Điều phối viên ra mắt sản phẩm (Product Launch Coordinator) và Giám đốc vận hành sản phẩm (Operations Manager) cấp cao có nhiều năm kinh nghiệm quản lý các chiến dịch ra mắt (Go-to-Market execution) phức tạp liên phòng ban.

Nhiệm vụ của bạn là: Thiết lập một Danh sách kiểm tra sẵn sàng phát hành sản phẩm (Product Launch Checklist / Go-Live Readiness Review) chi tiết, đầy đủ và tối ưu để đảm bảo đợt phát hành sản phẩm [Tên sản phẩm] diễn ra an toàn, không có sai sót vận hành hay kỹ thuật.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Tên sản phẩm/dịch vụ: [Tên sản phẩm]
  + Thời gian còn lại trước ngày ra mắt: [Thời gian còn lại trước khi ra mắt, ví dụ: 7 ngày]
  + Các kênh phát hành chính: [Kênh phát hành chính, ví dụ: Apple App Store, Google Play Store, Web platform]
  + Các bộ phận liên quan trực tiếp: [Các phòng ban tham gia chính, ví dụ: Kỹ thuật, Marketing, Chăm sóc khách hàng, Pháp lý]
- **Yêu cầu chi tiết Launch Checklist**:
  + Phân chia danh mục kiểm tra theo các mảng công việc cụ thể:
    * **Kỹ thuật & Cơ sở hạ tầng (Tech & Infrastructure)**: Deploy code lên production, backup dữ liệu, kiểm tra chứng chỉ bảo mật SSL, đo lường tải (load testing), cấu hình DNS.
    * **Tiếp thị & Truyền thông (Marketing & Communications)**: Hoàn thiện Landing Page, thiết lập các chiến dịch email marketing, kiểm duyệt bài viết social media, kiểm tra mã theo dõi pixel (Facebook/Google pixel).
    * **Vận hành & Hỗ trợ (Operations & Support)**: Đào tạo đội ngũ hỗ trợ khách hàng (CS/Support) về sản phẩm mới, chuẩn bị sẵn tài liệu hướng dẫn/FAQ, chuẩn bị luồng trực nóng (hotline/livechat) trong ngày ra mắt.
    * **Thanh toán & Pháp lý (Payment & Legal)**: Kiểm thử thanh toán trên production (Sanity check), cập nhật Điều khoản sử dụng (Terms of Service) và Chính sách bảo mật (Privacy Policy).
  + Mỗi đầu việc trong danh sách kiểm tra (Checklist Item) phải đề xuất rõ:
    * Vai trò chịu trách nhiệm (Owner).
    * Mức độ ưu tiên (P0 - Bắt buộc trước go-live, P1 - Cần có, P2 - Có thể hoàn thành sau).
    * Ghi chú hướng dẫn kiểm tra nhanh.

Hãy cung cấp kết quả chi tiết dưới dạng bảng biểu (Markdown table) cho từng bộ phận để dễ dàng theo dõi và cập nhật tiến độ trước giờ G.

45. Tối ưu hóa hiển thị App Store (ASO)

Tình huống áp dụng thực tế: Ứng dụng di động của bạn có lượt tải rất thấp vì không hiển thị ở vị trí cao khi người dùng tìm kiếm các từ khóa liên quan trên App Store/Google Play.

Hướng dẫn sử dụng: Điền tên app và từ khóa mục tiêu. Prompt giúp bạn tối ưu hóa ASO: từ tiêu đề, mô tả ngắn, mô tả chi tiết đến đề xuất hình ảnh minh họa.

Bạn là một chuyên gia Tối ưu hóa cửa hàng ứng dụng (App Store Optimization - ASO Specialist) và Growth Marketer cấp cao với nhiều năm kinh nghiệm đẩy thứ hạng từ khóa ứng dụng lên top và tối ưu tỷ lệ chuyển đổi tải app (Conversion Rate Optimization - CRO) trên App Store và Google Play.

Nhiệm vụ của bạn là: Thiết lập tài liệu Chiến lược Tối ưu hóa Cửa hàng Ứng dụng (ASO Strategy) chi tiết, chuẩn SEO cho ứng dụng di động [Tên ứng dụng] thuộc lĩnh vực [Lĩnh vực / Ngành] để tối ưu hóa lượt tải tự nhiên (Organic Installs).

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin sản phẩm & Bối cảnh**:
  + Tên ứng dụng: [Tên ứng dụng]
  + Lĩnh vực/Ngành: [Lĩnh vực / Ngành, ví dụ: Tài chính cá nhân, Sức khỏe & Thể thao, Thương mại điện tử]
  + Điểm độc bản (USP) & Tính năng cốt lõi: [Giá trị cốt lõi / Điểm độc bản (USP)]
  + Các từ khóa hạt giống mong muốn tập trung: [Danh sách từ khóa mong muốn tập trung, ví dụ: sổ thu chi, quản lý tài chính, tiết kiệm tiền]
- **Yêu cầu chi tiết nội dung ASO Strategy**:
  + **Tối ưu hóa Siêu dữ liệu (Metadata Optimization)**:
    * **App Title**: Đề xuất ít nhất 3 phương án tiêu đề (dưới 30 ký tự) kết hợp tên thương hiệu và từ khóa chính có lượng tìm kiếm lớn.
    * **Subtitle (iOS) & Short Description (Android)**: Đề xuất 3 phương án mô tả ngắn (dưới 30 ký tự cho iOS, dưới 80 ký tự cho Android) nhằm làm nổi bật giá trị cốt lõi của ứng dụng.
    * **Long Description (Mô tả chi tiết)**: Viết bản mô tả chi tiết (dưới 4000 ký tự) theo cấu trúc chuẩn: Câu mở đầu cuốn hút -> Các điểm đau giải quyết được -> Các tính năng chính chi tiết -> Lời kêu gọi hành động (CTA). Lồng ghép các từ khóa mục tiêu một cách tự nhiên.
    * **Keyword Field (Chỉ dành cho iOS)**: Đề xuất chuỗi từ khóa dài tối đa 100 ký tự, phân tách bằng dấu phẩy không khoảng trắng.
  + **Tối ưu hóa Tài sản Trực quan (Visual Assets Guide)**:
    * **Ảnh chụp màn hình (Screenshots)**: Đề xuất ý tưởng bố cục và thông điệp hiển thị (caption text) cho bộ 5-8 ảnh chụp màn hình thể hiện các tính năng nổi bật.
    * **Video xem trước (App Preview/Promo Video)**: Lên kịch bản chi tiết 15-30 giây cho video giới thiệu ứng dụng (tập trung thể hiện giá trị lớn nhất trong 3-5 giây đầu).

Hãy cung cấp kết quả chi tiết dưới dạng một kế hoạch ASO hoàn chỉnh, trình bày rõ ràng và khoa học theo yêu cầu trên.

46. Chiến lược Onboarding khách hàng doanh nghiệp (B2B)

Tình huống áp dụng thực tế: Bạn muốn sản phẩm của mình được báo chí và cộng đồng công nghệ chú ý khi ra mắt nhưng không có ngân sách lớn cho các agency PR bên ngoài.

Hướng dẫn sử dụng: Prompt giúp bạn viết thông cáo báo chí (Press Release) chuẩn chuyên nghiệp và lập kế hoạch truyền thông tiếp cận các kênh báo chí tự nhiên.

Bạn là một Giám đốc hỗ trợ thành công khách hàng (Customer Success Manager - CSM) B2B cấp cao với hơn 10 năm kinh nghiệm dẫn dắt quy trình onboarding phần mềm doanh nghiệp lớn (Enterprise SaaS) trị giá hợp đồng lớn.

Nhiệm vụ của bạn là: Thiết lập Chiến lược và Kế hoạch Onboarding Khách hàng Doanh nghiệp (B2B Customer Onboarding Plan) chi tiết cho phần mềm SaaS [Tên phần mềm SaaS] thuộc lĩnh vực [Lĩnh vực / Chức năng phần mềm] để giúp doanh nghiệp đối tác nhanh chóng làm quen và đạt được giá trị thực tế đầu tiên (Time-to-Value - TTV) nhanh nhất.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh**:
  + Tên phần mềm SaaS: [Tên phần mềm SaaS]
  + Lĩnh vực/Chức năng chính: [Lĩnh vực / Chức năng phần mềm, ví dụ: Quản lý nhân sự HRM, quản trị quan hệ khách hàng CRM]
  + Quy mô doanh nghiệp khách hàng: [Quy mô khách hàng mục tiêu, ví dụ: 500 - 1000 nhân viên]
  + Thời gian Onboarding mục tiêu: [Thời gian Onboarding mong muốn, ví dụ: 30 ngày]
- **Yêu cầu chi tiết kế hoạch**:
  + **Lộ trình Onboarding theo từng giai đoạn**:
    * Tuần 1 (Kickoff & Setup): Thiết lập cấu hình hệ thống, tích hợp API, import dữ liệu cũ từ hệ thống hiện tại của khách hàng và phân quyền tài khoản (Admin, Manager, Staff).
    * Tuần 2 (Enablement & Training): Kế hoạch tổ chức các buổi đào tạo thực chiến (Train-the-Trainer) cho các key users và cung cấp các video, tài liệu tự học.
    * Tuần 3 (Adoption Monitoring): Giám sát thói quen sử dụng hàng ngày và giải quyết nhanh các khó khăn phát sinh (friction points) của nhân viên khách hàng.
    * Tuần 4 (Review & Transition): Đánh giá mức độ áp dụng thực tế và chuẩn bị bàn giao cho đội hỗ trợ kỹ thuật lâu dài.
  + **Các chỉ số KPIs đo lường onboarding thành công**: Đề xuất ít nhất 3 chỉ số quan trọng (ví dụ: Tỷ lệ active users hàng ngày, tốc độ đạt mốc giá trị đầu tiên - Time-to-Value, CSAT sau đào tạo).
  + **Mẫu Email Chào mừng (Welcome Email Template)**: Viết kịch bản email chào mừng chuyên nghiệp gửi từ Giám đốc CSM/Dịch vụ để thiết lập kỳ vọng và giới thiệu các cột mốc quan trọng tiếp theo cho đối tác.

Hãy cung cấp kết quả chi tiết, rõ ràng và trình bày khoa học với các đề xuất chiến lược thực tế theo yêu cầu trên.

47. Thiết kế chương trình giới thiệu nhận quà (Referral)

Tình huống áp dụng thực tế: Sản phẩm chuẩn bị thương mại hóa nhưng bạn vẫn băn khoăn không biết nên đặt giá thế nào: theo người dùng, theo tính năng, hay theo gói đăng ký tháng.

Hướng dẫn sử dụng: Mô tả giá trị sản phẩm và đối thủ cạnh tranh. Prompt giúp bạn phân tích các mô hình giá (Pricing Strategy) phù hợp và xây dựng bảng giá tối ưu.

Bạn là một Chuyên gia tăng trưởng lan truyền (Viral Growth Hacker) và Tiếp thị Sản phẩm (Product Marketer) cấp cao với kinh nghiệm thiết kế các chiến dịch referral/affiliate giúp ứng dụng tăng trưởng người dùng tự nhiên mạnh mẽ.

Nhiệm vụ của bạn là: Thiết kế chi tiết một Chương trình Giới thiệu nhận quà (Referral Program Campaign) sáng tạo, tối ưu hóa tỷ lệ chuyển đổi cho ứng dụng/sản phẩm [Tên ứng dụng] nhằm đẩy mạnh tốc độ tăng trưởng người dùng tự nhiên.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin sản phẩm & Ngân sách**:
  + Tên ứng dụng/sản phẩm: [Tên ứng dụng]
  + Mô tả dịch vụ & Giá trị cốt lõi: [Giá trị cốt lõi / Dịch vụ cung cấp, ví dụ: Ứng dụng đặt đồ ăn nhanh hoặc Nền tảng học tiếng Anh trực tuyến]
  + Ngân sách/Chi phí giới thiệu tối đa cho mỗi lượt thành công: [Ngân sách cho mỗi lượt referral thành công, ví dụ: 50,000 VND tổng cộng cho cả hai bên]
- **Yêu cầu thiết kế chương trình**:
  + **Cơ chế phần thưởng kép (Two-Sided Incentive)**: Đề xuất phương án phần thưởng tối ưu cho cả người giới thiệu (Referrer) và người được giới thiệu (Referee) (ví dụ: tiền mặt, voucher giảm giá đơn đầu, tích lũy điểm thưởng).
  + **Luồng trải nghiệm người dùng (UX Referral Flow)**: Phác thảo quy trình thao tác từng bước trực quan từ lúc lấy link/mã giới thiệu, gửi đi qua mạng xã hội, người dùng mới đăng ký, cho đến lúc nhận thưởng thành công. Đảm bảo thao tác tối giản.
  + **Quy quy định phòng chống gian lận (Anti-fraud Guardrails)**: Đề xuất 3-4 quy tắc cơ bản để hạn chế gian lận, trục lợi phần thưởng (ví dụ: xác thực OTP số điện thoại, thiết bị duy nhất, hoặc chỉ nhận thưởng khi Referee hoàn thành đơn hàng đầu tiên).
  + **Mẫu thông điệp truyền thông (Marketing Copywriting)**: Viết 2 mẫu lời thoại mời chào/tin nhắn mẫu kèm link tải app để người dùng sao chép nhanh gửi cho bạn bè qua SMS/Zalo/Messenger.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc dưới dạng tài liệu kế hoạch chiến dịch chuyên nghiệp.

48. Thiết lập bộ tài liệu hỗ trợ bán hàng (Sales Kit)

Tình huống áp dụng thực tế: Bạn có cuộc hẹn demo sản phẩm với một đối tác lớn. Nếu buổi demo diễn ra tẻ nhạt hoặc gặp lỗi kỹ thuật, bạn sẽ mất đi một cơ hội hợp tác lớn.

Hướng dẫn sử dụng: Prompt giúp bạn thiết kế kịch bản demo (Product Demo Script) hấp dẫn, tập trung vào việc giải quyết nỗi đau của khách hàng thay vì chỉ khoe tính năng.

Bạn là một Chuyên gia Tiếp thị Sản phẩm (Product Marketing Specialist) và Giám đốc Hỗ trợ Bán hàng (Sales Enablement Manager) cấp cao có kinh nghiệm xây dựng các bộ Sales Kit, Battlecards giúp đội ngũ kinh doanh chốt các hợp đồng Enterprise thành công.

Nhiệm vụ của bạn là: Xây dựng Bộ tài liệu hỗ trợ bán hàng (Sales Enablement Kit) toàn diện và chi tiết cho sản phẩm B2B mới [Tên sản phẩm B2B] hoạt động trong lĩnh vực [Lĩnh vực / Công dụng của sản phẩm].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin sản phẩm & Đối thủ**:
  + Tên sản phẩm B2B: [Tên sản phẩm B2B]
  + Lĩnh vực/Giá trị cốt lõi: [Lĩnh vực / Công dụng của sản phẩm, ví dụ: Hệ thống CRM quản lý khách hàng cho ngành bất động sản]
  + Hai đối thủ cạnh tranh chính: [Hai đối thủ cạnh tranh chính, ví dụ: HubSpot, Salesforce]
  + Các phản bác/từ chối phổ biến nhất của khách hàng: [Các lời từ chối mua hàng phổ biến nhất, ví dụ: Giá cao hơn đối thủ nội địa, tốn thời gian đào tạo nhân viên sử dụng]
- **Yêu cầu chi tiết nội dung Sales Kit**:
  + **Tài liệu giới thiệu một trang (One-pager)**: Tóm tắt cực ngắn về sản phẩm, điểm đau giải quyết được, tính năng cốt lõi và bảng báo giá/chính sách giá bán.
  + **Thẻ so sánh cạnh tranh (Competitive Battlecards)**: Lập bảng so sánh trực diện (Markdown table) giữa sản phẩm của chúng ta với [Hai đối thủ cạnh tranh chính] dựa trên các tiêu chí: Tính năng chính, Giá cả, Dịch vụ hỗ trợ. Chỉ ra điểm mạnh độc bản (USP) để thắng đối thủ và điểm yếu cần phòng thủ.
  + **Cẩm nang xử lý phản bác (Objection Handling Guide)**: Cung cấp kịch bản phản hồi chi tiết cho [Các lời từ chối mua hàng phổ biến nhất] theo công thức: Lắng nghe/Đồng cảm -> Đưa ra giải pháp/Bằng chứng (case study) thuyết phục.
  + **Kịch bản Demo sản phẩm trong 10 phút (Demo Script)**: Lộ trình demo từng bước phân bổ theo thời gian (ví dụ: Phút 1-2: Phá băng & Đặt câu hỏi tìm hiểu; Phút 3-8: Demo trực tiếp 3 tính năng giải quyết đúng điểm đau khách hàng; Phút 9-10: Hỏi cảm nhận & Chốt bước tiếp theo).

Hãy cung cấp kết quả chi tiết dưới dạng một bộ cẩm nang bán hàng chuyên nghiệp, dễ tra cứu nhanh khi gọi điện tư vấn khách hàng.

49. Thiết lập cẩm nang thành công của khách hàng

Tình huống áp dụng thực tế: Sản phẩm ra mắt được vài tuần và nhận được rất nhiều ý kiến khen chê lẫn lộn trên mạng xã hội và app store, bạn cần tổng hợp chúng để cải tiến.

Hướng dẫn sử dụng: Cung cấp phản hồi thô của người dùng. Prompt giúp phân tích cảm xúc (Sentiment Analysis) và phân loại ý kiến để đưa vào backlog cải tiến.

Bạn là một Giám đốc hỗ trợ thành công khách hàng (Customer Success Director) kiêm Chuyên gia thiết kế quy trình (Process Writer) có nhiều năm kinh nghiệm tối ưu hóa tỷ lệ giữ chân doanh thu ròng (NRR) và giảm tỷ lệ rời bỏ (Churn Rate) tại các doanh nghiệp SaaS lớn.

Nhiệm vụ của bạn là: Thiết lập tài liệu Cẩm nang Vận hành Chăm sóc Khách hàng (Customer Success Playbook) chi tiết, thực chiến cho công ty [Tên công ty] cung cấp sản phẩm/dịch vụ [Sản phẩm SaaS / Lĩnh vực hoạt động].

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh doanh nghiệp**:
  + Tên công ty: [Tên công ty]
  + Sản phẩm SaaS/Lĩnh vực hoạt động: [Sản phẩm SaaS / Lĩnh vực hoạt động, ví dụ: Phần mềm quản lý bán hàng đa kênh, Nền tảng học trực tuyến LMS]
  + Chỉ số sức khỏe khách hàng cần chú ý (Health Score): [Chỉ số sức khỏe cần chú ý, ví dụ: Tần suất đăng nhập app của quản trị viên, số lượng tickets phản hồi lỗi]
- **Yêu cầu chi tiết nội dung Playbook**:
  + **Quy trình xử lý các tình huống trọng yếu**:
    * *Tình huống 1 (Lỗi nghiêm trọng - Critical Bug)*: Quy trình phân phối thông tin với đội kỹ thuật (Tech Team), kịch bản email phản hồi xoa dịu khách hàng và cam kết thời gian xử lý (SLA).
    * *Tình huống 2 (Khách hàng đòi giảm giá khi gia hạn - Price Objection)*: Cách đàm phán dựa trên giá trị (Value-based selling), chứng minh ROI phần mềm mang lại và cung cấp phương án tặng quyền lợi thay vì giảm giá trực tiếp.
    * *Tình huống 3 (Khách hàng không hoạt động 14 ngày - Low Engagement)*: Quy trình tiếp cận chủ động (Re-engagement flow) để tìm hiểu nguyên nhân và kéo khách hàng hoạt động trở lại.
  + **Mẫu Email liên hệ**: Viết sẵn các mẫu email phản hồi chuyên nghiệp tương ứng cho cả 3 tình huống trên.
  + **Chỉ số KPIs đánh giá bộ phận CS**: Định nghĩa các chỉ số hiệu quả như Net Revenue Retention (NRR), Churn Rate, CSAT, NPS.

Hãy cung cấp kết quả chi tiết, rõ ràng và có cấu trúc mạch lạc dưới dạng tài liệu quy trình chuyên nghiệp theo yêu cầu trên.

50. Họp rút kinh nghiệm sau đợt ra mắt sản phẩm

Tình huống áp dụng thực tế: Sản phẩm đã bão hòa ở thị trường trong nước, ban giám đốc yêu cầu bạn lập kế hoạch để đưa sản phẩm tấn công sang thị trường nước ngoài.

Hướng dẫn sử dụng: Điền tên sản phẩm và quốc gia mục tiêu. Prompt giúp bạn phân tích rào cản văn hóa, pháp lý, đối thủ địa phương và xây dựng chiến lược bản địa hóa.

Bạn là một Giám đốc Vận hành Sản phẩm (Product Operations Director) và Huấn luyện viên Agile (Agile Coach) cấp cao với kinh nghiệm điều phối hàng trăm buổi Retrospective liên phòng ban phức tạp.

Nhiệm vụ của bạn là: Thiết lập Kế hoạch Tổ chức và Kịch bản điều phối buổi họp rút kinh nghiệm sau ra mắt sản phẩm (Post-Launch Retrospective Playbook) cho dự án/sản phẩm [Tên sản phẩm / Chiến dịch] với thời lượng [Thời lượng cuộc họp] cho toàn bộ đội ngũ liên phòng ban.

Hãy tuân thủ các hướng dẫn sau:
- **Thông tin bối cảnh cuộc họp**:
  + Tên sản phẩm/chiến dịch ra mắt: [Tên sản phẩm / Chiến dịch]
  + Thời lượng cuộc họp: [Thời lượng cuộc họp, ví dụ: 90 phút]
  + Quy mô/Thành phần tham gia: [Thành phần tham gia, ví dụ: 15 người từ bộ phận Tech, Product, Marketing, Sales, CS]
  + Dữ liệu sơ bộ đợt ra mắt: [Dữ liệu sơ bộ về đợt ra mắt, ví dụ: Đạt 120% KPI đăng ký mới nhưng trễ deadline phát hành 1 tuần, có xung đột giao tiếp giữa Tech và Marketing]
- **Yêu cầu chi tiết nội dung Playbook**:
  + **Phân bổ Agenda khoa học (Time-boxed Agenda)**:
    * Giai đoạn 1 (15-20% thời lượng): Review số liệu thực tế so với KPIs ban đầu.
    * Giai đoạn 2 (30% thời lượng): Thảo luận những điểm làm tốt (What went well) để ghi nhận.
    * Giai đoạn 3 (30% thời lượng): Chỉ ra các vấn đề, điểm nghẽn phát sinh (What didn't go well) và dùng kỹ thuật 5 Whys tìm nguyên nhân gốc rễ.
    * Giai đoạn 4 (20% thời lượng): Biểu quyết (Dot voting) để chốt và thống nhất các hành động cải tiến cốt lõi.
  + **Kỹ thuật điều phối giảm xung đột**: Hướng dẫn điều phối viên cách giữ không khí cuộc họp mang tính chất "Không đổ lỗi" (Blameless Retrospective), tập trung học hỏi thay vì chỉ trích cá nhân.
  + **Quản lý hành động cải tiến (Action Items)**: Đề xuất cách thức phân công người chịu trách nhiệm (Owner), thời hạn hoàn thành (Deadline) và cách đưa bài học kinh nghiệm vào quy trình vận hành chuẩn (SOP) của công ty.

Hãy cung cấp kết quả chi tiết dưới dạng một cẩm nang (Playbook) hướng dẫn điều phối chuyên nghiệp theo yêu cầu trên.

Câu hỏi thường gặp (FAQ)

Kết luận

Suy cho cùng, công cụ AI sinh ngẫu nhiên chỉ là một người trợ lý đắc lực, còn quyền quyết định và sự thấu hiểu sâu sắc về sản phẩm vẫn hoàn toàn thuộc về bạn. Việc sở hữu một bộ prompt quản lý sản phẩm chuyên nghiệp giúp bạn tiết kiệm hàng giờ suy nghĩ cấu trúc tài liệu, từ đó có thêm thời gian tập trung vào những việc mang lại giá trị cao hơn như trò chuyện trực tiếp với khách hàng hay hoạch định tầm nhìn chiến lược.

Hãy bắt đầu áp dụng thử nghiệm từ những prompt đơn giản như viết vé Jira hay sắp xếp độ ưu tiên Backlog bằng RICE ngay trong Sprint tới. Sau đó, hãy tinh chỉnh dần các biến số đầu vào để AI học được văn phong và bối cảnh đặc thù của doanh nghiệp bạn. Hy vọng bộ tài liệu này sẽ là một trợ thủ đắc lực giúp bạn nâng cao hiệu suất vận hành sản phẩm mỗi ngày.