Quản trị kỳ vọng khi làm PM/PO, khó hay dễ?
Không "say no" với stakeholder đời không nể.
Tiếp nối post lần trước của mình về: 4 điều mình nhận ra về ngành product sau khi bị lay off. Mình sẽ đi vào chủ đề được nhiều bạn rất đồng cảm - Quản trị kì vọng của Stakeholder dưới vai trò của một PM/PO.
Đầu tiên thì có một sự thật mà mình sẽ muốn làm rõ với các bạn:
Không bao giờ có thể quản trị hoàn toàn được kỳ vọng của toàn bộ các Stakeholder, đặc biệt là những người có nhiều quyền lực và ảnh hưởng.
Nếu mà quản trị được như vậy thì mình đã không bị lay off rồi. Vậy nên những gì mình chia sẻ sẽ là những thứ mà mình nghĩ mọi người có thể tránh và làm tốt hơn dựa trên trải nghiệm của mình.
Okay, let’s go!
1. Tại sao lại cần phải quản trị kỳ vọng?
Như mình đã nói ở post trước, trong tất cả các kĩ năng về Product management, chúng ta sẽ được học về rất nhiều template và mindset cho việc nghiên cứu user, giải quyết vấn đề, etc… Nhưng chỉ riêng phần “quản trị kỳ vọng” là kĩ năng mà không có một trường lớp hay khoá học nào dạy. Và dường như đa phần những đau khổ của anh em PM/PO lại đều đến từ việc này. Lý do là bởi Stakeholder sẽ luôn nghĩ:
Bạn là Dr.Strange
Tính năng này dễ phải không em?
Cái này làm có 1 tuần là xong nhỉ?
Tuần sau là diễn ra sự kiện với Investor rồi, chuẩn bị tính năng xong trước đó 2 ngày cho chị để chạy thử sự kiện trước nhé.
Và rất nhiều các câu hỏi hoặc yêu cầu mà bạn phải là phù thuỷ thì mới có thể hô biến đáp ứng được stakeholders. Bạn không phải là phù thuỷ, chẳng có đũa phép và cũng chẳng có nhẫn. Thứ duy nhất bạn có là cái board backlog Jira lúc nào cũng đang trong tình trạng overload mà thôi.
→ Nếu không quản trị kỳ vọng, bạn sẽ mãi là "kẻ hứa hẹn" trong mắt họ. Niềm tin với Stakeholder là thứ rất khó để xây dựng nhưng sẽ sụp đổ rất nhanh.
Bạn là Master Chef, còn sản phẩm là buffet 5 sao
Sản phẩm nào cũng sẽ có những điểm còn hạn chế nhưng với các business stakeholder, đa phần họ sẽ luôn nghĩ rằng sản phẩm của mình là số một hoặc chẳng qua vì một lý do abcxyz gì đó mà sản phẩm của chúng ta ít người dùng hơn đối thủ chẳng hạn (nghe quen không nào).
Thực tế thì sản phẩm của chúng ta không phải là buffet 5 sao mà là bánh mì chảo còn chúng ta không phải Master Chef mà chỉ là người bếp trưởng đang cố gắng làm tốt hết sức có thể với những nguồn nguyên liệu hạn chế mà thôi.
→ Nếu không làm rõ kì vọng, bạn hoàn toàn có thể bị đánh giá sai khả năng và bay màu nhanh chóng .
2. Vậy cần làm gì để quản trị kỳ vọng?
Để quản lý được kì vọng của Stakeholders, sẽ có 3 thứ mà mình nghĩ các bạn cần chuẩn bị.
Hiểu sản phẩm như hiểu bản thân
“Biết người biết ta, trăm trận trăm thắng” - nếu như không hiểu được sản phẩm của mình (ưu điểm, khuyết điểm và cả những góc tối) thì rất khó để có thể có được sự lắng nghe từ phía các Stakeholder. Bởi đơn giản, nếu bạn không hiểu sản phẩm, những quan điểm mà bạn đưa ra sẽ không có sức thuyết phục.
Thảm hoạ nhất sẽ là khi các Stakeholder có độ hiểu biết về sản phẩm còn lớn hơn chính bạn. Đặc biệt là với những PM/PO mới tiếp nhận team cũng như sản phẩm thời gian đầu.
Vậy nên mọi người hãy chú ý tìm hiểu cặn kẽ mọi tính năng và feedback từ khách hàng khi đang trong những ngày onboard nhé. Mình sẽ viết về checklist cần làm khi onboard cho các bạn PM/PO trong một bài khác.
Dám nói không (nhưng với lý do nghe được)
Với một đứa từng là “People pleaser” (người luôn muốn làm hài lòng tất cả mọi người) như mình, đây là thứ tối quan trọng mà mình luôn muốn nhấn mạnh cho tất cả các anh em PM/PO hiện tại. TUYỆT ĐỐI KHÔNG SAY YES NGAY LẬP TỨC VỚI MỌI REQUEST hoặc bạn sẽ tự đào hố chôn chính mình.
Bản thân mình trước đây phải làm việc với các stakeholder có title và sức ảnh hưởng rất lớn ở công ty từ Sale director, Marketing manager cho đến cả CEO. Các bạn biết thứ kĩ năng mà những người ở vị trí cao này giỏi nhất là gì không? Không phải là kĩ năng chuyên môn, thứ họ giỏi nhất chính là khả năng thao túng suy nghĩ (manipulate).
Concept thao túng mà các Stakeholder thường dùng
Với tầm ảnh hưởng của mình, họ thường sẽ tạo áp lực cho PM/PO theo concept:
Mức độ quan trọng của request + hậu quả của việc không làm (hoặc không đúng timeline) + chi tiết về request
Ví dụ: “Em ơi anh đang có request này siêu gấp, sắp tới ngày Sale 08/03 rồi, không kịp là phía anh không có gì để push số luôn, em triển khai giúp anh một màn hình dashboard hiển thị doanh số sale khi livestream cho khách hàng cùng với bình luận và lượt chia sẻ nhé”.
Mức độ quan trọng ở đây: “Request này siêu gấp”.
Hậu quả của việc không đúng timeline hoặc không làm: “sắp tới ngày sale 08/03”, “Không kịp là không có gì để push số”.
Yêu cầu chi tiết: “dashboard hiển thị doanh số sale khi livestream cho khách hàng cùng với bình luận và lượt chia sẻ”.
Nếu như là 1 PM/PO mới vào ngành bạn sẽ trả lời như thế nào ngoài việc phải meeting với team phát triển và triển khai task chèn vào sprint đây. Mình trước đây cũng thường xuyên rơi vào hoàn cảnh này và kết quả là anh em team dev phải OT mệt nhoài cuối tuần để vừa hoàn thành được các hạng mục Sprint goal từ trước cũng như task chèn.
Vậy giải pháp mà mình đã vượt qua là gì?
Hãy dùng Data để validate request
Trong concept mà các Stakeholder thường dùng để thao túng PM/PO chúng ta tồn tại một nhược điểm chí mạng, đó là nó rất “bánh vẽ”. Nó chỉ là giả thiết của stakeholder về việc nếu làm tính năng đó thì sẽ có được kết quả như mong muốn như tăng sale, tăng lead, revenue… Nhưng đặt câu hỏi ngược lại, nếu không thì sao? Điều gì chứng minh được nếu làm feature đó, kết quả sẽ tích cực như họ nói.
Đây chính là lúc mà Data-driven decision lên tiếng, chúng ta cần mạnh dạn challenge lại các stakeholder về những data chống lưng cho yêu cầu của họ.
Liệu có đối thủ nào đã làm như vậy chưa?
Doanh thu của họ có tốt hơn khi có tính năng đó không?
Có khách hàng nào có nhu cầu về tính năng đó hay chưa?
Rất nhiều những câu hỏi để validate được idea/request của stakeholder. Còn gì tuyệt hơn nếu như Stakeholder có được những câu trả lời để validate idea/request hộ chúng ta đúng không nào? Còn nếu không, chúng ta hoàn toàn có đủ quyền để SAY NO.
Hiểu được mục tiêu cuối cùng của một Stakeholder
Một mẹo của mình khi đối mặt với những request theo dạng thao túng như trên, đó là hãy xác định mục đích cuối cùng mà họ hướng tới, từ đó sẽ có cách phản hồi thích hợp. Ví dụ: Sale sẽ luôn quan tâm tới doanh thu, Marketing sẽ quan tâm tới Lead, Customer service sẽ luôn quan tâm tới số lượng review, ticket phàn nàn…
Giao tiếp minh bạch, mục tiêu rõ ràng
Cái này thì chắc mọi người đều biết rồi, thế nhưng mình vẫn phải lưu ý. Đó là bởi khi bị cuốn vào quá nhiều những task/request, mọi người thường sẽ quên luôn những tài liệu mình cần đang được lưu trữ ở chỗ nào.
Một đoạn tin nhắn, một chiếc meeting notes hay một business requirement, hãy phân loại thật khoa học và gửi email đầy đủ cho các Stakeholder liên quan. Cái này quan trọng nên nhắc lại, luôn luôn phải có email cho các Stakeholder liên quan, nó sẽ là thứ giúp bạn thoát pressing khi bị các Stakeholder hay quên dí task đó.
Stakeholder lạ lắm, những gì mà chúng ta hứa thì họ luôn nhớ rất rõ nhưng những gì mà họ hứa với chúng ta thì mình không chắc họ có nhớ không. Vậy nên việc có văn bản chính là để nhắc nhở cho cả 2 phía về vai trò và trách nhiệm của mình
3. Quản trị kỳ vọng như thế nào?
Thực ra quản trị kỳ vọng là thứ giúp chúng ta cân bằng giữa hứa hẹn và thực tế.
Như biểu đồ trên, mặc dù cùng delivery được 1 tính năng với chất lượng như nhau nhưng một bên thì Stakeholder rất happy, còn bên ngược lại thì rất tức giận. Sự khác biệt chính là nằm ở việc chúng ta hứa hẹn và cho họ kỳ vọng như thế nào.
Vậy cụ thể chúng ta sẽ làm như thế nào? Mình không có framework gì cho việc này cả nhưng đây sẽ là 4 mẹo mọi người có thể cân nhắc.
Hứa ít, làm nhiều (Under promise, over delivery)
Mình có cơ hội được làm việc khá sát với Meta (theo dạng Partnership) khi còn làm việc tại công ty cũ. Có một thứ mà Partnership Manager khu vực APAC luôn luôn nhắc mình trước khi tham gia bất kì một buổi conference đó là:
“Không bao giờ cam kết số hay hạn deadline trong mỗi buổi hội thảo”.
Và đến giờ, lời nhắc nhở đó vẫn được mình áp dụng rất nhiều.
Việc cam kết thời hạn hay KPI khi chưa tìm hiểu rõ ràng mọi thứ sẽ rất dễ đẩy chúng ta vào tình trạng há miệng mắc quai. Cam kết quá khả năng và phải chỉnh sửa lại mục tiêu hoặc thậm chí là xin lỗi các Stakeholder vì fail cam kết.
Để Stakeholder thất vọng đáng sợ 1 thì để chính team của mình thất vọng đáng sợ 10. Khi PM không nhận được sự tín nhiệm của team sản phẩm nữa thì bạn có thể hiểu thời gian làm việc của mình ở đây không còn lâu nữa đâu.
Thông thường, khi bắt buộc phải cam kết về thời hạn deadline với các Stakeholder, mình sẽ suy nghĩ và setup meeting với team PTSP và cộng thêm 2-3 ngày để đề phòng bug hoặc issue có thể xảy ra với sản phẩm trước khi đưa ra deadline chính thức. Kịch bản đẹp đó là khi team hoàn thành sớm hơn so với deadline, bạn sẽ có được sự tín nhiệm từ phía các stakeholder.
Hãy kiên nhẫn lắng nghe
Dù xung đột với các stakeholder thường xảy ra nhưng điều đó không có nghĩa là PM và stakeholder luôn khác biệt. Chúng ta đều hướng đến một mục tiêu chung: Đem lại giá trị cho business qua những giải pháp đem tới cho khách hàng. Thế nên việc kiên nhẫn để lắng nghe là yếu tố tiên quyết thay vì phản ứng ngay lập tức khi chưa làm rõ được vấn đề.
Ví dụ: Stakeholder nói "Tôi muốn nút này màu đỏ" → Đừng vội phản hồi "Không được", hãy hỏi "À, anh/chị muốn nút đỏ để tăng tỷ lệ click, đúng không?".
Họ cần giải pháp, không phải màu sắc. Do đó, hãy luôn lắng nghe và giúp các Stakeholder làm rõ được mong muốn cuối cùng của mình. Đó chính là vai trò của người làm Product như chúng ta.
Đặt Stakeholder vào lựa chọn 50/50
Để mình kể cho các bạn một kịch bản này:
Team sản phẩm đang chạy hết công suất để launching tính năng A ra mắt sau khi kết thúc sprint và chỉ còn 4 ngày nữa là hết sprint
Vì một lí do bất khả kháng, Stakeholder muốn đưa một request B vào sprint với thời gian hoàn thành cũng là kết thúc sprint
Nguồn lực không thể cho phép làm được cả 2 mục tiêu cùng lúc.
Quen chứ? Nếu là bạn, bạn sẽ làm gì? Để team OT? Xin thêm nguồn lực?
Với tình huống ở trên, mình sẽ thường đặt Stakeholder vào lựa chọn 50/50. Kiểu như: “Nếu em thêm tính năng B này, anh/chị sẵn sàng cắt bớt tính năng A hoặc delay timeline không ạ” cùng 1 nụ cười trìu mến. Quả bóng trách nhiệm khi được đẩy sang cho stakeholder, sự thành công của 1 sprint giờ không nằm trên vai PM nữa mà là stakeholder, chắc chắn họ sẽ phải có sự cẩn trọng với những request của mình.
Chúng ta có thể có tất cả mọi thứ nhưng không phải là cùng một lúc.
Xử lý thay đổi chủ động
Làm product, chạy sprint mà không có bug, issue hoặc xử lý biến thì rõ ràng là bạn chưa làm PM thực thụ. Vậy nên việc xử lý thay đổi chủ động cũng là thứ mình muốn các bạn lưu ý.
Với các issue xảy ra, mình thường xử lý theo 5 bước sau:
Mình tin rằng nếu mọi người follow các bước trên thì Stakeholder không thể nào trách chúng ta được. Điều quan trọng đó là phải thông báo kịp thời và đưa ra hướng xử lý mới, đó là thứ mà mình thường làm khi có issue xảy ra. Trộm vía chưa bao giờ phải vào họp riêng với sếp khi chuyện này xảy ra.
Tạm kết
Bạn không thể khiến mọi người ngừng "mơ", nhưng có thể giúp họ mơ đúng hướng. Tất cả những mẹo và framework mình đưa ra đều là dựa trên trải nghiệm cá nhân của bản thân. Vậy nên việc áp dụng sẽ có thể work hoặc không.
Hi vọng mọi người qua bài viết này có thể chọn được một vài mẹo hữu ích cho bản thân. Và đừng buồn nếu như chúng ta không thể làm hài lòng hết tất cả mọi người, đó chưa bao giờ là nhiệm vụ của PM/PO.
Có những tình huống không thể từ chối mà chỉ có thể OT để làm thôi. Sếp top-down yêu cầu, nhân viên bottom-up ý thức.