Một Product team có thể release đều đặn mỗi sprint, roadmap chạy đúng kế hoạch, backlog liên tục được xử lý, thậm chí mỗi quý có thêm hàng chục tính năng mới. Nhưng sau một thời gian, retention không tăng, người dùng vẫn gặp những vấn đề cũ, business outcome không cải thiện đáng kể. Vậy team có phải đang làm việc không hiệu quả? Chưa chắc. Có thể team đang rất hiệu quả trong việc tạo ra output, nhưng chưa biết những output đó có thực sự tạo ra outcome hay không.

Đấy cũng là lý do vì sao metrics lại quan trọng trong toàn bộ quá trình phát triển và quản lý sản phẩm. Có thể nói, metrics không phải để làm đẹp dashboard hay báo cáo kết quả cuối quý, mà để giúp chúng ta biết những gì mình đang xây có thực sự tạo ra thay đổi mà mình mong muốn hay không.

Metrics là gì và tại sao Product cần Metrics?

Hiểu đơn giản, metric là một phép đo được định nghĩa nhất quán để theo dõi trạng thái hoặc sự thay đổi của sản phẩm, hành vi người dùng hay kết quả kinh doanh theo thời gian. Một con số đứng riêng lẻ thường không nói lên nhiều điều. 100.000 active users là tốt hay xấu? Conversion rate (tỷ lệ chuyển đổi) 5% là cao hay thấp? CSAT (độ hài lòng của khách hàng) 70% có đáng mừng không? Chúng chỉ bắt đầu có ý nghĩa khi được đặt trong một ngữ cảnh nhất định: so với mặt bằng chung, mục tiêu, cùng kỳ, cohort khác, phiên bản trước hoặc một thay đổi vừa được triển khai.

Với những người làm Product, việc theo dõi một metric trong một ngữ cảnh nào đó, có thể hiểu đơn giản là quan sát những gì team mình đã làm đang tạo ra hệ quả gì. Hiểu nôm na là: việc team bạn ra mắt một tính năng hay một sản phẩm là output của quá trình phát triển sản phẩm, không phải outcome. Nó chưa cho biết tính năng đó có giúp người dùng hoàn thành tác vụ dễ hơn, sử dụng sản phẩm thường xuyên hơn, chuyển đổi tốt hơn hay giải quyết được vấn đề hiệu quả hơn hay không. Lúc này, chính những con số dùng để đo lường mức độ hoàn thành tác vụ, mức độ thường xuyên sử dụng sản phẩm, tỷ lệ chuyển đổi, sẽ là tín hiệu cho bạn biết bạn đã đạt được outcome hay chưa.

Output là thứ team tạo ra, còn product outcome thường là một thay đổi trong hành vi của người dùng mà team tin rằng sẽ đóng góp vào business outcome.¹

Có thể hình dung mối quan hệ này như sau:

Product work → Output → User behavior → Product outcome → Business outcome

Tuy nhiên, có metrics để theo dõi không đồng nghĩa với việc chúng ta đang đo đúng outcome. Ví dụ, một team có thể theo dõi rất sát velocity, số ticket hoàn thành, số feature đã release hay tỷ lệ hoàn thành roadmap. Những con số này không sai, nhưng phần lớn chỉ cho chúng ta biết team đang phát triển sản phẩm nhanh hay chậm, đúng hay trễ kế hoạch. Chúng không trả lời được sau khi feature được release, người dùng có thực sự sử dụng hay không, hành vi của họ có thay đổi không, vấn đề ban đầu có được giải quyết tốt hơn không và cuối cùng có tạo ra tác động mà business mong muốn hay không. Nói cách khác, nếu chỉ nhìn vào những metrics này, chúng ta đang đo khá tốt khả năng tạo ra output, nhưng chưa chắc đã đo được outcome mà những output đó tạo ra.

Ngay cả khi chuyển sang theo dõi hành vi của người dùng, việc chọn metric cũng không đơn giản là lấy những con số mình có sẵn rồi quan sát chúng tăng hay giảm. Khi xây dựng HEART Framework để đo User Experience (trải nghiệm người dùng) ở quy mô lớn, Google cũng chỉ ra rằng những chỉ số như page views (lượt xem của trang web) hay time spent (thời gian sử dụng sản phẩm) tuy rất dễ thu thập nhưng bản thân chúng chưa đủ để kết luận trải nghiệm của người dùng đang tốt lên hay xấu đi.² Thời gian sử dụng sản phẩm tăng có thể là tín hiệu cho thấy người dùng dành nhiều thời gian hơn vì sản phẩm hấp dẫn, nhưng trong một flow thanh toán, nó cũng có thể có nghĩa người dùng đang mất nhiều thời gian hơn để hoàn thành giao dịch. Tương tự, số lượt click tăng có thể thể hiện engagement (tính gắn bó) cao hơn, nhưng cũng có thể vì navigation (điều hướng) quá phức tạp khiến người dùng phải đi lòng vòng mới tìm được thứ mình cần. Cùng một metric và cùng một chiều tăng trưởng, nhưng đặt trong những mục tiêu khác nhau lại có thể mang ý nghĩa hoàn toàn khác nhau.

