Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng ngồi dự một buổi demo sản phẩm và thấy mình lơ đãng lướt điện thoại sau phút thứ ba, thì bạn vừa chứng kiến một demo được thiết kế sai. Người trình bày mở phần mềm lên, click hết menu này đến menu kia, đọc vanh vách từng tính năng như đang đọc bản kê khai — và khách hàng thì chẳng hiểu tất cả những thứ đó có liên quan gì đến vấn đề của họ.
Với vai trò Product Marketing Manager (PMM), bạn không phải là người trực tiếp bấm chuột trong mọi buổi demo. Nhưng bạn là người thiết kế "bộ khung" của buổi demo đó: kịch bản, thứ tự các bước, câu chuyện dẫn dắt, và những khoảnh khắc "wow" mà đội Sales sẽ tái sử dụng hàng trăm lần. Một demo được thiết kế tốt là một trong những tài sản có đòn bẩy cao nhất mà PMM có thể tạo ra: bạn làm một lần, và nó tạo ra doanh thu qua tay của mọi Sales Engineer trong công ty.
Bài học này tập trung vào một điều duy nhất: cách thiết kế luồng (flow) của một buổi demo và cách nhồi storytelling vào trong đó, để demo biến từ một chuyến "tham quan tính năng" khô khan thành một câu chuyện thuyết phục khiến khách hàng gật đầu. Đây không phải bài về sales deck (bài 18) hay về cách thiết kế trang demo trên website — mà là về nghệ thuật dàn dựng chính buổi trình diễn sản phẩm sống.
Khái niệm cốt lõi
Demo không phải là feature tour
Đây là ranh giới quan trọng nhất bạn phải khắc cốt ghi tâm.
Feature tour nói: "Đây là tất cả những gì chúng tôi có." Người trình bày đi qua từng module, từng nút bấm, từng cấu hình, cố gắng chứng minh sản phẩm "làm được nhiều thứ". Kết quả là khách hàng bị ngợp, không nhớ nổi điều gì quan trọng, và tệ nhất là tự hỏi "cái này liên quan gì đến tôi?".
Demo nói: "Để tôi cho anh/chị xem cách giải quyết vấn đề CỦA ANH/CHỊ." Mọi thao tác trên màn hình đều phục vụ một mục tiêu: chứng minh rằng sản phẩm này gỡ được đúng nút thắt mà khách hàng đang đau. Bạn không show hết tính năng — bạn chỉ show những tính năng nằm trên đường đi tới kết quả mà khách hàng khao khát.
Một cách nhớ: feature tour lấy sản phẩm làm trung tâm, demo lấy khách hàng làm trung tâm. Feature tour trả lời câu hỏi "sản phẩm làm được gì?"; demo trả lời câu hỏi "đời tôi sẽ tốt hơn thế nào?".
Demo là một câu chuyện, không phải danh sách
Bộ não con người ghi nhớ câu chuyện tốt hơn danh sách gấp nhiều lần. Một demo hay có cấu trúc của một câu chuyện: có nhân vật (khách hàng và nỗi đau của họ), có xung đột (tình trạng hiện tại tồi tệ), có bước ngoặt (khoảnh khắc sản phẩm can thiệp), và có cái kết hạnh phúc (kết quả sau khi dùng sản phẩm).
Khi bạn thiết kế demo, hãy tự hỏi: nếu bỏ hết phần mềm đi và chỉ kể lại buổi demo bằng lời, nó có thành một câu chuyện mạch lạc không? Nếu câu trả lời là "không, nó chỉ là chuỗi thao tác rời rạc", thì bạn đang làm feature tour trá hình.
Luồng demo chuẩn — cấu trúc 5 phần
Một luồng demo được thiết kế tốt thường đi theo cấu trúc sau:
1. Setup — Dựng bối cảnh (2–3 phút). Trước khi chạm vào sản phẩm, hãy vẽ ra "một ngày trong đời" của khách hàng khi chưa có giải pháp. Nêu lại nỗi đau bạn đã nghe từ họ trong buổi discovery. Câu mở màn kinh điển: "Trước khi tôi cho anh xem, cho tôi xác nhận lại — hiện tại đội anh đang mất khoảng 2 tiếng mỗi ngày để đối soát đơn hàng thủ công, đúng không?". Setup tạo ra "hố sâu" của vấn đề để lát nữa sản phẩm lấp đầy.
2. The problem moment — Khoảnh khắc đau (1–2 phút). Cho khách hàng thấy tình trạng "before" ngay trên màn hình, hoặc mô tả sinh động nó. Mục tiêu là khách hàng gật đầu "đúng, đây chính xác là cái tôi đang khổ".
3. The reveal — Cú lật (khoảnh khắc wow). Đây là trái tim của demo. Bạn thực hiện đúng MỘT thao tác then chốt chứng minh sản phẩm giải quyết vấn đề, và làm nó thật kịch tính. Ví dụ: bấm một nút và cả 500 đơn hàng được đối soát trong 3 giây. Đừng dàn trải nhiều "wow" — một khoảnh khắc mạnh hơn năm khoảnh khắc nhạt.
4. The payoff — Kết quả (2–3 phút). Cho khách hàng thấy bức tranh "after": báo cáo sạch đẹp, thời gian tiết kiệm, con số cụ thể. Nối kết quả này với nỗi đau ở phần Setup để khép vòng câu chuyện.
5. The path forward — Bước tiếp theo. Trả lời ngầm câu hỏi "vậy giờ sao?". Gợi ý rõ ràng bước kế tiếp: bản dùng thử, buổi demo sâu hơn cho đội kỹ thuật, hoặc báo giá.
Nguyên tắc "Tell-Show-Tell"
Với mỗi phần quan trọng trong demo, áp dụng cấu trúc Tell-Show-Tell: Tell (nói trước bạn sắp cho xem gì và tại sao nó quan trọng) → Show (thực hiện thao tác) → Tell (chốt lại ý nghĩa của điều vừa xem). Nguyên tắc này ngăn khách hàng bị lạc: họ luôn biết mình đang xem gì và vì sao.
"Show, don't tell" ngược đời
Nghe có vẻ mâu thuẫn với ý trên, nhưng đây là sắc thái quan trọng: với tính năng, hãy show đừng kể; với ý nghĩa, hãy kể đừng để khách tự đoán. Nghĩa là đừng nói "hệ thống của chúng tôi rất nhanh" — hãy cho họ xem nó nhanh. Nhưng sau khi show xong, phải nói rõ "tốc độ này giúp anh xử lý gấp 3 lần đơn trong mùa sale mà không cần thuê thêm người" — đừng để khách hàng tự suy ra lợi ích, vì họ sẽ suy ra sai hoặc không suy ra gì cả.
Tình huống thực tế
Ví dụ 1: Base.vn demo phần mềm quản trị công việc cho một chuỗi F&B
Giả sử một Sales Engineer của Base.vn chuẩn bị demo cho chủ một chuỗi 12 quán cà phê tại TP.HCM. Ở phiên bản đầu, bạn ấy làm feature tour: mở Base Wework, giới thiệu bảng Kanban, rồi Base Request, Base HRM, Base Inbox... 40 phút trôi qua, khách hàng gật gù lịch sự nhưng ánh mắt trống rỗng. Cuối buổi khách nói: "Để anh suy nghĩ thêm." Deal nguội dần.
PMM của Base can thiệp, thiết kế lại luồng demo. Buổi sau bắt đầu bằng Setup: "Em biết mỗi sáng anh phải gọi điện từng quản lý quán để hỏi doanh thu hôm qua, và tổng hợp bằng tay vào Excel, đúng không? Trung bình mất 90 phút mỗi sáng." Khách hàng gật mạnh — đúng nỗi đau. Đến phần Reveal, Sales chỉ làm một việc: bấm mở dashboard tổng hợp báo cáo tự động của cả 12 quán, hiện lên trong 2 giây. Khách hàng buột miệng: "Ủa, nó tự cập nhật hết à?". Đó chính là khoảnh khắc wow. Payoff: "90 phút mỗi sáng của anh giờ còn 0 phút, và anh xem được từ điện thoại lúc còn đang uống cà phê." Deal chốt trong hai tuần.
Bài học: cùng một sản phẩm, cùng những tính năng, nhưng luồng lấy khách hàng làm trung tâm thắng luồng lấy sản phẩm làm trung tâm. Sự khác biệt không nằm ở phần mềm — nằm ở thiết kế demo.
Ví dụ 2: MoMo demo giải pháp thanh toán cho một chuỗi bán lẻ
Một PMM tại MoMo thiết kế demo giải pháp thu hộ (QR + đối soát) cho chuỗi cửa hàng tiện lợi 50 điểm bán. Cạm bẫy điển hình: đội demo muốn khoe hết — ví điện tử, MoMo Rewards, mini-app, marketing trên MoMo... Nhưng nỗi đau thật của khách hàng bán lẻ này rất cụ thể: cuối ngày kế toán phải đối soát tiền mặt lệch với hệ thống, mỗi cửa hàng lệch vài trăm nghìn, cộng lại đau đầu.
PMM cắt gọn demo xuống đúng một câu chuyện đối soát. Setup: mô tả cảnh kế toán ngồi đến 8 giờ tối dò từng bill. Reveal: cho xem màn hình đối soát tự động của MoMo khớp 100% giao dịch QR theo thời gian thực. Payoff: "Khoản lệch tiền mặt giảm vì khách chuyển sang QR, và báo cáo đối soát ra tự động lúc 22h mỗi ngày gửi thẳng vào email kế toán trưởng." Những tính năng hào nhoáng khác (Rewards, mini-app) được gói vào một câu duy nhất cuối buổi: "Và đây mới chỉ là phần lõi — MoMo còn giúp anh kéo khách quay lại, nhưng cái đó để buổi sau khi mình đã giải quyết xong bài toán đối soát."
Bài học: kỷ luật cắt bỏ. Mỗi tính năng bạn thêm vào demo mà không phục vụ câu chuyện chính là một cơ hội để khách hàng phân tâm. "Đề dành" tính năng cho buổi sau còn là một chiêu tạo lý do cho lần gặp tiếp theo.
Ví dụ 3: Startup SaaS demo bị "sự cố kỹ thuật" nuốt chửng
Một startup SaaS Việt Nam bán công cụ quản lý kho cho các shop online demo cho một nhà bán hàng lớn trên Shopee. Sales Engineer quyết định demo trên dữ liệu thật, kết nối trực tiếp API Shopee ngay tại buổi họp. Giữa demo, API timeout, màn hình quay vòng, và 4 phút quý giá trôi qua trong lúng túng. Khoảnh khắc "wow" biến thành khoảnh khắc "ê chề".
Sau buổi đó, PMM ra một quy tắc cứng cho toàn đội: mọi demo phải chạy trên môi trường sandbox với dữ liệu mẫu đã được dàn dựng sẵn (demo data đẹp, có sẵn các đơn hàng minh họa đúng kịch bản), và mọi kịch bản demo phải được "rehearse" ít nhất một lần trước buổi họp thật. Kết nối live với hệ thống khách hàng chỉ diễn ra ở giai đoạn Proof of Concept sau này, không phải trong demo bán hàng.
Bài học: demo là sân khấu, và mọi nghệ sĩ chuyên nghiệp đều tổng duyệt. Rủi ro kỹ thuật giết chết storytelling nhanh hơn bất kỳ lỗi nội dung nào. PMM có trách nhiệm thiết kế cả "môi trường an toàn" cho demo, không chỉ kịch bản.
Hướng dẫn từng bước
Đây là quy trình để bạn — với vai trò PMM — thiết kế một luồng demo hoàn chỉnh:
Bước 1 — Xác định persona và use case then chốt. Bạn không thiết kế "một demo" mà thiết kế "demo cho ai, giải bài toán gì". Chọn đúng một use case đau nhất cho persona mục tiêu. Nếu sản phẩm phục vụ nhiều persona, hãy làm nhiều biến thể demo, mỗi biến thể một câu chuyện.
Bước 2 — Viết ra câu chuyện trước khi chạm vào sản phẩm. Lấy giấy bút (hoặc slide trắng), viết ra mạch truyện theo cấu trúc 5 phần: bối cảnh → nỗi đau → cú lật → kết quả → bước tiếp. Đây là "screenplay" của demo. Chưa cần biết bấm nút nào.
Bước 3 — Ánh xạ mỗi đoạn truyện sang thao tác cụ thể trên sản phẩm. Bây giờ mới mở phần mềm ra. Với mỗi phần của câu chuyện, xác định đúng thao tác tối thiểu cần làm. Nguyên tắc vàng: nếu một thao tác không đẩy câu chuyện tiến lên, cắt bỏ.
Bước 4 — Xác định khoảnh khắc "wow" duy nhất. Chọn ra một điểm là đỉnh cảm xúc của demo. Dồn lực dàn dựng cho nó: tạo suspense trước đó ("giờ hãy để ý con số này"), làm chậm lại đúng lúc, và để một khoảng lặng sau khi nó xảy ra để khách hàng cảm nhận.
Bước 5 — Chuẩn bị demo data đã dàn dựng. Tạo tài khoản mẫu với dữ liệu sạch, đẹp, và đúng ngữ cảnh ngành của khách hàng. Tên công ty, tên sản phẩm, con số — tất cả nên trông giống thế giới của khách hàng, không phải "Test Company 123" với "Sản phẩm ABC".
Bước 6 — Cài các chốt tương tác (interaction hooks). Thiết kế sẵn 2–3 điểm dừng để hỏi khách hàng: "Chỗ này khớp với quy trình bên anh chứ?". Demo một chiều là độc thoại; demo hai chiều là bán hàng. Những câu hỏi này cũng giúp bạn phát hiện phản đối sớm.
Bước 7 — Viết "leave-behind" và tài liệu hóa cho đội Sales. Đóng gói luồng demo thành một demo script chuẩn: slide bối cảnh, checklist thao tác, câu thoại mẫu cho từng phần, và các câu trả lời cho phản đối thường gặp. Đây là điểm PMM tạo đòn bẩy: một script tốt được nhân bản qua mọi Sales.
Bước 8 — Tổng duyệt và tinh chỉnh theo phản hồi. Chạy thử với đồng nghiệp đóng vai khách hàng khó tính. Bấm giờ. Nếu demo dài quá 15–20 phút cho phần lõi, cắt tiếp. Sau mỗi demo thật, thu thập phản hồi và lặp lại.
Lỗi thường gặp & mẹo
Lỗi 1 — "Death by feature." Sợ bỏ sót nên nhồi hết tính năng vào. Mẹo: mỗi khi định thêm một màn hình, hỏi "nó phục vụ câu chuyện nào?". Không có câu trả lời rõ ràng thì cắt.
Lỗi 2 — Bắt đầu bằng sản phẩm, không phải bằng vấn đề. Mở màn "Đây là dashboard của chúng tôi..." khiến khách hàng chưa thấy lý do quan tâm. Mẹo: luôn dành 2 phút đầu cho bối cảnh và nỗi đau, chưa share màn hình sản phẩm.
Lỗi 3 — Độc thoại 30 phút. Nói liên tục không cho khách chen vào. Mẹo: cứ 3–4 phút cắm một câu hỏi. Biến demo thành hội thoại.
Lỗi 4 — Quá nhiều khoảnh khắc "wow" khiến chẳng cái nào wow. Mẹo: chọn một đỉnh duy nhất, hạ thấp mọi thứ khác để nó nổi bật.
Lỗi 5 — Dùng jargon nội bộ. Gọi tính năng bằng tên mã nội bộ ("module X-27") mà khách không hiểu. Mẹo: gọi tính năng bằng ngôn ngữ lợi ích của khách hàng.
Lỗi 6 — Demo live trên hệ thống thật đầy rủi ro. Mẹo: sandbox + demo data đã kiểm tra + tổng duyệt. Luôn có phương án B (bản ghi màn hình) phòng khi sự cố.
Mẹo vàng — "Câu chuyện có thể kể lại": khách hàng giỏi nhất của bạn là người sẽ đi kể lại demo cho sếp của họ (người ra quyết định không dự demo). Nếu demo của bạn đơn giản và mạch lạc đến mức khách hàng có thể tóm tắt nó trong một câu, bạn đã thắng. Hãy thiết kế để câu chuyện "dễ kể lại".
Bài tập thực hành
Bài tập 1 — Phân biệt tour và demo. Chọn một sản phẩm bạn quen (có thể là chính sản phẩm công ty bạn, hoặc một app như MoMo, Base, Shopee). Viết ra hai kịch bản mở màn 3 phút: một theo kiểu feature tour, một theo kiểu demo lấy khách hàng làm trung tâm. Đọc to cả hai và cảm nhận sự khác biệt.
Bài tập 2 — Viết screenplay 5 phần. Chọn một persona cụ thể và một use case đau nhất. Viết ra luồng demo theo cấu trúc 5 phần (Setup → Problem → Reveal → Payoff → Path forward), mỗi phần 2–4 câu. Chưa cần đụng đến sản phẩm — chỉ viết câu chuyện.
Bài tập 3 — Xác định khoảnh khắc wow. Từ screenplay ở bài 2, khoanh tròn đúng MỘT thao tác sẽ là đỉnh cảm xúc. Viết ra ba câu: câu tạo suspense trước đó, mô tả thao tác, và câu chốt ý nghĩa sau đó (Tell-Show-Tell).
Bài tập 4 — Đóng gói cho Sales. Chuyển screenplay thành một demo script một trang: checklist thao tác + câu thoại mẫu + 3 câu trả lời cho phản đối thường gặp. Thử đưa cho một đồng nghiệp không biết sản phẩm và xem họ có chạy theo được không.
Tóm tắt
Demo không phải là màn khoe tính năng — nó là một câu chuyện được dàn dựng để khách hàng thấy chính vấn đề của mình được giải quyết. Ranh giới cốt lõi: feature tour lấy sản phẩm làm trung tâm và nói "đây là tất cả những gì chúng tôi có", còn demo lấy khách hàng làm trung tâm và nói "để tôi cho anh xem cách giải quyết vấn đề của anh".
Luồng demo chuẩn đi theo 5 phần: dựng bối cảnh, khoảnh khắc đau, cú lật (một khoảnh khắc wow duy nhất), kết quả, và bước tiếp theo. Xuyên suốt, áp dụng Tell-Show-Tell để khách hàng không bao giờ lạc, và giữ kỷ luật cắt bỏ mọi thứ không phục vụ câu chuyện.
Với vai trò PMM, giá trị lớn nhất bạn tạo ra không phải là buổi demo cho một khách hàng — mà là thiết kế và đóng gói luồng demo chuẩn để mọi Sales trong công ty tái sử dụng. Hãy viết câu chuyện trước, ánh xạ sang thao tác sau, dàn dựng demo data cẩn thận, tổng duyệt kỹ, và luôn thiết kế để câu chuyện "dễ kể lại". Một demo tốt là câu chuyện mà khách hàng có thể kể lại cho sếp của họ chỉ trong một câu.