مدیریت ذی‌نفعان برای مدیر محصول یعنی تبدیل درخواست‌ها و تعارض‌ها به تصمیم شفاف؛ با ماتریس نفوذ، برنامه ارتباطی، DACI، مثال و چک‌لیست عملی.
مدیریت ذی‌نفعان برای مدیر محصول یعنی شناخت افرادی که بر محصول اثر می‌گذارند یا از تصمیم‌های آن اثر می‌پذیرند، فهم منافع و محدودیت‌هایشان و ساختن یک مسیر شفاف برای مشارکت، تصمیم و اطلاع‌رسانی. هدف این نیست که همه را همیشه راضی نگه دارید؛ هدف این است که مسئله درست، شواهد، حق تصمیم و پیامد انتخاب‌ها برای افراد درست روشن باشد.
مدیر محصول میان کاربر، تیم سازنده و کسب‌وکار حرکت می‌کند. فروش تعهد مشتری را می‌بیند، پشتیبانی تکرار درد را، حقوقی ریسک را، مالی هزینه را و مدیرعامل جهت استراتژیک را. اگر این سیگنال‌ها به فهرست قابلیت تبدیل شوند، roadmap میدان رقابت صداهای بلندتر می‌شود. مدیریت خوب، درخواست را به نیاز، محدودیت یا نتیجه مطلوب ترجمه می‌کند و سپس تصمیم را به outcome محصول وصل نگه می‌دارد.
این راهنما در ۶ اکتبر ۲۰۲۶ با منابع جاری بازبینی شده است. راهنمای محصول دولت بریتانیا نیز «مدیریت رابطه با ذی‌نفعان» را مهارتی مستقل برای مدیر محصول می‌داند: شناخت ذی‌نفعان، طراحی ارتباط، حل مسئله و ساخت رابطه بلندمدت. اگر ابتدا باید مرز نقش‌ها را روشن کنید، تفاوت مدیر محصول، مالک محصول و مدیر پروژه را بخوانید.
هر همکار علاقه‌مند، ذی‌نفع کلیدی نیست. ذی‌نفع کسی است که مسئول بخشی مهم از کسب‌وکار یا تجربه کاربر است، قید معتبری وارد تصمیم می‌کند، منابع لازم را در اختیار دارد، از نتیجه اثر جدی می‌پذیرد یا می‌تواند عرضه را متوقف کند. معمولاً مدیران ارشد، مهندسی، طراحی، فروش، بازاریابی، پشتیبانی، عملیات، مالی، امنیت، حقوقی و انطباق در این دایره قرار می‌گیرند؛ اما ترکیب آن با مرحله و نوع محصول تغییر می‌کند.
SVPG در راهنمای ۲۰۲۵ همکاری ذی‌نفع و تیم محصول سه ورودی ارزشمند را برجسته می‌کند: زمینه و محدودیت کسب‌وکار، صورت‌بندی کار به شکل مسئله و نتیجه، و دسترسی تیم به مشتری، کاربر و داده. این تفکیک مهم است: ذی‌نفع باید مسئله و قید را روشن کند، اما راه‌حل از پیش‌تعیین‌شده را به تیم تحمیل نکند.
کاربر نیز همیشه ذی‌نفع سازمانی نیست؛ اما مهم‌ترین منبع فهم ارزش است. صدای کاربر را نباید با نظر مدیر ارشد هم‌وزن یا جایگزین کرد. مدیر محصول باید هر دو را به شواهد قابل‌مقایسه تبدیل کند: مشکل چه کسی است، چند بار رخ می‌دهد، چه outcomeای را تهدید می‌کند و هزینه حل‌نکردن آن چیست؟
به‌جای نوشتن فهرست تمام مدیران شرکت، یک تصمیم مشخص انتخاب کنید؛ مثلاً «آیا احراز هویت دومرحله‌ای را در این فصل عرضه کنیم؟». برای هر فرد یا گروه چهار مورد ثبت کنید: میزان نفوذ بر تصمیم، میزان اثرپذیری از نتیجه، دانشی که اضافه می‌کند و ریسکی که نمایندگی می‌کند.
سپس افراد را در ماتریس نفوذ و علاقه قرار دهید: نفوذ زیاد و درگیری زیاد نیازمند همکاری نزدیک است؛ نفوذ زیاد و درگیری کم به خلاصه مدیریتی و نقاط تصمیم نیاز دارد؛ نفوذ کم و اثرپذیری زیاد باید زود شنیده و منظم مطلع شود؛ سایر افراد فقط در تغییرهای مرتبط خبر می‌گیرند.
اصل پنجم مدیریت محصول در سرویس‌های دولتی بریتانیا که در ۲۸ آوریل ۲۰۲۶ بازبینی شده، پیشنهاد می‌کند ماتریس ذی‌نفعان مرتب مرور شود، ارتباط متناسب باشد و رابطه با گفت‌وگوهای یک‌به‌یک حفظ شود. پس نقشه را دست‌کم در شروع فصل، تغییر استراتژی یا ورود ذی‌نفع تازه بازبینی کنید.
وقتی فروش می‌گوید «این قابلیت باید تا نمایشگاه آماده شود»، فوراً وارد تخمین نشوید. بپرسید: کدام مشتری و کدام معامله؟ چه مشکلی حل می‌شود؟ موفقیت با چه رفتاری یا عددی دیده می‌شود؟ تاریخ واقعاً ثابت است یا هدف تجاری پشت آن؟ اگر قابلیت ساخته نشود چه گزینه‌ای داریم؟
خروجی گفت‌وگو باید شبیه این باشد: «سه مشتری سازمانی برای آغاز قرارداد به کنترل دسترسی نقش‌محور نیاز دارند؛ نتیجه مطلوب فعال‌شدن دو قرارداد تا پایان فصل است؛ قید حقوقی ثبت تاریخچه تغییرات است.» اکنون تیم می‌تواند چند راه‌حل را بررسی کند. این همان پیوندی است که در تفاوت Discovery و Delivery و اولویت‌بندی نقشه راه با هوش مصنوعی به آن نیاز دارید.
ابهام در اختیار، اختلاف فنی را به کشمکش سیاسی تبدیل می‌کند. برای تصمیم‌های پراثر از DACI استفاده کنید. در چارچوب DACI آتلسیان، Driver اطلاعات و افراد را برای رسیدن به تصمیم جمع می‌کند، یک Approver تصمیم نهایی را می‌گیرد، Contributors تخصص و توصیه می‌دهند و Informed پس از تصمیم در جریان قرار می‌گیرند.
یک نفر می‌تواند Driver باشد و لزوماً Approver نیست. تعداد Contributorها را محدود کنید و دقیق بنویسید تصمیم درباره چیست، گزینه‌ها و معیارها کدام‌اند و مهلت تصمیم چه زمانی است. DACI را برای تصمیم‌های بین‌تیمی، پرریسک یا گیرکرده نگه دارید.
همه به یک اسلاید هفتگی نیاز ندارند. برای هر گروه مشخص کنید چه چیزی، با چه تناوب، در چه کانالی و برای چه تصمیمی لازم است:
یک منبع حقیقت داشته باشید؛ مثلاً صفحه تصمیم یا roadmap مبتنی بر outcome. جلسه فقط برای حل ابهام یا تعارض باشد، نه خواندن اطلاعاتی که می‌شد ناهم‌زمان دید. برای طراحی outcome و متریک مشترک، راهنمای North Star Metric مکمل مفیدی است.
پشت موضع «این قابلیت را می‌خواهم» معمولاً منفعتی واقعی است: حفظ قرارداد، کاهش ریسک، کم‌شدن تماس پشتیبانی یا رسیدن به هدف درآمد. ابتدا همان منفعت را بازگو کنید تا مطمئن شوید درست فهمیده‌اید. سپس گزینه‌ها را با معیار مشترک مقایسه کنید: اثر بر کاربر، outcome کسب‌وکار، ریسک، هزینه فرصت، برگشت‌پذیری و سطح شواهد.
اگر داده کافی ندارید، اختلاف را با رأی‌گیری پنهان نکنید؛ یک آزمایش کوچک تعریف کنید. برای نمونه می‌توان جریان دستی یا prototype را با دو مشتری کلیدی آزمود. راهنمای آزمایش محصول کم‌هزینه برای همین موقعیت است. اگر تصمیم برگشت‌ناپذیر، قانونی یا امنیتی است، استاندارد شواهد و سطح تأیید را بالاتر ببرید.
پس از تصمیم، یک Decision Log کوتاه بنویسید: سؤال، تاریخ، Driver و Approver، گزینه‌های بررسی‌شده، شواهد، تصمیم، دلیل، پیامدها، فرض‌های باز و زمان بازبینی. سپس به Contributors نتیجه را نشان دهید و به Informedها اثر عملی را بگویید.
بستن حلقه اعتماد می‌سازد؛ حتی وقتی درخواست فرد انتخاب نشده است. افراد باید ببینند ورودی‌شان فهمیده و در معیارها لحاظ شده، نه اینکه در جلسه شنیده و بعد ناپدید شده است. اگر شواهد جدید فرض کلیدی را رد کرد، تصمیم را باز کنید؛ تغییر تصمیم با دلیل نشانه ضعف نیست.
فرض کنید فروش برای یک مشتری بزرگ «خروجی Excel خودکار» می‌خواهد، امنیت با ارسال فایل حساس مخالف است و تیم محصول روی بهبود فعال‌سازی کار می‌کند. مدیر محصول ابتدا درخواست را بازصورت‌بندی می‌کند: مشتری باید گزارش هفتگی را برای مدیرانی بفرستد که وارد سامانه نمی‌شوند؛ نتیجه مطلوب حفظ قرارداد و کاهش ۶ ساعت کار دستی است.
در نقشه ذی‌نفعان، فروش و امنیت نفوذ بالا دارند، کاربر عملیات اثرپذیری و دانش بالا دارد و مالی درباره ارزش قرارداد داده می‌دهد. مدیر محصول Driver، مدیر محصول ارشد Approver و فروش، امنیت، مهندسی و عملیات Contributors می‌شوند. گزینه‌ها شامل فایل رمزگذاری‌شده، لینک زمان‌دار فقط‌خواندنی و گزارش زمان‌بندی‌شده داخل محصول است.
تیم با دو کاربر prototype لینک زمان‌دار را می‌آزماید، امنیت قید دسترسی و audit را می‌افزاید و مالی ارزش حفظ قرارداد را تأیید می‌کند. تصمیم و دلیل ثبت می‌شود: عرضه لینک زمان‌دار برای پایلوت، با سنجش استفاده، رخداد امنیتی و زمان کار دستی. هیچ‌کس همه خواسته‌های اولیه‌اش را نگرفته، اما همه می‌دانند چرا این برش انتخاب شده و چه شاهدی تصمیم بعدی را تغییر می‌دهد.
تعداد جلسه معیار خوبی نیست. زمان رسیدن از مسئله به تصمیم، درصد تصمیم‌های دارای مالک و معیار روشن، تعداد غافلگیری‌های دیرهنگام، تغییر دامنه پس از شروع Delivery و تکرار بحث‌های حل‌شده را بسنجید. در کنار آن، هر فصل از چند ذی‌نفع بپرسید: آیا می‌دانید تیم روی چه outcomeای کار می‌کند؟ آیا می‌دانید چگونه ورودی بدهید؟ آیا دلیل تصمیم‌های مهم را پیدا می‌کنید؟
چارچوب رسمی نقش مدیر محصول دولت بریتانیا که در ۲۸ فوریه ۲۰۲۵ به‌روزرسانی شده، در سطح حرفه‌ای بر ارتباط روشن و منظم، حل مسئله، اثرگذاری و رابطه بلندمدت تأکید می‌کند. یعنی موفقیت فقط بردن یک مذاکره نیست؛ ساختن سیستمی است که تصمیم‌های بعدی را سریع‌تر و سالم‌تر می‌کند.
مدیریت ذی‌نفعان هنر راضی‌کردن همه نیست؛ طراحی یک سیستم تصمیم‌گیری قابل‌اعتماد است. افراد درست را برای تصمیم درست وارد کنید، درخواست‌ها را به مسئله و outcome تبدیل کنید، اختیار و معیارها را شفاف سازید و حلقه بازخورد را ببندید. نتیجه، تیمی نیست که تعارض ندارد؛ تیمی است که تعارض را زود، محترمانه و با شواهد حل می‌کند.
برای شروع، یک تصمیم گیرکرده این هفته را انتخاب کنید و فقط یک صفحه بسازید: سؤال، outcome، ذی‌نفعان، نقش DACI، گزینه‌ها، معیارها و موعد تصمیم. اگر برای ارزیابی الگوی همکاری یا تمرین یک گفت‌وگوی دشوار کمک می‌خواهید، ارزیابی بلوغ محصول تیم، پروداکت کلاب راه چابکی و منتورینگ مدیریت محصول قدم‌های بعدی‌اند.
