Báo cáo kết quả sau ra mắt

Báo cáo kết quả sau ra mắt dùng để làm gì?

Launch chưa xong khi tính năng đã bật 100%. Nó xong khi đội trả lời được câu hỏi đã đặt ra từ đầu: chúng ta có đạt mục tiêu không, và học được gì. Không có readout, đội chuyển sang việc tiếp theo, và ba tháng sau không ai nói được lần ra mắt đó thành công hay chỉ là "đã xong".

Mẫu này dùng cho hai mốc. Readout 2 tuần trả lời: người dùng có thử không, có hỏng gì không, có cần dừng hay sửa gấp không. Readout 6 tuần trả lời: người dùng có quay lại không, chỉ số kinh doanh có dịch chuyển không, và giữ, cải tiến hay dừng. Con số tuần đầu gần như luôn đẹp vì tò mò; con số tuần thứ sáu mới nói thật.

Readout không phải báo cáo thành tích. Phần quan trọng nhất là cột mục tiêu đặt trước nằm ngay cạnh kết quả, và một mục riêng cho những gì không như dự kiến. Một readout chỉ có tin tốt là readout người đọc sẽ không tin.

Dành cho: PM · Growth PM · Data analyst (cùng viết) · Head of Product · BA

Dùng khi: Hai tuần và sáu tuần sau khi tính năng tới tay phần lớn đối tượng mục tiêu (nấc 25% trở lên). Ngày readout ghi sẵn trong release plan, và lời mời lịch gửi ngay ngày release.

Readout khác gì với dashboard và Feature Impact Review?

Readout là cầu nối: đủ sớm để sửa, đủ có cấu trúc để sau này viết Feature Impact Review mà không phải đào lại số liệu.

Bản trắng — copy và dán vào tài liệu của bạn

Một trang. Viết cùng data analyst. Gửi trước buổi họp một ngày; buổi họp 30 phút chỉ để thảo luận mục 4 và 5.

READOUT [2 TUẦN / 6 TUẦN] — [Tên tính năng]
Ngày release tới đối tượng mục tiêu: ......   Ngày readout: ......
Người viết: ...... (PM), ...... (Data)
Gửi tới: ......

1. TÓM TẮT TRONG BA DÒNG
   Kết quả so với mục tiêu: ĐẠT / ĐẠT MỘT PHẦN / CHƯA ĐẠT
   Điều quan trọng nhất học được: ......
   Quyết định đề xuất: ......

2. MỤC TIÊU ĐẶT TRƯỚC VÀ KẾT QUẢ
   Chỉ số: ......
     Định nghĩa: ......
     Mục tiêu (đặt ngày ......): ......   Kết quả: ......
     So với nhóm đối chứng: ......        Đánh giá: ......
   (lặp lại cho mỗi chỉ số)
   Chỉ số bảo vệ: ......   Ngưỡng: ......   Kết quả: ......

3. ĐỘ TIN CẬY CỦA SỐ
   Nguồn dữ liệu: ......
   Cách so sánh: [A/B ngẫu nhiên / trước-sau / không có] — vì sao: ......
   Điều có thể làm số sai (mùa vụ, chiến dịch trùng thời gian,
   lỗi event...): ......

4. ĐIỀU CHÚNG TA HỌC ĐƯỢC
   4a. Như dự kiến: ......
   4b. Không như dự kiến: ......
   4c. Ai dùng mà ta không ngờ; ai không dùng mà ta tưởng sẽ dùng: ......

5. QUYẾT ĐỊNH VÀ VIỆC TIẾP THEO
   Quyết định: GIỮ NGUYÊN / CẢI TIẾN / ĐỊNH VỊ LẠI / DỪNG MỞ RỘNG / TẮT
   Việc | Người làm | Hạn
   ......
   Cần ai duyệt gì: ......

6. MỐC TIẾP THEO
   Readout tiếp theo: ......   sẽ trả lời câu hỏi: ......

Từng ô điền gì, và vì sao ô đó tồn tại

Cách viết readout trong hai buổi

• Trước ngày release: dựng sẵn khung readout. Chép mục tiêu, định nghĩa chỉ số và chỉ số bảo vệ từ release plan vào mục 2. Nếu lúc này không viết được định nghĩa, tracking plan đang thiếu event — sửa ngay, đừng chờ tới ngày readout.
• Buổi 1 (60 phút, cùng data analyst): điền mục 2 và 3. Kiểm định nghĩa trong truy vấn có khớp định nghĩa đã viết không. Ghi mọi yếu tố có thể làm số sai — một chiến dịch giảm giá trùng tuần ra mắt có thể giải thích toàn bộ mức tăng.
• Đọc dữ liệu định tính: 20 ticket support, phản hồi trong ứng dụng, ghi chú từ sales. Số cho biết chuyện gì xảy ra; ticket thường cho biết vì sao.
• Buổi 2 (45 phút, một mình): viết mục 4 và 5. Bắt đầu bằng 4b — điều không như dự kiến. Nếu không nghĩ ra điều gì, tách số theo thiết bị, vùng, khách mới và khách cũ, quy mô khách.
• Viết mục 1 cuối cùng, khi đã biết mình định đề xuất gì.
• Gửi trước một ngày; họp 30 phút. Không trình bày lại số liệu. Hỏi: "Có ai không đồng ý với quyết định ở mục 5 không, và vì sao?"
• Lưu readout cạnh PRD và release plan. Feature Impact Review sau này sẽ cần cả ba.

Ví dụ đã điền đầy đủ