Do đó, thay vì bắt đầu bằng câu hỏi “Chúng ta đang có những dữ liệu nào để đo?”, trước hết Product team cần xác định “Chúng ta muốn sản phẩm tạo ra thay đổi gì?” và “Nếu thay đổi đó thực sự xảy ra, chúng ta sẽ nhìn thấy những tín hiệu nào?” Đây cũng là logic của Goals → Signals → Metrics trong HEART Framework: xác định goal trước, từ goal tìm ra những tín hiệu trong hành vi hoặc cảm nhận của người dùng cho thấy goal đang được đáp ứng, sau đó mới lựa chọn metric phù hợp để đo lường những tín hiệu đó.³ Hiểu nôm na, chúng ta không chọn một metric vì nó có sẵn hay vì “sản phẩm nào cũng đo chỉ số này”, mà vì nó giúp trả lời một câu hỏi cụ thể về outcome mà chúng ta đang muốn tạo ra.

Các loại Metrics – Các thước đo của cùng một sản phẩm không hề đứng đơn lẻ

Metrics có thể được phân loại theo nhiều cách, tùy vào mục đích đo lường và góc nhìn của từng framework. HEART của Google tập trung vào trải nghiệm người dùng với năm nhóm Happiness, Engagement, Adoption, Retention và Task Success.⁴ Trong product experimentation, Spotify sử dụng các nhóm Success, Guardrail, Deterioration và Quality metrics để hỗ trợ việc đánh giá một thử nghiệm.⁵ North Star Framework của Amplitude lại tập trung vào North Star Metric cùng các input metrics có khả năng tác động đến nó.⁶ Không có cách phân loại nào đúng cho mọi sản phẩm, bởi mỗi framework được xây dựng để giải quyết một bài toán khác nhau.

Điểm quan trọng hơn việc nhớ tên từng loại metric là hiểu rằng một metric hiếm khi có thể đứng một mình và cho chúng ta biết toàn bộ sản phẩm đang hoạt động tốt hay xấu. Một con số có thể cho thấy outcome mà chúng ta quan tâm đang tăng, nhưng chưa cho biết sự tăng trưởng đó có đánh đổi bằng một khía cạnh khác của sản phẩm hay không. Khi outcome giảm, bản thân con số đó cũng chưa giải thích được nguyên nhân nằm ở đâu. Vì vậy, thay vì chọn một vài metrics riêng lẻ để theo dõi, người làm Product cần hình dung chúng như một hệ thống các thước đo có quan hệ với nhau, trong đó mỗi metric trả lời một câu hỏi khác nhau về cùng một sản phẩm.

Trong phạm vi bài viết này, chúng ta có thể nhìn hệ thống đó qua ba vai trò chính. North Star Metric giúp trả lời sản phẩm có đang tạo ra value như kỳ vọng hay không. Guardrail Metrics bổ sung một góc nhìn khác: trong quá trình cải thiện North Star, có khía cạnh quan trọng nào của sản phẩm đang trở nên tệ hơn không? Khi một trong những con số này thay đổi, Diagnostic Metrics lại giúp Product team đi sâu xuống bên dưới để tìm nguyên nhân. Nói cách khác, thay vì đọc từng metric riêng lẻ, chúng ta đọc mối quan hệ giữa chúng để hiểu chuyện gì thực sự đang xảy ra với sản phẩm.

North Star Metric: Sản phẩm có đang tạo ra giá trị không?

North Star Metric (NSM) có thể hiểu là metric đại diện cho giá trị cốt lõi mà người dùng nhận được từ sản phẩm, đồng thời có mối liên hệ với kết quả kinh doanh dài hạn. Theo North Star Playbook của Amplitude, một NSM tốt cần kết nối được vấn đề của khách hàng mà Product team đang giải quyết với các kết quả kinh doanh bền vững. Vì vậy, North Star thường được lựa chọn như một kim chỉ nam cho khả năng phát triển của business, thay vì chỉ phản ánh một kết quả đã xảy ra.

