Ngay cả Senior Product Manager cũng có thể phạm sai lầm, một số sai lầm có thể còn được duy trì và kéo dài trong thời gian làm việc mà bản thân người Product Manager đó chưa nhận ra.

Bản thân tôi đã phạm sai lầm, đã có thất bại. Cũng trong quá trình đó, tôi đã lạc lối và làm việc với những thứ khiến sản phẩm ra mắt nhưng không đúng hướng của toàn bộ công ty. Bài viết này bao gồm một vài sai lầm trước đây của tôi và có lẽ bạn có thể học hỏi điều gì đó từ những sai lầm này.

Quản lý các bên liên quan (Stakeholder Management) không tốt

Không tìm hiểu các bên liên quan (stakeholder) là một vấn đề phổ biến.

Tùy thuộc vào quy mô của tổ chức và mức độ phức tạp của sản phẩm, những người có liên quan đến hình hài của sản phẩm sẽ khác nhau. Nếu bạn không biết họ là ai và mục tiêu của họ, đề xuất đầu tiên của bạn sẽ gặp trở ngại đáng kể trong việc giao tiếp cho đến việc đồng thuận về mặt giải pháp.

Một Product Manager phải dành phần lớn thời gian trong những ngày đầu tiên đảm nhận vai trò này để tìm hiểu những người có khả năng đưa ra quyết định và cách mà các sản phẩm được hình thành. Điều này sẽ thiết lập một cơ sở đủ tốt để ra mắt sản phẩm hoặc tính năng đầu tiên của bạn một cách dễ dàng.

Đa số các Junior Product Manager tôi gặp (trong đó có tôi) nhầm lẫn giữa 2 việc: trao đổi thông tin về cái gì đó vs. đồng thuận với nhau trên cái gì đó.

Đối với tôi, sai lầm rõ ràng nhất của các Junior Product Manager là cố gắng làm hài lòng quá nhiều người bằng việc ủng hộ cách ra quyết định của họ. Khi bạn là người mới, thiếu kinh nghiệm và đang học hỏi kinh nghiệm, bạn không có xu hướng tin vào bản năng của mình. Bạn nghi ngờ khả năng ra quyết định của mình nên bạn nhờ sự giúp đỡ. Đó là một phản ứng hoàn toàn tự nhiên và là cách tốt nhất để học hỏi. Vấn đề là bạn thường hỏi quá nhiều người về suy nghĩ hoặc ý kiến ​​của họ và sau đó phải vật lộn với bản thân để đi đến quyết định.

Lời khuyên của tôi là đừng lãng phí thời gian để cố gắng làm hài lòng tất cả mọi người. Một khi bắt đầu có một tầm nhìn về cách bạn sẽ làm sản phẩm, hãy tin tưởng vào nó và nỗ lực hết mình để biến nó thành hiện thực. Không phải ai cũng thích ý tưởng của bạn, nhưng điều đó cũng luôn xảy ra thường xuyên, suy cho cùng, chúng ta đều là những con người khác nhau.

Bạn cũng nên tìm một người cố vấn như là Senior Product Manager, Head of Product hoặc đồng nghiệp khác từng làm trước bạn. Khi xin lời khuyên, hãy cố gắng xác định người mà bạn kết nối một cách chuyên nghiệp, và hãy lắng nghe một cách tích cực.

Luôn nghĩ đến giải pháp (solution) trước khi xác định vấn đề (problem)

Một sai lầm phổ biến mà tôi thấy không chỉ ở các Junior Product Manager mà còn ở các Senior Product Manager: họ nhầm lẫn công việc làm giải pháp sản phẩm là công việc chính của một Product Manager.

Thực sự không phải như vậy. Công việc chính và đầu tiên của một Product Manager luôn (và mãi mãi) sẽ là: Xác định được vấn đề, phạm vi của vấn đề.

