Storytelling & Presenting

Vì sao PM phải kể chuyện được

Phần lớn công việc của PM kết thúc bằng một lần trình bày: xin nguồn lực, bảo vệ roadmap, báo kết quả một thí nghiệm, thuyết phục kỹ sư rằng vấn đề đáng giải. Nếu người nghe không hiểu hoặc không nhớ, công sức phía trước gần như mất trắng. Trình bày không phải là đọc lại những gì bạn đã làm; nó là giúp người nghe đi đến một kết luận và một quyết định.

Trang này có kỹ năng riêng về giao tiếp với hội đồng quản trị và ban điều hành (Board & Exec Communication). Kỹ năng ở đây là nền bên dưới: cách dựng một câu chuyện, chọn dữ liệu và đứng trước bất kỳ nhóm người nghe nào — từ kỹ sư, sales tới khách hàng.

Một câu chuyện sản phẩm có năm phần. Thiếu phần nào, người nghe sẽ cảm thấy thiếu mà không gọi tên được:

Phần hay bị thiếu nhất là căng thẳng — PM nhảy thẳng từ bối cảnh sang giải pháp, và người nghe không hiểu vì sao phải quan tâm. Phần hay bị thiếu thứ hai là lời đề nghị: buổi trình bày kết thúc, mọi người gật đầu, và không ai biết mình vừa đồng ý điều gì.

Biết người nghe là ai

Cùng một nội dung, bốn nhóm người nghe cần bốn cách kể. Sai lầm phổ biến là dùng một bộ slide cho mọi buổi — bộ slide đó sẽ quá chi tiết cho sếp và quá mơ hồ cho kỹ sư.

Trước mỗi buổi trình bày, viết một câu: "Sau buổi này, [ai] sẽ [hiểu điều gì] và [làm gì]." Nếu không viết được câu đó, bạn chưa sẵn sàng làm slide.

Kết luận trước, rồi mới đến lý do — cấu trúc SCQA

Cách kể theo thứ tự thời gian ("đầu tiên chúng tôi phỏng vấn, sau đó chúng tôi phân tích, rồi chúng tôi thấy...") tự nhiên với người kể nhưng mệt cho người nghe: họ phải giữ mọi thứ trong đầu đến phút cuối mới biết điều gì quan trọng. Sếp thường cắt ngang trước khi bạn đến phần đó. Hãy nói kết luận trong một câu ở ngay đầu, rồi dùng phần còn lại để chứng minh.

Khung SCQA giúp dựng phần mở đầu: Situation (tình hình), Complication (vấn đề phát sinh), Question (câu hỏi cần trả lời), Answer (câu trả lời). Phần còn lại của deck là các lý do ủng hộ câu trả lời, mỗi lý do một nhóm slide.

Tiêu đề slide là một câu khẳng định, không phải một nhãn. "Doanh thu quý 3" là nhãn; "Doanh thu quý 3 hụt 12% vì khách doanh nghiệp gia hạn chậm" là khẳng định. Một cách kiểm: đọc liên tiếp các tiêu đề slide mà không nhìn nội dung — nếu thành một câu chuyện mạch lạc, deck của bạn đã có xương sống.

Kể chuyện bằng dữ liệu: mỗi biểu đồ một ý

Biểu đồ trong một buổi trình bày không phải để người nghe tự khám phá; nó để chứng minh một ý bạn đã nói. Nếu người nghe phải hỏi "biểu đồ này nói gì", bạn đã bắt họ làm việc của bạn.

• Viết ý chính làm tiêu đề biểu đồ. "Khách đặt đơn đầu vào giờ trưa chờ lâu gần gấp đôi" thay vì "Thời gian chờ theo khung giờ".
• Làm nổi một đường, làm mờ phần còn lại. Nếu bạn muốn nói về khách mới, tô màu nhóm đó và để các nhóm khác màu xám.
• Một biểu đồ, một so sánh. Muốn nói hai điều thì dùng hai biểu đồ. Một biểu đồ có sáu đường và hai trục tung là một bảng tính, không phải một luận điểm.
• Luôn có điểm so sánh: so với mục tiêu, so với cùng kỳ, so với nhóm đối chứng. Một con số đứng một mình không nói được tốt hay xấu.
• Nói rõ nguồn và định nghĩa ở chân slide. Người hoài nghi nhất trong phòng sẽ hỏi; trả lời được ngay làm tăng niềm tin vào mọi slide còn lại.
• Làm tròn. "Khoảng 38%" dễ nhớ hơn "37,84%", và độ chính xác thừa không làm con số đáng tin hơn.

