The Paradoxes - Khi dữ liệu cũng nói dối và làm mất thời gian.
Trong những năm đầu sự nghiệp, tôi từng tin rằng Product Management là một bộ môn khoa học chính xác. Với tôi khi ấy: "Nếu không đo lường được,nó chắc chắn nó sai."
“Nay vừa nói với 1 bạn trong team nhìn tương đối và đảm bảo nó đúng về số là ok rồi chuyển qua việc xử lý nó đi chứ mất thời gian chứng minh có đủ hằng trăm back-up để bảo vấn đề đó chắc chắn 100% thì làm gì khi mục tiêu của team là đến đích chứ ko phải tìm hiểu cái chúng ta nói là đúng 100% đâu.”
Quay lại tuổi trẻ tôi thích các bảng biểu Excel, bị cảm giác ám ảnh bởi biểu đồ Google Analytics, và coi A/B testing là chân lý cuộc đời. Giờ nhìn lại thì là tranh luận nhau về toán hơn là insight đa phần một số bạn hay tự nhận mình giỏi cũng hay nhầm lẫn việc tìm ra insight và tìm ra một vấn đề về số.
Nhưng rồi, sau hơn nhiều năm làm đủ thử qua đủ các dạng sản phẩm, từ lúc thai nghén đến khi khai tử, tôi nhận ra một sự thật có phần chốt lại: Dữ liệu phần nhiều mang lại sự an tâm và giúp optimize, nhưng hiếm khi mang lại sự đột phá cao.
Hãy nói về giữa những con số Data metric và thứ mà chúng ta hay gọi là Cảm giác sản phẩm - Product Sense.
Product Sense vs Product Metric
Sự quyến rũ của những con số
Chúng ta đang sống trong kỷ nguyên mà cụm từ “Data-driven” được dùng nhiều đến chán trong mọi bản mô tả công việc. Dễ hiểu, dữ liệu là câu chuyện hoàn hảo. Khi một tính năng thất bại, nếu bạn đã làm theo dữ liệu, bạn vô tội. “Dữ liệu bảo thế” là câu nói an toàn nhất để bảo vệ một PM trước mọi góc nhìn.
Nhưng dữ liệu có một điểm mù chết người: Nó luôn nhìn về quá khứ.
Dữ liệu dễ dàng cho bạn biết người dùng đã làm gì, đã click vào đâu, và rời đi ở bước nào. Nhưng nó hiếm khi nói cho bạn biết tại sao user lại cảm thấy như vậy, hay user đang muốn điều gì mà chưa thành hình.
Một feedback hay dùng trong team nếu chỉ là số. Chúng ta Ko chỉ show số và next action mà nên chuyển nó thành insight và cũng chỉ nên tranh luận về insight có thể các đội khác ko thể tốt hơn bằng chúng ta về số nhưng họ có thể có insight tốt hơn nên ko nói cùng ngôn ngữ.
Dữ liệu rất phù hợp trong việc tối ưu hóa cái đang có (từ 5 lên 8 lên 9), nhưng nó cực kỳ tệ trong việc tưởng tượng ra cái chưa từng tồn tại (từ 0 lên 1) hoặc chúng ta còn đang âm.
Nhiều khi nên tin vào Trực giác
Nhiều người trẻ thường e ngại khi nói “Tôi cảm thấy...” trong các cuộc họp chiến lược. Họ sợ bị đánh giá là thiếu chuyên nghiệp, là cảm tính.
Tuy nhiên, cần phân biệt rõ giữa “đoán mò” và “trực giác” .
Trực giác của một người làm sản phẩm lâu năm không phải là phép thuật hay sự ngẫu hứng. Đó là kết quả của hàng nghìn giờ quan sát hành vi người dùng, hàng trăm cuộc phỏng vấn sâu, và vô số lần chứng kiến thị trường biến động. Tất cả những thông tin đó được não bộ xử lý ngầm và kết tinh lại thành một góc nhìn. Vì thế khi được cơ hội nói chuyện và trao đổi về công việc tôi hay có 1 câu hỏi giả định để bạn có thể show việc bạn nghĩ và các kiến thức bạn đã có xưa giờ thay vì hỏi về how cho các vấn đề quá cụ thể.
Khi bạn nhìn vào một giao diện và cảm thấy “nó hơi cấn”, dù các chỉ số UX vẫn ổn, thì đó là lúc trực giác lên tiếng. Có thể là do dòng copy thiếu sự đồng cảm, hay luồng thao tác thiếu tính tự nhiên của con người. Excel không ghi nhận được sự cảm giác đó, nhưng con người thì có.
Và Dữ liệu rất nhiều lúc nói dối để chìu lòng PM
Bạn đã gặp trường hợp này chưa: Mọi chỉ số đều xanh, nhưng người dùng vẫn rời bỏ sản phẩm?
Đó là cái bẫy của Local Maximum. Bạn có thể A/B test để tối ưu hóa màu sắc nút bấm, vị trí banner để tăng tỷ lệ click (CTR) lên 20%. Dữ liệu đẹp show cho sếp. Nhưng bạn có thể đã vô tình biến trải nghiệm người dùng thành một phiên bản để thử nghiệm số của bạn và liên tục thay đổi UI, khiến niềm cảm giác sản phẩm của user sụt giảm.
Dữ liệu rất giỏi trả lời câu hỏi “Cái nào?” (A hay B?), nhưng nó hay nói dối hoặc chả biết gì trước câu hỏi “Để làm gì?” (So what?).
Một sản phẩm tốt không phải là tập hợp của những chỉ số tối ưu cục bộ. Nó là một tổng thể hài hòa, đôi khi cần sự hy sinh ở chỉ số này để đổi lấy sự thỏa mãn về cảm xúc ở chỉ số khác – thứ mà máy móc khó thể đo đếm được mà cần con người, một PM thực sự dùng sp và đủ cái tâm của người làm sản phẩm để luôn nghĩ về nó thay vì cái bạn muốn làm là viết PRD với đầy đủ Corner Case. Và lỗi nếu có ở sản phẩm không phải do mình viết Document thiếu.
Luôn cần cân bằng Lý trí (Data)và Cảm xúc (Sense)
Vậy theo bạn một Product Manager sẽ chọn phe nào? Câu trả lời là không chọn phe nào cả. Chúng ta cần chuyển dịch tư duy từ Data-driven (Bị dữ liệu lái xoay vòng vòng ko có chính kiến và được cả 1 xã hội tung hô) sang Data-informed (Được dữ liệu tham vấn).
Hãy tưởng tượng quy trình đó như thế này:
Dùng Trực giác để đặt câu hỏi và định hình giả thuyết:“Tôi cảm thấy người dùng đang mệt mỏi với bước đăng ký này.”
Dùng Dữ liệu để kiểm chứng và phản biện:“Hãy xem drop-rate ở màn hình đăng ký có cao bất thường không?”
Dùng Trực giác để thiết kế giải pháp:“Số liệu xác nhận là cao. Giờ thay vì chỉ đổi màu nút, hãy thử bỏ hẳn việc bắt buộc đăng ký xem sao.”
Dùng Dữ liệu để đo lường kết quả:“Sau khi bỏ đăng ký, retention rate thay đổi thế nào?”
Sự cân bằng nằm ở chỗ: Dùng dữ liệu để đã bảo không làm lơ ngơ, nhưng dùng trực giác để làm sản phẩm cho user không phải làm sản phẩm đúng Document.
Tóm lại theo góc nhìn cá nhân.
Làm sản phẩm, đến tận cùng, là làm việc với con người. Mà con người thì phức tạp, đầy mâu thuẫn và cảm xúc – những thứ không thể chỉ nói trong các ô tính rồi cả ngày tranh cải nhau về số liệu ai đúng ai giỏi toán hơn ai.
Đừng quên dữ liệu luôn là kim chỉ nam, nhưng cũng đừng để nó tước đi quyền năng lớn nhất của bạn: Sự thấu cảm và trí tưởng tượng và góc nhìn một PM. Đôi khi, dũng cảm tin vào tiếng nói nhỏ bé bên trong mình trước hàng tấn bảng biểu, đó mới là khoảnh khắc định hình nên một Product Manager giỏi, chứ không phải một Product Manager Document và backlog :D
Disclaimer: Bài viết là góc nhìn cá nhân, Product Sense sẽ phù hợp cao cho Product nơi PM được làm chủ về Biz, nơi chúng ta chiến thắng khi biz tăng trưởng bằng sản phẩm hay được gọi Prod led growth. Sẽ chưa và có thể không bao giờ phù hợp cho nhiều môi trường PM là người chỉ build tính năng theo yêu cầu lúc đó làm đúng quan trọng hơn.
T.D 20/11/2025 Ps : Cá nhân cũng đã từng chúng kiến rất nhiều quyết định chỉ dựa bằng Product Sense đem lại thành công ngoài dự kiến, hay việc cả 1-2 tuần ngồi nghiên cứu số liệu lại tìm ra vấn đề không khác gì 1 anh chỉ nhìn và đưa ra vấn đề duy nhất bằng Product Sense.
