title: "Cách tổ chức các buổi Review/Demo: Biến buổi Demo thành buổi bán hàng thành công"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 27
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "9 phút đọc"
tags: ["sprint review", "demo", "storytelling", "product owner", "stakeholder management", "facilitation"]

Cách tổ chức các buổi Review/Demo: Biến buổi Demo thành buổi bán hàng thành công

Bạn đã bao giờ ngồi trong một buổi Sprint Review mà người trình bày click hết màn hình này sang màn hình khác, khách hàng gật đầu lịch sự rồi tắt camera 5 phút sau chưa? Một buổi demo tệ không giết chết dự án ngay lập tức — nó giết chết niềm tin từng chút một, cho đến ngày khách hàng bắt đầu hỏi "đội có đang làm đúng hướng không". Buổi Review/Demo, nếu làm đúng, không phải là một thủ tục báo cáo — nó là cơ hội bán hàng lại giá trị đội ngũ đang tạo ra, mỗi hai tuần một lần.

🎯 Kỹ thuật cốt lõi: Kể chuyện qua Demo (Narrative-Driven Demo)

Sai lầm phổ biến nhất của người dẫn demo là click theo cấu trúc kỹ thuật: "Đây là ticket A, đây là ticket B, đây là ticket C" — tức là kể chuyện theo góc nhìn của đội phát triển. Khách hàng không quan tâm ticket, họ quan tâm vấn đề của họ đã được giải quyết chưa.

Kỹ thuật "kể chuyện qua demo" đảo ngược trình tự: thay vì đi từ tính năng ra vấn đề, đi từ vấn đề vào tính năng. Cấu trúc tổng quát gồm 4 bước, áp dụng cho từng tính năng/nhóm tính năng trong buổi demo:

Đặt lại bối cảnh (Set the Scene) — Nhắc lại vấn đề hoặc nỗi đau nghiệp vụ mà tính năng này giải quyết, bằng chính ngôn ngữ khách hàng đã dùng khi mô tả yêu cầu. Ví dụ: "Tuần trước anh Long có nói bộ phận kế toán mất gần 2 tiếng mỗi cuối tháng để đối soát công nợ thủ công."
Nhập vai người dùng thật (Play the Persona) — Không demo với tài khoản test tên "abc123", mà nhập vai đúng người dùng cuối sẽ dùng tính năng (ví dụ: "Bây giờ tôi sẽ đóng vai chị kế toán viên, đăng nhập và làm đúng quy trình cuối tháng của chị ấy").
Trình diễn luồng trọn vẹn (End-to-end Flow) — Đi hết một luồng nghiệp vụ có ý nghĩa, không phải từng nút bấm rời rạc. Nếu có bước phải bỏ qua (dữ liệu mẫu, môi trường test), nói rõ để khách hàng không nhầm là bug.
Chốt lại giá trị (Close the Loop) — Quay lại vấn đề ban đầu và nói rõ nó đã được giải quyết như thế nào, định lượng nếu có thể ("Từ 2 tiếng xuống còn thao tác dưới 5 phút").

Song song với kỹ thuật kể chuyện, nguyên tắc thứ hai không kém quan trọng là chuẩn bị kịch bản (demo script) thay vì click ngẫu nhiên theo cảm hứng. Một kịch bản demo tốt cần có: (a) danh sách tính năng theo thứ tự ưu tiên giá trị — không phải thứ tự hoàn thành; (b) dữ liệu mẫu đã dựng sẵn, thật và sạch, không lộ dữ liệu nhạy cảm; (c) kịch bản dự phòng khi có lỗi kỹ thuật (network chậm, môi trường staging đứng) — biết trước sẽ nói gì, chuyển sang gì; (d) thời lượng ước tính cho từng phần, có buffer cho câu hỏi.

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp từ các dự án phần mềm doanh nghiệp phổ biến tại Việt Nam, không phải case cụ thể của công ty nào.

Chị H. là Product Owner của một dự án xây dựng hệ thống quản lý kho vận cho một công ty logistics vừa. Dự án đang ở sprint thứ 6 trong tổng số kế hoạch 12 sprint. Buổi Sprint Review lần này rơi đúng vào thời điểm nhạy cảm: khách hàng — cụ thể là ông N., Giám đốc vận hành phía khách hàng — vừa có một cuộc họp nội bộ với Ban giám đốc công ty mình, nơi có ý kiến đặt câu hỏi "dự án này đã chạy 6 sprint rồi, tiền đã chi gần một nửa ngân sách, nhưng nhìn vào chưa thấy cái gì ra hồn dùng được ngay".

Sprint 6 chỉ hoàn thành các tính năng khá "khô khan" về mặt hình ảnh: module đối soát tồn kho theo lô hàng, cơ chế cảnh báo lệch tồn kho, và một phần API tích hợp với hệ thống kế toán hiện có của khách hàng. Không có màn hình dashboard đẹp mắt, không có biểu đồ trực quan — chỉ là các bảng dữ liệu và luồng nghiệp vụ vận hành nền.

