Lemon's Tribe

Tạo dựng tư duy và kỹ năng phân tích dữ liệu cho Product Owner

Thử hình dung bạn là một Product Owner đứng trước quyết định quan trọng về tính năng tiếp theo cho sản phẩm của mình. Liệu bạn sẽ dựa vào trực giác và kinh nghiệm cá nhân, hay để những con số khách quan dẫn đường? Trong kỷ nguyên mà thuật toán đề xuất của Amazon đóng góp đến 35% doanh số mua hàng trên trang web1, hay Starbucks dùng phân tích dữ liệu địa điểm để quyết định mở quán mới ở đâu2, rõ ràng dữ liệu đã trở thành kim chỉ nam cho các quyết định sản phẩm. Việc ra quyết định dựa trên dữ liệu (data-driven decision-making) không còn là đặc quyền của các công ty lớn, mà đã trở thành yếu tố sống còn giúp Product Owner (PO) hiểu rõ người dùng, tối ưu sản phẩm và dẫn dắt đội ngũ đi đến thành công.

Vậy “tư duy hướng dữ liệu” thực sự là gì và vì sao nó đặc biệt quan trọng đối với Product Owner? Những kỹ năng phân tích dữ liệu nào một PO cần trang bị? Làm sao để xây dựng được tư duy và kỹ năng này từ con số 0? Và cần cảnh giác những rủi ro/bẫy nào khi làm việc với dữ liệu? Hãy cùng khám phá chi tiết, với những ví dụ thực tế trong bài viết lần này của Lemon’s Tribe nhé.

1. Data-driven mindset là gì và tại sao quan trọng?

Tư duy hướng dữ liệu (data-driven mindset) là cách suy nghĩ và ra quyết định dựa trên bằng chứng dữ liệu thay vì chỉ dựa vào cảm tính hoặc ý kiến chủ quan. Thay vì hỏi “Tôi nghĩ người dùng sẽ thích tính năng này”, một Product Owner với tư duy hướng dữ liệu sẽ hỏi “Dữ liệu cho thấy người dùng thực sự hành xử ra sao, và ta rút ra được gì từ đó?”. Điều này không có nghĩa phủ nhận vai trò của trực giác – trực giác có thể gợi ý ý tưởng, nhưng cần được kiểm chứng và định hướng bằng dữ liệu3.

Tại sao tư duy này lại quan trọng, đặc biệt với Product Owner? Trước hết, dữ liệu giúp giảm thiên kiến và phỏng đoán chủ quan trong quyết định. Một khảo sát của PwC với hơn 1.000 lãnh đạo cấp cao cho thấy các tổ chức ra quyết định dựa nhiều vào dữ liệu có khả năng cải thiện đáng kể việc ra quyết định gấp 3 lần so với những tổ chức ít dựa vào dữ liệu4. Nói cách khác, dữ liệu giúp quyết định của chúng ta chính xác và tự tin hơn. Đối với Product Owner – người chịu trách nhiệm tối đa hóa giá trị sản phẩm – những quyết định đúng đắn về tính năng, trải nghiệm người dùng, ưu tiên backlog… sẽ định đoạt sự thành bại của sản phẩm. Có dữ liệu hậu thuẫn, PO dễ dàng thuyết phục stakeholders hơn, vì các đề xuất của bạn dựa trên bằng chứng rõ ràng chứ không chỉ là quan điểm cá nhân.

Thêm vào đó, văn hóa doanh nghiệp đang dịch chuyển mạnh mẽ sang hướng data-driven. Harvard Business Review (2020) ghi nhận rằng kỹ năng làm việc với dữ liệu nay đã cần thiết cho hầu hết mọi vai trò trong tổ chức – công ty ngày càng cần nhân sự biết diễn giải dữ liệu, rút ra cái nhìn sâu sắc (insight) và đặt câu hỏi đúng từ dữ liệu5. Product Owner không phải ngoại lệ: bạn không thể “đơn độc” ra quyết định sản phẩm tách rời khỏi bối cảnh dữ liệu chung của doanh nghiệp. Thậm chí, Diễn đàn Kinh tế Thế giới (WEF) vào năm 2023 đã dự báo “tư duy phân tích” đang và sẽ là kỹ năng số một được doanh nghiệp tìm kiếm6. Nói cách khác, một Product Owner có tư duy và kỹ năng phân tích dữ liệu sẽ có lợi thế rất lớn trong công việc hiện tại cũng như con đường sự nghiệp tương lai.

Cuối cùng, tư duy hướng dữ liệu giúp Product Owner nhanh nhạy và chiến lược hơn. Thay vì ưu tiên tính năng dựa trên tiếng nói to nhất trong phòng họp, PO hướng dữ liệu sẽ ưu tiên dựa trên số liệu người dùng: tính năng nào tăng tương tác, bước nào trong funnel đang rớt nhiều khách nhất,… Nhờ đó, sản phẩm phát triển đúng cái người dùng cần, tránh lãng phí nguồn lực vào những ý tưởng không được đón nhận. Như chuyên gia Tomas Chamorro-Premuzic từng nhận xét trên HBR: nhiều tổ chức vẫn có xu hướng ưu tiên trực giác của HIPPO (Highest Paid Person’s Opinion) hơn dữ liệu, nhưng điều này đang dần thay đổi – chúng ta đã “hướng dữ liệu” hơn nhiều so với 20 năm trước, nhất là trong công việc7. Nếu các quyết định sản phẩm của bạn chưa dựa trên dữ liệu, rất có thể bạn đang tụt lại phía sau.

