Đo lường tính năng sau ra mắt: làm sao biết nó có ích?

Tính năng đã ra mắt, rồi sao nữa?

Team vừa ra mắt nút “Đặt lại đơn cũ” cho app của một cửa hàng cà phê hạt online. Ticket đã chuyển sang Done, bản phát hành chạy ổn, không có lỗi nghiêm trọng. Trong buổi họp tuần, quản lý hỏi bạn một câu ngắn: “Tính năng này có giúp được khách không em?”

Bạn mở dashboard và thấy rất nhiều con số: lượt mở app, số đơn, doanh thu, số lần bấm nút. Con số nào cũng tăng hoặc giảm một chút. Bạn không biết nên nhìn vào đâu, và cũng không chắc thay đổi nào là nhờ tính năng.

Đây là tình huống minh họa, cửa hàng và số liệu trong bài đều là giả định. Bài này đi qua cách trả lời câu hỏi của quản lý một cách có căn cứ: chuẩn bị gì trước khi làm, đọc số sau khi ra mắt thế nào, kết hợp với phản hồi của người dùng ra sao, và dùng kết quả để quyết định bước tiếp.

Output và outcome khác nhau thế nào?

Output là thứ team làm ra: một màn hình, một nút, một bản phát hành. Outcome là thay đổi xảy ra ở phía người dùng nhờ thứ đó: họ làm một việc nhanh hơn, ít lỗi hơn, hoặc quay lại thường xuyên hơn. Một tính năng có thể đúng thiết kế, đúng hạn, đạt mọi tiêu chí kiểm thử mà vẫn không đổi được gì ở người dùng.

Việc này khó với người mới vì vài lý do.

• Done cho cảm giác đã xong. Definition of Done xác nhận phần việc đạt chuẩn chất lượng để phát hành, nhưng không trả lời được người dùng có được lợi hay không.
• Không ai chốt từ đầu là đo cái gì. Đến lúc ra mắt mới đi tìm số, nên dễ chọn con số trông đẹp nhất thay vì con số liên quan nhất.
• Thiếu con số hiện tại. Không biết trước khi làm là bao nhiêu thì không nói được sau khi làm là tốt hơn hay không.
• Nhiều thứ cùng thay đổi một lúc. Khuyến mãi, mùa mua sắm, một chiến dịch quảng cáo đều có thể làm số tăng hoặc giảm, không liên quan tới tính năng của bạn.
• Ngại nhìn kết quả xấu. Khi đã bỏ công làm, ai cũng muốn tính năng thành công, nên dễ chỉ tìm bằng chứng ủng hộ.

Tin tốt là nhiều phần việc đo lường nằm ở trước khi làm, không phải sau khi ra mắt. Nếu chuẩn bị đúng, câu hỏi của quản lý chỉ cần mở một trang ghi chú là trả lời được.

• Definition of Ready và Definition of Done

Đo tính năng sau khi ra mắt bằng cách nào?

Một cách làm đơn giản gồm bốn bước. Hai bước đầu diễn ra trước khi team bắt tay làm, hai bước sau diễn ra sau khi ra mắt.

Bước 1, viết hành vi mong đợi thành một câu: “Sau khi có tính năng này, [ai] sẽ [làm gì khác đi] để [đạt được gì]”. Câu này nói về người dùng, không nói về nút bấm. Nếu team không viết được câu này, đó là dấu hiệu vấn đề chưa rõ, nên quay lại tìm hiểu thêm trước khi làm.

Bước 2, chọn hai hoặc ba số đo gắn với câu ở bước 1. Mỗi số cần đủ bốn phần: tên số đo và cách tính, mốc hiện tại (baseline, tức con số trước khi có tính năng), mục tiêu, và thời hạn kiểm tra. Hỏi người giữ dữ liệu xem số đó có đo được không và lấy ở đâu. Số đo chính, tức con số trả lời trực tiếp câu ở bước 1, ghi vào mục “Mục tiêu và cách đo” của tài liệu yêu cầu một trang. Các số đo hỗ trợ ghi vào mẫu xem lại sau khi ra mắt ở cuối bài.

Bước 3, sau khi ra mắt, theo dõi số liệu theo lịch đã hẹn, không phải mỗi giờ. Song song, đọc ticket hỗ trợ, phản hồi trong app và nói chuyện với vài người dùng. Số liệu cho bạn biết điều gì đang xảy ra, còn người dùng giúp bạn hiểu vì sao.

Bước 4, đến hạn thì ngồi lại với team, so kết quả với mục tiêu và quyết định bước tiếp. Ghi quyết định vào một trang để lần sau ai cũng xem lại được.

• Tài liệu yêu cầu một trang

Nên đo chỉ số gì cho từng loại tính năng?