Chị H. nhận được lịch họp demo chỉ 3 ngày trước buổi họp, và biết rằng ông N. sẽ đưa thêm 2 người từ phía Ban giám đốc tham dự lần này — những người chưa từng ngồi demo buổi nào trước đó.

Thách thức (Task)

Thách thức của chị H. có ba lớp chồng lên nhau.

Thứ nhất, về nội dung: các tính năng của sprint 6 vốn dĩ không "đẹp" để demo. Đối soát tồn kho và cảnh báo lệch số là những tính năng vận hành nền, dễ trông nhàm chán nếu trình bày kiểu liệt kê màn hình.

Thứ hai, về khán giả: hai người mới từ Ban giám đốc không có bối cảnh kỹ thuật, không biết sprint là gì, không quan tâm "đã hoàn thành 8/10 story point" — họ chỉ muốn biết một câu duy nhất: tiền bỏ ra có đáng không.

Thứ ba, và nguy hiểm nhất: nếu buổi demo diễn ra nhạt nhẽo, đúng như lo ngại ban đầu của Ban giám đốc khách hàng, thì đây sẽ là bằng chứng cụ thể củng cố nghi ngờ "dự án chạy chậm, không ra sản phẩm" — có thể dẫn đến việc khách hàng yêu cầu tái cấu trúc lại phạm vi, giảm ngân sách, hoặc tệ hơn là đưa ra cảnh báo chấm dứt hợp đồng sớm. Nếu chị H. xử lý sai — tức là vẫn demo theo lối cũ, đi từng tính năng kỹ thuật mà không có mạch chuyện — buổi họp gần như chắc chắn sẽ củng cố ấn tượng xấu thay vì gỡ nó.

Hành động (Action)

Nhận ra lịch demo dày đặc và rủi ro cao, chị H. dành trọn buổi chiều trước ngày họp 2 ngày để chuẩn bị kịch bản, thay vì để nhóm dev tự do demo theo cảm hứng như các sprint trước.

Bước 1 — Xác định "câu chuyện lớn" của buổi demo trước khi nghĩ đến tính năng. Chị H. không bắt đầu bằng câu hỏi "sprint này làm được gì" mà bằng câu hỏi "buổi demo này cần khách hàng tin điều gì khi ra về". Câu trả lời chị chọn: "Hệ thống đang xây đúng nền móng để công ty khách hàng ngừng thất thoát hàng tồn kho do sai lệch số liệu — một vấn đề mà chính Ban giám đốc từng nêu ở buổi kickoff." Toàn bộ kịch bản demo được viết xoay quanh thông điệp này.

Bước 2 — Viết lại thứ tự trình bày theo giá trị, không theo thứ tự hoàn thành kỹ thuật. Thay vì demo theo trình tự "làm module A trước, module B sau" như báo cáo sprint, chị H. sắp lại theo mạch: mở đầu bằng vấn đề cũ (excel đối soát thủ công gây sai lệch hàng tháng, đã từng khiến công ty khách hàng lệch tồn kho trị giá đáng kể trong một đợt kiểm kê trước đây) → cho xem cách hệ thống tự động phát hiện lệch số theo thời gian thực → rồi mới đến phần kỹ thuật API tích hợp kế toán, được đóng khung lại là "nền tảng để con số này tự động chảy sang hệ thống kế toán, không cần ai nhập tay lại".

Bước 3 — Dựng dữ liệu mẫu mô phỏng đúng một tình huống thật của khách hàng. Chị H. đề nghị đội kỹ thuật dựng một bộ dữ liệu demo mô phỏng đúng kịch bản lệch kho mà khách hàng từng gặp phải (số lượng SKU, tên kho tương tự thực tế nhưng đã được làm giả hoàn toàn để không lộ dữ liệu vận hành thật), thay vì dùng dữ liệu "Test 1, Test 2, SKU-AAA".

Bước 4 — Nhập vai người dùng cuối khi demo, không nhập vai lập trình viên. Khi đến phần thao tác, chị H. tự tay demo (không để dev demo) trong vai "nhân viên kho đang kiểm hàng cuối ngày" — mở đúng màn hình nhân viên kho sẽ mở, bấm đúng các bước họ sẽ bấm, và dừng lại ở đúng khoảnh khắc hệ thống bắn cảnh báo lệch số để nhấn mạnh: "Đây — khoảnh khắc mà trước đây phải đợi đến cuối tháng mới phát hiện ra, giờ phát hiện ngay lúc kiểm hàng."

Bước 5 — Chuẩn bị sẵn "cầu nối" sang câu chuyện lớn hơn (mở upsell một cách tự nhiên). Biết trước có người từ Ban giám đốc tham dự, chị H. chuẩn bị một slide ngắn (không phải demo trực tiếp) đặt cạnh phần đối soát tồn kho: cho thấy nếu dữ liệu lệch kho được theo dõi theo thời gian thực như vậy, ở giai đoạn sau dự án có thể mở rộng thành báo cáo dự báo tồn kho theo mùa vụ — một hạng mục nằm ngoài phạm vi hợp đồng hiện tại nhưng đã được khách hàng nhắc đến một lần ở buổi họp kickoff. Chị H. cố tình không chốt gì trong buổi demo, chỉ gieo hạt giống ý tưởng và ghi chú lại phản ứng của Ban giám đốc.