Tóm lại, data-driven mindset đối với Product Owner chính là kim chỉ nam giúp định hướng sản phẩm bằng sự thật khách quan. Nó quan trọng vì giúp PO ra quyết định sáng suốt, thuyết phục và hiệu quả hơn, đồng thời phát triển kỹ năng nghề nghiệp phù hợp với xu thế chung. Vậy làm thế nào để có được tư duy này? Hãy cùng đi tiếp với những kỹ năng phân tích dữ liệu cụ thể nào mà một Product Owner cần trang bị ở phần dưới nhé.

2. Kỹ năng phân tích dữ liệu bao gồm những gì?

“Kỹ năng phân tích dữ liệu” nghe có vẻ rộng, nhưng chúng ta có thể chia nó ra thành một số nhóm năng lực cụ thể mà Product Owner nên có. Dưới đây là những thành tố chính:

  • Hiểu biết cơ bản về dữ liệu và thống kê: Trước tiên, một PO cần có data literacy – hiểu những khái niệm cơ bản về dữ liệu. Điều này bao gồm việc biết các loại dữ liệu khác nhau, nguồn gốc dữ liệu, cách thu thập, cũng như các khái niệm thống kê nền tảng (trung bình, phân phối, phần trăm, v.v.)8 9. Bạn không cần trở thành một nhà khoa học dữ liệu, nhưng nên nắm được sự khác biệt giữa các loại phân tích dữ liệu phổ biến: ví dụ phân tích mô tả (chuyện gì đã xảy ra), phân tích chẩn đoán (tại sao lại xảy ra) đến phân tích dự báo (dự báo điều gì có thể xảy ra) và phân tích đề xuất (đề xuất hành động nên làm)10. Hiểu được những nguyên lý này giúp PO đặt đúng kỳ vọng khi làm việc với dữ liệu – biết được mình cần tìm câu trả lời loại nào và sử dụng phương pháp phân tích nào là phù hợp.
  • Tư duy phản biện và đặt câu hỏi đúng: Phân tích dữ liệu không chỉ là tính toán, mà quan trọng là biết hỏi câu hỏi nào và nghi vấn những gì dữ liệu thể hiện. Kỹ năng này đòi hỏi PO phải có tư duy phản biện (critical thinking) – không vội tin ngay kết quả bề mặt, mà luôn tự hỏi “Vì sao số liệu lại như vậy?”, “Có cách giải thích nào khác không?”. HBR từng nhấn mạnh các công ty cần nhân sự có khả năng diễn giải dữ liệu thành insight và đặt ra những câu hỏi phù hợp từ dữ liệu thu thập được. Ví dụ, nếu dữ liệu cho thấy doanh thu tăng sau một chiến dịch, người có tư duy phản biện sẽ tự hỏi: Do chiến dịch thật sự hiệu quả hay do yếu tố mùa vụ? Có yếu tố nhiễu nào đang tác động không? Việc đặt câu hỏi đúng giúp PO đào sâu đến gốc rễ vấn đề và tránh được kết luận sai lầm.
  • Kỹ năng thu thập và làm sạch dữ liệu: Trước khi phân tích, dữ liệu đầu vào phải đủ tốt. Một Product Owner giỏi phân tích cần hiểu cách thu thập dữ liệu phù hợp – biết xác định chỉ số KPIs nào cần theo dõi cho mục tiêu sản phẩm, biết tận dụng các công cụ có sẵn (Google Analytics, Mixpanel, cơ sở dữ liệu nội bộ…) để lấy dữ liệu. Bên cạnh đó là kỹ năng làm sạch và kiểm tra dữ liệu (data wrangling): đảm bảo dữ liệu không bị sai lệch do trùng lắp, thiếu giá trị hay lỗi thu thập. Theo HBS, trong nhiều tổ chức, dữ liệu thô thường được làm sạch qua các thuật toán hoặc công cụ, nhưng bản thân mỗi nhân viên liên quan đến dữ liệu cũng phải biết tự rà soát để dữ liệu “đạt chuẩn” trước khi đem phân tích. Dữ liệu giống như nguyên liệu đầu vào – nếu bẩn hoặc không đúng mục tiêu, kết quả phân tích sẽ vô nghĩa (garbage in, garbage out).11
  • Kỹ năng phân tích và diễn giải số liệu: Đây chính là năng lực “đọc vị” được những gì dữ liệu muốn nói. Product Owner cần biết cách sử dụng các phương pháp phân tích phù hợp (từ đơn giản như so sánh, tính tỷ lệ, đến phức tạp hơn như phân tích tương quan, hồi quy, kiểm định A/B…). Bạn cũng cần hiểu về ý nghĩa thống kê: ví dụ khái niệm độ lệch chuẩn, khoảng tin cậy, hay mức ý nghĩa p-value để đánh giá kết quả thử nghiệm có đáng tin cậy không. Quan trọng không kém, PO phải nhận thức được sự khác biệt giữa tương quan và nhân quả – hai biến số cùng tăng/giảm chưa chắc biến này gây ra biến kia, có thể cả hai đều do một yếu tố khác chi phối. Nhận thức điều này giúp ta tránh những kết luận ngụy nhân quả (như nghĩ rằng việc tăng ngân sách quảng cáo gây ra tăng trưởng, trong khi thực tế cả hai có thể do mùa cao điểm tác động).12
  • Sử dụng công cụ phân tích và trực quan hóa dữ liệu: Trong thời đại ngày nay, làm việc với dữ liệu đồng nghĩa với thành thạo một số công cụ hỗ trợ. Với Product Owner, bạn không nhất thiết phải biết những ngôn ngữ lập trình phức tạp, nhưng nên thông thạo các công cụ trực quan hóa và phân tích cơ bản. Điều này có thể đơn giản là dùng Excel hoặc Google Sheets để xử lý dữ liệu, tạo bảng pivot, cho đến sử dụng các công cụ BI (Business Intelligence) như Tableau, PowerBI, hoặc Google Data Studio để tạo dashboard theo dõi sản phẩm. Trực quan hóa dữ liệu là một phần rất quan trọng: biểu đồ, đồ thị giúp chúng ta “nhìn ra” xu hướng và mô hình một cách nhanh chóng thay vì nhìn chằm chằm vào bảng số khô khan13. Kỹ năng này giúp PO kể câu chuyện dữ liệu một cách thuyết phục đến đội ngũ và các bên liên quan – ví dụ, thay vì chỉ nói “tỷ lệ chuyển đổi giảm 5%”, bạn có thể trình bày biểu đồ hành vi người dùng cho thấy rõ bước nào trong quy trình khiến người dùng rớt nhiều nhất, dẫn đến hành động cụ thể cần làm. Tuy nhiên, cũng cần lưu ý là với mỗi loại dữ liệu thì nên chọn biểu đồ tương ứng thì mới biểu đạt được ý nghĩa của số liệu đó một cách hiệu quả. Ví dụ đơn giản như nói về tỷ trọng các kênh liên hệ hỗ trợ của người dùng đến doanh nghiệp, người ta sẽ thường dùng sử dụng biểu đồ tròn (pie chart) để biểu diễn thay vì sử dụng các loại biểu đồ khác.
  • Kỹ năng “data storytelling” và giao tiếp: Cuối cùng, dữ liệu sẽ vô nghĩa nếu chúng ta không truyền đạt được insight cho người khác. Product Owner cần biết diễn giải kết quả phân tích thành câu chuyện dễ hiểu và gắn với mục tiêu kinh doanh. Điều này đòi hỏi khả năng giao tiếp tốt, cả nói lẫn viết, để trình bày luận điểm dựa trên dữ liệu một cách mạch lạc. Ví dụ, cùng một dữ liệu nhưng cách bạn trình bày cho team kỹ thuật sẽ khác với khi nói chuyện với lãnh đạo cấp cao. PO giỏi phải biến insight thành ngôn ngữ mà khán giả của mình hiểu và bị thuyết phục hành động (dù đó là ưu tiên sửa một lỗi UX hay đầu tư vào một tính năng mới). Kỹ năng này mang tính “mềm” hơn, nhưng không thể thiếu để biến phân tích dữ liệu thành kết quả thực tế.

