GIẢI QUYẾT MÂU THUẪN GIỮA PRODUCT MANAGER VÀ PRODUCT DESIGNER
Bài viết minh oan cho các PO PM khác và chia sẻ tips để đối mặt với conflict cho PD
Cách đây mấy ngày thì có một vài người bạn và học viên của mình tham gia 1 event festival lớn 2024 của giới công nghệ. Thì mọi người khá bức xúc về 1 thanh niên speaker chia sẻ quan điểm độc hại về cách làm việc PO PM với Product Designer. Lưu ý là mình nhận được từ rất nhiều feedbacks thanh niên này từ học viên vì thanh niên này trước đây đã từng công kích mình trên Linkedin. Trước đây, mình chia sẻ về quá trình tại sao 1 PO PM nên học Product Strategy và Product Roadmap thì thanh niên viết ngay 1 bài là khuyên không học Strategy khi mới vào làm Product Management. Sự việc này dẫn tới phần lớn học viên của mình đều biết và có cái nhìn không tốt với thanh niên ấy nên khi vừa thấy thanh niên chia sẻ quan điểm toxic là về thông báo và đưa mình xem thông tin ngay lập tức.
Nên bài viết này để giúp làm trong sạch hình ảnh của các PO PM với các bạn Product Designer và Developer chứ không công kích lại ai cả (mình xin phép không đề cập tên và lôi thanh niên ấy vào phần phân tích ở dưới). Yên tâm mình sẽ chia sẻ các kinh nghiệm đối mặt với PO PM phía dưới.
1. Product Manager không phải ai cũng push Product Designer
Cần phải làm rõ các tasks của Product Manager hay Product Owner nên phần lớn thời gian của họ là research competitors, đưa ra định hướng strategy, roadmap mới để cạnh tranh với đối thủ. Nên thường PO PM sẽ nắm rõ tính năng nào nên release trước để giúp công ty growth. Và do Product phải kiếm tiền nên không phải lúc nào cũng Trải nghiệm users là trên hết. Ví dụ trước đây khi design 1 solution không có banner ads ở 1 trang về sản phẩm bán vé livestream là do các bạn PD không nắm rõ cách kiếm tiền của sản phẩm đấy. Nên mình có giải thích lại là tại sao cần có banner ads vì chúng ta bán quảng cáo CPM / Rich Media nên mặc dù đồng ý UX có không tốt 1 chút nhưng bù lại có khách hàng trả tiền để hiển thị.
Nên đôi khi nhiều PO PM sẽ quyết định bằng cách là chốt Wireframe / Mockup với BOD thì transfer lại cho PD dẫn tới các bạn hiểu nhầm là push. Do cách giải thích và truyền tải của mỗi PO PM là khác nhau nên cảm nhận cũng sẽ khác nhau về PO PM đấy. Ví dụ có PO PM thì ít nói kiệm lời họ truyền tải kiểu giải thích qua sơ sài dẫn tới PD hiểu nhầm là ông PO PM đang sai mình làm Prototype cho đẹp lại dựa trên idea của ông ấy.
PD còn mới và chưa có quá nhiều exp trong việc thiết kế solution vì có nhiều solution phức tạp như hệ thống Bank hay ERP,… thì ngoài PO PM ra còn có các ITBA hỗ trợ trong việc phân tích các luồng nghiệp vụ chuyên sâu như BPMN, BPM,… để có thể cover các use case chặt chẽ. Nên đôi khi dẫn tới các ITBA consult về mặt solution rất chi tiết cho PO PM và họ dựng chi tiết luôn thành Mockup dẫn tới tình trạng PD không có đất sáng tạo. Thật ra ở vấn đề này có khá nhiều người bạn PO PM của mình khéo léo bằng cách là yêu cầu ITBA chỉ dựng tới High-Fidelity Wireframe thôi còn đâu phần optimize UX ở Mockup vẫn nên đưa qua cho PD làm để align với Design System.
2. PO PM stress không phải do mỗi vấn đề làm việc với các Stakeholders
Ở nhiều Big Corp thì nhiều PO PM phải chịu trách nhiệm về OKR / KPI / Success Metrics của sản phẩm nên áp lực lớn của họ là đến từ làm sao giúp sản phẩm / tính năng đấy tăng trưởng. Ngay trong theory của PSPO có nói “PO PM là người manage Backglog và maximize ROI”. Bọn mình áp lực vì mình phải chịu trách nhiệm với nhiều con người trong team. Các bạn thử nghĩ nếu sản phẩm launch không tốt ra thị trường thì công ty bị cắt vốn từ các Venture Capital hoặc phá sản. Việc này dẫn tới câu chuyện cả team Product đấy sẽ bị layoff, nhiều người sẽ mất thu nhập và thời gian tìm kiếm công việc mới.
Còn việc PO PM áp lực do làm việc stakeholders không hoàn toàn đúng. Vì PO PM nào đã đi làm 1-2 năm đều sẽ quen với việc phải đi họp với nhiều phòng ban và align goal của các phòng ban với nhau. Nhưng thứ khiến họ mệt mỏi thực sự là bài toán chính trị của các công ty, họ phải dĩ hoa vi quý với các phòng ban khiến họ không mất lòng nhưng vẫn phải bảo vệ team của mình. Tức khi Stakeholders đòi add ad hoc vào Sprint đang chạy PO PM thì họ cần phải deal rằng nên đưa vào Sprint sau hoặc nếu ad hoc thường xuyên quá thì bên em sẽ chừa 20-30% space trong 1 sprint cho stakeholders đấy. Tránh team product phải chịu thêm task trong quá trình chạy sprint.
3. PO PM không empathize các members như PD, Dev,…
Thực trạng này vừa có nhưng lại vừa không có. Tức không phải công ty nào cũng giống công ty nào là áp đặt vô tội vạ cho PD. Trước đây, khi mình làm cho 1 big corp thì PD cực kỳ có tiếng nói trong các sản phẩm công nghệ. Đơn cử mỗi lần mình làm xong Wireframe các sếp đều yêu cầu mình đưa cho PD duyệt về UX và đã align với Design System của công ty hay chưa. Thậm chí mình đã bị các sếp chửi rất nhiều vì là 1 PO PM mù màu sắc, không nắm font chữ,… đến mức mình phải đi học 3 courses UI UX ở các trung tâm. Sau khi mình học về thì mình thấy mình hiểu hơn về thế giới quan của các bạn PD từ đấy mình sử dụng đúng ngôn ngữ của họ hơn để nói chuyện, respect họ là tại sao họ phải mất hàng giờ đồng hồ chỉ ngồi chỉnh 1 cái màn hình mà trước đấy mình chỉ mất 10p để dựng Wireframe bằng Balsamiq (kéo thả icons và components).
Còn đối với các công ty không empathize hay lắng nghe ý kiến của PD thì mình sẽ xin phép chia sẻ vài giải pháp mà học viên mình đã áp dụng khá hiệu quả ở các công ty họ làm. Tức thay vì chúng ta chịu trận mà chúng ta cũng có thể đối mặt và xử lý thử với vài cách được liệt kê ở phần 5. Nhưng trước hết chúng ta cần phải nắm một chút mindset phân tích / thế giới quan hàng ngày của PO PM đang phải làm. Để từ đấy chúng ta có thể collab hiệu quả hơn.
4. Thế Giới Quan của PO PM (Các Câu Hỏi PO PM Hay Đối Mặt)
Tháng này tôi cần phải tăng trưởng sản phẩm / tính năng tăng trưởng bao nhiêu % hoặc đạt theo Plan do công ty đề ra cùng với Marketing – Sale Team (Metrics and Growth)?
Làm sao để feature / product của chúng ta outstanding ở trên thị trường. Nhưng nếu release thì liệu competitors có đánh cắp và làm tốt hơn chúng ta hay không (Unfair Advantage)?
Các sếp yêu cầu phải duy trì năng suất của team vì team Product hiện tại đang tốn ngân sách nhiều nhất công ty (lương). Vậy làm sao để nắm được performance của team và chứng minh được team của mình đang hiệu quả trong việc deliver các features (thông thường estimate bằng velocity trong Agile)?
Hiện tại users đã tăng trưởng (User Growth Business Model) đến 1 mức nhất định, vậy làm sao có thể earn money từ lượng users lớn để từ đấy có thể make profit cho công ty?
Hiện tại features này gần gấp quá mà optimize UX thì lại bị chậm tiến độ trong quá trình thực thi story trong Sprint đang chạy. Vậy có nên ưu tiên release features ra trước rồi phase sau improve UX sau không?
Hiện tại các chỉ số mục tiêu phòng ban là như thế nào + nhu cầu của các stakeholders ở các phòng ban đấy như thế nào để đạt đúng kỳ vọng của họ?
Làm sao phải cân đối với các nhu cầu stakeholders nhưng không gây mất lòng của họ, nếu add vào trong sprint thì sẽ không đạt đúng Commitment của đầu Sprint Planning?
Làm sao tìm ra solution nào giải quyết đúng Underserved Needs giúp metrics tăng trưởng?
Làm sao thuyết phục được các stakeholders là giải pháp này / prototype này của team mình sẽ giúp user có trải nghiệm tốt và từ đấy tăng trưởng metric? (Gợi ý: thông thường bọn mình sẽ kết hợp làm nhiều versions và dành ra 2 ngày làm Usability Test khi còn ở Prototype và quantify results theo các UX Metrics)
Hiện tại các thành viên trong team đang bất hòa quan điểm và không muốn phối hợp với nhau. Làm sao để cho các thành viên trong team phối hợp hiệu quả với nhau?
Mười câu hỏi trên thông thường là các câu hỏi mà mình và bạn bè mình hay phải suy nghĩ mỗi ngày khi bước lên công ty. Dĩ nhiên, còn nhiều câu hỏi toxic khác như:
Làm sao để tôi có thể giữ tốt cái ghế của mình?
Làm sao để người khác nhìn nhận tôi không yếu kém và tôi phải luôn nổi trội trong mắt sếp?
Làm sao tôi có thể thăng tiến nhanh hơn ở trong công việc?
Vậy làm sao đối mặt và xử lý các PO PM áp bức?
5. Đối Mặt Với Các PO PM Áp Bức (Nhớ Đọc Kỹ Nhé)
5.1 Thuyết Phục Solution
Thật ra với 3 câu hỏi này thì mọi người đừng nên tỏ ra quá giỏi và nổi bật hơn PO PM vì những người này lúc này đang khá sợ mất vị trí của họ. Điều này dễ hiểu vì con người ai cũng có tham vọng nên thay vì sợ hãi thì chúng ta nên đối mặt bằng cách mình làm việc xuất sắc nhưng mọi việc luôn confirm với PO PM. Vì những người này thứ họ mong muốn là kết quả đầu ra để được mình khen ngợi và gây ấn tượng trong mắt các sếp. Các bạn đừng hiểu lầm mình là mình không nói các bạn không nên tỏa sáng về năng lực của bản thân. Nếu các bạn giúp PO PM dạng này chứng minh được kết quả tốt hơn kỳ vọng các sếp thì những con người sẽ có nhiều thiện cảm hơn về chúng ta. Và dần dần họ sẽ trao quyền cho PD. Chúng ta thời gian đầu sẽ tỏa sáng trong âm thầm giống như ánh sáng của mặt Trăng trong đêm tối rồi tới thời điểm là ban ngày là chúng ta sẽ tỏa sáng như Mặt Trời. Tin mình đi cách này khá hiệu quả.
Thông thường những PO PM dạng áp bức hình thành sự áp bức cho bạn vì khi này họ sợ rằng giải pháp của bạn không hiểu quả bằng của họ và chính bản thân họ cũng đang như ngồi trong đống lửa không biết rằng solution này thực sự có hiệu quả. Nếu không hiệu quả thì tôi bay mất chiếc ghế mất. Vậy thì thay vì phải cãi nhau giải thích tay đổi là idea và solution của chúng ta là tốt thì chúng ta nên chứng minh bằng các Evidence-Based. Tức chúng ta dựa trên phân tích chuyên sâu, data, lượng hóa Usability Test… Long tin rằng nếu mọi người có 1 cơ sở lập luận phản biện vững chắc cho việc solution sẽ tăng trưởng thì PO PM áp bức sẽ lăng nghe mọi người. Nếu họ vẫn chưa chấp nhận solution của chúng ta mặc dù chúng ta đã đưa ra các evidence thì hãy hỏi 1 cách cầu thì và học hỏi là tại sao họ lại nghĩ solution của họ lại tốt hơn để giúp cho chúng ta hiểu rõ hơn về góc nhìn của họ. Hay lúc này có thể hiểu thay vì phải đợi PO PM thấu hiểu chúng ta thì chúng ta đeo lăng kính của PO PM.
Một lưu ý nhỏ là tốt nhất chúng ta nên chứng minh về mặt tăng trưởng users hoặc tốt như thế nào về Business Value. Nếu Solution / UX đấy tốt về mặt Long-Term Strategy thì chúng ta cần phải lý giải dựa trên nghiên cứu khoa học, đối thủ, hay evidence như bên trên đã đề cập.
5.2 Chia Sẻ Về Phương Pháp / Framework / Cách Làm Việc Mới
Đừng chia sẻ kiến thức gì quá mới mà bạn vừa học được hoặc đọc được cho các PO PM áp bức. Vì theo mình quan sát thì thường phần lớn các PO PM áp bức rơi vào những anh chị và bạn làm lâu năm nhưng lười update kiến thức mới. Họ chỉ tin vào những gì mà họ tin mà họ đã trải qua vì điều đấy an tâm không dẫn tới ghế của họ bị mất. Khi bạn chia sẻ mình đảm bảo các bạn sẽ bị nói là hàn lâm và lý thuyết xuông hoặc bị nói là cái này chỉ phù hợp ở nước ngoài còn ở Việt Nam thì không. Long đã từng bị nói không chỉ bởi BOD mà còn bị những người bạn bè thân lớn tuổi nói hơn là lý thuyết và hàn lâm mặc dù mình đù apply cho rất nhiều công ty giúp học tăng trưởng metrics.
Để thuyết phục các PO PM áp bức tốt nhất là làm – hành động ra kết quả rồi chọn lựa vào 1 thời điểm vui vẻ nào đấy để chia sẻ tại sao solution đấy mình áp dụng phương pháp luận / framework đấy. Ví dụ: trước đây có 1 học viên của mình làm ở 1 Bank khá lớn trong Nam, các PO PM thường là các anh chị làm 10-15 năm trong ngân hàng nên họ không được tiếp cận Job To Be Done Framework khi anh ấy giới thiệu thì lập tức bị sự phản bác của các PO PM kêu mày cứ dùng Design Thinking giúp tao cái. Mà họ lại không biết JTBD là 1 Framework giúp tối ưu hóa 2 bước Empathize và Define. Vậy là trong lúc tâm sự mình cũng bảo anh cứ apply dần dần từng phần của framework vào công việc là được. Đừng apply hết, hãy điều chỉnh nó phù hợp với dự án, nguồn lực và ngữ cảnh của công ty anh. Kết quả sau đấy 3 tháng thì anh ấy bảo rằng C-Level khen rất nhiều về bản phân tích Customer bằng JTBD đấy nên yêu cầu anh ấy nhân bản phương pháp luận và chia sẻ cho nhiều người cùng biết tới.
Lý giải cho việc phải chọn lựa thời điểm để giải thích vì thông thường các PO PM trong công ty lúc nào cũng ong ong trong đầu 10 câu hỏi trên nên họ ngại phải thay đổi cái cũ để theo cái mới. Vì họ sẽ mất chiếc ghế của họ nếu theo phương pháp mới, đồng thời tâm lý lúc này bị áp lực nhiều nên họ khá khó chịu. Tốt nhất chọn lựa các thời điểm như ngồi ăn trưa trò chuyện vui vẻ với nhau hoặc uống trà sữa vào buổi chiều…
Hãy ám thị họ về các phương pháp luận / framework / cách làm việc thông qua các bài viết, các case study thành công của thế giới bằng cách gửi vu vơ vào hội nhóm làm việc. Kiểu như sau giờ làm thì bạn giả vờ gửi vào nhóm riêng của cá nhân kêu bài này hay lắm nè. Vì nếu bạn đưa ra cái gì cho PO PM áp bức mà họ vô tình không biết trước mặt các đồng nghiệp thì họ dễ bị quê hay sợ bị nói là update chậm chưa biết cái này. Nên thường các bạn sẽ hay nghe các câu “à anh / chị biết cái này… anh / chị có đọc qua… mà cảm thấy chưa phù hợp công ty mình lắm…”. Thật ra sau đấy tối về họ nghiên cứu ngầm đấy (tin mình đi mình gặp case này nhiều lắm vì trước đây khi sếp mình bật google search mình vô tình thấy câu hỏi tìm kiếm đấy là gì?). Việc gửi bài vào hội nhóm giúp cho họ có thời gian nghiên cứu âm thầm 1 mình ở nhà để họ có thể tự tin thảo luận với các đồng nghiệp tại công ty. Tâm lý của con người rất lạ, họ sẽ tự tin thảo luận về 1 vấn đề gì đấy mà mình biết chắc kiến thức đấy trong tay. Còn việc ám thị liên tục sẽ tạo ra 1 tâm lý là ờ thấy thế giới nó cũng dùng thử hay mình cũng dùng thử nhỉ. Các bạn có biết rằng để thuyết phục 1 Big 4 Bank sử dụng JTBD vào tìm kiếm underserved needs mình phải mất 1 năm nói chuyện với các anh chị Leaders. Sau khi chúng ta ám thị khoảng 3-4 lần thì đã tới lúc chúng ta kích hoạt bằng cách là giải thích điểm mạnh yếu của phương pháp luận mới / cách làm việc mới và cần cải thiện cho ngữ cảnh công ty của chúng ta. Ví dụ: ở ngân hàng chúng ta không có tiền cho survey ở sample lớn nên tôi kết hợp Chat GPT với interview 3-4 users thôi.
5.3 Áp Bức Vì Họ Gia Trưởng Quen Rồi
Hãy chia sẻ thẳng thắn với họ về vấn đề này. Em cảm thấy không thoải mái về cách làm việc này vì bọn em cũng muốn có tiếng nói trong việc thiết kế sản phẩm, chứ cứ bắt em vẽ UI không thực sự mất động lực. Chúng ta phải mạnh mẽ đứng lên chia sẻ để giải quyết vấn đề cốt lõi thay vì ngày nào nghĩ tới công ty đi làm áp lực rồi nghỉ sớm. Điều này trước đây Long cũng từng bị khi làm ở công ty đây gần nhất và Long cứ giữ trong lòng dẫn tới bản thân bị stress và nghỉ sớm. Vậy thay vì nghỉ trong ấm ức thì tại sao chúng ta không thử chia sẻ nỗi lòng của chúng ta với các PO PM. Nếu có nghỉ sau đấy ít nhất chúng ta không cảm thấy hối hận. Đừng như Long nghỉ rồi mới thấy hối hận. Nhưng hãy lựa vào 1 thời điểm nào đấy không có đồng nghiệp và như mời PO PM đi ăn trưa hoặc cà phê lúc nào tâm lý của họ đã thực sự thoải mái. Đừng góp ý và chia sẻ trước mặt các thành viên khác họ sẽ bị quê và có khi họ cho các bạn nghỉ việc luôn ngay lập tức.
Tóm lại cứ chia sẻ thẳng thắn chúng ta chả phải sợ bố con thằng nào cả :))) Mình đùa đấy, chúng ta đi làm chúng ta offer công sức thì công ty offer lương, tức 2 bên mối quan hệ win-win.
6. Kết Lại
Trước khi các Product Designer cảm thấy khó chịu về PO PM áp bức chúng ta thì chúng nên đặt câu hỏi trước là chúng ta đặt thật sự hiểu tâm tư và tầm nhìn của PO PM. Chúng ta có hiểu nhầm ý kiến của PO PM không. Nếu không hiểu nhầm thì chúng ta thử các cách xử lý phía trên để giải quyết. Chúng ta không thể ép 1 con người thấu hiểu người khác khi bản thân họ còn chưa biết họ đang gặp vấn đề. Nên chúng ta cứ thẳng thắn chia sẻ với các PO PM. Còn bạn nào vẫn gặp vấn đề thì hãy inbox Zalo cho Long để cùng nhau thử nghĩ cách giải quyết xem sao nhé!
Thông tin thêm về mình:
Mình có một thời gian trải nghiệm làm tại các công ty như Onpoint, VnExpress, KAS, Zalo. Mình cũng hiện là Trainer và quản lý chất lượng khối Product Manager của 1 trung tâm đào tạo công nghệ lớn tại Việt Nam. Đồng thời mình cũng đang là một trong những người tiên phong tư vấn ứng dụng bài bản Job To Be Done cho các Bank và công ty công nghệ tại Việt Nam. Một số mình tư vấn đã ứng dụng như Momo, Chợ Tốt, BIDV, Vua Nệm… và một số công ty Startup AI khác. Background của mình thật ra không dính tí gì tới Product cả :v Mình học Quantitative Finance rồi lên Master mình học Applied Economic and Data Science của chương trình Erasmus University Rotterdam với UEH. Mình có một bài viết liên quan về “Hấp thụ công nghệ và bằng chứng về Hội Tụ Câu Lạc Bộ” tại hội nghị Kinh Tế Châu Á, được đăng trên tạp chí khoa học JABES. Mình thấy khá hứng thú về hấp thụ công nghệ nên từ đấy mình chuyển sang làm công nghệ và Product luôn là thế. Mình là dân dữ liệu và định lượng nhưng mình lại có niềm đam với việc tìm hiểu các nhu cầu của khách hàng.
Mình có 2 công ty: 1 công ty về Education, 1 công ty về cửa hàng đồ ăn. Bạn nào ở HCM có thể qua ăn ủng hộ :D
Cộng Đồng Job To Be Done:
Các kênh và group có tên “Job To Be Done Viet Nam” hoặc Job To Be Done VN” hầu như là của mình nên mọi người search là ra.
Linkedin của mình:
Đăng ký để đọc nhiều bài viết hay hơn!!!
Cảm ơn anh Long về bài viết chia sẻ khá hay và thực tế ạ. Mong các bài viết tiếp theo ít sai chính tả xíu để mn đọc dễ hiểu hơn. Thanks anh ạ.