Nhóm nghiên cứu của Google đề xuất khung HEART gồm năm nhóm số đo trải nghiệm người dùng: Happiness (mức hài lòng), Engagement (mức độ gắn bó), Adoption (người dùng mới bắt đầu dùng), Retention (người dùng quay lại) và Task success (làm xong việc, nhanh và ít lỗi). Chính bài viết gốc nói không phải lúc nào cũng nên dùng cả năm nhóm, mà nên chủ động chọn nhóm phù hợp với mục tiêu.

Bài gốc cũng đi kèm một quy trình ba bước: Goals (mục tiêu), Signals (hành vi hoặc cảm nhận cho thấy mục tiêu đạt được), Metrics (con số cụ thể để theo dõi tín hiệu đó). Bước 1 và 2 ở phần trên là phiên bản rút gọn của quy trình này. Mức hài lòng không đọc được từ số lần bấm, nên theo Amplitude, nhóm này thường được đo qua khảo sát.

Bảng dưới là gợi ý của bài viết cho vài loại tính năng hay gặp. Hãy coi nó là điểm bắt đầu để bàn với team, không phải đáp án cố định.

Với tính năng nội bộ, người dùng là nhân viên nên khái niệm “gắn bó” ít ý nghĩa, vì họ dùng công cụ như một phần công việc. Bài viết gốc về HEART cũng nêu ví dụ tương tự cho sản phẩm doanh nghiệp. Lúc đó, làm xong việc nhanh và đúng là thứ đáng đo hơn.

Tín hiệu sớm và tín hiệu muộn là gì?

Amplitude phân biệt hai loại chỉ số. Leading indicator (tín hiệu sớm) giúp dự đoán kết quả sắp tới và có thể dùng để điều chỉnh công việc hằng ngày. Lagging indicator (tín hiệu muộn) phản ánh kết quả đã xảy ra, như doanh thu, và dùng để đánh giá thành công.

Với một PO mới, cách hiểu thực tế là: tín hiệu sớm trả lời “người dùng có dùng và dùng được không”, đọc được sau vài tuần. Tín hiệu muộn trả lời “việc đó có tạo ra kết quả mình muốn không”, cần chờ lâu hơn. Nếu chỉ nhìn tín hiệu muộn, bạn sẽ phải chờ rất lâu mới biết có vấn đề. Nếu chỉ nhìn tín hiệu sớm, bạn có thể vui vì nhiều người bấm nút trong khi kết quả thật không đổi.

Thời hạn kiểm tra nên chốt theo chu kỳ dùng sản phẩm. Khách mua cà phê hạt có thể mua lại sau vài tuần, nên đo tỷ lệ mua lại sau một tuần là quá sớm. Một ứng dụng dùng hằng ngày thì có thể thấy tín hiệu nhanh hơn.

Để lấy số, bạn có thể nhờ người làm dữ liệu, dùng công cụ phân tích của team, hoặc tự viết vài câu truy vấn đơn giản nếu được cấp quyền đọc dữ liệu.

• SQL cho Product Owner mới bắt đầu

Ví dụ: nút “Đặt lại đơn cũ” sau bốn tuần

Quay lại cửa hàng cà phê hạt ở đầu bài. Mọi con số dưới đây là giả định để minh họa cách đọc, không phải số liệu thật của cửa hàng nào.

Trước khi làm, team viết hành vi mong đợi: “Khách đã từng mua sẽ đặt lại đơn quen dễ dàng hơn, nhờ đó mua lại nhiều hơn.” Team chọn ba số đo, đúng như mẫu ở cuối bài: hai số cho tín hiệu sớm, xem sau bốn tuần, và một số cho tín hiệu muộn, xem sau tám tuần vì khách cần thời gian để hết cà phê. Số đo chính ghi trong tài liệu yêu cầu là tỷ lệ khách mua lại trong 30 ngày.

Nếu chỉ nhìn số người dùng nút, team sẽ báo “thành công”. Nhưng tỷ lệ hoàn tất thấp cho thấy có chỗ vướng. Số liệu không nói chỗ vướng là gì, nên PO đọc 14 ticket hỗ trợ liên quan và gọi cho năm khách đã bấm nút mà không đặt xong.

Cả năm cuộc gọi và phần lớn ticket chỉ về cùng một chuyện: khi một món trong đơn cũ đã hết hàng, cả đơn đặt lại báo lỗi, khách phải xóa giỏ và chọn lại từ đầu. Đây là trường hợp lỗi team chưa tính tới khi viết tiêu chí chấp nhận.

Còn tỷ lệ mua lại tăng từ 18% lên 20%, nhưng giữa kỳ có đợt giảm giá toàn cửa hàng. So sánh trước và sau có thể bị ảnh hưởng bởi yếu tố khác, nên team không ghi phần tăng này là nhờ tính năng. Team hẹn đo lại vào một tháng không có khuyến mãi lớn.