Tựu trung, kỹ năng phân tích dữ liệu cho Product Owner là một tập hợp đa diện, từ hiểu biết nền tảng về dữ liệu và thống kê, khả năng tư duy phản biện, thành thạo công cụ, đến giao tiếp hiệu quả. Không phải ai sinh ra cũng có đủ những kỹ năng này, nhưng chúng ta hoàn toàn có thể rèn luyện và thành thạo nếu làm đúng cách và chịu khó.

3. Cách xây dựng kỹ năng phân tích dữ liệu và tư duy hướng dữ liệu

Chuyển đổi sang một mindset hướng dữ liệu có thể là thách thức, đặc biệt nếu xuất phát điểm của bạn thiên về trực giác hơn là con số. Tuy nhiên, mọi hành trình lớn đều bắt đầu từ những bước nhỏ. Dưới đây là một số cách tiếp cận thực tiễn giúp bạn xây dựng kỹ năng phân tích dữ liệu và tư duy data-driven cho mình:

  • Chủ động tập “suy nghĩ bằng dữ liệu” trong công việc hàng ngày: Hãy biến dữ liệu thành một phần trong mọi quyết định nhỏ của bạn. Luyện thói quen tìm kiếm số liệu và mẫu hình (pattern) trong các tình huống hàng ngày. Chẳng hạn, khi xem báo cáo tuần về sản phẩm, đừng chỉ lướt qua con số – hãy tự hỏi xu hướng đang lên hay xuống, có điểm bất thường nào không, và tại sao. Ngay cả ngoài đời thường, bạn cũng có thể thực hành: Đứng xếp hàng mua cà phê, hãy thử quan sát xem bao nhiêu người gọi đồ mang đi so với uống tại chỗ, và phán đoán lý do. Việc rèn luyện bộ não luôn tò mò tìm kiếm dữ liệu và giải thích ý nghĩa đằng sau nó sẽ giúp bạn dần dần hình thành tư duy phân tích một cách tự nhiên. Như HBS gợi ý, hãy cố gắng tìm “pattern” và diễn giải chúng bất cứ khi nào có thể – ban đầu có thể chỉ là những quan sát nhỏ, nhưng lâu dần bạn sẽ nhạy bén hơn rất nhiều trong việc nhìn ra câu chuyện ẩn trong dữ liệu.14
  • Gắn mỗi quyết định với một cơ sở dữ liệu (Tie decisions to data): Mỗi khi phải ra quyết định sản phẩm – từ lớn như chọn tính năng cho quý tới, đến nhỏ như thay đổi CTA trên màn hình – hãy tập thói quen đòi hỏi dữ liệu hỗ trợ. Nếu có sẵn dữ liệu, sử dụng nó: ví dụ quyết định làm tính năng A vì 70% khách hàng trong khảo sát nói họ cần. Nếu chưa có dữ liệu, hãy nghĩ cách thu thập: chạy một khảo sát nhỏ, xem số liệu Google Analytics, hoặc làm một thử nghiệm A/B. Quan trọng là tạo phản xạ không vội vã chốt điều gì dựa trên trực giác khi chưa cân nhắc dữ liệu liên quan. Khi bạn luôn “buộc” mình phải tìm dữ liệu hỗ trợ, dần dần mọi quyết định sẽ tự động có căn cứ rõ ràng. Điều này cũng giúp bạn nhìn nhận lại các quyết định quá khứ dưới lăng kính dữ liệu: cái nào thành công? tại sao? Từ đó rút kinh nghiệm cho tương lai.15
  • Học hỏi kiến thức và công cụ phân tích một cách có hệ thống: Nếu bạn cảm thấy thiếu nền tảng về phân tích dữ liệu, đừng ngại đầu tư vào học tập. Ngày nay có rất nhiều khóa học online về data analytics hoặc business analytics cho người không chuyên từ các trường danh tiếng (MIT, Harvard Online, Coursera…). Những khóa này thường cung cấp kiến thức nền tảng về thống kê, các phương pháp phân tích, cũng như hướng dẫn dùng công cụ. HBR gợi ý rằng chỉ cần tham gia một khóa học trực tuyến phù hợp, bạn có thể xây dựng nền tảng cần thiết để tự tin làm việc với dữ liệu trong kinh doanh. Nếu không có điều kiện học bài bản, hãy tận dụng nguồn lực xung quanh: hỏi đồng nghiệp trong team Data, đọc sách hoặc blog uy tín về phân tích (chẳng hạn như blog của trang Harvard Business Review, McKinsey, v.v.). Việc học này không chỉ một lần – hãy coi đó là quá trình học tập liên tục. Công nghệ và công cụ dữ liệu luôn tiến hóa, nên PO cũng cần liên tục cập nhật để không bị lạc hậu.16
  • Thực hành trên dự án nhỏ và tích lũy kinh nghiệm thực tế: Không gì thay thế được kinh nghiệm thực hành. Hãy chủ động xin tham gia vào những dự án trong công ty có liên quan đến phân tích dữ liệu, hoặc tự đặt ra một dự án phụ cho mình. Ví dụ, bạn có thể bắt đầu bằng cách xây dựng một dashboard đơn giản theo dõi một vài chỉ số chính của sản phẩm hàng ngày. Hoặc đề xuất chạy một thử nghiệm A/B nhỏ trên giao diện ứng dụng – chẳng hạn thay đổi nội dung của CTA – rồi tự mình phân tích kết quả thử nghiệm đó. Trong quá trình này, bạn sẽ học được cách chọn thước đo thành công, cách thu thập dữ liệu thử nghiệm, và cách xác định liệu kết quả có ý nghĩa hay không. Đừng lo nếu ban đầu kết quả không rõ ràng; điều quan trọng là bạn đang rèn luyện quy trình tư duy thực nghiệm – đưa ra giả thuyết, thu thập dữ liệu, phân tích, kết luận, và lặp lại. Mỗi lần thực hành như vậy, kỹ năng phân tích của bạn sẽ sắc bén hơn và sự tự tin với dữ liệu cũng tăng lên.
  • Xây dựng văn hóa dữ liệu trong đội nhóm: Product Owner thường đứng ở giao điểm giữa các bộ phận kỹ thuật, thiết kế, kinh doanh… Bạn có thể tận dụng vị trí này để khuyến khích cả team cùng hướng đến dữ liệu. Hãy bắt đầu từ những việc nhỏ: trong các buổi họp sprint review, bổ sung phần cập nhật số liệu sản phẩm (ví dụ: người dùng hoạt động tuần qua, kết quả của một thử nghiệm vừa chạy). Khi mọi người đưa ra ý kiến về tính năng, tập thói quen cùng nhau xem dữ liệu trước khi kết luận. Bạn cũng có thể đóng vai trò “data champion” – người truyền cảm hứng cho team về ý nghĩa của dữ liệu. Chẳng hạn, chia sẻ một câu chuyện thành công nhờ dữ liệu (case study) trong ngành với team, hoặc hướng dẫn nhanh cho team cách đọc một biểu đồ phân tích người dùng. Josh Bersin – một chuyên gia về nhân sự – từng nhận định: kỹ năng dữ liệu muốn lan tỏa cần bắt đầu từ chính con người (people) và văn hóa trong tổ chức. Khi cả nhóm cùng coi trọng dữ liệu, bạn sẽ dễ dàng hơn rất nhiều trong việc triển khai các quyết định data-driven, đồng thời bản thân bạn cũng học hỏi nhanh hơn nhờ có đồng đội hỗ trợ.17
  • Kiên trì và điều chỉnh từng bước một: Xây dựng kỹ năng phân tích dữ liệu và tư duy hướng dữ liệu là một chặng đường dài, không thể “một sớm một chiều”. Lời khuyên ở đây là bắt đầu nhỏ, nhưng bắt đầu ngay, và liên tục điều chỉnh. HBS gợi ý rằng bạn không cần phải thay đổi tất-cả-hoặc-không-gì-cả (all-or-nothing) để trở nên data-driven; thay vào đó, hãy khởi đầu từ những dự án nhỏ, đo lường hiệu quả, ghi chép lại bài học và cải tiến dần dần18. Ví dụ, tháng này bạn tập trung học cách dùng Google Analytics cho website, tháng sau thử sức với một bài toán phân tích cụ thể. Mỗi bước nhỏ sẽ tích lũy thành tiến bộ lớn theo thời gian. Quan trọng là duy trì tính nhất quán: luôn tò mò, luôn học hỏi, và luôn đón nhận phản hồi từ dữ liệu một cách cầu thị. Sau mỗi quý, hãy nhìn lại: quyết định nào của mình thành công? Có dựa trên dữ liệu không? Nếu chưa, lần tới có thể cải thiện ra sao?

