Là một Product Manager (PM), chúng ta không tránh khỏi những sai lầm như bị trễ deadline, hiểu sai nhu cầu người dùng, hoặc ngay cả việc tính năng thất bại sau khi ra mắt. Những sự kiện này mình đều đã trải qua, và bất cứ ai làm sản phẩm một cách nghiêm túc cũng chắc hẳn như thế. Dù chúng đau đớn, nhưng lại là cơ hội tuyệt vời để học hỏi và cải thiện bản thân. Tuy nhiên, đôi khi chúng ta chỉ rút ra những bài học không đủ sâu, và nhiều lần như vậy sẽ cản trở quá trình phát triển trong sự nghiệp.

Dương - co-founder của mình tại Breaking into Product Management, gần đây có chia sẻ một câu chuyện về một cựu học viên đang trong quá trình phỏng vấn. Bạn có nhờ Dương tư vấn và feedback CV cũng như câu trả lời phỏng vấn của bạn. Trong quá trình đó, bạn có kể về một trải nghiệm cụ thể: bạn cần nghiên cứu một bộ APIs nào đó để viết PRD, nhưng chỉ sau khi dev làm xong rồi thì mới nhận ra một sự thiếu sót.

Khi Dương hỏi rằng bài học ở đây là gì, thì bạn ấy kết luận: "Em cần đọc tài liệu API kỹ hơn." Mặc dù không sai, nhưng mình và Dương đều thấy có một bài học khác hữu ích hơn, đó là nên involve dev sớm hơn trong quá trình tìm hiểu nghiên cứu API docs, vì điều đó sẽ tăng khả năng giải quyết vấn đề này hơn so với việc cố gắng đọc kỹ hơn.

Bài viết này mình chia sẻ một số suy nghĩ của bản thân về việc tại sao chúng ta đôi khi rút ra bài học không hữu ích, và quan trọng hơn, làm thế nào để học từ trải nghiệm tốt hơn.

Tại sao chúng ta rút ra bài học không hữu ích?

Suy nghĩ nhanh mà nói, thì nguyên nhân cho hiện tượng này là do Cognitive Bias (thiên kiến nhận thức), nhưng cụm từ đó quá rộng và cũng không quá thú vị. Khi suy nghĩ về chủ đề này, mình nhận ra nguyên nhân cốt rễ phần nhiều là do cách chúng ta quy trách nhiệm cho những sự kiện tiêu cực (attribution).

Một framework để suy nghĩ về việc này, đó là có ba khía cạnh quan trọng thường xuất hiện khi chúng ta cố gắng giải thích một sự kiện (thường là tiêu cực) nào đó trong công việc hay cuộc sống. Nói cách khác, các "bài học" mà chúng ta rút ra trừ trải nghiệm thường đều bao gồm các chiều không gian sau:

• Internal vs. External: Vấn đề này là do bản thân mình hay yếu tố bên ngoài?
• Global vs. Specific: Kết quả của vấn đề này đề rộng lớn hay chỉ mang tính tình cụ thể trong tình huống này.
• Stable vs. Unstable: Vấn đề này là một vấn đề dài hạn hay chỉ mang tính chất tạm thời?

Dựa vào framework này, chúng ta có thể phân tích bài học mà bạn học viên ở trên rút ra như sau:

• Internal: Bạn ấy tự trách khả năng đọc tài liệu của mình, nghĩ rằng do bản thân đã thiếu cẩn thận khi đọc tài liệu API mà không nhìn thấy vai trò quan trọng của developers, những người hoàn toàn có thể phát hiện lỗi này nếu được tham gia sớm hơn.
• Specific: Bạn ấy coi đây là một vấn đề đặc biệt của tình huống này và không liên kết nó với các vấn đề rộng hơn như kỹ năng giao tiếp hay cách thức làm việc chung với team.
• Unstable: Bạn cho rằng đây là vấn đề tạm thời, hoàn toàn có thể cải thiện được chỉ bằng cách đọc tài liệu kỹ hơn lần sau, mà không nghĩ tới việc điều chỉnh quy trình làm việc hay cách phối hợp team.