Doanh thu (revenue) là một ví dụ khá rõ để thấy sự khác biệt này. Đây chắc chắn là một metric quan trọng đối với business, nhưng chưa chắc phù hợp để trở thành North Star của Product. Revenue phản ánh “lượng” giá trị doanh nghiệp thu được từ khách hàng, trong khi North Star metrics giúp team quan sát liệu người dùng có đang nhận được giá trị lõi (core value) của sản phẩm hay không. Với một ứng dụng học tập, tín hiệu đó có thể là số learning sessions được hoàn thành. Với marketplace, đó có thể là số lượng giao dịch thành công. Với một công cụ tăng năng suất, số task có ý nghĩa được hoàn tất có thể phản ánh tốt hơn số lượt mở ứng dụng. North Star, theo cách hiểu này, đại diện cho một giá trị trao đổi: user nhận được giá trị từ sản phẩm và việc giá trị đó liên tục được tạo ra sẽ đóng góp vào khả năng phát triển dài hạn của business.

Dù vậy, biết North Star đang tăng hay giảm vẫn chưa đủ để Product team biết mình nên tác động vào đâu. Vì thế, trong North Star Playbook, Amplitude còn xác định các input metrics — những hành vi hoặc yếu tố nằm gần hơn với hoạt động của Product team và có khả năng dẫn dắt North Star. Chẳng hạn, nếu North Star là số tác vụ được hoàn thành thành công, inputs có thể bao gồm số user bắt đầu luồng sản phẩm, tỷ lệ đi tới một bước quan trọng hoặc tần suất thực hiện các tác vụ chính của tính năng/sản phẩm. Nói cách khác, North Star giúp team biết “Sản phẩm có đang đi đúng hướng không?”, còn input metrics giúp xác định “Muốn tác động tới kết quả đó, chúng ta có thể tác động vào đâu?”.^{7 8}

North Star vì vậy cho team một điểm tham chiếu chung về hướng đi của sản phẩm, nhưng chưa đủ để kết luận mọi thứ đều đang tốt lên. Một North Star tăng vẫn có thể đi cùng sự suy giảm của một khía cạnh quan trọng khác. Đó là lý do chúng ta cần nhìn thêm Guardrail Metrics.

Guardrail Metrics: Chúng ta có đang tối ưu bằng một cái giá quá đắt?

Giả sử một AI chatbot đang được tối ưu Deflection Rate — tỷ lệ conversation không cần chuyển sang human agent. Sau khi điều chỉnh một tính năng, Deflection tăng 8%, trong khi CSAT giảm 6%. Nhìn riêng Deflection, thay đổi này có vẻ thành công. Nhưng nếu chatbot giữ được nhiều người dùng ở self-service hơn bằng cách làm trải nghiệm của họ tệ đi đáng kể, rất khó kết luận sản phẩm thực sự tốt hơn trước.

Đây là bài toán mà Guardrail Metrics (hay còn gọi là Counter metrics⁹) giúp Product team kiểm soát. Trong nghiên cứu về cách ra quyết định với A/B testing tại Spotify, Success metrics được dùng để đánh giá outcome mà experiment muốn tạo ra, còn Guardrail metrics bảo vệ những khía cạnh quan trọng khác của sản phẩm trước các tác động không mong muốn. Nói cách khác, khi tối ưu một metric, chúng ta đồng thời xác định những thứ không được phép trở nên tệ hơn quá một giới hạn nhất định.¹⁰

Với ví dụ trên, team có thể đặt mục tiêu Deflection tăng tối thiểu 5%, đồng thời sử dụng CSAT như một guardrail với điều kiện không giảm quá 1%. Như vậy, CSAT không cần phải tăng để experiment được xem là thành công; nó chỉ cần nằm trong khoảng suy giảm mà team chấp nhận được. Đây cũng là điểm khác biệt giữa target của metric chính và threshold của guardrail.

Threshold này tốt nhất nên được thống nhất trước khi team nhìn thấy kết quả. Nếu Deflection tăng 8% rồi chúng ta mới bắt đầu tranh luận xem CSAT giảm 6% “có đáng đánh đổi hay không”, quyết định rất dễ bị ảnh hưởng bởi kết quả mà mình đang muốn bảo vệ. Tương tự, nếu mỗi lần guardrail bị phá vỡ team lại thay đổi ngưỡng để hợp thức hóa outcome, metric đó trên thực tế không còn làm nhiệm vụ của một guardrail nữa.

