Bài viết được đúc kết từ quá trình đi làm thực tiễn và học hỏi/ quan sát từ những người có kinh nghiệm trong lĩnh vực Product Management.

*"Stakeholder là cá nhân, nhóm hoặc tổ chức có thể ảnh hưởng, bị ảnh hưởng hoặc nhận thấy bản thân bị ảnh hưởng bởi quyết định, hoạt động hoặc kết quả của dự án, chương trình hoặc danh mục."

Tạm hiểu theo cách đơn giản là những người tìm tới mình và đưa ra yêu cầu cho sản phẩm/ tính năng sắp tới.*

1. Không để bị cuốn theo giải pháp của họ

• Trước khi đưa ra yêu cầu với team Product, phía business hoặc BOD thường đã suy nghĩ khá nhiều về vấn đề và cách giải quyết vấn đề. Họ thường tìm tới team Tech khi đã có 1 giải pháp và mong muốn team Tech sẽ hiện thực hoá nó. Điều này đôi lúc đúng, nhưng nếu có nhiều stakeholder cùng làm như vậy, thì hẳn cái sản phẩm của mình sẽ thành 1 mớ hỗn độn ngay lập tức.

-> Đừng hỏi: Bạn muốn làm gì?

-> Hãy hỏi: Bạn muốn gì?

(*) bài học này mình học được khi mình còn đóng vai trò là Stakeholder ở công ty cũ, anh Sr. PM luôn luôn gạt phăng những giải pháp phía mình đưa ra. Tuy nhiên, có 1 hạn chế là anh chỉ cho mình 1 giải pháp phát triển khác (nếu có sự tham gia của team Tech), nhưng với trường hợp team Tech chưa làm ngay (lý do ở mục số 2) thì anh chưa đưa cho mình giải pháp thay thế cụ thể (mục số 3).

-> Hiện tại, mình đang đóng vai trò PM, và mình thường khắc phục bằng cách đưa ra cho stakeholder những cách có thể xử lý bằng tay (hoặc bằng các công cụ khác) trong thời gian team Tech chưa làm tính năng/ sản phẩm đó, và chỉ cho họ toàn bộ flow kết hợp giữa các công cụ (miễn phí) bên ngoài để có thể hoàn thành công việc. Đôi khi, với cách làm đó, team Tech cũng không cần phải phát triển thêm tính năng như yêu cầu, sẽ không lãng phí nguồn lực.

2. Sắp xếp độ ưu tiên

• Có một câu nói đùa: Backlog chính là những gì mà stakeholder yêu cầu liên tục (chứ không phải là đưa ra vision, rồi roadmap, rồi user story,... bla bla). Mình thấy đúng 1 phần, trong quá trình làm thực tế!

• Vậy khi có quá nhiều stakeholder cùng đến và nói: "Làm cho tớ tính năng này nhé! Gấp lắm!". Ai cũng có cái lý GẤP của họ.

-> Mình sẽ hỏi: Cái này phục vụ cho ai? Sẽ giải quyết được những gì? Hiệu quả (dự kiến) ra sao? (hiệu quả có thể đo được bằng chỉ số, liên quan tới mục tiêu của team/ công ty).

• Nếu các yêu cầu đều đến từ những người có "quyền lực" như nhau thì sao? Có 2 hướng:

Các bên phải thương lượng với nhau về thứ tự ưu tiên và chịu trách nhiệm về nó, tất nhiên sẽ có sự tham vấn từ team Product.

Uỷ thác cho team Product đưa thứ tự ưu tiên dựa vào độ phức tạp và phân tích MVP của từng yêu cầu, từ đó có thể đảm bảo release được các sản phẩm 1 cách sớm nhất cho tất cả các bên.

(*) Bài học này cũng từ khi mình đóng vai trò là stakeholder. Mình luôn nhận được câu hỏi: "Cái này sẽ làm ra bao nhiêu tiền cho công ty?". Nói vui là vậy, nhưng "tiền" ở đây chính là thứ mà tính năng đó (nếu có) sẽ giải quyết được: có thể là mang lại tiền cho công ty, rút ngắn thời gian làm việc của nhân viên, giảm số người lao động, tăng lượng user, tăng hiệu quả branding cho công ty,...

3. Biết "say no"

• Thông thường, phía business có rất nhiều ý tưởng rất hoành tráng, những chiếc "bánh vẽ" rất lớn rằng: nếu làm tính năng này như này, giống ông lớn kia, thì mình cũng sẽ được như họ,... Nhưng thường thì làm xong lại chẳng ai dùng, không có user, không có data, mọi thứ lại chỉ đi theo thiên kiến (bias) của stakeholder và kéo theo một vòng luẩn quẩn.

-> Mình sẽ hỏi về yêu cầu: Bạn muốn làm gì? (Không phải: Bạn muốn làm thế nào?) để biết được nhu cầu, và có thể gợi ý cho họ những giải pháp thay thế (có thể tốn tiền hay không). Khi những giải pháp đó (có thể sẽ chưa được hoàn thiện lắm, nhưng đủ để release) có thể chứng minh được hiệu quả dù chỉ rất nhỏ, team Tech sẽ bắt tay vào làm ngay.

Có 1 thứ mà stakeholder thường nghĩ: team Tech nhà làm thì miễn phí, đi mua bên ngoài thì mất phí. Nhưng họ quên mất rằng, team Tech làm thì cũng phải mất thời gian và cũng cần trả lương cho dev trong khoảng thời gian đó mà. Đôi khi, chi phí còn đắt đỏ hơn nhiều (lương dev đâu có thấp đâu :)) )

• Mình quan niệm rằng: Không nên build lại những gì mà các ông lớn đã làm rất tốt, hãy tận dụng họ, trừ khi xác định đó là đối thủ cạnh tranh của mình.

Trên đây là những đúc rút của mình trong quá trình làm sản phẩm và làm việc với những Senior trong nghề. Mình làm cả những sản phẩm cho end user, cả những sản phẩm tối ưu cho vận hành nội bộ, và thấy cả những điều trên đều đúng. Có lẽ quá trình làm stakeholder lại giúp cho mình hiểu tâm lý của họ hơn, và từ đó khi "deal" với họ cũng được thuyết phục hơn.