Bước 6 — Chuẩn bị kịch bản dự phòng và phân vai rõ ràng. Chị H. họp nhanh 15 phút với đội trước buổi demo: ai demo phần nào, ai trực chat để trả lời câu hỏi kỹ thuật không nên trả lời trực tiếp trên màn hình chính, và quan trọng nhất — nếu môi trường demo lỗi giữa chừng (một rủi ro có thật, vì môi trường staging từng bị treo ở sprint trước), sẽ chuyển ngay sang video demo đã quay sẵn thay vì loay hoay sửa lỗi trước mặt khách hàng.

Bước 7 — Kết thúc bằng câu hỏi mở, không phải câu hỏi đóng. Thay vì hỏi "mọi người có câu hỏi gì không", chị H. chủ động hỏi: "Với những gì anh N. và các anh chị vừa thấy, điều gì các anh chị thấy hữu ích nhất cho công việc hàng ngày của đội vận hành, và điều gì còn khiến các anh chị băn khoăn?" — câu hỏi này ép người tham dự phản hồi cụ thể thay vì gật đầu xã giao.

Kết quả (Result)

Buổi demo diễn ra trong 35 phút thay vì kế hoạch ban đầu là liệt kê tất cả các tính năng trong hơn 1 tiếng. Ông N. chủ động đặt 4 câu hỏi trong lúc demo — dấu hiệu ông thực sự theo dõi thay vì chỉ ngồi nghe. Một trong hai người từ Ban giám đốc hỏi thẳng về ý tưởng báo cáo dự báo tồn kho theo mùa vụ mà chị H. gieo ở bước 5, và đề nghị đội gửi một đề xuất phạm vi (scope) sơ bộ cho hạng mục này trong tuần sau — đây chính là cơ hội mở rộng hợp đồng (upsell) mà buổi demo tạo ra một cách tự nhiên, không phải chèn ép bán hàng lộ liễu.

Sau buổi họp, ông N. gửi email nội bộ (có CC dự án) báo cáo lại với Ban giám đốc công ty mình rằng "đội phát triển đang đi đúng hướng, tính năng đối soát kho đã giải quyết đúng vấn đề đã nêu ở kickoff" — một câu nói có trọng lượng lớn hơn nhiều so với việc chị H. tự giải trình.

Điều chưa hoàn hảo: một trong hai người mới từ Ban giám đốc vẫn hỏi lại "vậy khi nào có giao diện đẹp như ứng dụng di động" — cho thấy dù mạch chuyện đã tốt hơn nhiều, kỳ vọng về mặt hình ảnh giao diện (UI polish) của người không có bối cảnh kỹ thuật vẫn là một khoảng cách chị H. cần tiếp tục quản trị ở các buổi demo sau, có thể bằng cách dành riêng một mục ngắn giải thích rõ ràng ranh giới giữa "chức năng nền" và "giao diện hoàn thiện" sẽ đến ở giai đoạn nào.

📋 Áp dụng ngay

Trước mỗi buổi demo, viết ra một câu duy nhất: "Người xem cần tin điều gì khi ra về" — và sắp toàn bộ nội dung xoay quanh câu đó.
Sắp thứ tự trình bày theo giá trị nghiệp vụ khách hàng cảm nhận được, không theo thứ tự hoàn thành kỹ thuật hay theo ticket.
Luôn chuẩn bị dữ liệu mẫu mô phỏng đúng kịch bản thật của khách hàng, không dùng dữ liệu test vô nghĩa (Test 1, Test 2, SKU-AAA…), và không dùng dữ liệu nhạy cảm thật.
Có kịch bản dự phòng cho rủi ro kỹ thuật (video quay sẵn, môi trường backup) và phân vai rõ ai demo, ai trả lời câu hỏi.
Kết thúc bằng câu hỏi mở buộc người tham dự phản hồi cụ thể, thay vì câu hỏi đóng dễ chỉ nhận được cái gật đầu xã giao.

💡 Bài học đúc rút (Key Takeaway): Một buổi demo không phải là nơi để "báo cáo đã làm xong cái gì" — nó là nơi để chứng minh vấn đề của khách hàng đang thực sự được giải quyết. Ai kể câu chuyện đúng thứ tự — vấn đề trước, tính năng sau — người đó biến 30 phút click màn hình thành 30 phút củng cố niềm tin, và đôi khi, thành cánh cửa mở ra hợp đồng tiếp theo.

🔗 Kỹ năng liên quan

Bài trước: Visualizing Complex Systems (Cho EA) · Bài tiếp theo: Quản lý sự thay đổi (Change Management)