North Star và Guardrail đặt cạnh nhau giúp Product team nhìn được trade-off: chúng ta đang cải thiện điều gì và có đang đánh đổi điều gì hay không. Nhưng khi một trong hai thay đổi ngoài kỳ vọng, chúng vẫn mới cho biết chuyện gì xảy ra, chưa cho biết vì sao nó xảy ra. Lúc này mới cần tới Diagnostic Metrics.¹¹

Diagnostic Metrics: Nếu có chuyện xảy ra, tại sao?

North Star và Guardrail chủ yếu giúp chúng ta nhận biết có chuyện gì đang xảy ra với sản phẩm, nhưng chưa chắc giải thích được nguyên nhân. Khi một outcome tăng hoặc giảm, Product team thường cần đi xuống một lớp metrics chi tiết hơn để tìm xem sự thay đổi bắt đầu từ đâu. Đây là vai trò của Diagnostic Metrics.

Ví dụ, tỷ lệ user hoàn thành payment flow đột nhiên giảm. Con số này mới cho chúng ta biết flow đang có vấn đề, chưa cho biết vấn đề nằm ở đâu. Product team có thể cần phân rã funnel để xem user rơi nhiều nhất ở bước nào, sau đó kiểm tra thêm API success rate, error rate, response time, platform, app version hoặc từng payment method. Nếu self-service resolution của chatbot giảm, quá trình chẩn đoán cũng tương tự: vấn đề có thể đến từ intent recognition, retrieval quality, API/tool success, handoff rate hoặc chỉ tập trung ở một nhóm intent nhất định.

Vì mục đích chính là tìm nguyên nhân, Diagnostic Metrics không nhất thiết phải trở thành mục tiêu cần tối ưu. Một error rate, conversion tại một bước nhỏ trong funnel hay API latency có thể cực kỳ hữu ích khi điều tra sự cố, nhưng điều đó không có nghĩa Product team nên biến tất cả chúng thành KPI. Metric dùng để biết sản phẩm có thành công hay không và metric dùng để giải thích tại sao sản phẩm thành công hay thất bại đang phục vụ hai câu hỏi khác nhau.

Còn Leading và Lagging Metrics?

North Star và Guardrail chủ yếu giúp chúng ta nhận biết có chuyện gì đang xảy ra với sản phẩm, nhưng chưa chắc giải thích được nguyên nhân. Khi một outcome tăng hoặc giảm, Product team thường cần đi xuống một lớp metrics chi tiết hơn để tìm xem sự thay đổi bắt đầu từ đâu. Đây là vai trò của Diagnostic Metrics.

Ví dụ, tỷ lệ user hoàn thành payment flow đột nhiên giảm. Con số này mới cho chúng ta biết flow đang có vấn đề, chưa cho biết vấn đề nằm ở đâu. Product team có thể cần phân rã funnel để xem user rơi nhiều nhất ở bước nào, sau đó kiểm tra thêm API success rate, error rate, response time, platform, app version hoặc từng payment method. Nếu self-service resolution của chatbot giảm, quá trình chẩn đoán cũng tương tự: vấn đề có thể đến từ intent recognition, retrieval quality, API/tool success, handoff rate hoặc chỉ tập trung ở một nhóm intent nhất định.¹²

Vì vậy, một metric không tự động trở thành leading indicator chỉ vì nó xảy ra trước một metric khác. Ví dụ, việc user mở ứng dụng ba lần trong tuần đầu tiên chỉ hữu ích như một leading indicator của retention nếu chúng ta có bằng chứng rằng nhóm user có hành vi này thực sự có khả năng tiếp tục sử dụng sản phẩm cao hơn. Leading indicator về bản chất là một giả thuyết về quan hệ giữa tín hiệu hiện tại và outcome tương lai — và giả thuyết đó vẫn cần được kiểm chứng bằng dữ liệu.

Dấu hiệu bạn có thể đang đặt sai Metrics

Đặt sai metric không có nghĩa metric đó hoàn toàn vô nghĩa. Trong nhiều trường hợp, con số chúng ta theo dõi vẫn được tính toán chính xác, chỉ là nó không trả lời đúng câu hỏi mà Product team đang muốn trả lời. Đây cũng là lý do một metric không phù hợp đôi khi khó nhận ra: bảng theo dõi vẫn có số liệu, metric vẫn tăng giảm và team vẫn có thể đưa ra rất nhiều phân tích từ đó.

