Posted by Có thể nói công việc của PM và PO là quá trình liên tục đưa ra các quyết định từ nhỏ đến lớn. Từ quyết định phân tích yêu cầu của khách hàng và thị trường, quyết định vision và roadmap của sản phẩm, quyết định quy mô (scope) của sản phẩm cùng với team lập trình và thiết kế,… Ở mỗi giai đoạn, họ phải liên tục đưa ra quyết định một mình hoặc cùng với những người có chuyên môn ở những mảng khác.
Một PM phải làm gì vào thời điểm phải đưa ra một quyết định mang tính chiến lược cần sự lý trí đến gần? Quyết định được đưa ra khi đó phải hợp lý và mang tính logic.
Data-driven decision (quyết định dựa vào data) thường được xem là tiêu chuẩn cho một quyết định mà người làm Product cần đưa ra. Một data-driven decision thường được tạo ra sau một quy trình như sau: PM sử dụng lượng data khổng lồ thu được từ những hoạt động hằng ngày của Product và người dùng để tìm kiếm, đọc các pattern, lập hàng loạt các chart hoành tráng để khiến các dữ liệu thô trở nên có sức sống và có ý nghĩa. Cuối cùng đem kết quả đó áp dụng vào Product để tạo giá trị cho Product.
Chúng ta cố gắng giải thích một quyết định dựa vào data hợp lý như thế nào và mang tính logic ra sao. Tuy nhiên, quyết định tuy dựa trên data nhưng vẫn được thực hiện bởi con người và không thể tránh những lỗi rất con người như thiên kiến (bias) và ngụy biện (fallacy).
Hôm nay tôi muốn cùng các bạn tìm hiểu về 2 loại thiên kiến/định kiến nhận thức tiêu biểu nhất mà một PM phải luôn thận trọng cảnh giác, tránh mắc phải trong quá trình thực hiện nghiệp vụ. Đồng thời chia sẻ một số phương pháp để có thể đưa ra một quyết định có logic, khách quan, không bị ảnh hưởng của các thiên kiến/định kiến này.
A. Thiên kiến xác nhận (Confirmation Bias):
Thiên kiến xác nhận (Confirmation Bias) là thiên kiến thường được nhắc đến nhiều nhất khi đề cập về thiên kiến nhận thức. Thiên kiến xác nhận mang khuynh hướng chỉ chấp nhận thông tin bản thân cho là đúng, bỏ qua các thông tin khác với quan điểm của bản thân, chỉ nghe những điều bản thân muốn nghe. Khi bị phát hiện điểm sai hoặc bị chỉ trích trong quan điểm, thay vì thừa nhận, người mang thiên kiến xác nhận sẽ gấp rút đi tìm tài liệu để chứng minh ý kiến của mình là đúng, với họ sự thật không hề quan trọng.
Thiên kiến một PM thường mắc phải chính là quan điểm bản thân có năng lực làm việc mang tính chuyên môn nhất trong team. Hay nói cách khác chính là quan điểm “không ai bằng tôi ở lĩnh vực này”. Vì vậy, một khi PM nghĩ mình được nâng cấp lên bậc senior hoặc expert, thay vì thực hiện test thì họ lại bắt tay vào tìm kiếm tài liệu để làm bàn đạp chứng minh cho các giả định hoặc scenario trước. Ngoài ra họ ngụy biện rằng hành động này dựa trên kinh nghiệm của chuyên gia hay chủ trương rằng đây là best practice. Hậu quả xấu nhất thiên kiến xác nhận mang lại chính là việc dễ dàng bỏ qua ý kiến cho rằng “bạn đã sai”, từ đó dẫn đến hậu quả nghiêm trọng hơn chính là việc PM liên tục mang quan điểm cá nhân áp đặt vào cả quá trình hình thành sản phẩm. Vì vậy, đây chính là thiên kiến nguy hiểm nhất cần tránh.
Chúng ta cùng tìm hiểu ví dụ sau:
Trong quy trình chuẩn bị launching sản phẩm mới, bước đầu tiên nhất bộ phận Engineering cần thực hiện chính là phân tích kỹ kết quả yêu cầu của khách hàng hoặc nghiên cứu người dùng. Nhiều người nghĩ rằng thiên kiến xác nhận bắt đầu ở bước phân tích feedback và yêu cầu của người dùng nhưng thực tế một cách vô thức, thiên kiến xác nhận có thể đã được bao hàm từ ngay trong nội dung phỏng vấn hoặc survey mà team đã gửi cho người dùng/khách hàng. Chúng ta cùng phân tích một trong những câu hỏi rất điển hình trong các survey:
“Trong số rất nhiều chức năng hiện có, khi cần tìm chức năng X bạn đánh giá độ khó ở mức độ nào?”
Trong câu hỏi trên, có những điểm thiên kiến xác nhận nào?
- Bằng việc sử dụng từ “khó”, bạn đã khiến người dùng không thể trả lời “dễ” hoặc “không khó”. Đây là một dạng leading question, dẫn độ người dùng phải chọn trả lời “rất khó” hoặc “hơi khó”.
- Ngoài ra trong câu hỏi đã nêu rõ “nhiều chức năng”, vô tình đã làm lộ nguyên nhân giải thích cho việc tại sao người dùng cảm thấy khó khăn.
- Tất nhiên, đối với câu hỏi này, bạn sẽ đưa ra thang đo đánh giá cho người dùng (thang đo độ khó từ 0 đến 5), như vậy dữ liệu bị ép nghiêng về một phía.
- Dữ liệu đạt được từ câu hỏi trên sẽ không trung thực vì vốn dĩ bạn đã ra lệnh cho người dùng phải trả lời phiến diện, không phản ánh đúng ý kiến thật của người dùng.
Chúng ta có thể thay đổi câu trả lời trên như sau:
“Bạn cảm thấy việc tìm kiếm chức năng X có khó khăn hay không? Nếu có, lý do là gì?”
Trong câu hỏi trên:
- Không ép buộc người dùng trả lời phiến diện, đưa ra lựa chọn có thể trả lời “Có/Không”.
- Chỉ khi người dùng trả lời có thì mới tiếp tục thu thập lý do, vì vậy khác với câu hỏi trên, câu hỏi này không giả mạo dữ liệu, không hướng người dùng về một lý do.
- Dữ liệu thu thập được đa dạng đủ, và có thể giúp ích cho quyết định thực tế, đây là dữ liệu chất lượng cao.
Luyện tập để tránh thiên kiến xác nhận:
- Thừa nhận và nhận thức được sự thật bản thân đang mang thiên kiến.
- Tuyệt đối tránh các câu hỏi leading, hạn chế phạm vi câu trả lời trong user research/survey/feedback.
- Nhận feedback đa dạng từ đại diện khách hàng, người dùng, đồng nghiệp, người liên quan,… Thiên kiến xác nhận sẽ yếu dần khi dữ liệu thu thập được càng nhiều.
- Khi thiết lập mục tiêu, PM nên ngồi xuống cùng các leader đến từ team dev, design, product leadership,…, PM phải trực tiếp giải thích lý do cho các leader và xin ý kiến từ họ.
- Với mỗi quyết định, thay vì đặt câu hỏi ‘cái gì’ cho bối cảnh cần quyết định, hãy review xem có thỏa mãn câu hỏi ‘tại sao’ hay không.
B. Ngụy biện chi phí chìm (Sunk-cost fallacy)
Ngụy biện chi phí chìm thường xuất hiện trong tình huống khi chúng ta dù đã dự đoán trước được kết quả không khả quan hoặc không chắc chắn của một dự án trong tương lai nhưng vì thời gian, nỗ lực và chi phí đã đầu tư ban đầu trước đó nên phải tiếp tục duy trì đầu tư và thực hiện.
Khi gặp tình huống một sản phẩm/dự án không đảm bảo được mang về tương lai sáng sủa, PM phải đưa ra quyết định liệu có nên tiếp tục đầu tư hay dũng cảm từ bỏ để tập trung vào xây dựng chiến lược tạo giá trị gia tăng mới. Lúc này, một trong những điều sẽ khiến PM phân vân đó là quyết định đưa ra lần này sẽ khiến việc đổi phương hướng trong tình huống tương tự gặp trong tương lai khó khăn hơn. Vì vậy, thông thường khi gặp tình huống trên, các PM thường đưa ra quyết định tiếp tục đầu tư thay vì mạnh dạn thay đổi. Hay nói cách khác yếu tố tâm lý mang tên “nỗi lo mất mát” đã dẫn đến thiên hướng ngụy biện chi phí chìm. “Nỗi lo mất mát” là tên gọi của nỗi đau khi bị mất mát sẽ lớn gấp 1.5 đến 2 lần niềm vui khi nhận được lợi ích với cùng một giá trị.
PM thường phải đảm đương nguy hiểm khi tiếp tục duy trì đầu tư vào sản phẩm dự đoán mang lại ROI thấp, họ thường hy vọng trong tương lai kết quả sẽ cải thiện nếu cố gắng tiến hành tốt. Ngụy biện chi phí chìm khiến PM tìm ra lý do hợp lý để tiếp tục cho quyết định phản logic của mình, chính là việc tiếp tục đầu tư vào các dự án/sản phẩm dự đoán mang lại ROI thấp.
Luyện tập để tránh ngụy biện chi phí chìm:
Nếu một PM mang ngụy biện chi phí chìm, người đó có thể sẽ liên tục đưa ra những quyết định sai, và quyết định đó sẽ ảnh hưởng đến sự tồn tại của sản phẩm. Sau đây là một số câu hỏi đơn giản nhưng có thể trở thành tiêu chí quan trọng trước khi đưa ra quyết định.
- Nếu sản phẩm này ảnh hưởng đến sự sống còn của toàn công ty thì liệu tôi vẫn đưa ra quyết định này hay không?
- Nếu tất cả code có sẵn đều biến mất, thì liệu tôi vẫn tiếp tục bảo thủ duy trì code bằng cách này hay không?
- Nếu đây là dự án đồng nghiệp thực hiện, thì tôi có thể nói rằng đó là quyết định đúng hay không?
Tạm kết:
“Kỹ thuật khó nhất để trở thành một PM, PO thuần thục chính là khả năng nhìn được bức tranh toàn thể, loại bỏ hoàn toàn mọi dự cảm và suy nghĩ của cá nhân vào giây phút phải đưa ra quyết định.” – Rian van der Merwe, “Making It Right”.
Một quyết định của PM mang sức ảnh hưởng rất lớn đến cả dự án vì vậy một PM rất cần tránh những quyết định bị ảnh hưởng bới thiên kiến/định kiến. Tuy chúng ta không thể hoàn toàn không bị ràng buộc bởi những định kiến/thiên kiến này, việc tìm hiểu về yếu tố ảnh hưởng sẽ phần nào giúp PM đưa ra quyết định chuẩn xác hơn.
Đọc thêm một số bài viết khác liên quan từ Careerly:
- Làm User Research chỉ trong 4 ngày: https://blog.careerly.vn/blog/user-research-bang-research-sprint/
- Competitor Analysis trong Product Design: https://blog.careerly.vn/newsletter/competitor-analysis-trong-product-design/
Cập nhật thường xuyên những nội dung tương tự về Product Management, UX/UI,… đăng ký nhận bản tin qua email từ Careerly tại http://www.careerly.vn/.
3 comments