Bằng cách kết hợp những bước trên, dần dần bạn sẽ nhận thấy mình tự tin hơn hẳn với dữ liệu. Từ chỗ e ngại các con số, bạn sẽ bắt đầu “nghĩ bằng dữ liệu” một cách tự nhiên, và lan tỏa tinh thần đó đến những người xung quanh. Tư duy hướng dữ liệu không phải là loại bỏ hoàn toàn trực giác sáng tạo – mà là bổ trợ cho sáng tạo, để những ý tưởng bay bổng đều có “dây neo” giữ chặt với thực tế. Khi đã trang bị kỹ năng và tư duy này, Product Owner có thể cân bằng được giữa đổi mới sản phẩm táo bạo và kiểm chứng thực tế, giữa tầm nhìn dài hạn và kết quả ngắn hạn dựa trên dữ liệu.

4. Những rủi ro/bẫy khi phân tích dữ liệu

Phân tích dữ liệu giống như một con dao sắc bén: nếu sử dụng thuần thục, nó giúp ta cắt xuyên màn sương mù để thấy rõ sự thật; nhưng nếu không cẩn thận, chính lưỡi dao đó có thể làm ta tổn thương hoặc lạc hướng. Dưới đây là một số rủi ro và “bẫy” phổ biến mà Product Owner cần lưu ý khi làm việc với dữ liệu:

  • Bẫy “thước đo trở thành mục tiêu” (Goodhart’s Law): Nhà kinh tế Charles Goodhart đã cảnh báo: “When a measure becomes a target, it ceases to be a good measure” – tạm dịch: khi một chỉ số bị biến thành mục tiêu, nó không còn là thước đo tốt nữa19. Bẫy này xảy ra khi chúng ta quá chú trọng vào một KPI đến mức tìm mọi cách đẩy nó lên, mà quên mất ý nghĩa thực sự đằng sau. Ví dụ kinh điển: một Product Owner coi số lượng người dùng hoạt động hàng ngày (DAU) là KPI quan trọng nhất. Để tăng DAU, team quyết định gửi thật nhiều thông báo (push notifications) để lôi kéo người dùng mở app mỗi ngày. Kết quả: DAU tăng thật, nhưng liệu sản phẩm có cải thiện giá trị cho người dùng? Hay người dùng chỉ mở app cho có rồi thoát? Goodhart’s Law nhắc chúng ta rằng hầu hết chỉ số chỉ là proxy cho mục tiêu cuối (DAU chỉ là proxy cho “giá trị thực người dùng nhận được mỗi ngày”). Khi tập trung quá mức vào chỉ số, ta có thể đánh mất mục tiêu gốc. Vì vậy, PO cần luôn tự hỏi: việc tăng chỉ số X có thực sự đồng nghĩa với thành công không? Chúng ta có đang “ăn mòn” giá trị dài hạn để đạt được con số ngắn hạn hay không? Luôn giữ cái nhìn toàn cảnh sẽ giúp bạn tránh được bẫy này.
  • Nhầm lẫn tương quan – nhân quả và các thiên kiến phân tích: Đây là rủi ro rất phổ biến khi diễn giải dữ liệu. Con người chúng ta có xu hướng tìm kiếm câu chuyện trong các con số, và đôi khi thấy mối liên hệ nhân quả ở nơi không hề có. Ví dụ, dữ liệu cho thấy trong tháng mà chiến dịch marketing chạy rầm rộ thì doanh số bán hàng tăng vọt. Tuy nhiên, cũng tháng đó đối thủ cạnh tranh chính của công ty lại gặp sự cố và tạm ngưng kinh doanh. Vậy nguyên nhân tăng doanh số là do marketing tốt hay do đối thủ vắng mặt? Nếu chỉ nhìn tương quan, ta dễ dàng gán nhầm công lao cho chiến dịch marketing. Để tránh bẫy này, Product Owner cần nhắc mình rằng tương quan không đồng nghĩa với nhân quả, và luôn cảnh giác với các thiên kiến nhận thức20. Một ví dụ thiên kiến là confirmation bias – xu hướng chỉ chú ý dữ liệu nào ủng hộ giả thuyết ban đầu của ta và bỏ qua dữ liệu mâu thuẫn. Chẳng hạn, bạn tin rằng tính năng mới rất hay, nên chỉ chăm chú tìm số liệu tích cực sau khi ra mắt tính năng, mà lờ đi những chỉ báo cho thấy người dùng không hề tương tác. Để khắc phục, hãy cố gắng tìm kiếm cả bằng chứng trái chiều và nhờ người khác trong đội phản biện lại phân tích của bạn. Việc thường xuyên tự hỏi “Liệu mình có đang thiên vị kết quả nào không?” sẽ giúp bạn trở thành một nhà phân tích công tâm và chính xác hơn.
  • “Phân tích tê liệt” (analysis paralysis) – chậm trễ vì quá cầu toàn: Mặt trái của văn hóa hướng dữ liệu là đôi khi quyết định bị đình trệ vì chờ dữ liệu. Một Product Owner quá cẩn trọng có thể nghĩ: “Chúng ta chưa quyết định được đâu, đợi thêm dữ liệu đã”, và cứ thế trì hoãn. Trong khi đó, thị trường thì không chờ đợi – cơ hội có thể qua đi hoặc đối thủ đã nhanh chân nắm lấy. Thực tế, dữ liệu nhiều khi không hoàn hảo hoặc không sẵn có 100%. Theo một chuyên gia, dù các phương pháp A/B test hay phân tích định lượng có thể cho kết quả “chính xác” hơn, nhưng trong một thế giới mà tốc độ ra mắt và đổi mới liên tục quyết định kẻ thắng người thua, việc quá câu nệ chờ đợi dữ liệu hoàn hảo có thể khiến bạn bỏ lỡ thời cơ21. Nói cách khác, đừng để “sự hoàn hảo của phân tích” cản trở “sự hiệu quả của hành động”. Giải pháp là xác định mức đủ (good enough): khi dữ liệu đã đủ để thấy xu hướng chính, hãy mạnh dạn ra quyết định. Bạn có thể bổ sung dữ liệu và điều chỉnh sau, nhưng thời gian là một loại chi phí cơ hội. Như người ta nói, “hoàn thành còn hơn hoàn hảo” – đưa ra quyết định dựa trên dữ liệu hiện có (dù chưa đầy đủ 100%) thường tốt hơn là bất động chờ đợi.
  • Chỉ tập trung cải tiến nhỏ, bỏ quên những đột phá lớn: Phân tích dữ liệu rất giỏi trong việc chỉ ra những vấn đề hiện tại và tối ưu cục bộ, nhưng nó có thể bỏ sót cơ hội đổi mới đột phá. Lý do là vì các phân tích thường dựa trên dữ liệu quá khứ – chúng cho ta biết cái gì đã xảy ra và đang xảy ra, còn những ý tưởng hoàn toàn mới chưa triển khai thì… chưa có dữ liệu để phân tích. Điều này dễ dẫn đến việc Product Owner sa vào lối mòn cải tiến nhỏ (incrementalism). Ví dụ, bạn liên tục thử nghiệm các biến thể màu sắc, vị trí nút, text nhỏ để tăng 1-2% conversion (Google từng nổi tiếng thử nghiệm 42 sắc độ màu xanh chỉ để tối ưu tỷ lệ click22). Những cải tiến nhỏ này cộng dồn có thể tạo nên cải thiện đáng kể – nhưng chúng cũng có thể dẫn sản phẩm đến điểm cực đại cục bộ (local maximum), nơi mà mọi tối ưu nhỏ lẻ đã cạn kiệt hiệu quả23. Trong trạng thái đó, một ý tưởng đột phá (ví dụ giao diện hoàn toàn mới) ban đầu có thể cho kết quả kém hơn chút so với phiên bản đã được “tối ưu hóa hoàn toàn” hiện tại, khiến dữ liệu đánh lừa bạn rằng ý tưởng mới tệ hơn. Nếu chỉ chăm chăm nhìn vào dữ liệu ngắn hạn, bạn có thể vô tình kìm hãm sự sáng tạo táo bạo. Cách hóa giải là kết hợp giữa tầm nhìn và dữ liệu: dùng dữ liệu để tối ưu những gì đang có, nhưng thỉnh thoảng cũng dám thử nghiệm những ý tưởng lớn (và chấp nhận dữ liệu ban đầu có thể chưa đẹp mắt). Như vậy, bạn vừa gặt hái “trái thấp dễ hái” từ dữ liệu, vừa không bỏ lỡ khu rừng ý tưởng phía xa.24
  • Dữ liệu sai lệch hoặc không đầy đủ: Một bẫy khác nghe có vẻ đơn giản nhưng rất nguy hiểm: tin tưởng tuyệt đối vào dữ liệu mà không kiểm chứng bối cảnh. Dữ liệu có thể bị sai lệch do lỗi thu thập, do mẫu chưa đại diện, hoặc thậm chí do… con người cố tình tô vẽ. Nếu Product Owner nhận được một báo cáo số liệu, hãy luôn nghĩ “Chất lượng dữ liệu này ra sao?”. Ví dụ, số liệu về tỷ lệ hài lòng khách hàng có thể rất cao, nhưng có thể vì chỉ những khách hàng hài lòng mới phản hồi khảo sát (bias do đối tượng tự chọn). Hoặc dữ liệu hành vi người dùng cho thấy một tính năng hầu như không ai dùng – có thể không phải vì nó không hữu ích, mà vì người dùng không tìm thấy nó trong menu rối rắm. Dữ liệu không bao giờ tồn tại trong chân không; nó gắn liền với cách thu thập và ngữ cảnh thực tế. Do đó, Product Owner cần đào sâu một lớp: kiểm tra cách thu thập, so sánh chéo nhiều nguồn dữ liệu nếu có thể, và kết hợp định lượng với định tính (phỏng vấn, feedback trực tiếp) để có bức tranh đầy đủ. Đừng để những con số hào nhoáng làm bạn lóa mắt, hãy đảm bảo chúng thực sự phản ánh đúng thực tế.

