Mở đầu — vì sao bài này quan trọng
Bạn có thể có một sản phẩm xuất sắc, một kiến trúc kỹ thuật tinh tế, hay một giải pháp giải quyết đúng nỗi đau của khách hàng. Nhưng nếu buổi demo diễn ra vụng về — màn hình treo, dữ liệu mẫu trông giả tạo, hay bạn nói mười lăm phút mà người nghe vẫn không hiểu "vậy thì sao" — thì tất cả công sức phía sau gần như tan biến trong vài phút định mệnh đó.
Demo và pitch tới stakeholder là khoảnh khắc mà công nghệ gặp con người ra quyết định. Đây không phải lúc để khoe kỹ thuật, mà là lúc để tạo ra một trải nghiệm khiến người nghe tin rằng thứ bạn đang trình bày đáng để họ chi tiền, phân bổ nguồn lực, hay gật đầu phê duyệt. Điều trớ trêu là: kỹ năng demo và pitch hiếm khi được dạy bài bản cho dân kỹ thuật. Chúng ta được đào tạo để làm cho sản phẩm chạy đúng, chứ không phải để làm cho nó trông thuyết phục trước mặt người khác.
Bài này tập trung riêng vào hai năng lực gắn bó với nhau: (1) cách demo một sản phẩm sao cho mượt mà và đáng nhớ, và (2) cách pitch tới stakeholder — những người nắm quyền quyết định nhưng thường không chia sẻ nền tảng kỹ thuật với bạn. Đây là kỹ năng thực chiến, càng luyện càng vững, và một khi thành thạo, nó sẽ theo bạn suốt sự nghiệp — từ demo cho sếp, cho khách hàng, cho nhà đầu tư, cho đến ban lãnh đạo.
Khái niệm cốt lõi
Demo không phải là "cho xem sản phẩm", mà là "kể một câu chuyện có sản phẩm trong đó"
Sai lầm phổ biến nhất là biến demo thành một tour tham quan tính năng: "Đây là nút này, đây là màn hình kia, chỗ này chúng tôi có thêm bộ lọc...". Người nghe không quan tâm sản phẩm có gì; họ quan tâm sản phẩm làm được gì cho họ. Một demo tốt luôn xoay quanh một tình huống thực tế mà người nghe nhận ra chính mình trong đó. Bạn không demo "chức năng export báo cáo", bạn demo "cảnh chị kế toán trưởng cuối tháng chỉ cần bấm một nút thay vì ngồi ghép Excel ba tiếng đồng hồ".
Nguyên tắc vàng: Show, don't tell — nhưng show có chủ đích. Mỗi thao tác trên màn hình phải phục vụ một điểm giá trị cụ thể, không thừa, không lan man.
Hiểu khán giả: technical hay business?
Trước mọi buổi demo hay pitch, câu hỏi đầu tiên phải là: người ngồi đối diện là ai? Cùng một sản phẩm, bạn phải kể theo hai kiểu hoàn toàn khác nhau.
- Khán giả kỹ thuật (kỹ sư, kiến trúc sư giải pháp, CTO): họ muốn biết nó hoạt động thế nào, có mở rộng được không, độ trễ ra sao, tích hợp với hệ thống hiện tại thế nào. Với nhóm này, sự trung thực kỹ thuật và chiều sâu là thứ tạo niềm tin.
- Khán giả business (giám đốc, trưởng phòng, nhà đầu tư): họ muốn biết nó giải quyết vấn đề gì, tốn bao nhiêu, tiết kiệm/mang lại bao nhiêu, rủi ro thế nào, bao lâu thấy kết quả. Với nhóm này, chi tiết kỹ thuật quá sâu là gây nhiễu, không phải gây ấn tượng.
Chuẩn bị môi trường demo: đừng bao giờ live coding
Đây là quy tắc gần như tuyệt đối trong demo trước stakeholder: không live coding, không thao tác ngẫu hứng trên môi trường thật chưa kiểm soát. Live coding hấp dẫn với dân dev vì nó thể hiện sự tự tin, nhưng trước stakeholder nó là canh bạc: chỉ cần một lỗi cú pháp, một API timeout, một dòng dữ liệu xấu, buổi demo sụp đổ và bạn mất sạch uy tín.
Thay vào đó, hãy chuẩn bị một môi trường demo được kiểm soát: dữ liệu mẫu sạch và thực tế, kịch bản đã chạy thử nhiều lần, mọi bước đã bấm đúng thứ tự. Và luôn có backup plan: bản ghi màn hình (screen recording) của toàn bộ luồng demo, ảnh chụp các bước quan trọng, hoặc môi trường staging thứ hai. Nếu mạng chết hay hệ thống treo, bạn chuyển sang video mà không hề bối rối.
Cấu trúc một pitch tới stakeholder
Một pitch hiệu quả thường đi theo mạch: Vấn đề → Giải pháp → Bằng chứng → Lời kêu gọi hành động. Bạn mở đầu bằng nỗi đau cụ thể mà stakeholder quan tâm, cho họ thấy giải pháp qua demo, chứng minh bằng số liệu/kết quả, rồi kết bằng một đề nghị rõ ràng (phê duyệt ngân sách, ký hợp đồng, cho triển khai thử). Đừng bao giờ kết thúc bằng "vậy đó, cảm ơn mọi người" — luôn phải có một "ask" cụ thể.
Tình huống thực tế
Ví dụ 1 — Buổi demo suýt hỏng của startup fintech tại TP.HCM
Một startup fintech giả định tên VíNhanh phát triển giải pháp thanh toán cho chuỗi cửa hàng bán lẻ. Họ được mời demo cho ban lãnh đạo một chuỗi siêu thị mini có 40 điểm bán. Founder — vốn là dân kỹ thuật — quyết định demo live việc tạo một giao dịch qua API thật, kết nối tới sandbox của ngân hàng đối tác.
Đúng lúc demo, sandbox của ngân hàng bị bảo trì đột xuất. Màn hình quay vòng loading, founder toát mồ hôi, lặp lại "chờ chút, bình thường nó nhanh lắm" đến ba lần. Không khí phòng họp lạnh dần. May mắn là CTO đi cùng đã âm thầm chuẩn bị một video screen recording luồng thanh toán hoàn chỉnh từ tuần trước. Anh này xin phép chuyển sang video, vừa chạy vừa thuyết minh, và cứu được buổi demo.
Bài học: Không bao giờ để buổi demo phụ thuộc vào một hệ thống bên thứ ba mà bạn không kiểm soát được vào thời điểm đó. Backup plan không phải là sự thiếu tự tin — nó là dấu hiệu của sự chuyên nghiệp. Sau lần đó, VíNhanh ra quy tắc nội bộ: mọi demo với khách đều phải có video dự phòng và dữ liệu mẫu chạy offline.
Ví dụ 2 — Cùng một sản phẩm, hai cách pitch khác nhau
Một công ty phần mềm quản lý kho giả định tên KhoThôngMinh đi pitch giải pháp WMS (warehouse management system) cho một doanh nghiệp logistics ở Bình Dương. Buổi làm việc có hai nhóm ngồi cùng phòng: giám đốc vận hành (business) và trưởng phòng IT (technical).
Ở lần pitch đầu, người trình bày dành 20 phút nói về kiến trúc event-driven, hàng đợi message, khả năng xử lý 10.000 đơn/phút. Trưởng phòng IT gật gù thích thú, nhưng giám đốc vận hành — người ký quyết định — ngồi bấm điện thoại vì chẳng thấy liên quan.
Lần pitch thứ hai, họ đổi cách. Mở đầu bằng con số business: "Hiện tại mỗi tháng kho của anh chị thất thoát khoảng 3% hàng do sai sót kiểm đếm thủ công, tương đương khoảng 180 triệu đồng." Rồi họ demo cảnh nhân viên kho quét mã bằng điện thoại và hệ thống tự đối soát tồn kho theo thời gian thực. Chỉ sau đó, khi trưởng phòng IT đặt câu hỏi kỹ thuật, họ mới đi sâu vào kiến trúc — đúng lúc, đúng người. Giám đốc vận hành phê duyệt triển khai thử ngay trong tuần đó.
Bài học: Khi phòng họp có cả hai nhóm khán giả, hãy dẫn dắt bằng ngôn ngữ business, và đào sâu kỹ thuật khi được hỏi. Đừng ép người ra quyết định phải ngồi nghe thứ họ không có nền tảng để đánh giá.
Ví dụ 3 — Grab và sức mạnh của dữ liệu demo "biết nói"
Grab, khi giới thiệu các giải pháp cho đối tác merchant tại Đông Nam Á, nổi tiếng với việc dùng dữ liệu demo phản ánh đúng bối cảnh địa phương. Thay vì dùng dữ liệu mẫu chung chung kiểu "Sản phẩm A, Sản phẩm B", đội ngũ giải pháp của họ dựng demo với tên món ăn Việt thật, mức giá thật bằng VND, khung giờ cao điểm giao đồ ăn buổi trưa của người Việt.
Kết quả là đối tác nhìn vào màn hình và lập tức thấy chính cửa hàng của mình trong đó, thay vì phải tự tưởng tượng. Sự đồng cảm đó rút ngắn khoảng cách niềm tin rất nhiều.
Bài học: Dữ liệu demo càng gần với thực tế của khán giả, sức thuyết phục càng cao. Một cái tên "Bún bò Huế — 45.000đ" mạnh hơn "Món ăn 001 — $2.00" gấp nhiều lần khi bạn đang đứng trước chủ quán ăn Việt Nam.
Hướng dẫn từng bước
Bước 1 — Xác định khán giả và mục tiêu. Trước buổi demo, viết ra hai câu: "Người ra quyết định là ai?" và "Sau buổi này, tôi muốn họ làm gì?". Toàn bộ demo phải phục vụ hai câu đó.
Bước 2 — Chọn một kịch bản duy nhất, kể như một câu chuyện. Đừng cố demo hết tính năng. Chọn một luồng đại diện cho giá trị cốt lõi, gắn với một nhân vật (persona) và một nỗi đau cụ thể.
Bước 3 — Chuẩn bị môi trường và dữ liệu mẫu chất lượng. Dữ liệu phải sạch, thực tế, đúng bối cảnh địa phương. Chạy thử toàn bộ kịch bản ít nhất 3 lần cho đến khi mọi bước trơn tru.
Bước 4 — Dựng backup plan. Quay screen recording toàn bộ luồng demo. Chụp ảnh các bước quan trọng. Chuẩn bị môi trường thứ hai nếu có thể. Đặt sẵn câu chuyển: "Để tiết kiệm thời gian, tôi sẽ cho anh chị xem bản ghi luồng này."
Bước 5 — Mở đầu bằng vấn đề, không bằng sản phẩm. 30 giây đầu phải chạm vào nỗi đau của khán giả bằng ngôn ngữ và con số của họ.
Bước 6 — Demo có chủ đích, mỗi thao tác gắn một giá trị. Vừa thao tác vừa diễn giải "điều này có nghĩa là gì với anh chị", không đọc tên nút.
Bước 7 — Chốt bằng bằng chứng và lời kêu gọi hành động. Đưa số liệu/kết quả, rồi đề nghị rõ ràng bước tiếp theo.
Bước 8 — Dự phòng câu hỏi. Chuẩn bị trước 5–7 câu hỏi khó nhất mà stakeholder có thể đặt, và luyện câu trả lời ngắn gọn.
Lỗi thường gặp & mẹo
- Demo quá dài, quá nhiều tính năng. Người nghe chỉ nhớ được một, hai điểm. Thà demo ít mà sâu còn hơn nhiều mà loãng. Mẹo: nếu bạn phân vân có nên demo một tính năng, câu trả lời gần như luôn là "không".
- Live coding hoặc thao tác chưa kiểm soát. Đã nói ở trên, nhưng đáng nhắc lại: rủi ro không đáng với chút "ngầu" nó mang lại. Luôn có bản ghi dự phòng.
- Nói ngôn ngữ kỹ thuật với người business. Dịch mọi thứ ra giá trị: tiền tiết kiệm, thời gian rút ngắn, rủi ro giảm. "Độ trễ 50ms" nên trở thành "khách hàng thấy kết quả ngay lập tức, không phải chờ".
- Không có "ask" ở cuối. Kết thúc lửng lơ khiến buổi pitch mất động lực. Luôn đề nghị một bước cụ thể tiếp theo.
- Xin lỗi vì lỗi vặt. Nếu có một trục trặc nhỏ, đừng làm to chuyện. Mỗi lần bạn xin lỗi là một lần bạn kéo sự chú ý vào điểm yếu. Xử lý gọn và đi tiếp.
- Mẹo tâm lý: đến sớm, kiểm tra máy chiếu, mạng, âm thanh, độ phân giải. Một buổi demo trơn tru bắt đầu từ 15 phút setup yên tĩnh trước khi khán giả bước vào.
- Mẹo về nhịp: dừng lại sau mỗi điểm giá trị quan trọng, nhìn khán giả, để họ kịp "thấm". Đừng lướt qua như đang chạy đua với thời gian.
Bài tập thực hành
- Xác định khán giả kép. Chọn một sản phẩm hoặc dự án bạn đang làm. Viết hai phiên bản mở đầu demo dài 60 giây: một cho khán giả kỹ thuật, một cho khán giả business. So sánh xem chúng khác nhau thế nào về ngôn ngữ và trọng tâm.
- Dựng kịch bản demo một luồng. Chọn đúng một luồng giá trị cốt lõi của sản phẩm. Viết ra kịch bản từng bước, gắn mỗi thao tác với một câu diễn giải giá trị ("điều này giúp anh chị..."). Loại bỏ mọi bước không phục vụ giá trị.
- Chuẩn bị backup plan thật. Quay một screen recording hoàn chỉnh luồng demo của bạn. Sau đó, tự tạo một tình huống hỏng (tắt mạng, dừng server) và luyện tập chuyển sang video một cách mượt mà, nói được câu chuyển tiếp không lúng túng.
- Luyện chốt bằng "ask". Viết ba cách kết thúc pitch khác nhau, mỗi cách có một lời kêu gọi hành động cụ thể (ví dụ: "Tôi đề nghị chúng ta chạy thử 2 tuần trên một điểm bán"). Đọc to và chọn cái tự nhiên nhất với bạn.
- Diễn tập trước một người "phản biện". Nhờ một đồng nghiệp đóng vai stakeholder khó tính, đặt câu hỏi về chi phí, rủi ro, thời gian triển khai. Ghi lại những câu bạn trả lời vấp và chuẩn bị lại.
Tóm tắt
Demo và stakeholder pitch là khoảnh khắc công nghệ gặp người ra quyết định — và thường quyết định số phận của cả một dự án chỉ trong vài phút. Điểm cốt lõi cần khắc ghi:
- Demo là kể chuyện có sản phẩm bên trong, không phải tour tính năng. Mỗi thao tác phải gắn với một giá trị cụ thể cho khán giả.
- Luôn hỏi khán giả là ai — technical hay business — và điều chỉnh ngôn ngữ cho phù hợp. Dẫn dắt bằng business, đào sâu kỹ thuật khi được hỏi.
- Không bao giờ live coding trước stakeholder. Chuẩn bị môi trường kiểm soát, dữ liệu mẫu thực tế đúng bối cảnh, và luôn có backup plan bằng video ghi màn hình.
- Cấu trúc pitch: Vấn đề → Giải pháp → Bằng chứng → Lời kêu gọi hành động. Không bao giờ kết thúc mà không có một "ask" rõ ràng.
- Dữ liệu demo càng gần thực tế khán giả, sức thuyết phục càng cao — như Grab dùng tên món ăn Việt và giá VND thật.