Một trong những dấu hiệu dễ nhận thấy nhất là metric thay đổi theo hướng chúng ta mong muốn, nhưng giá trị mà người dùng nhận được không thực sự tăng lên. Thời gian sử dụng tăng trong một sản phẩm giải trí có thể là tín hiệu tích cực vì người dùng muốn dành nhiều thời gian hơn cho nội dung. Cùng mức tăng đó trong một luồng thanh toán lại có thể cho thấy họ đang mất nhiều thời gian hơn để hoàn thành giao dịch. Google cũng lưu ý rằng những tín hiệu hành vi như số lượt xem trang hay thời gian sử dụng có thể được diễn giải theo nhiều cách khác nhau. Vì vậy, việc lựa chọn tín hiệu cần xuất phát từ mục tiêu mà sản phẩm muốn đạt được, thay vì mặc định một metric tăng luôn đồng nghĩa với trải nghiệm tốt hơn.¹³

Một cách khác để kiểm tra là thử hỏi: “Có cách nào làm metric này đẹp lên mà sản phẩm không cần tốt hơn không?” Giả sử team muốn tăng Deflection Rate (tỷ lệ hội thoại không cần chuyển sang nhân viên hỗ trợ) của chatbot. Một cách là cải thiện khả năng tự phục vụ để nhiều người dùng thực sự giải quyết được vấn đề mà không cần tới nhân viên. Nhưng team cũng có thể đạt Deflection Rate cao hơn bằng cách khiến việc chuyển sang nhân viên trở nên khó khăn hơn. Tương tự, DAU (số người dùng hoạt động hằng ngày) có thể tăng vì sản phẩm tạo đủ giá trị để người dùng chủ động quay lại, hoặc đơn giản vì team gửi thông báo thường xuyên hơn để kéo họ vào ứng dụng. Average Handling Time (thời gian xử lý trung bình) có thể giảm nhờ cung cấp công cụ tốt hơn cho nhân viên, nhưng cũng có thể giảm vì yêu cầu của khách hàng được kết thúc sớm dù vấn đề chưa được xử lý triệt để. Khi một metric có thể được tối ưu mà kết quả thực tế không cải thiện tương ứng, chúng ta cần xem lại metric đó đang đại diện cho điều gì và có cần thêm những thước đo khác để kiểm soát hay không.

Một metric cũng trở nên ít hữu ích nếu sự thay đổi của nó không dẫn tới bất kỳ quyết định nào. Giả sử tỷ lệ chuyển đổi giảm 10%, team quyết định tiếp tục theo dõi. Vậy nếu giảm 20% thì sao? Khi nào cần tìm nguyên nhân, dừng một thay đổi vừa triển khai hay điều chỉnh kế hoạch sản phẩm? Nếu không có một mức biến động nào khiến Product team hành động khác đi, con số đó có thể hữu ích để tham khảo hoặc chẩn đoán, nhưng chưa chắc phù hợp để trở thành một metric trọng yếu trong việc điều hành sản phẩm.

Một dấu hiệu khác nằm ở chính cách team tổ chức hệ thống đo lường. Một dashboard (bảng theo dõi) có thể chứa hàng chục metrics và tất cả đều được gọi là “key metrics” hay KPI. Khi mọi con số đều quan trọng như nhau, team lại không có cách xác định nên ưu tiên nhìn vào đâu khi chúng đi theo những hướng khác nhau. North Star tăng nhưng CSAT giảm thì sản phẩm đang tốt lên hay xấu đi? Tỷ lệ chuyển đổi tăng nhưng retention (tỷ lệ duy trì người dùng) giảm thì có nên tiếp tục triển khai thay đổi hay không? Nếu mỗi stakeholder (bên liên quan) đều có thể chọn một con số để bảo vệ quan điểm của mình, vấn đề không nằm ở việc thiếu dữ liệu mà ở chỗ các metrics chưa được đặt trong một hệ thống đủ rõ để Product team hiểu mối quan hệ và mức độ ưu tiên giữa chúng.

Một vấn đề khác là metric từng phù hợp chưa chắc sẽ phù hợp mãi. Khi chiến lược, mô hình kinh doanh hoặc cách người dùng sử dụng sản phẩm thay đổi, hệ thống đo lường cũng cần được xem xét lại. Kaplan và Norton từng chỉ ra rằng nhiều tổ chức thay đổi chiến lược nhưng vẫn tiếp tục sử dụng những thước đo cũ mà không kiểm tra xem chúng còn phản ánh đúng mục tiêu mới hay không.¹⁴

Dấu hiệu một Metric phù hợp