Phản tư này là tích cực, nhưng vẫn chưa đầy đủ. Con người chúng ta thường có xu hướng đánh giá cao những yếu tố nội tại thay vì để ý đến các yếu tố tình huống dẫn đến một sự kiện hay hành vi nào đó xảy ra (fundamental attribution error). Cơ chế này chính là thứ khiến chúng ta đánh giá nhân cách của một người qua một sai lầm nào đó, hơn là nghĩ về cái hoàn cảnh đã cho phép sai lầm đó xảy ra.

Làm thế nào để học từ trải nghiệm tốt hơn?

Ý tưởng này không phải mới, nhưng điều thú vị mình thấy từ việc phân tích như trên đó là: chúng ta có thể sử dụng framework này để tự đánh giá những bài học mình tự rút ra. Điều này sẽ ít nhất đảm bảo rằng chúng ta đang không tự mặc định (autopilot) nghĩ về một khía cạnh cụ thể mà bỏ qua những chiều không gian khác.

Để chắc chắn rằng mình rút ra bài học đúng đắn, PM có thể chủ động nhìn lại các sự kiện thông qua các chiều không gian như trên. Mình muốn nhấn mạnh rằng mỗi chiều không gian cũng như các thái cực của chúng đều có thể giúp chúng ta thêm được góc nhìn mới, vì vậy không có cách nào là tốt nhất cả.

Sau đây là một số câu hỏi PMs có thể cân nhắc đặt ra khi cố gắng rút ra bài học từ trải nghiệm trong công việc:

Internal vs. External: ai hoặc điều gì kiểm soát kết quả?

• Khi bạn bỏ sót dependency về mặt kỹ thuật:
  • Internal: Mình đã trình bày rõ dependencies cho stakeholders chưa? Mình có thiếu nền tảng kỹ thuật để nhìn thấy dependencies này chưa?
  • External: Mình đã chủ động phối hợp sớm với engineering chưa? Cách hiện tại mà team chúng ta nghiên cứu và xác định dependencies có vấn đề gì không.
• Khi stakeholders phản đối một quyết định nào đó:
  • Internal: Mình đã truyền đạt luận cứ của quyết định này một cách rõ ràng chưa? Mình đã cân nhắc các chiều không gian mà người phản đối nếu ra chưa?
  • External: Có yếu tố bên ngoài nào làm cho mình chưa thấy trước được những sự phản đối này không? Người kia có context gì nhiều hơn mình để họ có thể thấy được điều này hay không?
• Tính năng mới ít được người dùng sử dụng:
  • Internal: Mình đã xác nhận nhu cầu người dùng kỹ càng chưa? Mình có hiểu sai ý người dùng truyền đạt khi làm discovery không?
  • External: Tần suất tự nhiên của vấn đề này trên tập người dùng là gì (hằng ngày, hằng tuần, hằng tháng?) Có yếu tố thị trường nào điều khiến hành vi của người dùng khác với giải pháp được đề ra không?

Global vs. Specific: đây là vấn đề chung hay chỉ mang tính cục bộ?

• Nghiên cứu người dùng không hiệu quả:
  • Global: Phương pháp nghiên cứu của mình có vấn đề không? Team mình đã nói chuyện với đủ người dùng chưa?
  • Specific: Có phải do nhóm người dùng này chưa thuộc vào tập ICP của sản phẩm không? Nhóm người dùng này có tính chất gì khiến cho họ không gặp vấn đề này hay không?
• Hành vi người dùng bất ngờ:
  • Global: Có pattern chung nào trong việc không hiểu được vấn đề của người dùng không? Có phải giải pháp của chúng ta đang không dựa trên một sự hiểu sâu về không gian vấn đề không?
  • Specific: Thiết kế tính năng lần này có gì đặc biệt và xa lạ với tệp người dùng này không? Hành vi của họ bất ngờ so với hành vi mong đợi, vậy hành vi mong đợi có đến từ việc quan sát một tập người dùng khác không?