Bản chất của việc xây dựng giải pháp (solution) là sự đánh đổi liên tục giữa các yếu tố thương mại, tính khả thi về kỹ thuật, và khả năng sử dụng của sản phẩm. Bạn chịu trách nhiệm chính về khả năng thương mại của sản phẩm. Do đó, bạn phải xác định được vấn đề cốt lõi mà sản phẩm sẽ giải quyết cho người dùng.

Các Junior Product Manager sẽ đánh giá các tùy chọn giải pháp khác nhau và cuối cùng có thể thích một giải pháp cụ thể vì vô số lý do khác nhau. Ví dụ: một giải pháp có thể sử dụng công nghệ “tuyệt vời” mới nhất hoặc có thể là “rẻ nhất” hoặc UI trông “vui vui, trendy nhất”. Tôi cũng đã từng như thế ở những năm tháng đầu tiên của sự nghiệp.

Một trong những vấn đề chính mà mọi người gặp phải khi bắt đầu công việc quản lý sản phẩm là tập trung lập tức vào các yêu cầu thay vì hiểu rõ về vấn đề và các ảnh hưởng xung quanh nó.

Từ đó bạn sẽ có xu hướng xây dựng những gì khách hàng yêu cầu thay vì lùi lại một bước, dành thêm đủ thời gian để hiểu vấn đề và các tác động của nó nếu có. Điều này có thể dẫn đến việc một Junior Product tạo ra một giải pháp hoặc tính năng hoàn hảo nhất với một đối tượng cụ thể, nhưng lại không phù hợp với đại đa số người dùng. Điều này cũng tương tự như việc những gì “mắt thấy, tai nghe” chưa chắc đã là đúng. Căn bản bạn phải luôn dành cho bản thân 1 khoảng tĩnh lặng để hiểu, để ngẫm nghĩ tại sao nó lại như vậy.

Tôi cũng thấy rất nhiều câu “Đối thủ cạnh tranh của chúng ta đang làm điều này nên chúng ta cũng nên làm như vậy.” Tôi tin rằng đây là cách tiếp cận lười biếng. Tôi không khẳng định đây là cách tiếp cận sai, nhưng tiếp cận lười biếng sẽ tự tay đẩy sản phẩm đi lùi.

Chúng ta có thể copycat, nhưng trước khi copy thì chúng ta cần nghĩ xem tính năng nói trên có phù hợp với sản phẩm và khách hàng của bạn hay không.

Hiểu chưa đúng ý của "Product Manager là CEO của sản phẩm"

Có nhiều tài liệu nói rằng Product Manager là CEO của sản phẩm. Thoạt nghe thì bản thân tôi thấy đúng là nó có một sức mạnh nào đó khởi lên trong ý nghĩ.

Thực tế khi nghe nhiều bạn nói câu này, mọi người có xu hướng thể hiện phong cách độc đoán khi bắt đầu đảm nhận vai trò này. Điều này gây ra sự ngộ nhận. Từ ngộ nhận dẫn đến sự xung đột trong cách đưa ra quyết định làm sản phẩm.

Một điều hết sức cơ bản và tự nhiên với những người bắt đầu chính là: ai cũng sẽ phải trải qua một chặng đường dài để học cách giao tiếp hiệu quả, học cách rèn luyện sự tự tin, bồi đắp sự thấu cảm với người dùng cũng như cách đưa ra quyết định đúng đắn cho sản phẩm.

Thực chất nên hiểu ý nghĩa của câu “CEO của sản phẩm” như thế nào mới đúng?

Nếu bạn tin vào công việc và khả năng của mình, câu trên có nghĩa rằng: Bạn sẽ đảm nhận vai trò Product Manager và bạn chịu trách nhiệm với tư duy của bạn. Quan trọng là tư duy của bạn có thẩm quyền.

Vì vậy một người quản lý sản phẩm mới đến với suy nghĩ rằng họ sẽ trở thành “CEO” của bất cứ thứ gì ngay lập tức, họ có thể sẽ vô cùng thất vọng. Tôi mong bạn không tư duy theo hướng này.