Một metric phù hợp không phải metric nghe hợp lý, mà là metric giúp team quan sát đúng outcome và biết phải làm gì khi nó thay đổi. Nếu một metric có thể dẫn chúng ta tới kết luận sai, vậy làm sao biết metric mình chọn đang phù hợp? Không có một phép kiểm tra duy nhất cho câu hỏi này, bởi gần như không có metric nào phản ánh hoàn toàn chính xác những khái niệm phức tạp như giá trị người dùng nhận được, mức độ tương tác hay sự hài lòng. Thay vào đó, có thể bắt đầu bằng việc kiểm tra metric đang đại diện cho điều gì, chúng ta có thể tác động tới nó hay không và sự thay đổi của nó có giúp Product team đưa ra quyết định tốt hơn không.

Trước hết, metric cần có mối liên hệ đủ rõ với outcome (kết quả) mà sản phẩm muốn tạo ra. Nếu mục tiêu là giúp người dùng hoàn thành thanh toán dễ dàng hơn, tỷ lệ giao dịch thành công có thể là một tín hiệu trực tiếp hơn số lần người dùng mở màn hình thanh toán. Nếu mục tiêu là giúp người dùng tự giải quyết vấn đề, việc một cuộc hội thoại không chuyển sang nhân viên có thể là một tín hiệu, nhưng sẽ đáng tin cậy hơn nếu chúng ta biết người dùng thực sự đã giải quyết xong vấn đề. Đây cũng là logic của Goals → Signals → Metrics (Mục tiêu → Tín hiệu → Thước đo) trong HEART Framework: xác định mục tiêu trước, tìm những dấu hiệu cho thấy mục tiêu đó đang được đáp ứng, rồi mới lựa chọn cách đo những tín hiệu này.¹⁵

Khoảng cách giữa metric và hoạt động của Product team cũng cần đủ gần để chúng ta có thể tác động. Doanh thu toàn công ty chắc chắn quan trọng, nhưng một team phụ trách một tính năng khó nhìn doanh thu giảm rồi biết ngay mình cần thay đổi điều gì. Một product metric hữu ích thường cho phép team hình thành một giả thuyết tương đối rõ: nếu thay đổi một luồng, một tính năng hay một hành vi cụ thể, metric nào được kỳ vọng sẽ thay đổi theo? Đây cũng là lý do North Star Framework không chỉ dừng ở North Star Metric mà còn liên kết nó với các input metrics (thước đo đầu vào) nằm gần hơn với những yếu tố Product team có khả năng tác động.¹⁶

Bên cạnh việc chọn đúng thứ cần đo, cách định nghĩa metric cũng quyết định chúng ta đang nhìn thấy điều gì. Cùng gọi là Deflection Rate, một team có thể tính tỷ lệ cuộc hội thoại không chuyển sang nhân viên trên tổng số cuộc hội thoại, trong khi team khác chỉ tính tỷ lệ những cuộc hội thoại thực sự được giải quyết bằng kênh tự phục vụ trên tổng số trường hợp đủ điều kiện tự phục vụ. Hai công thức nghe có vẻ đang đo cùng một thứ, nhưng thực tế lại trả lời hai câu hỏi khác nhau. Vì vậy, một metric cần có định nghĩa đủ rõ về tử số, mẫu số, nhóm người dùng hoặc trường hợp được tính, khoảng thời gian quan sát, những trường hợp bị loại trừ và các tình huống ngoại lệ quan trọng. Nếu hai team gọi cùng tên một metric nhưng tính theo hai cách khác nhau, việc so sánh hay tranh luận dựa trên con số đó gần như không còn nhiều ý nghĩa.

Metric cũng cần đủ nhạy với sự thay đổi mà Product team đang muốn quan sát. Trong HEART Framework, Google đề xuất lựa chọn tín hiệu dựa trên mục tiêu rồi xác định những metrics có thể đo các tín hiệu đó một cách phù hợp ở quy mô cần thiết. Nếu một metric chủ yếu biến động theo mùa vụ, chiến dịch marketing hoặc sự thay đổi về cơ cấu người dùng, trong khi tác động từ tính năng quá nhỏ để nhận biết, Product team rất dễ kết luận sai rằng sản phẩm tốt lên hoặc xấu đi vì thay đổi mình vừa thực hiện.

Sau cùng, một metric phù hợp phải giúp chúng ta hiểu hoặc quyết định được điều gì đó. Khi con số thay đổi, team ít nhất cần biết sự thay đổi đó có đáng chú ý không, cần quan sát thêm, đi sâu vào các Diagnostic Metrics để tìm nguyên nhân hay bắt đầu hành động. Metrics không tồn tại chỉ để dashboard có thêm một biểu đồ; giá trị của chúng nằm ở việc giúp Product team hiểu sản phẩm và đưa ra quyết định dựa trên những gì đang thực sự xảy ra.

