I. Thực trạng

Tôi có bảng điểm này:

Bảng điểm đầu vào của 1 bootcamp. Bài test trắc nghiệm 90 phút, 90 câu.

Analytical Thinking là điểm thấp nhất trong bài test đầu vào của UXCamp.

Phóng to vào các tiêu chí bên trong Analytical Thinking:

Một số kỹ năng con nằm trong 4 nhóm này gồm: Descriptive & Inferential Statistics, Hypothesis Testing Method, Break Down Metric, Active Use, CR, Retenion, LTV, Calculation & Drawing Conclusion.

Khả quan nhất là điểm User Behavior, hẹo nhất là Product Metrics và Hypothesis Testing. Với điểm năng lực này, không khó hiểu nếu chúng ta loay hoay khi được hỏi câu: "công việc của em tác động vào chỉ số sản phẩm như nào? và "em làm gì để chứng minh giả thuyết của mình?".

Nửa cuối 2025 tôi cung cấp bài test đánh giá năng lực cho một số đơn vị trên địa bàn Hà Nội thì bức tranh này cũng lặp lại ở cả Product Manager, UI UX Designer, UX Researcher và Product Marketing. Xin phép không show bảng điểm của họ ra đây.

II. Nguyên nhân?

Trước tiên phải nói tới việc phân tích số liệu không nằm trong scope of work của rất nhiều PM, Designers và Business Analyst (Vd làm outsourcing, product nội bộ, cty gia đình...). Có đợt UXCamp làm khảo sát người tham dự, chỉ khoảng 10% họ thực sự được làm số thường xuyên (hàng tháng, hàng tuần). Gần 3/4 còn lại là không biết hoặc chưa từng làm! Cũng tò mò số liệu này có đúng trên quy mô thị trường không, nhưng chúng tôi bận quá chưa có thời gian điều tra.

Survey này gần đây UXCamp thay thế bằng bài test đánh giá năng lực nên cũng không survey tiếp.

Thực tế phũ phàng: Rất nhiều người muốn được tiếp cận, làm và hiểu về số liệu nhưng công ty thì không có chủ trương ấy. Bước đầu tiên đi lấy chân kinh đã gian nan.

Một anh iu designer bảo: "Gửi email request số, 2 hôm sau Data Analyst mới rep".

Vẫn anh iu đấy, nghỉ sang công ty khác thì hành lang thông thoáng hơn.

Có lần anh phân tích hành vi, kết luận và cải tiến tính năng.

Sếp anh gạt đi và nói: "Em phải tin vào trực giác của anh".
Lần này cầm số đi trình bày vẫn bị reject =)).

"Em phải tin vào trực giác của anh"

III. Vấn đề trong từng giai đoạn:

• Không biết
• Có nhận thức
• Bắt đầu thực hành
• Nhìn thấy kết quả ý nghĩa

Giai đoạn không biết:

Nhiều team phát triển sản phẩm không quyết định dựa trên số liệu.

Có quyết định dựa trên số liệu thì quản lý nắm, nhân sự không được tiếp cận với những con số đó.

UX Researcher này onboard công ty một thời gian xong nhận ra công ty chả có số má gì.

Điều này dẫn đến:

• Môi trường thiếu chính kiến và khó scale.
• Không biết cách khai thác dữ liệu sẵn có
• Các kết luận, nhận định dựa trên trực giác, kinh nghiệm người lãnh đạo. Thiếu khách quan.
• Nhân sự không biết thành quả công việc của mình như thế nào.

Giai đoạn có nhận thức:

Với các môi trường tân tiến hơn, nhân sự được tiếp xúc với phân tích số liệu sản phẩm và hành vi người dùng nhưng chưa nhiều và chưa thực sự hiểu. Hiểu ở đây phải rất rõ ràng:

1. Khi nào cần phân tích?
2. Phân tích số gì?
3. Số này là gì?
4. Collect bằng cách nào?
5. Thể hiện điều gì?
6. Kết hợp với dữ liệu định tính ra sao?
7. Kết luận?
8. Ảnh hưởng như thế nào đến sản phẩm?

Thu Hà - PM 5 năm kinh nghiệm chia sẻ:

"Công ty không có mindset làm data lắm, gần đây đã có mindset rồi nhưng action thì chưa ok. Cty ko có DA, có nhiều việc quan trọng hơn nên gần đây mới bắt đầu học."

Con vợ Thảo thì nói công ty mới mua Clevertap về làm event tracking, ngót nghét tỷ bạc / năm.
Trên hệ thống có 2 product dashboards. Số liệu sản phẩm hơi hẻo vì trước giờ chẳng tracking, insight cũng chẳng có nhiều.

Có cơ hội và công cụ hỗ trợ nhưng quy trình phát triển thì chưa theo kịp những gì công cụ mang lại!

Giai đoạn vận dụng & Thực hành:

• Nhận thức xong rồi thì phải biết cách thao tác.
• Đưa được số liệu vào quy trình tư duy, phân tích và cải tiến sản phẩm.

Bước này cũng nhiều ú ớ

