Định nghĩa Stakeholder & vai trò
Đôi khi trong một cuộc nói chuyện về product design, bạn sẽ nghe tới “chức danh” này, như khi ai đó kêu “cần phải làm việc với stakeholder” hoặc “idea này có khi sẽ không được stakeholder đồng ý“. Vậy họ thật sự là ai? họ làm gì?
Không giống hầu hết các vai trò khác trong ngành product, Stakeholder không phải là một chức danh – không ai có card visit ghi “Stakeholder”. Đây là một vị trí quan hệ: ai đó trở thành stakeholder của một sản phẩm khi họ có lợi ích, quyền lực, hoặc trách nhiệm liên quan đến kết quả của sản phẩm đó.
Nghĩa tổng quát: Bất kỳ ai bị ảnh hưởng bởi sản phẩm đều là stakeholder – kể cả người dùng cuối, đối tác, cộng đồng xung quanh, và thậm chí xã hội nói chung. Đây là định nghĩa gốc trong quản trị doanh nghiệp và sustainability, nơi “stakeholder” đối lập với “shareholder” (cổ đông) để nhấn mạnh rằng một tổ chức có trách nhiệm với nhiều bên hơn là chỉ những người góp vốn.
Nghĩa hẹp – phổ biến trong thực hành product/UX: Stakeholder là những người bên trong hoặc gắn liền với tổ chức, không phải người dùng cuối, nhưng có quyền lực hoặc lợi ích trực tiếp ảnh hưởng đến quyết định xây dựng sản phẩm. Đây là nghĩa được dùng hàng ngày khi Designer nói “tôi cần present cho stakeholder” hay “stakeholder muốn thêm tính năng này”.
Trong ngữ cảnh thực hành, stakeholder thường là: CEO và C-level, Product Manager, Engineering Lead, Marketing Director, Sales, Legal/Compliance, và đôi khi là đối tác kinh doanh bên ngoài. Mỗi người trong số này có góc nhìn, ưu tiên, và định nghĩa về “thành công” khác nhau – và tất cả đều có ảnh hưởng đến sản phẩm mà Designer đang xây dựng.
Điểm quan trọng cần hiểu ngay từ đầu: stakeholder không phải người dùng. Đây là sự phân biệt có vẻ hiển nhiên nhưng thường bị mờ đi trong thực tế – đặc biệt khi stakeholder cho rằng họ đại diện cho người dùng, hoặc khi họ thực sự có dùng sản phẩm nhưng dùng theo cách rất khác với người dùng phổ thông.
Stakeholder làm gì và đóng góp gì cho sản phẩm?
Stakeholder không xây sản phẩm trực tiếp – nhưng họ tạo ra môi trường mà sản phẩm được xây trong đó. Đóng góp của họ đến từ ba hướng:
Định hướng chiến lược
C-level và các decision maker cấp cao thiết lập mục tiêu kinh doanh, phân bổ nguồn lực, và quyết định sản phẩm nào được đầu tư và ở mức độ nào. Không có sự ủng hộ từ stakeholder cấp cao, ngay cả dự án UX tốt nhất cũng có thể bị cắt ngân sách hoặc deprioritize.
Ví dụ: CEO quyết định pivot từ B2C sang B2B sẽ thay đổi toàn bộ đối tượng người dùng mà Designer đang hướng tới, các quyết định thiết kế trước giờ tự nhiên rơi vào trạng thái cần phải tái cấu trúc. Khá là cồng kềnh.
Có thể bạn sẽ quan tâm về 3 tiêu chí của một sản phẩm tốt, đọc thêm tại đây:
- Feasibility: tính Khả thi – 3 trụ cột đánh giá Product Design
- Viability: tính Kinh doanh – 3 trụ cột đánh giá Product Design
- Desirability: tính Hấp dẫn người dùng – 3 trụ cột đánh giá Product Design
Cung cấp context và constraint
Mỗi nhóm stakeholder mang đến một loại context mà Designer không tự có được:
- Engineering Lead biết cái gì có thể xây được, trong bao lâu, với chi phí kỹ thuật là bao nhiêu.
- Marketing biết người dùng đang được thu hút bằng thông điệp gì và kỳ vọng gì khi họ bắt đầu dùng sản phẩm.
- Sales có feedback trực tiếp từ khách hàng doanh nghiệp – những thứ người dùng nói trong cuộc gọi bán hàng mà không xuất hiện trong usability test.
- Legal/Compliance đặt ra những giới hạn không thể vượt qua về data, privacy, và quy định ngành – đặc biệt quan trọng với fintech, healthcare, và edtech.
Ra quyết định và phê duyệt
Ở hầu hết tổ chức, design không thể được ship mà không có sự đồng ý từ một hoặc nhiều stakeholder. Họ là người review design, raise concern, và cuối cùng sign-off để đưa sản phẩm ra thị trường. Hiểu ai cần approve cái gì, và ở bước nào trong quy trình, là một phần không thể thiếu trong công việc của Designer.
Bạn cần gì để trở thành stakeholder có ảnh hưởng trong sản phẩm?
Đây là một câu hỏi thú vị – vì nó lật ngược góc nhìn. Thay vì chỉ hỏi “làm thế nào để làm việc với stakeholder”, chúng ta có thể hỏi “làm thế nào để trở thành stakeholder đáng được lắng nghe” cho thấy một tư duy trưởng thành hơn về career, nhất là trong góc nhìn của một UI/UX Product Designer.
Có domain knowledge thực sự
Stakeholder có ảnh hưởng là người mang đến perspective mà người khác không có. Nếu bạn là Designer muốn có tiếng nói trong quyết định sản phẩm, bạn cần biết nhiều hơn về UX – biết về business model của công ty, về competitive landscape, về cách sản phẩm tạo ra doanh thu. Kiến thức đó là lý do người ta nghe bạn, không phải chức danh của bạn.
Xây dựng track record
Stakeholder có ảnh hưởng là người đã chứng minh được rằng judgment của họ đáng tin. Trong thực hành, điều này có nghĩa là: đưa ra dự đoán, theo dõi kết quả, và học từ những lần sai. Người được lắng nghe trong phòng họp thường là người đã từng nói “tôi nghĩ nếu chúng ta làm X thì Y sẽ xảy ra” – và họ đúng.
Biết cách frame vấn đề theo ngôn ngữ của stakeholder khác
Để trở thành stakeholder thực sự ảnh hưởng, bạn cần có khả năng translate – dịch concern của người dùng thành ngôn ngữ business mà CEO hiểu, dịch technical constraint của engineer thành impact với người dùng mà PM quan tâm. Người có khả năng này tự nhiên trở thành người được hỏi ý kiến trong nhiều quyết định khác nhau.
Có quan điểm và dám defend nó
Stakeholder thụ động – người chỉ đồng ý với mọi thứ – không có ảnh hưởng thực sự. Ảnh hưởng đến từ việc có quan điểm rõ ràng, được hình thành từ data và reasoning tốt, và sẵn sàng defend nó một cách constructive khi bị challenge.
Cẩm nang phối hợp và làm việc cùng stakeholder
Stakeholder và Designer collab với nhau như thế nào?
Quan hệ giữa Designer và Stakeholder khác hoàn toàn với quan hệ giữa Designer và Engineer hay PM. Đây không phải collaborative relationship theo nghĩa cùng làm một việc – mà là một relationship về sự ảnh hưởng, giao tiếp, và thuyết phục.
Stakeholder Interview – đầu dự án
Trước khi bắt đầu thiết kế, Designer cần hiểu perspective của các stakeholder chính: họ định nghĩa thành công là gì, họ lo ngại điều gì, và họ kỳ vọng gì từ dự án này. Stakeholder interview khác user interview ở chỗ – không phải hỏi về hành vi và pain point, mà hỏi về mục tiêu kinh doanh, constraint, và cách họ đo lường kết quả.
Design Presentation và Review
Đây là điểm giao tiếp thường xuyên nhất. Designer present work-in-progress hoặc final design cho stakeholder để lấy feedback và approval. Presentation cho stakeholder cần được chuẩn bị khác với presentation cho team – tập trung vào business impact, không phải chi tiết design; nói ngôn ngữ của họ (revenue, conversion, risk), không phải ngôn ngữ UX (hierarchy, affordance, mental model).
Stakeholder Management – trong suốt dự án
Không phải mọi stakeholder đều cần được update ở cùng tần suất hay cùng mức độ chi tiết. Một trong những kỹ năng quan trọng nhất của Designer senior là biết ai cần biết gì và khi nào – tránh tình trạng stakeholder quan trọng bị surprise bởi một quyết định lớn ở cuối dự án, hoặc ngược lại bị overwhelm bởi quá nhiều update không liên quan.
Conflict Resolution – khi stakeholder không đồng ý nhau
Tình huống phổ biến và khó xử nhất: hai stakeholder có ưu tiên mâu thuẫn nhau. Marketing muốn thêm promotional banner lớn trên homepage, Engineering muốn đơn giản hóa để giảm load time, và CEO muốn cả hai. Designer thường là người phải navigate situation này – dùng data và user insight để đưa ra đề xuất có căn cứ, không phải chỉ cố gắng làm hài lòng tất cả mọi người.
Làm việc với stakeholder cần tư duy và kỹ năng gì?
Tư duy: Stakeholder không phải đối thủ
Một trong những bẫy tư duy phổ biến nhất với Designer là xem stakeholder như trở ngại – người hay “block design” hoặc “không hiểu UX”. Tư duy này tạo ra adversarial dynamic không cần thiết và thường phản tác dụng.
Stakeholder có lý do hợp lý cho phần lớn những gì họ yêu cầu – họ chịu áp lực từ thị trường, từ board, từ đối thủ cạnh tranh, hoặc từ constraint mà Designer chưa có đủ context để thấy được. Thay vì phản ứng với “tại sao họ muốn điều này”, câu hỏi productive hơn là “điều gì đang thúc đẩy yêu cầu này và tôi có thể giải quyết underlying need đó bằng cách tốt hơn không?”
Tư duy: Advocacy (đề xuất, khuyến khích), không phải compliance (tuân thủ)
Designer không có nghĩa vụ làm theo mọi yêu cầu của stakeholder – đồng thời, designer cũng không có quyền dismiss chúng. Vai trò đúng là advocate (khuyến nghị, vận động): đưa ra perspective người dùng một cách rõ ràng, chứng minh được bởi data, và đề xuất giải pháp thay thế khi một yêu cầu xung đột với trải nghiệm người dùng.
Điều này đòi hỏi sự tự tin và kỹ năng giao tiếp – và quan trọng hơn, đòi hỏi data. Không thể push back bằng “tôi cảm thấy cái này không tốt cho người dùng”. Phải có: usability test data, analytics, hoặc ít nhất là reasoning có căn cứ rõ ràng.
Kỹ năng: Stakeholder mapping
Trước khi bắt đầu dự án, xác định rõ: ai là stakeholder, họ quan tâm đến điều gì, mức độ ảnh hưởng của họ là bao nhiêu, và họ hiện đang support hay neutral hay resist dự án. Công cụ đơn giản nhất là ma trận 2×2: trục dọc là mức độ ảnh hưởng (power), trục ngang là mức độ quan tâm (interest).
- High power, high interest – Manage closely. Đây là những người cần được update thường xuyên và cần được involve trong quyết định quan trọng.
- High power, low interest – Keep satisfied. Đừng làm họ surprise, nhưng không cần overwhelm với detail.
- Low power, high interest – Keep informed. Họ có thể là supporter quan trọng hoặc nguồn insight tốt.
- Low power, low interest – Monitor. Ít effort nhất, chỉ update khi cần thiết.
Kỹ năng: Storytelling với data
Stakeholder thường ra quyết định nhanh và dựa trên big picture, không phải detail. Presentation hiệu quả với stakeholder không phải là walkthrough chi tiết từng màn hình – mà là narrative rõ ràng: đây là vấn đề người dùng đang gặp, đây là impact với business, đây là giải pháp chúng tôi đề xuất, và đây là lý do nó sẽ hiệu quả.
Data không tự nói chuyện – người present cần frame data theo cách stakeholder quan tâm. Số liệu drop-off rate trên checkout flow chỉ có ý nghĩa khi được translate thành “mỗi tháng chúng ta đang để mất X triệu đồng doanh thu vì người dùng abandon ở bước này.”
Kỹ năng: Biết khi nào nên escalate
Không phải mọi bất đồng với stakeholder đều cần được giải quyết ngay lập tức ở cấp thấp nhất. Đôi khi conflict giữa hai stakeholder cần được escalate lên cấp cao hơn để được giải quyết – và Designer cần biết khi nào tình huống đó xảy ra, cách raise issue một cách professional, và tránh để conflict âm ỉ kéo dài mà không được giải quyết.
Kết luận
Stakeholder không phải vai trò bạn apply vào – mà là vị trí bạn chiếm giữ trong hệ sinh thái của một sản phẩm. Hiểu stakeholder là ai, họ muốn gì, và cách làm việc với họ hiệu quả là một trong những kỹ năng phân biệt Designer junior và Designer senior rõ rệt nhất.
Designer giỏi không phải người làm đúng theo stakeholder, cũng không phải người chống lại stakeholder để bảo vệ “sự thuần túy của UX“. Mà là người biết cách navigate sự phức tạp của nhiều perspective khác nhau – dùng insight về người dùng như một ngôn ngữ chung để align tất cả các bên xung quanh mục tiêu thực sự: xây sản phẩm mà người dùng thực sự muốn dùng và business có thể phát triển bền vững từ đó.
Những tư duy như thế này nếu chỉ đơn thuần hiểu về design và các chuyên môn UI/UX đôi khi bạn sẽ bị bỏ qua mất. Các kiến thức này thường được trang bị rất kĩ trong khóa Product Design & Manage. Bạn có thể đăng ký dưới đây.