“Metrics chính là mục tiêu” – một sai lầm nguy hiểm

Cho tới đây, có thể thấy việc chọn đúng metric không đơn giản là tìm một con số có tương quan với outcome rồi theo dõi nó. Còn một vấn đề khó hơn: ngay cả một metric được lựa chọn hợp lý ban đầu cũng có thể trở nên kém phù hợp khi chúng ta bắt đầu tối ưu nó như một mục tiêu cuối cùng.

Giả sử mục tiêu thực sự của một sản phẩm chăm sóc khách hàng là giúp người dùng giải quyết vấn đề nhanh, chính xác và ít tốn công sức nhất có thể. Team lựa chọn Deflection Rate làm một trong những metrics quan trọng với lập luận: nếu người dùng không cần gặp nhân viên, có khả năng kênh tự phục vụ đã giải quyết được vấn đề. Lập luận này không sai. Vấn đề nằm ở chữ “có khả năng”. Người dùng không chuyển sang nhân viên có thể vì vấn đề thực sự đã được giải quyết, nhưng cũng có thể vì họ bỏ cuộc, không tìm thấy cách chuyển, quyết định gọi hotline hoặc chuyển sang một kênh hỗ trợ khác. Deflection Rate vì vậy không phải bản thân mục tiêu; nó là một proxy (thước đo đại diện) cho điều mà chúng ta thực sự muốn đạt được.

Khoảng cách giữa mục tiêu thật và metric đại diện cho nó là điểm cần đặc biệt lưu ý khi một metric được đưa vào target (mục tiêu định lượng). Charles Goodhart ban đầu mô tả hiện tượng này trong bối cảnh chính sách tiền tệ: một mối quan hệ thống kê quan sát được có xu hướng thay đổi khi nó được sử dụng cho mục đích kiểm soát. Ý tưởng này sau đó được phổ biến rộng hơn qua cách diễn đạt thường gắn với Marilyn Strathern: “When a measure becomes a target, it ceases to be a good measure” – khi một thước đo trở thành mục tiêu, nó không còn là một thước đo tốt nữa. Đây không chỉ là một rủi ro mang tính lý thuyết. Một nghiên cứu phân tích hơn 120 triệu bài báo khoa học cho thấy khi các chỉ số như số lượng công bố, citation hay impact factor trở thành mục tiêu đánh giá, hành vi của hệ thống cũng dần thay đổi theo hướng tối ưu các con số đó, khiến chính những metrics này suy giảm khả năng đại diện cho chất lượng học thuật.¹⁷

Goodhart’s Law (Định luật Goodhart) không có nghĩa chúng ta không nên đặt mục tiêu cho metrics. Vấn đề xuất hiện khi team bắt đầu coi việc đạt được một con số là đích đến cuối cùng và quên mất tại sao metric đó được lựa chọn ngay từ đầu. Khi ấy, Product team có thể vô tình tối ưu phần dễ thay đổi nhất của metric thay vì outcome mà metric đại diện. Một thay đổi giúp Deflection Rate tăng vì chatbot giải quyết được nhiều vấn đề hơn và một thay đổi giúp Deflection Rate tăng vì người dùng khó tìm thấy nhân viên đều khiến cùng một con số đi lên, nhưng rõ ràng chỉ một trong hai tạo ra outcome mà sản phẩm thực sự mong muốn.

Đây cũng là lý do các metrics của cùng một sản phẩm không nên được nhìn riêng lẻ. North Star Metric giúp team theo dõi giá trị chính mà sản phẩm muốn tạo ra, Guardrail Metrics giúp nhận biết liệu quá trình tối ưu có đang làm tổn hại một khía cạnh quan trọng khác hay không, còn Diagnostic Metrics cung cấp thêm dữ liệu để hiểu nguyên nhân phía sau sự thay đổi. Các thước đo này không loại bỏ hoàn toàn khoảng cách giữa metric và thực tế, nhưng việc quan sát chúng cùng nhau giúp Product team tránh đưa ra kết luận chỉ từ một con số duy nhất.

