Prompt tạo tính năng MVP cho sản phẩm số
Bạn đang làm việc theo nhịp Việt Nam: Zalo ping cả đêm, Google Sheet mở cả ngày, cuối tuần vẫn còn việc chưa đóng. Bài này nói đúng nỗi đau đó — và cách gắn AI Agent vào tool bạn đã dùng, không phải thay cả hệ thống.
Bạn ngồi trước Notion trắng, tay cầm danh sách 47 ý tưởng feature từ phỏng vấn khách hàng, Slack nhóm dev ping "cần scope rõ để estimate", investor hỏi "MVP bao gồm gì, khi nào ra mắt?" — và bạn nhận ra: việc khó không phải là code, là quyết định cái gì vào MVP, cái gì để sau.
Đây là nỗi đau chung của founder, PM, và team sản phẩm số tại Việt Nam: có quá nhiều insight, quá ít khung quyết định. Nếu bạn đang tìm cách biến ghi chú phỏng vấn thành backlog MVP rõ ràng, có thể bảo vệ trước dev team và investor — bài này sẽ cho bạn workflow 5 bước và 4 prompt mẫu copy-paste ngay.
Trả lời nhanh: Prompt tạo tính năng MVP làm gì?
Prompt tốt biến insight thô thành danh sách feature có ưu tiên, có định nghĩa sẵn sàng cho dev estimate. Nó không thay thế tư duy sản phẩm — nó ép bạn tư duy có hệ thống: từ job-to-be-done → hypothesis → scope → acceptance criteria. Kết quả: bản v1 backlog trong 30 phút, không 3 ngày tranh luận.
Chưa rõ khái niệm MVP cốt lõi? Đọc thêm MVP là gì: định nghĩa, ví dụ, sai lầm thường gặp trên blog Ngân Ads trước khi đi tiếp.
Vấn đề thật: Tại sao định nghĩa MVP vẫn thủ công, chậm, lệch?
Trong 2 năm làm việc cùng hàng chục startup và team sản phẩm nội bộ, tôi thấy cùng một chuỗi lỗi lặp lại:
- Feature creep từ ngày 1: Mọi ý tưởng hay từ phỏng vấn đều được ghi vào backlog — không ai dám nói "không" vì sợ bỏ lỡ insight.
- Không có tiêu chí cắt bỏ: Team dùng cảm tính ("cái này có vẻ quan trọng") thay vì framework (RICE, MoSCoW, Kano).
- Prompt hỏi chung chung: "Hãy liệt kê tính năng cho app [tên]" → AI trả về danh sách generic: login, dashboard, settings, notification — chẳng khác gì template CRUD.
- Thiếu ngữ cảnh nghiệp vụ: AI không biết ràng buộc kỹ thuật, ngân sách, timeline, quy định pháp lý — nên đề xuất feature không thể triển khai trong 2 sprint.
- Không có acceptance criteria: Dev nhận ticket "làm trang thanh toán" — không biết có COD không, có ví điện tử không, có split payment không → estimate sai, scope trôi.
Kết quả: MVP trễ 2 tháng, quá budget, ra mắt mà khách hàng không dùng feature cốt lõi.
Workflow 5 bước: Từ insight → Backlog MVP sẵn sàng dev
Bước 1: Gom insight thành Job-to-be-Done (JTBD) — 15 phút
Đừng để phỏng vấn nằm rải rác trong Google Doc. Dùng prompt sau để nén thành danh sách JTBD có cấu trúc:
Bạn là Product Strategist. Dưới đây là ghi chú phỏng vấn [số lượng] khách hàng [ngành] về [vấn đề chính].
Hãy trích xuất 5-8 Job-to-be-Done (JTBD) theo format:
- JTBD: [Khi [tình huống], tôi muốn [hành động], để [kết quả mong đợi]]
- Tần suất: [ngày/tuần/tháng]
- Nỗi đau hiện tại: [cách họ đang làm, tốn bao nhiêu thời gian/chi phí]
- Độ quan trọng (1-5): [dựa trên tần suất + nỗi đau]
Ghi chú phỏng vấn:
[Paste toàn bộ note tại đây]Đầu ra mong đợi: Bảng 8 JTBD có điểm quan trọng — nền tảng cho bước 2.
Bước 2: Chuyển JTBD thành Hypothesis Statement — 10 phút
Mỗi JTBD → 1 hypothesis có thể test. Prompt:
Dựa trên danh sách JTBD dưới đây, hãy viết Hypothesis Statement cho từng JTBD theo format:
"Chúng tôi tin rằng [đối tượng] có nhu cầu [JTBD]. Nếu chúng tôi cung cấp [giải pháp cốt lõi], họ sẽ [hành động đo lường được]. Chúng tôi sẽ biết đúng/sai khi [metric + ngưỡng]."
Danh sách JTBD:
[Paste output bước 1]Đầu ra: 8 hypothesis — mỗi cái là ứng viên cho 1 epic trong backlog.
Bước 3: Áp dụng MoSCoW + RICE lọc scope MVP — 20 phút
Đây là bước quan trọng nhất: cắt bỏ. Prompt:
Bạn là Senior PM. Dưới đây là [số] hypothesis cho sản phẩm [tên sản phẩm - [ngành]].
Ràng buộc:
- Team: [số dev, stack]
- Timeline MVP: [số] sprint (2 tuần/sprint)
- Ngân sách: [khoảng]
- Yêu cầu pháp lý/bắt buộc: [nếu có]
Hãy phân loại từng hypothesis vào MoSCoW (Must/Should/Could/Won't) VÀ chấm điểm RICE (Reach, Impact, Confidence, Effort 1-10).
Trả về bảng:
| Hypothesis | MoSCoW | R | I | C | E | RICE Score | Ghi chú |
Danh sách hypothesis:
[Paste output bước 2]Đầu ra: Bảng đã chấm điểm — chỉ lấy Must + Should có RICE score cao vào MVP.
Bước 4: Viết User Story + Acceptance Criteria cho từng feature MVP — 25 phút
Dev cần chi tiết, không cần hypothesis. Prompt:
Dựa trên danh sách feature MVP (Must + Should) dưới đây, hãy viết User Story theo format INVEST và Acceptance Criteria theo format Given/When/Then.
Yêu cầu:
- Mỗi feature: 1-3 user story
- AC bao phủ: happy path, edge case, error state
- Viết cho dev [stack], không dùng thuật ngữ business mờ mịn
- Ưu tiên feature có dependency trước
Danh sách feature MVP:
[Paste output bước 3 - chỉ Must/Should]
Ngữ cảnh kỹ thuật:
- Stack: [React/Node, Postgres, v.v.]
- Auth: [Firebase/Auth0/Custom]
- Payment: [Stripe/Momo/VNPAY]
- Infra: [Vercel/AWS/DO]Đầu ra: Backlog sẵn sàng cho Sprint Planning — dev có thể estimate ngay.
Bước 5: Tạo MVP Canvas 1 trang cho stakeholder — 10 phút
Investor, sếp, team marketing cần nhìn toàn cảnh. Prompt:
Tóm tắt MVP thành canvas 1 trang (Markdown) gồm:
1. VISION: 1 câu
2. TARGET USER: 3 persona chính
3. CORE JTBD: Top 3
4. MVP SCOPE: Danh sách feature (Must/Should) gom theo Epic
5. SUCCESS METRICS: 3 KPI trọng tâm + ngưỡng 3 tháng
6. TIMELINE: Sprint 1-4, feature gì, milestone gì
7. RISKS & ASSUMPTIONS: Top 3 rủi ro + cách validate
8. OUT OF SCOPE: Điều KHÔNG làm (quan trọng để manage expectation)
Input: Tất cả output bước 1-4.
Viết gọn, có thể copy vào Notion/Slide ngay.Đầu ra: 1 trang A4 — xong xuôi trình duyệt, align team.
4 Prompt mẫu copy-paste ngay (có placeholder)
Prompt 1: Từ note phỏng vấn → JTBD (Bước 1)
Bạn là Product Strategist. Dưới đây là ghi chú phỏng vấn [số lượng] khách hàng [ngành] về [vấn đề chính].
Hãy trích xuất 5-8 Job-to-be-Done (JTBD) theo format:
- JTBD: [Khi [tình huống], tôi muốn [hành động], để [kết quả mong đợi]]
- Tần suất: [ngày/tuần/tháng]
- Nỗi đau hiện tại: [cách họ đang làm, tốn bao nhiêu thời gian/chi phí]
- Độ quan trọng (1-5): [dựa trên tần suất + nỗi đau]
Ghi chú phỏng vấn:
[Paste toàn bộ note tại đây]Prompt 2: JTBD → Hypothesis có metric (Bước 2)
Dựa trên danh sách JTBD dưới đây, hãy viết Hypothesis Statement cho từng JTBD theo format:
"Chúng tôi tin rằng [đối tượng] có nhu cầu [JTBD]. Nếu chúng tôi cung cấp [giải pháp cốt lõi], họ sẽ [hành động đo lường được]. Chúng tôi sẽ biết đúng/sai khi [metric + ngưỡng]."
Danh sách JTBD:
[Paste output Prompt 1]Prompt 3: Lọc scope MVP bằng MoSCoW + RICE (Bước 3) — QUAN TRỌNG NHẤT
Bạn là Senior PM. Dưới đây là [số] hypothesis cho sản phẩm [tên sản phẩm - [ngành]].
Ràng buộc:
- Team: [số dev, stack]
- Timeline MVP: [số] sprint (2 tuần/sprint)
- Ngân sách: [khoảng]
- Yêu cầu pháp lý/bắt buộc: [nếu có]
Hãy phân loại từng hypothesis vào MoSCoW (Must/Should/Could/Won't) VÀ chấm điểm RICE (Reach, Impact, Confidence, Effort 1-10).
Trả về bảng:
| Hypothesis | MoSCoW | R | I | C | E | RICE Score | Ghi chú |
Danh sách hypothesis:
[Paste output Prompt 2]Prompt 4: Feature → User Story + AC cho dev (Bước 4)
Dựa trên danh sách feature MVP (Must + Should) dưới đây, hãy viết User Story theo format INVEST và Acceptance Criteria theo format Given/When/Then.
Yêu cầu:
- Mỗi feature: 1-3 user story
- AC bao phủ: happy path, edge case, error state
- Viết cho dev [stack], không dùng thuật ngữ business mờ mịn
- Ưu tiên feature có dependency trước
Danh sách feature MVP:
[Paste output Prompt 3 - chỉ Must/Should]
Ngữ cảnh kỹ thuật:
- Stack: [React/Node, Postgres, v.v.]
- Auth: [Firebase/Auth0/Custom]
- Payment: [Stripe/Momo/VNPAY]
- Infra: [Vercel/AWS/DO]3 lỗi thường gặp khi dùng AI viết MVP spec (và cách sửa)
Lỗi 1: Không cho AI biết ràng buộc thật → feature không build được
Triệu chứng: AI đề xuất "real-time collaboration", "AI recommendation engine", "multi-tenant" cho team 2 dev, 4 sprint.
Sửa: Luôn điền đầy đủ ràng buộc ở Prompt 3: team size, stack, timeline, budget, compliance. AI không tự biết — bạn phải cho nó biết.
Lỗi 2: Dùng MoSCoW mà không có RICE → Must thành "mọi thứ sếp thích"
Triệu chứng: 15 feature Must, 0 Should — dev estimate 6 tháng.
Sửa: Bắt buộc chấm RICE cho từng hypothesis. Must = RICE score cao VÀ không thể launch thiếu. Should = RICE score cao nhưng có workaround tạm.
Lỗi 3: Acceptance criteria viết business language → dev hiểu sai
Triệu chứng: AC: "Khách hàng thanh toán dễ dàng" → dev làm 1 nút pay, thiếu COD, thiếu split, thiếu refund flow.
Sửa: Yêu cầu AC format Given/When/Then, liệt kê edge case: "Given user chọn COD, When order > 500k, Then hiển thị cảnh báo giới hạn COD".
Khi nào nên dùng workflow này — khi nào không?
| Dùng khi | Không dùng khi |
|---|---|
| Có note phỏng vấn ≥5 khách hàng | Chưa nói chuyện với bất kỳ user nào (dùng Customer Discovery trước) |
| Cần align team/dev/investor trong 1 tuần | Sản phẩm đã có PMF, đang scale feature (dùng Opportunity Solution Tree) |
| Team ít kinh nghiệm PM, cần khung xương sống | Cần spec chi tiết cho RFP/government bid (cần BA chuyên nghiệp) |
| Muốn từ insight → backlog trong 1 buổi làm việc | Đang build internal tool đơn giản (CRUD) — dùng template sẵn nhanh hơn |
FAQ
1. Prompt này thay thế được Product Manager không?
Không. Prompt là khung xương (scaffold) — PM vẫn phải: (1) phỏng vấn user thật, (2) quyết định trade-off khi RICE score gần nhau, (3) negotiate scope với dev/investor, (4) validate hypothesis sau launch. AI giúp bạn không bị trắng trang, không giúp bạn thay thế tư duy.
2. Dùng model nào cho kết quả tốt nhất?
Claude 3.5 Sonnet hoặc GPT-4o cho reasoning phức tạp (bước 2, 3). GPT-4o-mini đủ cho bước 1, 4, 5. Quan trọng hơn model là context bạn feed — note phỏng vấn chi tiết, ràng buộc thật, stack thật.
3. Có thể áp dụng cho internal tool / admin panel không?
Được, nhưng đơn giản hóa: bỏ bước 2 (hypothesis), dùng MoSCoW trực tiếp trên feature list từ stakeholder. Internal tool thường rõ requirement hơn — ít cần validate hypothesis.
Bạn đã có note phỏng vấn nhưng chưa dám động tay vào backlog? Thử chạy workflow 5 bước hôm nay — 1 tiếng đồng hồ có bản v1. Nếu muốn AI Agent tự chạy lặp workflow này mỗi sprint (tự gom note, tự cập nhật backlog, tự nhắc feature stale), inbox Ngân Ads — cài AI Agent cá nhân 499K, support 7 ngày. Đội ngũ chúng tôi đã giúp 40+ team sản phẩm từ idea đến MVP trong 6 tuần.