Không đủ hiểu biết về khách hàng hoặc sản phẩm

Để hiểu biết về khách hàng, trước hết bạn phải là khách hàng. Nghĩa là bạn phải học cách sử dụng các sản phẩm khác nhau của nhiều người khác nhau.

Product Manager là tiếng nói của khách hàng và phải có khả năng đồng cảm với họ. Muốn phát triển sự đồng cảm với khách hàng, Product Manager phải đặt mình vào vị trí của khách hàng mỗi ngày.

Điều này cũng tương tự trong cuộc sống hàng ngày của chúng ta vậy. Bạn không thể hiểu nếu bạn không tư duy, bạn đã hiểu nhưng bạn chưa thể đồng cảm khi bạn chưa đặt bản thân vào vị trí của người khác.

Cho nên là, Junior Product Manager ở thời điểm đầu của sự nghiệp, cần phải phát triển suy nghĩ này mỗi ngày.

Con người đa số đều có sai sót, ít nhất là 1 lần. Thực tế chuyện sai sót là chuyện bình thường (vô thường) trong cuộc sống này. Điều quan trọng là bạn làm gì, bạn khởi cái tâm (tâm ăn năn, tâm phục thiện) gì trên cái sai sót đó. Nếu bạn làm được như thế thì tôi tin rằng sản phẩm của bạn cũng rất xứng đáng đến với người dùng.

Với vai trò là một Product Manager, ngoài việc phải học cách đồng cảm, bạn phải thấy được những sai sót trong các sản phẩm mà bạn sử dụng hàng ngày. Có phải những Product Manager này không sử dụng sản phẩm của họ nhiều hay không ưu tiên sửa lỗi, cải tiến tính năng này đủ cao trong kế hoạch của họ?

Mục đích của MVP là cung cấp chức năng tối thiểu cho phép bạn xác thực một giả thuyết làm sản phẩm. Nhưng khi bạn không đủ hiểu biết về khách hàng hoặc sản phẩm, giả thuyết này có thể đã sai từ ban đầu. Điều này dẫn đến một tác động to lớn về sau.

Nói “CÓ/YES” với mọi thứ là một cạm bẫy khác mà các Junior Product Manager phải đối mặt, những người tin rằng quản lý sản phẩm là tìm cách xây dựng mọi thứ được yêu cầu.

Điều này thật đáng buồn là sự thật mà tôi cũng đã từng thực hành.

Sắp xếp mức độ Ưu tiên là một kỹ năng cần thiết và có giá trị lâu dài đối với Product Manager. Người quản lý sản phẩm phải học cách xác định khách quan giá trị kinh doanh của các ý tưởng khác nhau và đưa ra quyết định “có” hoặc “không”.

Điều tốt nhất về các Junior Product Manager là họ rất khao khát kinh nghiệm và thường sẵn sàng đảm nhận bất kỳ dự án nào theo cách họ muốn. Loại thái độ này chính là lý do tại sao các bạn bị thu hút về ngành Product Management ngay từ đầu: có thể gây ảnh hưởng đến sản phẩm, sản phẩm được nhiều người dùng đón nhận.

Tuy nhiên, các bạn Junior Product Manager có thể chưa nhận ra rằng khi mọi thứ đều được ưu tiên thì không có gì là ưu tiên cả. Cũng như khi tôi hay nói đùa với mọi người: “Khi không biết điều gì tốt nhất thì cái chúng ta đang có ở hiện tại mới chính là tốt nhất.”

Bỏ qua việc phân tích dữ liệu hoặc lạm dụng dữ liệu thái quá

Sản phẩm của bạn phải đi kèm với các số liệu. Số liệu sẽ ủng hộ giả thuyết của bạn và giúp bạn nhìn thấy được gì đó chưa tốt.

Quá tập trung vào phân tích dữ liệu và dùng dữ liệu để kiện toàn sản phẩm 100% cũng là một sai lầm phổ biến. Tất nhiên nếu bạn bỏ qua việc phân tích dữ liệu thì tôi không còn gì để nói. Dữ liệu rất cần thiết để đưa ra quyết định nhưng không phải là yếu tố duy nhất.