Tiếp nối ví dụ GiaoNhanh (giả định) — tính năng rút tiền thu hộ trong ngày cho shop. Đây là readout 6 tuần. Trong ba tuần đầu sau nấc 25%, một phần tư số shop đủ điều kiện được giữ lại làm nhóm đối chứng chọn ngẫu nhiên.

READOUT 6 TUẦN — Rút COD trong ngày
Ngày release tới đối tượng mục tiêu: 16/04 (25%), 07/05 (100%)
Ngày readout: 18/06
Người viết: Hiếu (PM), Vy (Data)
Gửi tới: chị Linh (Head of Product), anh Bảo (Giám đốc tài chính),
  Dũng (Sales/CS), Ngọc (Support)

1. TÓM TẮT
   Kết quả: ĐẠT MỘT PHẦN — vượt mục tiêu giữ chân shop, chưa đạt mục
   tiêu tỉ lệ dùng.
   Học được: shop dùng không phải vì tiền về nhanh mà vì biết trước
   tiền về lúc nào.
   Đề xuất: giữ tính năng, đưa nút rút vào màn hình đối soát; xin duyệt
   miễn phí lệnh rút đầu tiên mỗi tuần cho shop nhỏ.

2. MỤC TIÊU VÀ KẾT QUẢ
   Dùng thử
     Định nghĩa: shop đủ điều kiện có ít nhất 1 lệnh rút hoàn tất
       trong 30 ngày
     Mục tiêu (đặt 02/03): 25%   Kết quả: 18%   Đánh giá: CHƯA ĐẠT
   Dùng lại
     Định nghĩa: trong số đã dùng, tỉ lệ có lệnh rút ở cả tuần 5 và 6
     Mục tiêu: 40%   Kết quả: 57%   Đánh giá: VƯỢT
   Giữ chân shop
     Định nghĩa: shop còn gửi hàng sau 60 ngày
     Mục tiêu: hơn nhóm đối chứng 1 điểm
     Kết quả: 91,8% so với 89,4% — hơn 2,4 điểm   Đánh giá: VƯỢT
   Chỉ số bảo vệ
     Ticket về tiền trên 1.000 đơn — ngưỡng: không tăng quá 10%
       Kết quả: GIẢM 22%
     Lệnh rút thất bại — ngưỡng: dưới 2%   Kết quả: 0,6%

3. ĐỘ TIN CẬY
   Nguồn: bảng lệnh rút + event cod_withdraw_* (đã QA trước go/no-go)
   Cách so sánh: nhóm đối chứng 25% chọn ngẫu nhiên theo shop, giữ 3
     tuần; sau đó so trước-sau trên cùng nhóm. Độ tin cậy cao cho 3
     tuần đầu, trung bình cho phần còn lại.
   Có thể làm sai: đợt khuyến mãi 30/4 nằm giữa giai đoạn đo — tác
     động cả hai nhóm như nhau trong 3 tuần đầu.

4. ĐIỀU HỌC ĐƯỢC
   4a. Shop trên 100 đơn/ngày dùng nhiều nhất (41%), đúng như dự kiến.
   4b. Shop dưới 30 đơn/ngày chỉ dùng 7%. Phỏng vấn 9 shop: phí rút
       5.500đ/lần là "mất tiền lãi một đơn". Đây là phần lớn nhất của
       khoảng cách giữa 18% và 25%.
       Ticket "tiền của tôi đâu" giảm 22% ở CẢ shop không dùng tính
       năng — vì màn hình mới hiện giờ dự kiến tiền về cho mọi lệnh.
   4c. Shop bán đồ tươi sống dùng gấp ba trung bình: họ cần tiền mặt
       để nhập hàng sáng hôm sau. Nhóm này chưa từng có trong kế hoạch.

5. QUYẾT ĐỊNH: CẢI TIẾN
   - Đưa nút rút trong ngày vào màn hình đối soát, nơi 80% shop xem
     tiền (hiện chỉ có ở mục Tài chính)          Hiếu, sprint 26
   - Miễn phí lệnh rút đầu tiên mỗi tuần cho shop dưới 30 đơn/ngày;
     chi phí ước 85 triệu/tháng                   cần anh Bảo duyệt, 30/06
   - Tiếp cận riêng nhóm đồ tươi sống qua đội AM  Dũng, 15/07

6. MỐC TIẾP THEO
   Feature Impact Review ngày 10/09 — trả lời: mức giữ chân shop tăng
   thêm có bù được chi phí vốn ứng trước cho lệnh rút không.

Ba điều làm readout này dùng được. Thứ nhất, mục tiêu tỉ lệ dùng không đạt được nói thẳng ở dòng đầu, không bị giấu sau con số giữ chân đẹp. Thứ hai, mục 4b không dừng ở "shop nhỏ dùng ít" mà có lý do từ phỏng vấn và một đề xuất có giá. Thứ ba, phát hiện ticket giảm ở cả những shop không dùng tính năng là loại bất ngờ chỉ thấy khi chủ động đi tìm — và nó có thể là giá trị lớn nhất của cả dự án.

Hiccups thường gặp và cách xử lý

Vì sao vai trò của bạn cần cái này

Definition of done

• Có tóm tắt ba dòng: kết quả, điều học được, quyết định.
• Mỗi chỉ số có định nghĩa, mục tiêu đặt trước kèm ngày, và kết quả.
• Có so sánh với nhóm đối chứng, hoặc ghi rõ không có và hạ độ tin cậy.
• Chỉ số bảo vệ được báo cáo cùng ngưỡng.
• Mục "không như dự kiến" có ít nhất một điều thật.
• Quyết định có việc cụ thể, người làm và hạn; mốc readout tiếp theo đã được hẹn.