Tại sao tôi tin rằng quản lý stakeholder là kỹ năng sống còn của product manager – và cách RACI giúp bạn không phát điên

Tại sao tôi tin rằng quản lý stakeholder là kỹ năng sống còn của product manager – và cách RACI giúp bạn không phát điên

Lần đầu tiên tôi ngồi trong một buổi nói chuyện về product management, tôi háo hức nghĩ rằng công việc này chỉ xoay quanh việc “nghĩ ra tính năng mới”, vẽ wireframe, rồi bàn giao cho team dev. Nhưng khi ai đó hỏi: “Vậy ai sẽ phê duyệt ngân sách?” – cả căn phòng im lặng. Đúng lúc ấy tôi chợt nhận ra mình đã hiểu sai hoàn toàn. Làm product manager không chỉ là quản lý sản phẩm, mà còn là quản lý con người – đặc biệt là những người có quyền quyết định, có lợi ích, có ảnh hưởng lên dự án của bạn. Họ gọi chung là stakeholder. Và điều tôi tin nhất sau khi tự học về chủ đề này là: kỹ năng quản lý stakeholder chính là thứ quyết định sản phẩm của bạn sống hay chết, dù code có tốt đến đâu.

Nếu bạn cũng đang trên con đường tìm hiểu product management, bài viết này sẽ không chỉ cho bạn biết stakeholder là ai, mà còn giúp bạn hiểu vì sao việc phân loại họ, quản lý kỳ vọng, và dùng công cụ như RACI lại quan trọng đến vậy. Đây là những kiến thức tôi vừa học được từ quá trình tự tìm hiểu, và tôi muốn chia sẻ lại theo cách dễ hiểu, gần gũi nhất – không phải là một chuyên gia giảng dạy, mà là một người cùng học, cùng vật lộn với mớ bòng bong này.

Stakeholder không chỉ là “những người liên quan” – họ là mạng lưới quyền lực

Nghe cụm từ “stakeholder”, nhiều người mới sẽ nghĩ đó là sếp, khách hàng, hay đối tác. Đúng, nhưng chưa đủ. Trong một dự án product management, stakeholder xuất hiện từ CEO của công ty cho đến công chúng nói chung, với mức độ ảnh hưởng và quan tâm rất khác nhau. Có người có quyền quyết định cao, có người chỉ quan tâm một góc nhỏ, và có người chẳng biết bạn tồn tại nhưng lại bị ảnh hưởng bởi sản phẩm bạn làm. Điều đáng sợ nhất là: những stakeholder có mức độ ảnh hưởng và quan tâm cao có thể tác động mạnh đến dự án, thậm chí đẩy nó đến bờ vực hủy bỏ.

Chính vì vậy, cách đầu tiên tôi học được là phải nhận diện và phân loại họ một cách có chủ đích. Không phải ai cũng cần nhận cùng một loại thông tin. Ví dụ: CEO của bạn có thể chỉ muốn một bản cập nhật một trang giấy mỗi tuần, trong khi một kỹ sư lại cần báo cáo chi tiết về phần việc họ đang phụ trách, mất bao nhiêu thời gian, và có vướng mắc gì không. Nếu bạn gửi cho CEO một bản excel dài 20 trang, hoặc gửi cho kỹ sư một slide chiến lược chung chung, bạn sẽ nhanh chóng mất lòng tin từ cả hai phía.

Ngoài ra, stakeholder còn được chia thành nội bộ và ngoại bộ. Nội bộ có thể là quản lý cấp trung, các nhóm chức năng, hay phòng tài chính – kế toán. Ngoại bộ có thể là nhà cung cấp, người dùng cuối, hay các kênh phân phối. Mỗi nhóm có ngôn ngữ, mục tiêu và áp lực riêng. Người mới như tôi thường chỉ chăm chăm vào khách hàng, mà quên mất rằng đội kế toán cũng có thể là người duyệt chi phí, hay nhà cung cấp có thể làm đứt gãy chuỗi cung ứng nếu họ không thấy được lợi ích khi hợp tác. Vì vậy, lời khuyên thực tế đầu tiên cho bạn: hãy lập một danh sách stakeholder ngay từ khi dự án bắt đầu, đánh giá mức độ ảnh hưởng (thấp – vừa – cao) và mức độ quan tâm (thấp – vừa – cao) của từng người. Từ đó, bạn biết nên dành bao nhiêu thời gian cho họ, và nên truyền đạt theo hình thức nào.

Vai trò của bạn: quản lý kỳ vọng và kiểm soát ảnh hưởng lẫn nhau

Nhiều người tưởng rằng product manager chỉ cần “làm hài lòng” stakeholder. Nhưng học xong tôi mới thấy, công việc thực sự là quản lý kỳ vọng của họ – nghĩa là khiến họ hiểu rõ giới hạn của dự án, và lý do vì sao giới hạn đó tồn tại. Chẳng hạn, nếu khách hàng yêu cầu tính năng phải chạy nhanh gấp đôi trong khi ngân sách không đổi, bạn cần ngồi lại giải thích rõ đánh đổi giữa tốc độ, chi phí và chất lượng. Đó chính là lúc bạn phải làm “người mang tin buồn” nhưng lại không được làm họ mất niềm tin.

Khó hơn nữa, bạn còn phải quản lý cách stakeholder này ảnh hưởng đến stakeholder khác. Hãy xem tình huống trong bài học tôi tổng hợp lại: Raj là một giám đốc cung ứng, luôn quyết tâm tìm nhà cung cấp có giá rẻ nhất, dù anh ta biết rằng thành phần chất lượng cao hơn là cần thiết. Quyết định của Raj có thể kéo theo bộ phận kỹ thuật phải điều chỉnh thiết kế, và cuối cùng làm giảm tuổi thọ sản phẩm từ 8.000 giờ xuống còn 2.000 giờ – điều mà khách hàng của bạn hoàn toàn không mong muốn. Lúc này, bạn không thể luôn dễ dàng nói “Raj sai” vì anh ta có lý do riêng, mà bạn phải tìm cách cân bằng giữa mục tiêu chi phí của Raj với nhu cầu thực tế của khách hàng.

Một trong những biện pháp tôi thấy thú vị là hạn chế quyền truy cập thông tin ở một số giai đoạn. Nghe có vẻ phi dân chủ, nhưng trong một số ngữ cảnh, việc để một stakeholder có ảnh hưởng mạnh tiếp xúc trực tiếp với toàn bộ thông tin nhạy cảm có thể gây ra nhiễu loạn không đáng có.