Mở đầu — vì sao bài này quan trọng
Trong suốt hành trình PMM, bạn đã học cách lên kế hoạch launch, chạy checklist pre-launch, phân tầng launch theo 4 tier và đo lường metrics ban đầu. Nhưng có một sự thật ít ai nói thẳng: phần lớn giá trị học được từ một lần launch KHÔNG nằm trong tuần ra mắt, mà nằm ở những gì bạn làm sau đó 2–4 tuần. Đó chính là launch post-mortem — buổi "mổ xẻ" có cấu trúc để rút ra bài học, cải thiện lần sau và lưu lại tri thức cho cả tổ chức.
Tôi đã chứng kiến quá nhiều đội PMM chạy launch xong là "thở phào" rồi lao ngay vào launch tiếp theo. Kết quả? Họ lặp lại đúng những sai lầm cũ: sales lại không có battlecard kịp thời, PR lại lệch timeline với engineering, landing page lại chậm 3 ngày. Không phải vì họ kém, mà vì không ai ngồi lại để hệ thống hóa (codify) bài học thành tài liệu và quy trình.
Post-mortem không phải là buổi "truy tìm thủ phạm". Nó là công cụ để một tổ chức học nhanh hơn đối thủ. Một PMM giỏi có thể biến mỗi lần launch — dù thành công hay thất bại — thành một tài sản tri thức. Bài này sẽ dạy bạn cách làm điều đó một cách chuyên nghiệp, có kỷ luật và tạo ra ảnh hưởng thật sự.
Khái niệm cốt lõi
Post-mortem là gì và không phải là gì
Post-mortem (còn gọi là launch retrospective hoặc launch debrief) là buổi họp có cấu trúc, diễn ra sau khi một sản phẩm/tính năng đã ra mắt và có đủ dữ liệu, nhằm ba mục tiêu:
- Codify learnings — hệ thống hóa bài học thành dạng có thể tái sử dụng, không để nó "bay hơi" trong đầu vài người.
- Improve next launch — biến bài học thành hành động cụ thể cho lần launch kế tiếp.
- Document for org — lưu lại thành tài liệu để những người không tham gia launch này (đội mới, quý sau, phòng ban khác) vẫn học được.
- Buổi đổ lỗi cá nhân (blame game).
- Buổi khoe thành tích (chỉ nói cái tốt).
- Một cuộc họp "cho có" rồi biên bản nằm chết trong Google Drive.
Nguyên tắc "blameless" — không đổ lỗi
Đây là nguyên tắc quan trọng nhất, vay mượn từ văn hóa post-mortem của các đội engineering (như SRE của Google). Blameless nghĩa là: chúng ta giả định mọi người đã hành động hợp lý với thông tin họ có tại thời điểm đó. Khi có sự cố, ta hỏi "Quy trình/hệ thống nào đã cho phép sai lầm này xảy ra?" thay vì "Ai đã làm sai?".
Vì sao quan trọng? Vì nếu người ta sợ bị đổ lỗi, họ sẽ giấu vấn đề. Mà PMM lại là vai trò giao thoa (Product, Marketing, Sales) — nếu ba bên đổ lỗi cho nhau, bạn sẽ không bao giờ có được bức tranh thật.
Cadence — thời điểm và nhịp độ
Thời điểm lý tưởng để chạy post-mortem là 2–4 tuần sau launch. Vì sao không phải ngay tuần đầu?
- Tuần đầu, số liệu còn nhiễu (báo chí, hiệu ứng tò mò, traffic đột biến). Bạn cần đủ thời gian để metrics ổn định — đặc biệt là các chỉ số về adoption, activation, conversion.
- Nhưng cũng đừng để quá 4–6 tuần, vì ký ức của mọi người phai nhạt và bối cảnh cảm xúc, chi tiết bị mất.
Cross-functional — ai cần tham gia
Post-mortem của PMM khác post-mortem kỹ thuật ở chỗ nó phải cross-functional (liên phòng ban). Một launch chạm đến Product, Engineering, Marketing, Sales, Customer Success, đôi khi cả Legal và Finance. Danh sách người tham gia điển hình:
- PMM (thường là người điều phối/facilitator).
- Product Manager của sản phẩm.
- Đại diện Engineering/Design (nếu có yếu tố kỹ thuật).
- Demand Gen / Growth Marketing.
- Sales / Sales Enablement (đặc biệt với B2B).
- Customer Success / Support (họ nghe phản hồi khách hàng đầu tiên).
Khung dữ liệu để mổ xẻ
Một post-mortem tốt phải dựa trên dữ liệu, không dựa trên cảm giác. Bạn cần chuẩn bị trước:
- Metrics thực tế vs mục tiêu: signups, activation rate, revenue/pipeline, PQLs, MQLs, số deal có nhắc đến tính năng mới, traffic landing page, tỷ lệ mở email launch.
- Timeline thực tế vs kế hoạch: cái gì đúng hạn, cái gì trễ, trễ bao lâu.
- Phản hồi định tính: từ sales (khách nói gì), từ support (ticket tăng vì cái gì), từ social/PR.
Tình huống thực tế
Ví dụ 1 — Fintech Việt ra mắt tính năng "Đầu tư tích lũy" (giả định hợp lý)
Một startup fintech tại TP.HCM (gọi là "VíXanh") ra mắt tính năng đầu tư tích lũy tự động. Mục tiêu launch: 50.000 người kích hoạt trong 30 ngày. Thực tế sau 30 ngày: chỉ 18.000 người kích hoạt (36% mục tiêu), dù lượng tải app tăng mạnh.
PMM tổ chức post-mortem vào tuần thứ 3. Khi mổ xẻ dữ liệu, họ phát hiện: 120.000 người đã bấm vào banner "Đầu tư tích lũy", nhưng 70% rơi rớt ở bước xác minh eKYC bổ sung. Vấn đề không nằm ở messaging hay demand gen — hai thứ đó chạy rất tốt — mà nằm ở luồng onboarding mà đội Product tưởng là "đủ mượt".
Điều đáng giá của buổi post-mortem blameless: đội Product không bị chỉ trích, mà cả nhóm cùng nhận ra rằng pre-launch checklist đã thiếu một mục "test end-to-end luồng người dùng mới với tài khoản chưa eKYC đầy đủ".
Bài học rút ra: Metrics đầu phễu (clicks, traffic) có thể rất đẹp trong khi metrics cuối phễu (activation) thảm hại. Post-mortem phải đi hết phễu để tìm điểm rơi thật sự. Và bài học được codify: thêm mục "test luồng với đủ loại trạng thái tài khoản" vào launch checklist chuẩn.
Ví dụ 2 — B2B SaaS ra mắt module mới nhưng sales "không bán được"
Một công ty SaaS B2B phục vụ doanh nghiệp vừa (giả định: "WorkFlow.vn") ra mắt module Automation. Về mặt marketing, launch rất ồn ào: webinar 400 người tham dự, landing page traffic tốt, báo ngành đưa tin. Nhưng sau 4 tuần, pipeline từ tính năng mới gần như bằng 0.
Post-mortem cross-functional lôi được sự thật ra ánh sáng: đội sales nhận battlecard chỉ 2 ngày trước launch, chưa kịp tiêu hóa. Khi khách hỏi "cái này khác gì so với đối thủ Base hay công cụ Zapier?", sales lúng túng. Hơn nữa, demo môi trường của module mới thường xuyên lỗi trong tuần đầu do đội Engineering vẫn đang vá.
Nhờ nguyên tắc blameless, buổi họp không biến thành "PMM đổ lỗi sales" hay "sales đổ lỗi engineering". Thay vào đó, nhóm nhận diện được lỗ hổng quy trình: sales enablement phải sẵn sàng trước launch ít nhất 2 tuần, và cần có "code freeze" cho môi trường demo trước ngày ra mắt.
Bài học rút ra: Với B2B, một launch "ồn ào về marketing" hoàn toàn có thể thất bại về doanh thu nếu sales chưa được enable đúng cách. Post-mortem giúp phân biệt "launch được nhìn thấy" và "launch bán được". Hành động cụ thể: đưa mốc "enablement ready T-14" thành gate bắt buộc trong launch playbook.
Ví dụ 3 — Khi launch thành công vẫn cần post-mortem
Một ví dụ ngược lại để bạn thấy post-mortem không chỉ dành cho thất bại. Shopee (bối cảnh Đông Nam Á) khi tung một chương trình tính năng mua sắm mới đạt vượt mục tiêu 130%. Nhiều đội sẽ bỏ qua post-mortem vì "đã thắng rồi mổ xẻ làm gì".
Nhưng một đội PMM trưởng thành vẫn ngồi lại hỏi: Vì sao chúng ta thắng, và điều đó có tái lập được không? Họ phát hiện phần lớn thành công đến từ một kênh bất ngờ: các KOC (Key Opinion Consumer) nhỏ trên TikTok tự lan truyền, chứ không phải kênh paid media mà họ đổ tiền vào.
Bài học rút ra: Nếu không post-mortem, họ sẽ tưởng chiến thắng đến từ paid media và tiếp tục đổ ngân sách sai chỗ. Post-mortem giúp họ codify công thức thắng thật sự và tái phân bổ ngân sách cho lần sau. Đây là lý do câu hỏi "tại sao thắng" cũng quan trọng ngang "tại sao thua".
Hướng dẫn từng bước
Dưới đây là quy trình chạy một launch post-mortem chuyên nghiệp mà bạn có thể áp dụng ngay.
Bước 1 — Lên lịch đúng thời điểm (T+2 đến T+4 tuần). Ngay khi launch, hãy đặt lịch post-mortem trên calendar. Đừng để "khi nào rảnh sẽ họp" — nó sẽ không bao giờ xảy ra. Gửi lời mời cho đúng thành phần cross-functional.
Bước 2 — Thu thập dữ liệu trước buổi họp. PMM (người điều phối) tổng hợp trước: metrics vs mục tiêu, timeline thực tế vs kế hoạch, các phản hồi định tính từ sales/support. Gửi tài liệu này cho mọi người đọc trước ít nhất 24 giờ. Buổi họp không phải để trình bày số liệu lần đầu, mà để bàn về ý nghĩa của số liệu.
Bước 3 — Mở đầu bằng cam kết blameless. Câu mở đầu của facilitator nên là: "Hôm nay chúng ta tìm hiểu hệ thống và quy trình, không phải tìm người để trách." Điều này định khung cảm xúc cho cả buổi.
Bước 4 — Chạy qua 4 câu hỏi cốt lõi. Dùng khung đơn giản:
- Chúng ta đặt mục tiêu gì và đạt được đến đâu? (Kết quả vs kỳ vọng)
- Cái gì đã diễn ra tốt và vì sao? (Để tái lập)
- Cái gì đã không ổn và vì sao? (Nguyên nhân gốc, không phải triệu chứng)
- Chúng ta sẽ làm khác đi điều gì ở lần sau?
Bước 6 — Biến bài học thành action items có chủ. Mỗi bài học phải đi kèm: hành động cụ thể, người chịu trách nhiệm (owner), và deadline. "Cải thiện enablement" là vô nghĩa; "Sales Enablement chuẩn bị battlecard sẵn sàng T-14 cho mọi Tier 1 launch, owner: Minh, áp dụng từ launch tới" mới là action item.
Bước 7 — Viết và lưu tài liệu (document for org). Tạo một bản post-mortem chuẩn hóa: bối cảnh, mục tiêu, kết quả, cái tốt, cái chưa tốt, nguyên nhân gốc, action items. Lưu vào nơi cả tổ chức truy cập được (Notion, Confluence). Cập nhật launch playbook/checklist chuẩn nếu bài học mang tính hệ thống.
Bước 8 — Đóng vòng lặp ở launch sau. Ở đầu buổi kickoff của launch kế tiếp, mở lại action items của post-mortem trước và kiểm tra chúng đã được áp dụng chưa. Đây là bước hầu hết đội bỏ quên — và cũng là bước biến post-mortem từ "nghi thức" thành "cải tiến thật".
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ post-mortem khi thất bại. Nhiều đội chỉ mổ xẻ khi launch "flop". Nhưng như ví dụ Shopee, launch thắng cũng cần hiểu vì sao thắng. Mẹo: đặt post-mortem là bước mặc định trong launch playbook, không phải phản ứng với khủng hoảng.
Lỗi 2 — Biến buổi họp thành phiên đổ lỗi. Khi có người bị chỉ mặt, cả nhóm sẽ phòng thủ và sự thật bị giấu. Mẹo: dùng ngôn ngữ hệ thống ("quy trình cho phép điều này") thay vì ngôn ngữ cá nhân ("bạn đã làm sai").
Lỗi 3 — Không có dữ liệu, chỉ có cảm giác. "Tôi thấy launch cũng ổn" không phải là post-mortem. Mẹo: chuẩn bị bảng metrics vs mục tiêu trước, để tranh luận dựa trên con số.
Lỗi 4 — Action items không có owner và deadline. Bài học không ai sở hữu = bài học không xảy ra. Mẹo: kết thúc buổi họp bằng việc đọc to danh sách action items kèm tên người và ngày.
Lỗi 5 — Tài liệu nằm chết. Viết post-mortem xong rồi không ai đọc lại. Mẹo: liên kết action items vào công cụ quản lý task (Jira, Asana) và review ở kickoff launch sau.
Lỗi 6 — Chạy quá sớm hoặc quá muộn. Tuần đầu số liệu nhiễu; sau 6 tuần ký ức phai. Mẹo: khóa cửa sổ T+2 đến T+4 tuần.
Lỗi 7 — Chỉ mời "người trong cuộc". Nếu chỉ PMM và PM họp với nhau, bạn mất góc nhìn sales và support — nơi phản hồi khách hàng thật nhất. Mẹo: luôn giữ tính cross-functional.
Mẹo nâng cao: Duy trì một "learnings library" — kho tổng hợp bài học từ mọi post-mortem, phân loại theo chủ đề (messaging, enablement, timeline, tech readiness). Sau 5–6 launch, bạn sẽ thấy các pattern lặp lại và có thể sửa tận gốc ở cấp quy trình.
Bài tập thực hành
Bài tập 1 — Thiết kế template post-mortem của riêng bạn. Tạo một tài liệu mẫu gồm các phần: Bối cảnh launch, Mục tiêu & kết quả (bảng metrics vs target), Cái đã tốt, Cái chưa tốt, Nguyên nhân gốc (dùng 5 Whys cho ít nhất 2 vấn đề), Action items (bảng: hành động / owner / deadline). Đây sẽ là công cụ bạn dùng đi dùng lại.
Bài tập 2 — Mổ xẻ một tình huống giả định. Giả sử bạn launch một tính năng và đạt: mục tiêu 10.000 activation nhưng chỉ đạt 4.000; landing page traffic vượt 200% mục tiêu; sales báo 15 deal bị mất vì "không giải thích được điểm khác biệt". Hãy viết ra: đâu là triệu chứng, đâu là nguyên nhân gốc, và 3 action items có owner. Chú ý phân biệt vấn đề đầu phễu (marketing) và cuối phễu (product/sales).
Bài tập 3 — Viết câu mở đầu blameless. Soạn 3 câu khác nhau mà một facilitator có thể dùng để mở đầu post-mortem, đảm bảo định khung "không đổ lỗi". Thử đọc to và cảm nhận sự khác biệt về cảm xúc.
Bài tập 4 — Đóng vòng lặp. Lấy một launch bạn (hoặc công ty bạn quan tâm) đã thực hiện. Liệt kê 3 bài học và viết cách bạn sẽ đưa từng bài học vào launch playbook/checklist chuẩn để nó tự động áp dụng cho lần sau, chứ không phụ thuộc trí nhớ.
Tóm tắt
Launch post-mortem là cơ chế biến mỗi lần ra mắt — thắng hay thua — thành tài sản tri thức cho tổ chức. Ba mục tiêu cốt lõi: hệ thống hóa bài học (codify), cải thiện launch tiếp theo (improve), và lưu tài liệu cho cả org (document).
Những điểm cần khắc cốt ghi tâm:
- Thời điểm: chạy sau launch 2–4 tuần, khi số liệu đã ổn định nhưng ký ức chưa phai.
- Cross-functional: mời đủ Product, Engineering, Marketing, Sales, Support — mất một góc nhìn là mất một phần sự thật.
- Blameless: mổ xẻ hệ thống và quy trình, không truy tìm cá nhân. Đây là điều kiện để sự thật lộ ra.
- Dựa trên dữ liệu: đi hết phễu, phân biệt metrics đầu phễu đẹp và cuối phễu thật.
- Action items có chủ: mỗi bài học đi kèm hành động, owner và deadline; nếu không, bài học sẽ bay hơi.
- Đóng vòng lặp: review action items ở kickoff launch sau — đây là bước biến post-mortem thành cải tiến thật, không phải nghi thức.