Ví dụ: Trong 30 ngày qua tỷ lệ churn của người dùng đến 70%. Bạn dựa vào đó để làm lại trang giới thiệu sản phẩm. Nhưng có thể ở một ngữ cảnh khác, người dùng churn là vì bạn không có đủ hình thức khuyến mãi so với đối thủ, hoặc cách hiển thị khuyến mãi của bạn không trực quan.

Điều tôi muốn nói trong phần cuối của bài viết này đó chính là: Khi nhìn vào dữ liệu, bạn phải lắng nghe bản năng của mình. Bản năng là thuật ngữ dùng để chỉ những gì mang tính chất bẩm sinh, vốn có, không cần qua bất kỳ sự học tập hay rèn luyện nào để hình thành nên.

Không phải ai cũng có sẵn bản năng này. Vì vậy điều quan trọng nhất ở đây chính là việc xây dựng nên một thói quen, một loại bản chất thứ hai của Product Manager: Luôn quan sát chặt chẽ dựa trên dữ liệu.

Theo thời gian, bạn sẽ bắt đầu nhìn mọi thứ dựa trên dữ liệu và qua lăng kính này. Thứ bạn còn thiếu chính là các kỹ thuật, phương pháp xử lý dữ liệu tốt để phục vụ việc đưa ra quyết định làm sản phẩm.

Điều cuối cùng, đây là một bài học cực kỳ quan trọng đối với các Junior Product Manager: Quản lý sản phẩm theo hướng dữ liệu sẽ không tự động dẫn đến các sản phẩm tốt hơn bởi vì, mặc dù dữ liệu có giá trị nhưng bản thân nó không phải là yếu tố để kết luận, dữ liệu không đại diện cho việc kết luận trạng thái của một vấn đề. Dữ liệu chỉ là thông tin để giúp bạn đạt được kết luận của riêng bạn. Nếu bạn sử dụng sai hoặc dựa vào nó để loại trừ các yếu tố khác thì dữ liệu thực sự có thể gây hại nhiều hơn là có lợi cho sản phẩm của bạn.

Việc thu thập quá nhiều dữ liệu có thể dẫn đến suy nghĩ quá mức, điều này có thể dẫn đến đủ loại vấn đề. Trong đó có một loại thiên kiến về nhận thức có vẻ đặc biệt liên quan ở đây là thiên kiến xác nhận (confirmation bias)

Thiên kiến xác nhận xảy ra khi bạn cho rằng suy nghĩ của bản thân là đúng và có xu hướng tìm kiếm, tiếp nhận, và ghi nhớ những thông tin củng cố cho quan điểm của mình. Ví dụ, bạn tin rằng người thuận tay trái sáng tạo hơn người thuận tay phải. Hoặc bạn tin rằng người thích uống bia là người mê nhậu, không tốt cho gia đình.

Đây là những niềm tin được điều phối bởi thiên kiến xác nhận, nó khiến bạn vô thức đi tìm thông tin để chứng minh cho chúng. Các bằng chứng này tuy giúp củng cố lập luận của bạn nhưng lại tạo ra nhiều điểm mù khiến bạn khó nhận ra rằng chúng không hoàn toàn chính xác như bạn nghĩ, và bạn đang thiên vị niềm tin của mình.

Bây giờ là ví dụ.

Hãy tưởng tượng bạn chịu trách nhiệm phát triển về một sản phẩm SaaS cho B2B. Trong khi đánh giá dữ liệu trong 9 tháng qua, bạn phát hiện ra rằng khách hàng hiện không sử dụng một tính năng cụ thể mà bạn cho là cực kỳ có giá trị đối với quy trình làm việc của họ.

Nếu bạn đi sâu vào phân tích dữ liệu này để tìm kiếm những hiểu biết khách quan về khách hàng, bạn có thể xem xét một số khả năng sau đây:

1. Có thể nhóm của bạn và bạn đã đúng khi cho rằng tính năng này sẽ có giá trị, nhưng các bạn đã xây dựng theo cách không phù hợp với người dùng của mình.
2. Có thể nhóm của bạn và bạn đã mắc sai lầm khi đánh giá rằng người dùng sẽ muốn hoặc cần một tính năng như thế này.
3. Có thể nhóm của bạn và bạn đã nhận định đúng về giá trị của tính năng — và các bạn cũng đã xây dựng tính năng này một cách chính xác — nhưng vị trí mà bạn đặt tính năng này trong ứng dụng khiến việc tìm kiếm trở nên khó khăn với người dùng.

Bây giờ, với 3 khả năng trên (và có thể cả những khả năng khác), bạn có thể ra ngoài và thực hiện một số cuộc phỏng vấn và khảo sát để xác định xem giả thuyết của bạn có đúng không. Đây là cách quản lý sản phẩm thuần tuý dựa trên dữ liệu. Dữ liệu trao niềm tin cho hành động.

Nhưng nếu bạn dễ bị thiên kiến xác nhận, bạn thậm chí có thể không xem xét đến hai khả năng đầu tiên — và ngay lập tức bạn bị thu hút bởi khả năng thứ ba. Nói cách khác, tất nhiên là “chúng tôi đúng về tính năng này và tất nhiên chúng tôi đã xây dựng nó theo đúng cách; người dùng của chúng tôi vẫn chưa tìm thấy nó.” 😬

Bạn thậm chí có thể gọi cho người dùng và diễn đạt câu hỏi của mình theo cách này: “Nếu chúng tôi chuyển [tính năng ABC] sang một vị trí đẹp mắt, dễ thấy hơn trong ứng dụng, bạn có nhiều khả năng sẽ sử dụng nó hơn không?”

Kiểu thiên vị này có thể khiến ngay cả một Product Manager quen phân tích dựa trên dữ liệu tập trung ưu tiên vào những ngã rẽ sai lầm và cuối cùng làm suy yếu sản phẩm theo thời gian.

Cạm bẫy phổ biến này đối với Product Manager có thể do công nghệ sẵn có (để đào sâu dữ liệu) hoặc đơn giản là do các quy trình.

Xét về quy trình riêng của Product Manager, nhiều người cảm thấy không đủ “kỹ thuật” để xây dựng hoặc nghiên cứu các mảng dữ liệu lớn hơn, vì vậy họ hoàn toàn dựa vào nghiên cứu mang tính chất research hơn — chẳng hạn như gọi điện cho một người dùng và trò chuyện về cách họ sử dụng sản phẩm. Đây cũng là một thực tế mà tôi cũng từng có cơ hội trải nghiệm.

Tất nhiên, cả hai loại cạm bẫy này — sử dụng công nghệ phân tích dữ liệu hoặc sử dụng phương pháp thủ công hơn để thu thập thông tin người dùng — có thể cản trở Product Manager có cái nhìn sâu hơn về loại dữ liệu có ý nghĩa thống kê.

Như vậy, người quản lý sản phẩm phải được định hướng về dữ liệu. Lộ trình sản phẩm (roadmap) phải được điều khiển bằng dữ liệu. Và các quyết định bạn đưa ra về sản phẩm của mình, bất cứ khi nào có thể, sẽ bị ảnh hưởng bởi dữ liệu. Bởi dữ liệu không phải là yếu tố duy nhất đưa đến kết luận.

Chỉ cần đảm bảo rằng bạn đang tập trung vào đúng loại dữ liệu, diễn giải dữ liệu đúng cách và sử dụng các công cụ cũng như quy trình thông minh nhất để thu thập và phân tích dữ liệu đó.

Nhưng trên hết, thỉnh thoảng hãy nhớ lùi lại một bước, dành thời gian ngẫm nghĩ, và nhìn bức tranh toàn cảnh để nhìn thấy được mọi thứ tốt hơn.