Nhìn chung, làm bạn với dữ liệu đòi hỏi sự tỉnh táo và khiêm tốn. Tỉnh táo để không bị cuốn theo những ảo ảnh thống kê hay mục tiêu số liệu hão huyền; khiêm tốn để thừa nhận dữ liệu cũng có hạn chế và luôn có thể sai. Một Product Owner xuất sắc không chỉ biết dùng dữ liệu để chứng minh luận điểm, mà còn biết hoài nghi chính những dữ liệu đó, luôn tự kiểm tra và sẵn sàng thay đổi kết luận khi có bằng chứng mới đáng tin cậy hơn.

5. Tạm kết

Trong hành trình trở thành một Product Owner cứng, tư duy hướng dữ liệu và kỹ năng phân tích dữ liệu chính là người đồng hành đáng giá giúp bạn đưa ra quyết định sáng suốt và tự tin. Như chúng ta đã thảo luận, tư duy này không làm lu mờ khả năng sáng tạo hay tầm nhìn sản phẩm của bạn – ngược lại, nó cung cấp một nền tảng vững chắc để những ý tưởng bay bổng được hiện thực hóa một cách hiệu quả và thành công. Khi PO biết lắng nghe câu chuyện của những con số, bạn có thể thấu hiểu khách hàng sâu sắc hơn, phản ứng linh hoạt trước những thay đổi của thị trường, và dẫn dắt đội ngũ bằng sự thuyết phục dựa trên bằng chứng thay vì áp đặt chủ quan.