• Ngụy thống kê: Số nói một đằng, các bạn kết luận 1 kiểu. Số trên bề nổi một ý nghĩa nhưng đào sâu hơn lại một ý nghĩa khác.
• Thiếu kỹ năng phân tích số liệu trên tracking tools: Nhiều tool miễn phí có trải nghiệm quá ô dề mà mấy tool dễ dùng thì quá đắt. Nhiều công ty chấp nhận dùng tool có UX tệ vì nó free.
• Chưa có điều kiện để làm các phân tích chuyên sâu: Đa số các bạn khi được phỏng vấn chia sẻ trên công ty chủ yếu các bạn phân tích số tổng, chưa pivot nó theo nhiều chiều hoặc nhìn chi tiết dữ liệu của từng nhóm người dùng.
• Phân tích rất nhiều số, nhưng không ra được kết luận gì cho sản phẩm.

Cứng nhắc và rập khuôn

Một CPO sau khi cho team PM, Design học về product metric và anaytical thinking chia sẻ: "Giờ mỗi khi PM request designer thay đổi giao diện, designer lại yêu cầu phải viết một Business Requirement tầm 2 trang: cải tiến này giúp thay đổi số gì và một số đầu múc khác?
Kể cả một thay đổi bé tẹo như sửa design cái nút. =))

Cá nhân tôi thấy designer cũng hơi cứng nhắc.

Quá nhiều số liệu không biết lấy cái nào?

Một chỉ số trên sản phẩm có rất nhiều ý nghĩa. Mỗi góc nhìn lại nói ra một ý nghĩa khác. Vẫn là chỉ số đó nhưng truyền vào đối số (Argument) khác sẽ trả về kết quả khác, rất linh hoạt. Kể mọi người nghe câu chuyện này:

Chị CMO này thì đỉnh: tạo, quản lý báo cáo business, product metrics đủ cả.
Tôi tiếp xúc và thấy tư duy, năng lực của chị là không bàn cãi.
Có lần chị làm phân tích: "Những tính năng mang lại conversion rate mua premium cao nhất".

Cách tiếp cận vấn đề rất thông minh, nhưng khi hỏi: "Mua premium bao lâu sau khi dùng tính năng sẽ được tính vào CR?" thì chị tịt.

Có số nhưng không biết làm gì cho sản phẩm:

Một Head of Data từng chia sẻ với tôi trong bootcamp: "Em nắm rất nhiều số của doanh nghiệp, nhưng đọc số xong thì không biết next step cho sản phẩm sẽ là gì". Bối cảnh là bạn chuyển dịch dần từ vị trí Head of Data sang quản lý sản phẩm.

Số có nhiều nhưng chỉ dựa vào nó để quyết định cho product là không đủ. Cần thêm nhiều tư duy sản phẩm, các dữ liệu định tính, và đôi khi - đợi đủ số mới quyết định cho sản phẩm là quá muộn.

Cũng khoai!.

IV: Học cái gì?

Để cải thiện kỹ năng phân tích số liệu, có 2 topics lớn cần học:

• Cách thu thập số liệu
• Cách phân tích và kết luận

Thu thập số liệu là quy trình định nghĩa và ghi nhận dữ liệu của người dùng & chỉ số sản phẩm để tạo ra data point cho việc phân tích về sau. Tạo form khảo sát, xác định đối tượng cần khảo sát đối với survey. Define event, user properties đối với Product Analytic đều là bước trong quy trình thu thập số liệu.

Ví dụ event tracking plan thực tế của sản phẩm Meezy (Meezy.vn) tại bootcamp.

Giai đoạn này bạn cần tìm hiểu:

• Data model & Infrastructure of event tracking: Cơ sở hạ tầng và cấu trúc dữ liệu của các công cụ ghi nhận số liệu.
• Tools & Limitation: Giới hạn của các công cụ là gì? Ví dụ nhiều tools giới hạn số lượng parameter truyền vào của từng event, có tool khác giới hạn độ dài tên event...
• Structure of an event tracking requirement: Hiểu về công cụ, bắt đầu tới cấu trúc của một tài liệu yêu cầu event gồm những gì?.
• Prioritizing events
• Data type
• Naming convention
• Distinct ID
• Trigger: Condition & Action
• Event & Event properties

Lưu ý của bước này: Nhiều hệ thống phức tạp, một user journey có thể lên tới cả trăm event cần xác định. Khi đó việc define event cần chính xác và nhất quán.

Giai đoạn phân tích bạn cần tìm hiểu:

1. Product Metric Frameworks
2. Break Down Metrics
3. How to build Product Dashboard

Product Dashboard của Trương Thu Hương (PO @ Bộ Công An) xây dựng trong bootcamp

Quy trình phân tích và đưa kết luận thì cần lưu ý đến Statistical Error / Fallacy.

Các lỗi thường gặp trong Product Analytic nói riêng và Statistical Error / Fallacy nói chung trong "Designing Digital Product per Stage and Metric".

Mong các con vợ yêu có thêm góc nhìn và biết thêm vài cái mới khi đọc bài viết này.

Thén kìuu.