Ngay cả khi đã xây dựng một hệ thống như vậy, metrics vẫn chỉ là cách chúng ta quan sát thực tế, không phải bản thân thực tế. CSAT giúp đo mức độ hài lòng nhưng không thể phản ánh toàn bộ trải nghiệm của khách hàng. Retention cho biết người dùng có tiếp tục quay lại hay không nhưng không tự giải thích được lý do. Engagement (mức độ tương tác) cho thấy người dùng tương tác với sản phẩm ở mức độ nào nhưng chưa chắc cho biết những tương tác đó có thực sự tạo ra giá trị. Google cũng lưu ý rằng các thước đo định lượng trong HEART nên được sử dụng cùng những phương pháp nghiên cứu khác như usability study (nghiên cứu khả năng sử dụng) hay field study (nghiên cứu thực địa) để có được bức tranh đầy đủ hơn về trải nghiệm người dùng.

Vì vậy, mục tiêu của việc xây dựng một hệ thống metrics không phải tìm ra những con số có thể thay thế hoàn toàn thực tế. Điều chúng ta cần là những thước đo đủ tốt để quan sát thực tế từ nhiều góc độ, đồng thời luôn giữ được khoảng cách giữa thứ sản phẩm thực sự muốn tạo ra và con số chúng ta đang dùng để đại diện cho nó.

Tạm kết

Product team ngày nay hiếm khi thiếu dữ liệu. Thứ khó hơn là biết dữ liệu nào đáng để quan sát và chúng ta nên hiểu chúng như thế nào. Một metric có thể được tính hoàn toàn chính xác nhưng vẫn không phản ánh đúng outcome. Một metric có thể tăng theo hướng team mong muốn nhưng đi cùng sự suy giảm của một khía cạnh khác. Thậm chí một metric từng rất phù hợp cũng có thể dần mất đi ý nghĩa khi cách người dùng sử dụng sản phẩm, mô hình kinh doanh hoặc cách team tối ưu nó thay đổi.

Do đó, việc xây dựng metrics nên bắt đầu từ outcome mà sản phẩm muốn tạo ra, sau đó xác định những tín hiệu giúp chúng ta quan sát outcome đó và lựa chọn cách đo phù hợp. Khi đặt các metrics vào cùng một hệ thống, North Star Metric cho team biết sản phẩm có đang tạo ra giá trị như kỳ vọng hay không, Guardrail Metrics giúp kiểm soát những đánh đổi không mong muốn, còn Diagnostic Metrics giúp tìm nguyên nhân khi các chỉ số phía trên thay đổi.

Quan trọng hơn, đừng quên rằng metrics là công cụ để hiểu sản phẩm, không phải bản thân sản phẩm. Đo đúng không có nghĩa là tìm được một con số hoàn hảo, mà là xây được một hệ thống đo lường đủ tốt để chúng ta không nhầm sự thay đổi của con số với sự thay đổi của thực tế. Khi đã xác định được mình cần quan sát những gì, một bài toán khác lại xuất hiện: làm sao tổ chức hàng loạt metrics đó để người làm Product vừa nhìn thấy bức tranh tổng thể, vừa có thể nhanh chóng đi sâu vào chi tiết khi có tín hiệu bất thường? Đây cũng chính là vai trò của Product Dashboard (bảng theo dõi sản phẩm), và sẽ là chủ đề của bài viết tiếp theo. Hẹn gặp lại các bạn trong kỳ tới.

Cheers & Peace!

---

Nguồn tham khảo

1. Product Talk, Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid ↩︎
2. Google Research, Measuring the User Experience on a Large Scale:
   User-Centered Metrics for Web Applications ↩︎
3. Google Research, Measuring the User Experience on a Large Scale:
   User-Centered Metrics for Web Applications ↩︎
4. Google Research, Measuring the User Experience on a Large Scale:
   User-Centered Metrics for Web Applications ↩︎
5. Spotify, Risk-aware product decisions in A/B tests
   with multiple metrics ↩︎
6. Amplitude, North Star Playbook ↩︎
7. Amplitude, North Star Playbook ↩︎
8. Mixpanel, What is a North Star metric? ↩︎
9. Mixpanel, Guardrail metrics: The complete guide to balanced product growth ↩︎
10. Spotify, Risk-aware product decisions in A/B tests
    with multiple metrics ↩︎
11. Spotify, Spotify’s New Experimentation Platform (Part 2) ↩︎
12. Amplitude, North Star Playbook ↩︎
13. Google Research, Measuring the User Experience on a Large Scale:
    User-Centered Metrics for Web Applications ↩︎
14. Harvard Business Review, Putting the Balanced Scorecard to Work ↩︎
15. Google Research, Measuring the User Experience on a Large Scale:
    User-Centered Metrics for Web Applications ↩︎
16. Amplitude, North Star Playbook ↩︎
17. Fire & Guestrin, Over-Optimization of Academic Publishing Metrics:
    Observing Goodhart’s Law in Action ↩︎