Tuy nhiên, xây dựng tư duy và kỹ năng này đòi hỏi thời gian và sự kiên trì. Hãy bắt đầu ngay từ những bước nhỏ: ví dụ, tuần này hãy chọn một quyết định nhỏ trong công việc và thử áp dụng dữ liệu để ra quyết định đó. Hoặc thử khám phá một công cụ phân tích mới và sử dụng nó để tìm insight cho sản phẩm của bạn. Mỗi lần như vậy, bạn đang tiến một bước trên con đường trở thành Product Owner dẫn dắt bằng dữ liệu. Cũng đừng quên rằng dữ liệu không phải là cây đũa thần vạn năng. Sự nhạy bén và kinh nghiệm của bạn vẫn rất quan trọng. Tư duy data-driven không có nghĩa là “mù quáng chạy theo dữ liệu”, mà là biết kết hợp dữ liệu với trực giác một cách hài hòa. Hãy coi dữ liệu như người bạn đồng hành: người bạn này đôi khi sẽ mâu thuẫn với linh cảm của bạn, nhưng chính sự mâu thuẫn đó giúp bạn nhìn nhận lại vấn đề đa chiều và đưa ra quyết định đúng đắn hơn.

Kết thúc bài viết, hy vọng rằng bạn đã có cái nhìn rõ ràng hơn về tầm quan trọng của việc tạo dựng tư duy và kỹ năng phân tích dữ liệu cho Product Owner, cũng như những bước cụ thể để bắt đầu. Hãy nhớ lời khuyên “lấy dữ liệu làm kim chỉ nam” – và quan trọng hơn, hãy hành động. Thế giới sản phẩm số đang biến đổi từng ngày nhờ dữ liệu, và bạn chắc chắn không muốn bị bỏ lại phía sau. Bằng việc trang bị cho mình khả năng hiểu và ứng dụng dữ liệu, bạn đang trao cho bản thân một lợi thế cạnh tranh lớn, đồng thời mở cánh cửa đến những cơ hội và thành công mới trong sự nghiệp Product Owner của mình. Chúc bạn sớm gặt hái “trái ngọt” trên hành trình trở thành một Product Owner với tư duy dữ liệu sắc bén và đầy cảm hứng!