Quyết định: cải tiến. Team cho phép đơn đặt lại tự bỏ món hết hàng, báo rõ cho khách và đặt phần còn lại. Mục tiêu tỷ lệ hoàn tất giữ nguyên từ 80%, đo lại bốn tuần sau khi bản sửa ra mắt. Ý tưởng mở rộng sang đặt hàng định kỳ được để sau, cho tới khi luồng đặt lại chạy ổn.

Khi nào nên cải tiến, mở rộng hay gỡ tính năng?

Đến hạn xem lại, có thể đi qua bốn câu hỏi theo thứ tự. Trả lời “có” thì đi tiếp. Trả lời “không” thì làm việc ở bên cạnh câu hỏi đó.

Mỗi lựa chọn đều có giá. Cải tiến tốn thêm thời gian của team, đẩy lùi việc khác trong backlog. Mở rộng làm tăng phạm vi phải duy trì và kiểm thử. Đo thêm nghĩa là chờ, và câu hỏi của quản lý sẽ chưa có câu trả lời cuối. Gỡ tính năng cần báo trước cho người đang dùng, dọn code và có thể gây phản ứng từ một nhóm nhỏ thích nó. Giữ một tính năng ít người dùng cũng có giá: nó vẫn cần được kiểm thử và hỗ trợ ở mỗi lần phát hành.

Khi trình bày với quản lý, hãy nói cả quyết định đề xuất lẫn giá của nó, kèm bằng chứng: con số nào, so với mục tiêu nào, người dùng nói gì.

Kết hợp số liệu với phản hồi người dùng thế nào?

Số liệu cho biết có bao nhiêu người làm gì. Phản hồi định tính cho biết vì sao. Thiếu một trong hai, bạn dễ đọc sai.

• Ticket hỗ trợ và phản hồi trong app: lọc theo tên tính năng hoặc từ khóa liên quan, đọc bản gốc thay vì chỉ đếm.
• Vài cuộc nói chuyện ngắn: chọn người đã dùng và người đã bỏ dở. Hỏi họ đã làm gì lần gần nhất, đừng hỏi họ có thích tính năng không.
• Đội hỗ trợ và vận hành: họ nghe khách phàn nàn mỗi ngày và có thể thấy vấn đề trước khi nó hiện trên dashboard.
• Một câu khảo sát ngắn ngay sau khi dùng: hữu ích khi mục tiêu là mức hài lòng, thứ không đọc được từ số lần bấm.

Năm cuộc gọi không đủ để kết luận cho cả tập khách. Nhưng chúng đủ để giải thích một con số bất thường và gợi ý thứ cần sửa. Sau khi sửa, con số sẽ cho bạn biết cách giải thích đó có đúng không.

• Phỏng vấn người dùng: hỏi gì

Mẫu xem lại sau khi ra mắt trên một trang

Dùng mẫu này cho mỗi tính năng. Phần trên điền trước khi team bắt tay làm, phần dưới điền khi đến hạn xem lại. Bạn copy về, dán vào tài liệu hoặc trang wiki của team.

Tính năng: [tên]
Ngày ra mắt: [ngày]
Người phụ trách xem lại: [tên]

PHẦN 1: ĐIỀN TRƯỚC KHI LÀM
Hành vi mong đợi: Sau khi có tính năng này, [ai] sẽ [làm gì khác đi] để [đạt được gì].
Số đo 1 (tín hiệu sớm): [tên số đo, cách tính] | Mốc hiện tại: [số] | Mục tiêu: [số] | Xem lại ngày: [ngày]
Số đo 2 (tín hiệu sớm): [tên số đo, cách tính] | Mốc hiện tại: [số] | Mục tiêu: [số] | Xem lại ngày: [ngày]
Số đo 3 (tín hiệu muộn): [tên số đo, cách tính] | Mốc hiện tại: [số] | Mục tiêu: [số] | Xem lại ngày: [ngày]
Nguồn số liệu: [công cụ, bảng dữ liệu, người giữ số]
Sự kiện có thể làm lệch số trong thời gian đo: [khuyến mãi, mùa vụ, chiến dịch, thay đổi khác]

PHẦN 2: ĐIỀN KHI ĐẾN HẠN
Kết quả từng số đo so với mục tiêu: [đạt / chưa đạt / chưa kết luận được, kèm số]
Phản hồi định tính: [ticket, cuộc gọi, khảo sát: điều lặp lại nhiều nhất]
Yếu tố khác đã xảy ra trong thời gian đo: [có / không, là gì]
Điều team học được: [1 đến 3 ý]
Quyết định: [cải tiến / mở rộng / đo thêm / gỡ bỏ]
Lý do và chi phí của quyết định: [ngắn gọn]
Mốc đo tiếp theo: [số đo, mục tiêu, ngày]