• Khách hàng rời đi sau khi chúng ta tăng giá:
  • Global: Có phải sản phẩm của chúng ta chưa đủ giá trị cho mức giá mới này không? Có phải sản phẩm có nhiều khiếm khuyết khiến người dùng phẫn uất từ lâu và tăng giá chỉ là giọt nước tràn ly không?
  • Specific: Việc tăng giá lần này có hợp lý với nhóm khách hàng cụ thể này không? Họ có phải nhóm nhạy cảm về giá không? Họ có nằm trong đúng nhóm người dùng tốt nhất của sản phẩm chưa?

Stable vs. Unstable: vấn đề này là xu hướng hay là tạm thời?

• Xung đột thường xuyên với dev:
  • Stable: Có phải vấn đề này thường xuyên xảy ra? Có phải mâu thuẫn về thế giới quan giữa mình và engineers không?
  • Unstable: Vấn đề lần này có phải do việc viết tài liệu chưa được rõ ràng, làm cho dev bất xúc, hoặc áp lực tạm thời từ deadline không?
• Không đạt được mục tiêu sprint:
  • Stable: Có phải chúng ta thường đặt ra mục tiêu thường xuyên không thực tế không? Có phải velocity của team có vấn đề không?
  • Unstable: Có phải do thay đổi nhân sự hay yếu tố ngắn hạn gì không? Có một đầu việc nào bất ngờ bị chèn vào hay bug khiến cho team phải xử lý hay không?
• Stakeholders không đồng thuận:
  • Stable: Có mâu thuẫn về lợi ích lâu dài hay không? Họ có đang ngấm ngầm không thích con người mình không?
  • Unstable: Có phải do thay đổi chiến lược tạm thời làm cho mục tiêu ngắn hạn của mọi người bị mâu thuẫn không? Có phải do sự thiếu context giữa các stakeholders làm cho họ hiểu lầm ý nhau không?

Áp dụng lần tiếp theo khi bạn đi phỏng vấn

Trong một tập podcast với Dương hồi lâu, mình có nhớ đã nói rằng khi đánh giá ứng viên (ở vị trí nhà tuyển dụng), một dấu hiệu mình hay tìm kiếm đó là việc ứng viên chịu trách nhiệm với một kết quả gì đó không tốt. Đó thường là trong ngữ cảnh của một câu hỏi tình huống như kiểu "kể về lần gần nhất mà bạn phải xử lý một vấn đề khó khăn?".

Mình thường hay tìm kiếm trong câu trả lời của các bạn góc nhìn "tôi đã gây ra tình huống này như thế nào?". Điều đó nhằm để cho mình có thể filter được những ứng viên sống theo kiểu thoái trào trách nhiệm ("tôi không sai, thế giới này sai"). Thái độ đó theo mình là rất khó để có thể đi xa được trong việc làm sản phẩm, vì suy cho cùng Product Manager là người chịu trách nhiệm mặc dù đôi khi không có nhiều quyền lực.

Tuy nhiên, đó chỉ là một khía cạnh cụ thể (Internal trong Internal vs External) mà mình đã phân tích ở trên. Khi chiêm nghiệm lại, thì mình thấy rằng một câu trả lời tốt là một lời giải thích về tình huống khó khăn mà xem xét được ở nhiều khía cạnh khác nhau, có nghĩa là bao gồm cả ba chiều không gian trong framework trên. Khả năng phản tư đa chiều thể hiện sự trưởng thành và linh hoạt trong tư duy - hai thứ rất cần thiết khi bạn muốn làm PM.

Interactive Prototype

Sau đây là một chiếc tool nhỏ mình build để mọi người có thể thực hành rút ra bài học từ chính trải nghiệm của bản thân.

Kết luận

Lần tới khi bạn thất bại, hãy dừng lại và phản tư theo ba chiều cạnh trên. Mỗi thất bại đều là cơ hội để học hỏi và phát triển, giúp bạn trở thành một Product Manager tốt hơn mỗi ngày nhé.