Buổi 8 — Vận hành growth: nhịp làm việc và văn hoá
Kỹ thuật growth dễ học. Vận hành được nó đều đặn mới là phần khó.
Nhịp hằng tuần
Một chu kỳ growth điển hình:
- Đầu tuần — xem kết quả thử nghiệm đã kết thúc, quyết định triển khai hay dừng.
- Chọn ưu tiên — chấm điểm ý tưởng trong backlog, chọn 2-3 cái để chạy.
- Trong tuần — triển khai, kiểm tra tính đúng của tracking trước khi mở lưu lượng.
- Cuối tuần — ghi lại bài học, kể cả từ thử nghiệm thất bại.
Backlog ý tưởng
Nguồn ý tưởng nên đa dạng: dữ liệu funnel, phỏng vấn người dùng, ticket support, phân tích đối thủ, và trực giác của team. Ý tưởng từ một nguồn duy nhất sẽ hết nhanh.
Ưu tiên bằng ICE (Impact, Confidence, Ease) hoặc RICE. Ghi lại lý do chấm điểm, không chỉ con số — lý do là thứ cho phép người khác phản biện.
Tỉ lệ thắng nên là bao nhiêu
Trong ngành, tỉ lệ thử nghiệm thắng điển hình là 10-30%.
Nếu tỉ lệ của bạn trên 70%, đó thường không phải tin tốt: nó nghĩa là team chỉ thử những thứ an toàn và không học được gì bất ngờ. Thử nghiệm mà bạn chắc chắn kết quả thì không cần chạy.
Ghi lại thất bại
Đây là thứ phân biệt team growth trưởng thành với team chỉ chạy A/B test.
Thử nghiệm thất bại loại trừ một giả thuyết. Không ghi lại thì sáu tháng sau ai đó sẽ đề xuất đúng ý tưởng ấy, và cả team lại tốn thời gian.
Kho lưu nên tra cứu được theo chủ đề, không chỉ theo thời gian.
Dấu hiệu văn hoá không lành mạnh
Chỉ báo cáo thắng lợi. Tổ chức học sai và lặp lại lỗi cũ.
Velocity hoặc số thử nghiệm thành KPI. Team sẽ chạy nhiều thử nghiệm vụn vặt để đạt số.
Growth tách rời sản phẩm. Khi growth team chỉ được chạm vào bề mặt, họ sẽ tối ưu nút bấm trong khi vấn đề nằm ở giá trị cốt lõi.
Quan hệ với các team khác
Growth chạm vào phần của nhiều team: marketing sở hữu kênh, sản phẩm sở hữu tính năng, engineering sở hữu hạ tầng. Xung đột là mặc định trừ khi có thoả thuận rõ ràng về ranh giới và về guardrail.
Thoả thuận tối thiểu: growth được tự triển khai trong phạm vi đã định, với các chỉ số bảo vệ mà mọi bên đồng ý, và mọi thay đổi vượt phạm vi phải bàn trước.
Kết
Growth không phải một bộ thủ thuật. Nó là kỷ luật đặt giả thuyết, đo, và giữ lại điều đã học — áp dụng lên hệ thống mà sản phẩm dùng để tự lan rộng.
Bài tập
Thiết lập một nhịp hằng tuần cho team của bạn, dù chỉ có một người. Chạy bốn tuần và đo một chỉ số duy nhất: thời gian trung bình từ ý tưởng tới kết luận.
<!--les-append-->
Chỉ số sức khoẻ thật của một growth team
Không phải số thử nghiệm chạy mỗi tháng. Nó là thời gian từ ý tưởng tới kết luận.
| Thời gian ý tưởng → kết luận | Nghĩa là |
|---|---|
| Dưới 2 tuần | Đội học nhanh; có thể chạy nhiều vòng trong một quý |
| 2–4 tuần | Bình thường |
| Trên 6 tuần | Phần lớn thời gian nằm ở chờ đợi, không ở học hỏi |
Backlog ý tưởng: nguồn đa dạng
Ý tưởng chỉ từ một nguồn sẽ cho ra thử nghiệm giống nhau mãi:
- Dữ liệu phễu — chỗ rơi cao nhất
- Phiếu hỗ trợ — vấn đề người dùng tự nói ra
- Quan sát người dùng — chỗ họ ngập ngừng
- Đối thủ — nhưng hỏi vì sao họ làm thế trước khi sao chép
- Cả đội, không chỉ PM — người hỗ trợ và lập trình viên thường có ý tưởng tốt và ít được hỏi
Ghi lại bài học, kể cả từ thất bại
Thử nghiệm thất bại có giá trị bằng thử nghiệm thành công — nếu được ghi lại. Không ghi thì đội sẽ thử lại cùng một thứ sau 18 tháng, khi người cũ đã đi.
Mẫu tối thiểu: giả thuyết, kết quả, và vì sao chúng ta nghĩ nó thất bại. Ô thứ ba là ô có giá trị lâu dài.
Văn hoá: hai thứ phải có
Chấp nhận phần lớn thử nghiệm thất bại. Nếu tỉ lệ thắng của đội trên 50%, họ đang thử những thứ quá an toàn. Điều đó nghe phản trực giác nhưng nó đúng: thử nghiệm chỉ có giá trị khi kết quả chưa biết trước.
Không ai được phép bỏ qua kết quả vì không thích nó. Một thử nghiệm bị lờ đi vì kết quả trái với ý người cấp cao sẽ dạy cả đội rằng việc đo lường là hình thức.
Làm ngay
Đo thời gian từ ý tưởng tới kết luận cho ba thử nghiệm gần nhất. Tìm nút thắt lớn nhất trong khoảng thời gian đó, và sửa nó trước khi cố chạy thêm thử nghiệm. <!--/les-append-->