Dòng “Sự kiện có thể làm lệch số” dễ bị bỏ trống, trong khi nó là dòng giúp bạn tránh nhận công không phải của mình. Hỏi bộ phận marketing và kinh doanh lịch khuyến mãi trước khi ra mắt.

Những lỗi dễ mắc khi đo tính năng

• Coi ra mắt là thành công. Báo cáo “đã phát hành đúng hạn” mà không có dòng nào về người dùng.
• Chọn số đo sau khi đã thấy kết quả. Lúc đó rất dễ chọn con số trông đẹp. Chốt số đo và mục tiêu trước khi làm.
• Đo quá nhiều thứ. Mười con số trên dashboard không giúp ra quyết định. Hai hoặc ba số gắn với hành vi mong đợi là đủ.
• Chỉ đếm lượt bấm. Nhiều người bấm không có nghĩa là họ làm xong việc. Luôn đi kèm một số đo về việc hoàn tất.
• Gán mọi thay đổi cho tính năng. Số tăng trong tháng có khuyến mãi chưa chắc là nhờ tính năng. Ghi lại các sự kiện khác và so với giai đoạn tương tự.
• So nhóm dùng với nhóm không dùng rồi kết luận. Người chủ động dùng tính năng mới có thể vốn là khách trung thành hơn. Chênh lệch giữa hai nhóm chưa chứng minh tính năng tạo ra khác biệt.
• Xem lại xong mà không quyết gì. Mỗi lần xem lại nên kết thúc bằng một quyết định và một mốc đo mới.

Tóm tắt

• Ra mắt là output. Outcome là người dùng làm khác đi và đạt được điều họ cần nhờ tính năng.
• Trước khi làm, viết hành vi mong đợi trong một câu, rồi chọn hai hoặc ba số đo, mỗi số có mốc hiện tại, mục tiêu và thời hạn.
• Đọc tín hiệu sớm (có dùng, có làm xong việc) cùng tín hiệu muộn (có quay lại, có tạo kết quả), theo chu kỳ dùng sản phẩm.
• Số liệu cho biết điều gì xảy ra. Ticket hỗ trợ và vài cuộc nói chuyện giúp hiểu vì sao.
• So sánh trước và sau có thể bị ảnh hưởng bởi yếu tố khác như khuyến mãi hay mùa vụ. Ghi chúng lại trước khi kết luận.
• Mỗi lần xem lại kết thúc bằng một quyết định có lý do và chi phí: cải tiến, mở rộng, đo thêm hoặc gỡ bỏ.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Output và outcome khác nhau thế nào?

Output là thứ team làm ra, ví dụ một tính năng đã ra mắt. Outcome là thay đổi trong hành vi hoặc kết quả của người dùng nhờ tính năng đó. Ra mắt đúng hạn là output, người dùng làm việc nhanh hơn hoặc quay lại nhiều hơn mới là outcome.

Nên đo tính năng mới bằng chỉ số nào?

Chọn từ hành vi bạn mong người dùng thay đổi: có bao nhiêu người dùng tính năng, họ có làm xong việc không, và họ có quay lại không. Hai hoặc ba số đo gắn với mục tiêu là đủ, không cần đo mọi thứ.

Sau khi ra mắt bao lâu thì nên đánh giá tính năng?

Chốt thời hạn trước khi làm. Tín hiệu sớm như tỷ lệ sử dụng có thể xem sau vài tuần, còn tín hiệu muộn như mua lại hay doanh thu cần thời gian dài hơn, tùy chu kỳ dùng sản phẩm.

Nguồn kiểm tra

• Google Research: Measuring the User Experience on a Large Scale (HEART)
• Amplitude: How to use the HEART framework
• Amplitude: Leading vs. lagging indicators

Bài liên quan

• Success metrics là gì? Chốt chỉ số trước khi làm tính năng: Cách chốt chỉ số thành công cho một tính năng trước khi team bắt tay làm: một chỉ số chính, chỉ số bảo vệ, mốc hiện tại, mục tiêu, thời hạn và nguồn số, kèm phiếu định nghĩa một trang.
• PO có cần biết SQL không?: Không cần thành data analyst. Nhưng bạn nên biết cách biến tò mò thành một câu hỏi có thể kiểm tra.
• Dùng Claude cho PO: việc nào giúp được, việc nào phải tự làm: AI soạn nháp rất nhanh. Bài này chỉ ra bốn lỗi cần soi và một checklist để kiểm tra trước khi tài liệu tới tay team.
• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.