Nguồn tham khảo

  1. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=Amazon%20uses%20data%20to%20decide,to%20the%20company%E2%80%99s%20recommendation%20system ↩︎
  2. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=Starbucks%20now%20partners%20with%20a,taking%20on%20a%20new%20investment ↩︎
  3. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=Though%20intuition%20can%20be%20a,around%20a%20mere%20gut%20feeling ↩︎
  4. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=While%20intuition%20can%20provide%20a,who%20rely%20less%20on%20data ↩︎
  5. https://hbr.org/2020/02/building-a-data-driven-culture-from-the-ground-up ↩︎
  6. https://www.fastcompany.com/91108088/analytical-thinking ↩︎
  7. https://hbr.org/insight-center/the-data-driven-mindset#:~:text=Are%20You%20Still%20Prioritizing%20Intuition,Over%20Data ↩︎
  8. https://online.hbs.edu/blog/post/data-literacy#:~:text=What%20Is%20Data%20Literacy%3F ↩︎
  9. https://sobrief.com/books/hbr-guide-to-data-analytics-basics-for-managers#:~:text=Key%20analytical%20concepts,the%20right%20questions%20about%20analyses ↩︎
  10. https://online.hbs.edu/blog/post/data-literacy#:~:text=There%20several%20types%20of%20data,of%20the%20most%20common%20are ↩︎
  11. https://online.hbs.edu/blog/post/data-literacy#:~:text=Data%20wrangling%20is%20the%20act,and%20filling%20gaps%20in%20data ↩︎
  12. https://sobrief.com/books/hbr-guide-to-data-analytics-basics-for-managers#:~:text=Key%20analytical%20concepts,the%20right%20questions%20about%20analyses ↩︎
  13. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=3,the%20Data ↩︎
  14. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=1 ↩︎
  15. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=2,to%20the%20Data ↩︎
  16. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=4 ↩︎
  17. https://journals.sagepub.com/doi/full/10.1177/09610006241246789#:~:text=One%20common%20challenge%20identified%20among,a%20lack%20of%20awareness ↩︎
  18. https://online.hbs.edu/blog/post/data-driven-decision-making#:~:text=While%20there%20are%20many%20benefits,and%20thrive%20at%20your%20organization ↩︎
  19. https://www.productfocus.com/why-product-managers-should-not-be-data-driven/#:~:text=When%20a%20measure%20becomes%20a,to%20be%20a%20good%20measure ↩︎
  20. https://sobrief.com/books/hbr-guide-to-data-analytics-basics-for-managers#:~:text=Key%20analytical%20concepts,the%20right%20questions%20about%20analyses ↩︎
  21. https://www.productfocus.com/why-product-managers-should-not-be-data-driven/#:~:text=Do%20A%2FB%20testing%20and%20other,any%20incumbent%20who%20gets%20too ↩︎
  22. https://www.productfocus.com/why-product-managers-should-not-be-data-driven/#:~:text=Another%20issue%20with%20the%20data,we%20shipped%20a%20winning%20feature ↩︎
  23. https://www.productfocus.com/why-product-managers-should-not-be-data-driven/#:~:text=Another%20issue%20with%20the%20data,we%20shipped%20a%20winning%20feature ↩︎
  24. https://www.productfocus.com/why-product-managers-should-not-be-data-driven/#:~:text=Secondly%2C%20these%20small%20incremental%20wins,hard%20data%2C%20it%20often%20won%E2%80%99t ↩︎

trachanh71

One response to “Tạo dựng tư duy và kỹ năng phân tích dữ liệu cho Product Owner”

  1. UX “đủ tốt” liệu có đủ tốt? – Local Maxima in UX – Lemon's Tribe

    […] Tribe cũng từng phân tích về cạm bẫy của phân tích dữ liệu trong bài viết Tạo dựng tư duy và kỹ năng phân tích dữ liệu cho Product Owner, bạn có thể đọc thêm để tham […]

Leave a Reply