Trình bày roadmap và thí nghiệm thất bại một cách trung thực

Roadmap không phải lời hứa ngày giao hàng. Khi trình bày roadmap, hãy nói rõ mức chắc chắn của từng phần: việc đang làm (chắc chắn cao, có thời gian cụ thể), việc tiếp theo (đã có hướng, thời gian ước lượng theo quý), việc sau đó (đang khám phá, chưa cam kết). Nếu bạn trình bày tất cả như nhau, người nghe sẽ nhớ mọi thứ như một lời hứa, và mỗi lần trễ sẽ trở thành một lần mất uy tín.

Thí nghiệm thất bại là dữ liệu, không phải tai nạn. Ở nhiều công ty Việt Nam, PM ngại báo một thí nghiệm không đạt vì sợ bị đánh giá kém. Kết quả là kết quả xấu bị giấu hoặc tô hồng, và công ty lặp lại cùng một sai lầm. Một cấu trúc giúp trình bày thất bại mà vẫn giữ được uy tín:

Người nghe tin PM báo thất bại rõ ràng hơn PM chỉ báo thành công — vì khi PM đó nói "thành công", họ biết điều đó có nghĩa.

Trước và sau: viết lại một bản cập nhật yếu, và dàn ý một deck

Bối cảnh (giả định): PM của squad Thanh toán tại ví điện tử TúiVàng gửi cập nhật cuối tháng cho Giám đốc khối sản phẩm. Bản đầu tiên:

Chào anh,

Tháng này team đã hoàn thành sprint 14 và 15. Bọn em đã release tính năng lưu thẻ,
fix 23 bug, làm việc với bên đối tác ngân hàng về API mới, và họp với team Marketing
về chiến dịch tháng sau. Tỉ lệ thanh toán thành công là 91,2%. Có một số vấn đề với
đối tác nhưng bọn em đang xử lý. Tháng sau bọn em sẽ tiếp tục làm các task còn lại.

Em cảm ơn anh.

Bản này liệt kê việc đã làm, nhưng không trả lời ba câu sếp thật sự có: tình hình tốt hay xấu, vì sao, và anh cần làm gì. Con số 91,2% đứng một mình, không biết so với cái gì. "Một số vấn đề với đối tác" là câu mà sếp sẽ phải gọi điện hỏi thêm. Bản viết lại:

Chào anh,

Tóm tắt: Tỉ lệ thanh toán thành công tháng này 91% — dưới mục tiêu 94%. Nguyên nhân chính
là lỗi kết nối với một ngân hàng đối tác. Em cần anh hỗ trợ một cuộc gọi cấp giám đốc
với họ trước ngày 20.

1. Kết quả
   - Thanh toán thành công: 91% (tháng trước 93%, mục tiêu 94%).
   - Lưu thẻ đã ra mắt ngày 08: 27% người thanh toán bằng thẻ đã lưu thẻ;
     những người này thanh toán nhanh hơn trung bình 14 giây.

2. Vấn đề
   - 60% giao dịch thất bại tăng thêm đến từ một ngân hàng đối tác, do họ đổi cổng kết nối
     mà không báo trước. Đội kỹ thuật hai bên đã làm việc hai tuần, chưa có ngày sửa.

3. Đề nghị
   - Anh gọi cho Giám đốc khối số hoá bên ngân hàng để chốt ngày sửa. Em đã gửi anh
     bản tóm tắt kỹ thuật một trang.

4. Tháng tới
   - Đưa tỉ lệ thành công về 94% khi đối tác sửa xong.
   - Thử nhắc lưu thẻ ở màn hình thanh toán thành công, mục tiêu 35% người dùng thẻ lưu thẻ.

Em cảm ơn anh.

Bản sau không dài hơn bao nhiêu, nhưng sếp đọc ba dòng đầu là biết tình hình và việc mình cần làm. Danh sách "fix 23 bug, họp Marketing" biến mất — không phải vì không quan trọng, mà vì nó không giúp người đọc quyết định gì.

Dàn ý deck 10 slide cho buổi xin nguồn lực, theo SCQA — có thể copy và thay nội dung:

DECK: [Tên đề xuất] — [ngày], [người nghe]

1. Đề xuất trong một câu + điều cần quyết hôm nay
   (ví dụ: Xin 2 kỹ sư trong 6 tuần để giảm thời gian chờ đơn đầu; cần quyết hôm nay)
2. Tình hình: con số ai cũng đồng ý
3. Vấn đề: điều đang đi sai, một biểu đồ, một ý
4. Insight: điều chúng ta mới phát hiện, kèm bằng chứng (số liệu + một câu của khách)
5. Giải pháp đề xuất và vì sao chọn cách này
6. Các phương án đã cân nhắc và vì sao không chọn
7. Giá trị kỳ vọng: thấp / giữa / cao, giả định yếu nhất
8. Chi phí và rủi ro: người, thời gian, điều gì có thể sai, cách phát hiện sớm
9. Cách đo và ngày báo lại kết quả
10. Nhắc lại lời đề nghị: ai quyết, quyết gì, trước ngày nào

Phụ lục: số liệu chi tiết, định nghĩa chỉ số, câu hỏi dự kiến và câu trả lời

Câu hỏi khó và văn hoá doanh nghiệp Việt Nam

Câu hỏi khó là dấu hiệu người nghe đang để tâm, không phải dấu hiệu bạn đã thua. Chuẩn bị trước bằng cách liệt kê năm câu hỏi bạn sợ nhất và viết câu trả lời ngắn cho từng câu; đưa số liệu hỗ trợ vào phụ lục để lật ra khi cần.

Trình bày trong văn hoá doanh nghiệp Việt Nam có vài điều riêng mà sách nước ngoài ít nói tới:

• Thứ bậc ảnh hưởng tới việc ai nói gì trong phòng. Người cấp dưới ít khi phản biện sếp trước đông người. Nếu bạn cần ý kiến thật, hãy gặp riêng từng người trước buổi họp (tiền hội ý). Buổi họp chính nên là nơi chốt quyết định, không phải nơi lần đầu tiên mọi người nghe đề xuất.
• Giữ thể diện cho người khác. Khi số liệu cho thấy một quyết định trước đây của sếp hay của đội khác không hiệu quả, nói về quyết định và dữ liệu, không nói về người. "Giả định về mức chuyển đổi đã không đúng" thay vì "kế hoạch của anh A sai".
• Xin quyết định một cách rõ ràng nhưng lễ độ. "Em xin anh chị quyết giúp em giữa phương án A và B hôm nay để đội bắt đầu từ thứ Hai" vừa rõ vừa giữ được sự tôn trọng. Câu "anh chị thấy sao ạ" ở cuối buổi thường nhận về "để anh suy nghĩ thêm".
• Im lặng không có nghĩa là đồng ý. Sau buổi họp, gửi email tóm tắt quyết định trong ngày và hỏi xác nhận. Đó là cách biến một cái gật đầu thành một cam kết.
• Song ngữ có chừng mực. Dùng thuật ngữ tiếng Anh mà cả phòng đã quen, nhưng đừng để mỗi câu có ba từ tiếng Anh — người nghe ở khối kinh doanh hay vận hành sẽ mất mạch.

Lỗi thường gặp

Luyện kỹ năng này trong tuần này

• Lấy bản cập nhật gần nhất bạn đã gửi và viết lại theo mẫu TúiVàng: tóm tắt ba dòng, kết quả so với mục tiêu, vấn đề, đề nghị. So hai bản cạnh nhau.
• Với buổi trình bày sắp tới, viết câu "sau buổi này [ai] sẽ [làm gì]" trước khi mở phần mềm làm slide.
• Đọc liền các tiêu đề slide của deck gần nhất. Sửa mọi tiêu đề là nhãn thành một câu khẳng định.
• Chọn một biểu đồ bạn hay dùng và làm lại: tiêu đề là ý chính, một đường được tô màu, phần còn lại màu xám, có điểm so sánh.
• Liệt kê năm câu hỏi khó nhất cho buổi trình bày tới, viết câu trả lời ngắn và nhờ một đồng nghiệp hỏi thử.