https://virgool.io/feed/@m_53134823 انسانی در حال یادگیری؛ نیمچه مدیرمحصول fa 2026-06-15 23:57:24 https://files.virgool.io/upload/users/4819735/avatar/YYMCbT.jpg?height=120&width=120 https://virgool.io/@m_53134823 https://virgool.io/@m_53134823/%D9%88%D9%82%D8%AA%DB%8C-%D9%87%D8%B1-%D9%81%D8%B1%D8%B5%D8%AA-%D8%AF%D8%B1%D8%A2%D9%85%D8%AF%DB%8C-%D8%AA%D8%A8%D8%AF%DB%8C%D9%84-%D9%85%DB%8C-%D8%B4%D9%87-%D8%A8%D9%87-%DA%A9%D8%A7%D8%B1-%D9%81%D9%88%D8%B1%DB%8C-%D8%AA%DB%8C%D9%85-%D9%85%D8%AD%D8%B5%D9%88%D9%84-umnjthkrfst0 همیشه مسئله این نیست که یه کار واقعاً فوریه.خیلی وقت‌ها مسئله اینه که سازمان زیر فشارِ از دست ندادن فرصته.توی این وضعیت، هر فرصت جدیدی خیلی سریع از یه «بد نیست بررسیش کنیم» می‌تونه تبدیل بشه به «باید همین الان بسازیمش.»مثلاً یه فرصت فروش جدید پیش میاد.یه مشتری بالقوه می‌گه اگر فلان قابلیت رو داشته باشین، می‌تونیم همکاری کنیم.یا بیزینس حس می‌کنه اگر الان نجنبیم، این شانس از دست می‌ره.و این فشار معمولاً خیلی زود می‌رسه به تیم محصول و فنی.برنامه‌ها جابه‌جا می‌شن، اولویت‌ها عوض می‌شن، roadmap عقب می‌افته و همه می‌رن توی مود واکنش نشون دادن؛ همه می‌خوان سریع‌تر تصمیم بگیرن و سریع‌تر یه چیزی تحویل بدن.مسئله این نیست که این فشارها همیشه بی‌منطقی‌ هستن و بیزینس چرا عجله داره! خیلی وقت‌ها پشتشون یه نگرانی واقعیه: بقا، درآمد، یا از دست ندادن یه فرصت جدی.بعضی فرصت‌ها اگر همون موقع نریم سمتشون، واقعاً از دست می‌رن و شاید تا مدت‌ها هم نشه جبران‌شون کرد.بعضی مشتری‌ها هم صبر نمی‌کنن تا roadmap طبق برنامه‌ی ایده‌آل ما جلو بره.بعضی تصمیم‌ها هم، مخصوصاً وقتی فشار مالی هست، بیشتر از اینکه تصمیم ایده‌آل باشن، تصمیم بقا هستن.پس مسئله این نیست که بیزینس چرا عجله داره. مسئله اینه که این عجله چطوری وارد فرایند تصمیم‌گیری محصول می‌شه.مشکل از جایی شروع می‌شه که هر احتمال درآمدی، با همون شدتِ یه بحران واقعی، وارد تیم می‌شه بدون اینکه دقیق روشن باشه اگر این کار رو انجام بدیم، قراره دقیقاً چی گیرمون بیاد.اگر انجامش ندیم، چی رو از دست می‌دیم و اصلاً از کجا می‌فهمیم این همه عجله، ارزشش رو داشته یا نه.نتیجه‌اش هم معمولاً آشناست:یه چیزی با فشار زیاد ساخته می‌شه، اما بعد یا استفاده‌ی جدی‌ای ازش نمی‌شه یا اثرش روی فروش معلوم نیست یا خیلی زود یه درخواست فوری جدید از راه می‌رسه و همه‌چیز دوباره از اول تکرار می‌شه.این چرخه فقط تیم رو خسته نمی‌کنه. کم‌کم roadmap رو بی‌اعتبار می‌کنه، بین کارها مدام پرش ایجاد می‌کنه، کارهای بنیادی رو عقب می‌ندازه و از همه بدتر، فرصت یاد گرفتن رو از سازمان می‌گیره.وقتی همه‌چی فوری می‌شه، تشخیص اینکه کدوم فرصت واقعاً ارزشمنده سخت‌تر می‌شه. تمرکز منابع پخش می‌شن روی احتمال‌هایی که امیدوارم به نتیجه برسن و از اون سمت یه سری کار دیگه هست که موقتاً متوقف میشه (تو تیم‌های کوچک و استارت‌آپی) و ممکنه به قسمت‌های دیگه محصول و یا محصولات دیگه آسیب وارد بشه.پیش‌بینی‌پذیری پایین میاد، تمرکز از بین می‌ره و آخرش هم سازمان دقیق نمی‌فهمه کدوم تصمیم‌ها واقعاً به درآمد منجر شدن و کدوماش فقط یه حسِ حرکت ایجاد کردن.چون وقتی هر چیزی فوری می‌شه، کمتر کسی می‌پرسه:این تصمیم واقعاً جواب داد؟اصلاً این فرصت اون‌قدری که فکر می‌کردیم واقعی بود؟اگر برگردیم به همون نقطه، باز هم همین کار رو می‌کنیم؟از این تصمیم دقیقاً چی یاد گرفتیم؟یکی از کارهای مدیر محصول همینجاست؛ جایی که باید بین فشار واقعی بیزینس و فوریت واقعی برای اجرا فرق گذاشت.بیزینس ممکنه واقعاً تحت فشار باشه مخصوصاً وقتی بازار بی‌ثباته، پول سخت‌تر درمیاد و هر فرصت جدید شبیه یه راه نجات به نظر می‌رسه.این فشار کاملاً قابل‌فهمه. اما هر چیزی که برای بیزینس مهمه، نباید مستقیم و با همون شدت تبدیل بشه به بحران برای تیم محصول.اگر این ترجمه بدون مکث و بدون شفاف‌سازی اتفاق بیفته، کم‌کم تیم محصول به‌جای اینکه کیفیت تصمیم‌گیری رو بهتر کنه، تبدیل می‌شه به جایی که فقط سریع‌تر واکنش نشون می‌ده و به نظرم این یکی از فرساینده‌ترین وضعیت‌های کار محصوله.چون تیم مدام در حال ساختنه، ولی کمتر معلومه چرا این کار از بقیه مهم‌تر بوده. مدام یه چیزی تحویل داده می‌شه ولی نتیجه‌ش ممکنه خیلی واضح نباشه.همه مشغولن، ولی خودِ تصمیم‌ها لزوماً بهتر نمی‌شن.سرعت همیشه بد نیست، ولی جای شفافیت رو نباید بگیره.از اون طرف، roadmap هم قرار نیست یه سند مقدس و تغییرناپذیر باشه.اگر یه فرصت مهم پیدا شده، طبیعیه که برنامه بازبینی بشه. بعضی وقت‌ها تصمیم درست، واقعاً تصمیم سریع گرفتنه.گاهی اگر زیادی صبر کنیم، فرصت از دست می‌ره.حتی بعضی وقت‌ها یه اجرای سریع از یه تحلیل کامل ولی دیرهنگام، ارزشمندتره. اما همین‌جا هم ممکنه بیفتیم توی یه چرخه‌ی فرساینده.مثلاً توی دو هفته، سه بار جهت محصول عوض بشه و چیزهایی که با فشار زیاد ساخته شدن، حتی فرصت استفاده هم پیدا نکنن و خیلی زود برن کنار تا یه درخواست فوری تازه جاشون رو بگیره.برای من مسئله خودِ سرعت نیست. مسئله اینه که سرعت، جای شفافیت و یادگیری رو نگیره.واقعیت اینه که مدیر محصول همیشه نمی‌تونه جلوی این مدل درخواست‌ها وایسه. خیلی وقت‌ها اصلاً تصمیم‌گیر نهایی نیست.خیلی وقت‌ها هم شرایط بیزینس واقعاً طوریه که نمی‌شه فقط گفت: «نه، این توی roadmap ما نیست.»اما حتی وقتی نمی‌شه جلوی یه درخواست رو گرفت، باز هم می‌شه شکل تصمیم رو بهتر کرد.به نظرم نقش PM اینجا بیشتر از اینکه مخالفت مستقیم باشه، شفاف‌سازی کردنه.یعنی قبل از اینکه یه درخواست فوری مستقیم بره توی فاز اجرا، چند تا سؤال ساده ولی مهم روشن بشه:این فرصت دقیقاً چیه؟اگر دنبالش نریم، چی رو از دست می‌دیم؟آیا راه ساده‌تر یا کم‌هزینه‌تری برای امتحان کردنش هست؟این تصمیم دقیقاً قراره چه نتیجه‌ای بسازه؟از کجا می‌فهمیم موفق بوده یا نه؟این فرصت واقعاً چقدر حساس به زمانه؟هزینه‌ی انتخابش داره از روی چه کارهای دیگه‌ای میاد؟خیلی وقت‌ها فقط همین سؤال‌ها کمک می‌کنن یه درخواستی که اول شبیه بحران مطرح شده، تبدیل بشه به یه تصمیم آگاهانه‌تر.بعضی وقت‌ها هم نتیجه اینه که به‌جای ساختن یه راه‌حل کامل، یه نسخه‌ی محدودتر ساخته بشه یا حتی با یه راه‌حل موقت و دستی، اول خودِ فرصت تست بشه.این کار لزوماً فشار رو از بین نمی‌بره ولی کمک می‌کنه سازمان برای هر احتمال، هزینه‌ی یه بحران کامل نده.به نظرم یه بخش مهم دیگه هم اینه که بعد از اجرا، ماجرا واقعاً بسته بشه.یعنی اگر تیم به خاطر یه فرصت فوری، اولویت‌ها رو جابه‌جا کرده و انرژی جدی گذاشته، بعدش باید برگردیم و ببینیم چی شد:این کار به نتیجه رسید؟اون فرصت واقعاً تبدیل شد؟استفاده‌ای شکل گرفت؟اگر نه، مسئله از فرض اولیه بود یا از اجرا؟و مهم‌تر از همه، برای تصمیم بعدی چی یاد گرفتیم؟اگر این مرحله اتفاق نیفته، سازمان فقط وارد یه چرخه‌ی تکراری می‌شه:فرصت جدید => فشار برای ساخت سریع => تحویل => نتیجه‌ی نامشخص یا ضعیف => فرصت فوری بعدیاز یه جایی به بعد، نه تیم به این فوریت‌ها اعتماد می‌کنه، نه roadmap اعتبار خودش رو نگه می‌داره و نه کسی واقعاً می‌فهمه کدوم تصمیم‌ها ارزشش رو داشتن و کدوماش نه.کیفیت تصمیم‌گیری وقتی بهتر می‌شه که صورت مسئله، هزینه‌ها، بده‌بستان‌ها و نتیجه‌ی نهایی بین بیزینس، محصول و فنی، مشترک دیده بشه.برای همین، فکر می‌کنم یکی از مهم‌ترین وظیفه‌های PM این نیست که همیشه جلوی درخواست‌های فوری رو بگیره؛ بلکه اینه که نذاره هر فشار بیزینسی خیلی سریع بخواد تبدیل بشه به بحران عملیاتی برای تیم محصول و فنی.همه‌ی چیزهایی که فوری به نظر می‌رسن، بی‌اهمیت نیستن. بعضی‌ها واقعاً مهمن. بعضی‌ها واقعاً حساس به زمانن و بعضی‌ها اگر دیر بجنبیم، واقعاً از دست می‌رن.اما همون‌قدر که بیزینس نمی‌تونه نسبت به فرصت‌های واقعی بی‌تفاوت باشه، محصول هم نباید اجازه بده هر فرصت، بدون شفافیت و ارزیابی، مستقیم تبدیل بشه به اولویت فوری تیم.اینکه نذاره هر فشار، همون لحظه تبدیل بشه به بحران اجرا.یه مکث کوتاه بسازه.چند سؤال درست مطرح کنه.و کمک کنه تصمیم‌ها، حتی اگر سریع باشه، با آگاهی کامل گرفته بشن و تمام ابعاد درنظر گرفته بشه. فاطمه بشکوه فاطمه بشکوه Fri, 29 May 2026 23:40:35 +0330 https://virgool.io/@m_53134823/%D9%87%D9%85%D9%87-%DA%86%DB%8C%D8%B2-%D9%85%D9%87%D9%85%D9%87-%D8%AA%D8%A7-%D9%88%D9%82%D8%AA%DB%8C-%DA%A9%D9%87-%D9%85%D8%AC%D8%A8%D9%88%D8%B1-%D8%A8%D8%B4%DB%8C-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%DA%A9%D9%86%DB%8C-smy4xb7ecsci ساعت ۱۰ صبحه. اتاق جلسه پره.بک‌لاگ روی مانیتوره و هر کارت یه مسئله‌ست، یه فرصته یا یه نگرانی.«اگه این تغییر فیچر تا آخر هفته نرسه، تیم فروش نمی‌تونه بفروشه.»«اگه این باگ حل نشه، آزمون آنلاینی که می‌خوایم برگزار کنیم عملاً نابود میشه و هیچ‌کس نمی‌تونه شرکت کنه.»«اگه این فیچر جدید نرسه، بازار عملاً از دست میره و بیزینس عقب می‌مونه.»هرکدوم با اطمینان حرف می‌زنن و واقعیت اینه که هرکدوم هم از زاویه خودشون دارن درست می‌گن.اما منابع مثل ظرفیت تیم پروداکت، فنی، زمان و منابع مالی محدوده و قراره فقط چند تسک محدود، به اندازه ظرفیتی که داریم، وارد اسپرینت بعدی بشه.اینجاست که یه واقعیت ساده ولی سخت خودش رو نشون می‌ده:وقتی منابع محدوده، اولویت‌بندی یعنی انتخاب کردن و انتخاب کردن یعنی کنار گذاشتن.اینجاست که یکی از سخت‌ترین بخش‌های کار مدیر محصول شروع میشه.وقتی ذی‌نفع‌های مختلف با نیازهای متفاوت هستن، تقریباً همه‌چیز «مهم» به نظر می‌رسه اما محصول با «همه‌چیز» ساخته نمی‌شه؛ با تصمیم‌ها ساخته می‌شه.در عمل، چند رویکرد رایج برای مواجهه با این موقعیت وجود داره.اولین رویکرد چیزیه که در دنیای محصول بهش میگن HiPPO:مخفف کلمه Highest Paid Person’s Opinion هست. در این حالت، کسی که نفوذ بیشتری داره یا فشار بیشتری وارد می‌کنه، درخواستش جلوتر میاد.مزیتش اینه که تصمیم سریع گرفته میشه؛ اما اگر این تبدیل به روال دائمی بشه، محصول کم‌کم بر اساس قدرت و فشار شکل می‌گیره تا نیاز واقعی کاربر!در چنین حالتی معمولاً ترجیح ذی‌نفع‌های بانفوذ جلو می‌افته و محصول کم‌کم تبدیل میشه به بازتاب سلیقه همون افراد و خب وقتی این افراد معمولاً بالاترین سطح قدرت در سازمان رو دارن، گفتن «نه» هم کار ساده‌ای نیست.مزیت: سرعت بالا و کاهش اصطکاک در لحظه.عیب: محصول به جای «نیاز کاربر»، به «خواسته صاحبان قدرت» نزدیک میشه که لزوماً هم ممکنه بهترین خواسته برای محصول ما نباشه.وقتی فشار زمانی زیاده و ریسک توقف کار بالاست، رویکرد HiPPO گاهی اجتناب‌ناپذیره.سناریوهای رایج:- وقتی یک اتفاق اضطراری افتاده- وقتی بازار نیاز به واکنش سریع داره- وقتی به‌هرحال تصمیم باید همون روز گرفته بشهدر این مواقع، تصمیم سریع از «تصمیم بی‌نقص» مهم‌تره. اما این رویکرد باید موقتی باشه. اگر تبدیل به روال دائمی بشه، مسیر محصول کم‌کم از کنترل خارج میشه.رویکرد دوم استفاده از چارچوب‌های امتیازدهی مثل RICE.این مدل کمک می‌کنه گفتگوها ساختار پیدا کنن و تصمیم‌ها قابل توضیح باشن. وقتی اختلاف‌نظر زیاده، این چارچوب‌ها یه «زبان مشترک» برای اولویت‌بندی می‌سازن.در کتاب‌های Inspired از Marty Cagan و The Lean Product Playbook از Dan Olsen هم روی اهمیت همین موضوع تأکید شده.در این مدل هر کار بر اساس چهار معیار بررسی میشه:Reach: چند نفر تحت تأثیر قرار می‌گیرنImpact: میزان اثر چقدرهConfidence: چقدر به این تخمین مطمئنیمEffort: چقدر زمان و منابع لازم دارهمشکل اینجاست که خیلی از این عددها تخمینی هستن.اگر مراقب نباشیم، تصمیم‌ها ممکنه بیش از حد مکانیکی بشن.وقتی می‌خوای گفتگوها شفاف و قابل توضیح باشن، چارچوب‌هایی مثل RICE خیلی کمک‌کننده‌ان.سناریوهای رایج:- وقتی تعداد درخواست‌ها خیلی زیاده- وقتی ذی‌نفع‌ها اختلاف‌نظر جدی دارن- وقتی تیم نیاز به یک زبان مشترک برای اولویت‌بندی دارهرویکرد سوم تکیه بر داده و اهداف استراتژیک محصوله.اینجا سؤال اصلی اینه:کدوم کار بیشترین تأثیر رو روی اهداف کلیدی محصول داره؟ یا اهداف محصول و تارگت‌هاش چیه و این موارد از قبل مشخص شده باشه.مثلاً روی معیارهایی مثل نرخ فعال‌سازی، نگهداشت کاربر یا North Star Metric. (البته North Star هم متریک ثابتی نیست و ممکنه محصول به محصول فرق کنه.)این رویکرد کمک می‌کنه تصمیم‌ها با مسیر بلندمدت محصول هم‌راستا باشن. البته همیشه داده کافی وجود نداره، مخصوصاً در مراحل اولیه محصول.وقتی محصول وارد فاز رشد واقعی میشه، رویکرد داده‌محور و استراتژیک معمولاً بهترین راهنماست.سناریوهای رایج:- وقتی محصول به نقطه‌ای رسیده که معیارهاش مشخص شده- وقتی تمرکز روی OKRها یا North Star Metric هست- وقتی تیم می‌خواد بدونه هر تصمیم چه اثری روی شاخص‌های کلیدی می‌ذارهدن اولسن در The Lean Product Playbook میگه:«در مراحل بلوغ محصول، داده بهترین ابزار برای کاهش ریسک تصمیم‌گیریه.»البته این رویکرد زمانی خوب جواب میده که داده کافی داشته باشی. در مراحل اولیه، داده‌ها خیلی وقت‌ها ناقص یا کم هستن.یه بخش از اولویت‌بندی کمتر درباره‌ش صحبت میشه اینه که وقتی تصمیم می‌گیری، احتمالا حداقل یه نفر پیدا میشه که ناراضی هست. چون وقتی چیزی جلو میاد، چیز دیگه‌ای عقب میره.در برخورد با ذی‌نفع‌هایی که از عقب افتادن درخواست‌شون ناراحت میشن، چند نکته ساده اما مهم می‌تونه کمک کنه:- شفاف توضیح بده تصمیم بر چه اساسی گرفته شده.- آدم‌ها با «نه» گفتن مشکل دارن، اما با «نهِ بی‌دلیل» خیلی بیشتر.- به‌جای «فعلاً نه»، زمان یا شرط بازبینی مشخص کن. این کار حس بلاتکلیفی رو به حس برنامه‌مندی تبدیل می‌کنه. ما به عنوان PM باید بتونیم تا جایی که میشه بهشون یه سری ددلاین بدیم که ذی‌نفعان در جریان قرار بگیرن و اگه نیازشون فوری و واجبه، با هم صحبت کنیم و ببینیم چه راه‌حل جایگزینی میشه برای هندل کردنش پیدا کرد.- هزینه فرصت تصمیم رو توضیح بده. وقتی نشون بدی جلو آوردن یک کار یعنی عقب رفتن چه کار دیگه‌ای، گفتگو منطقی‌تر میشه.- مهم‌تر از همه: گوش بده. خیلی وقت‌ها پشت یک درخواست، نگرانی عمیق‌تری وجود داره که شاید با یک راه‌حل ساده‌تر هم حل بشه.در عمل هیچ‌کدوم از این روش‌ها به‌تنهایی جواب کامل نمی‌دن.چارچوب‌ها کمک می‌کنن گفتگو شفاف‌تر بشه، داده‌ها جهت تصمیم‌ها رو منطقی‌تر می‌کنن و قضاوت محصولی جایی به کار میاد که داده کافی وجود نداره.اما در نهایت، اولویت‌بندی بیشتر از اینکه یک فرمول ثابت باشه، یک گفتگوی مداومه بین محدودیت‌ها، اهداف کسب‌وکار و نیاز واقعی کاربر.شاید یکی از بخش‌های کمتر دیده‌شده‌ی کار مدیر محصول همین‌جاست؛ جایی که تقریباً همه درخواست‌ها مهم به نظر می‌رسن، اما باید انتخاب کنی کدوم‌شون زودتر ساخته بشن و همین انتخاب‌هاست که کم‌کم مسیر واقعی یک محصول رو شکل می‌ده. فاطمه بشکوه فاطمه بشکوه Fri, 22 May 2026 22:54:04 +0330 https://virgool.io/@m_53134823/%D9%85%D8%AF%DB%8C%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%DA%A9%DB%8C%D9%87-%D9%88%D8%A7%D9%82%D8%B9%D8%A7%D9%8B-elth56ujmiil بستگی داره با کدوم لنز بخوای بهش نگاه کنی.یه زمانی فکر می‌کردم اگه دقیق‌تر بدونم مدیریت محصول چیه، کارم هم واضح‌تر می‌شه.اما هر چی جلوتر رفتم، فهمیدم مسئله این نیست که تعریف درست کدومه؛ مسئله اینه که هر کسی یه تعریف متفاوت تو ذهنشه… .مدیر محصول برای یکی یعنی کسی که کار تیم رو جلو می‌بره، برای یکی یعنی صدای کاربر، برای یکی یعنی کسی که باید عدد و بیزینس رو درست کنه و بعضی وقت‌ها همه‌ی این‌ها با هم.بخش مهمی از این داستان برمی‌گرده به این‌که شرکت اصلاً مدیر محصول رو چی می‌بینه.با وجود این‌همه تعریف و مدل مختلف از PM، طبیعیه که هر سازمان یکی (یا چندتا) از این‌ها رو انتخاب کنه.مشکل از جایی شروع می‌شه که این انتخاب نانوشته‌ست و با چیزی که تو ذهن ما هست، فرق داره.من تو موقعیت‌هایی بودم که انتظار شرکت از مدیر محصول، به‌واسطه‌ی شرایطی که اون موقع داشت، بیشتر جلو بردن پروژه بود.نه الزاماً اشتباهه، نه الزاماً درسته. ولی چون این انتظار شفاف نبود و من یه «نوع بودنِ» دیگه‌ای از نقش تو ذهنم داشتم، یه‌جاهایی فکر می‌کردم دارم از کار اصلی‌م دور می‌شم؛ در حالی که از نگاه شرکت، دقیقاً داشتم کار درست رو انجام می‌دادم.اینجاست که اصطکاک شروع می‌شه!مشکل این نیست که مدیر محصول پروژه جلو ببره. مشکل از جایی شروع می‌شه که این اتفاق:اسم نداشته باشهزمان نداشته باشهشفاف نباشهو انتخاب آگاهانه نباشهاون‌وقت، بدون اینکه بفهمی، بیشتر وقتت صرف هماهنگی، فالوآپ و رسوندن می‌شه و کمتر وقت می‌مونه برای فکر کردن به خود محصول. حسی که میاد سراغت اینه که من دارم کار اصلی که باید انجام بدم رو انجام نمی‌دم.همون‌طور که گفتم، به‌نظر میاد «مدیر محصول» یه تیپ واحد نیست.تو تجربه‌ی من، معمولاً چند مدل دیده می‌شه:بعضی‌ها بیشتر فرآیند رو نگه می‌دارن.بعضی‌ها پروژه رو جلو هل می‌دن.بعضی‌ها غرق مسئله و کشف می‌شن.بعضی‌ها تمرکزشون روی بیزینسه.وقتی خودت ندونی الان کدوم مدلی، یا شرکت ندونه دقیقاً چی ازت می‌خواد، یه تعارضی شکل می‌گیره بین «کاری که الان لازمه» و «نقشی که قرار بوده داشته باشی، یا فکر می‌کردی قراره داشته باشی». (البته سطح سینیوریتی افراد هم ممکنه تو این زمینه نقش داشته باشه.)اگه این تعارض شفاف نشه؛ ممکنه کم‌کم فرسودگی بیاد، بعدش دل‌زدگی و بعد هم این سؤال که «من اصلاً دارم کار درستی می‌کنم؟»اینجاست که مصاحبه اولیه می‌تونه خیلی مهم باشه که واقعاً شفاف کنی دقیقاً چه مدل مدیریت محصولی ازت می‌خوان.نه فقط این سؤال کلی که «PM چه کارهایی می‌کنه؟»بلکه سؤال‌هایی مثل:تمرکز اصلی این نقش کجاست؟موفقیتش با چی سنجیده می‌شه؟بیشتر قراره مسئله حل کنه یا پروژه برسونه؟و هم‌زمان، خودت هم با ترجیحت صادق باشی.به‌نظرم دو تا حالت سالم وجود داره:حالت اول:می‌بینی نگاه شرکت با مدل ذهنی و ترجیح تو هم‌راستاست.عالی. احتمالاً تجربه‌ی خوبی در پیش داری.حالت دوم:می‌فهمی هم‌راستا نیستید ولی بنا به هر دلیلی تصمیم می‌گیری اون شغل رو بپذیری.اینجا هم هنوز همه‌چیز خراب نشده.چون حداقل:فضا برات شفافهمی‌دونی چی ازت می‌خوانو آگاهانه وارد بازی شدینه با این انتظار که «بعداً خودش درست می‌شه».یه حالت سوم هم هست که معمولاً سالم نیست.اینکه نه نقش شفافه، نه واقعاً معلومه هم‌راستایی وجود داره یا نه. هر کسی با تعریف خودش جلو می‌ره!شرکت یه چیز تو ذهنشه، مدیر یه چیز و مدیر محصول هم یه تصور دیگه داره! همه فکر می‌کنن برداشت خودشون واضحه، اما در عمل همه در ابهام ممکنه باشن. اینجاست که معمولاً بیشترین اصطکاک شکل می‌گیره.انتظارها با هم نمی‌خونه، نقش‌ها مدام جابه‌جا می‌شن و کم‌کم چالش‌های زیادی به وجود میاد. اگه فرصت شد، بعداً بیشتر درباره‌ی همین حالت سوم می‌نویسم.به طور کلی، اگه الان درگیر حالت اول یا دوم هستی می‌تونی با این سوال ساده شروع کنی که «الان دقیقاً چه نقشی دارم بازی می‌کنم، و تا کِی؟» و این سؤال رو با شرکت هم در میون بذاری و سعی کنی با هم به یه جمع‌بندی برسید.شاید بعد از همه‌ی این‌ها، سؤال اصلی این نباشه که «مدیر محصول دقیقاً کیه؟» سؤال مهم‌تر می‌تونه این باشه کهدر این شرکت، در این مقطع، این عنوان و پوزیشن شغلی دقیقاً به چه معناست؟چون عنوان‌ها ثابت به نظر می‌رسن اما نقش‌ها می‌تونن سیال باشن و اگر این سیال بودن شفاف نشه، کم‌کم تبدیل می‌شه به ابهام، ابهام تبدیل می‌شه به اصطکاک و اصطکاک تبدیل می‌شه به فرسودگی.برای من، بلوغ این مسیر از جایی شروع شد که کمتر دنبال تعریف جهانیِ مدیر محصول گشتم و بیشتر دنبال این رفتم که تعریف محلیِ این نقش رو بفهمم. هم برای خودم روشنش کنم، هم با شرکت درباره‌ش حرف بزنم.شاید در نهایت، حرفه‌ای بودن کمتر به این ربط داشته باشه که کدوم مدل PM هستی و بیشتر به این ربط داشته باشه که می‌دونی در چه بازی‌ای هستی، قواعدش چیه و آیا آگاهانه انتخابش کردی یا نه. فاطمه بشکوه فاطمه بشکوه Sat, 16 May 2026 23:11:22 +0330 https://virgool.io/@m_53134823/%D9%85%D8%AF%DB%8C%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D9%85%D8%AF%DB%8C%D8%B1-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%86%DB%8C%D8%B3%D8%AA-%D9%85%DA%AF%D8%B1-%D9%88%D9%82%D8%AA%DB%8C-%DA%A9%D9%87-%D9%87%D8%B3%D8%AA-hwe1jufvpcb0 یکی از رایج‌ترین سوءبرداشت‌هایی که توی محیط‌های کاری دیدم اینه که مدیر محصول و مدیر پروژه رو یکی می‌گیرن.در حالی که این دو نقش، از نظر ماهیت و تمرکز، فرق دارن.مدیر پروژه تمرکزش روی تحویله؛ زمان‌بندی، هماهنگی، فالوآپ، مدیریت ریسک و اینکه کار طبق برنامه جلو بره.مدیر محصول تمرکزش روی مسئله و ارزشه؛ اینکه چرا داریم چیزی رو می‌سازیم، برای کی، با چه اولویتی و قراره چه تغییری ایجاد کنه.اما این به این معنی نیست که مدیر محصول نباید مدیریت پروژه بلد باشه.به نظرم، یه مدیر محصول خوب حتماً باید اصول مدیریت پروژه رو بفهمه و بتونه انجامش بده:بتونه کارها رو خرد کنه، وابستگی‌ها رو ببینه، با زمان‌بندی و ریسک‌ها کنار بیاد و بدونه یه کار کِی واقعاً جلو می‌ره و کِی فقط روی کاغذه.خیلی وقت‌ها پیش میاد که این مهارت‌ها واقعاً بهتره توسط خودِ مدیر محصول انجام بشن مثل جلسه برگزار کردن، فالوآپ کردن تسک‌ها، جلو انداختن دلیوری و جمع‌وجور کردن کار وقتی همه‌چیز شلوغه. انجام دادن ایم موارد، بعضی وقت‌ها ممکنه ضروری‌ باشه. اما درست همین‌جا، یه خط باریکی‌ وجود داره که باید حواسمون بهش باشه.بلد بودن و انجام دادنِ مدیریت پروژه، با گم شدن توی نقش مدیر پروژه فرق داره!مسئله از جایی شروع می‌شه که این وضعیت:شفاف نباشهزمان‌دار نباشهو به‌عنوان یه انتخاب آگاهانه دیده نشهاون‌وقت، کارهای محصولی کم‌کم می‌رن تو سایه... نه کشف مسئله‌ای می‌مونه، نه تصمیم‌سازی‌ای و نه وقتی برای فکر کردن به مسیر بلندمدت محصول.همه‌چیز می‌شه پاسخ دادن به این جمله‌ی آشنا:«فعلاً فقط برسونیمش. یا تو فورسیم و این کار رو حتما باید انجام بدیم.»تجربه‌ی شخصی من این بوده که اگه قراره یه مدت تمرکز مدیر محصول بره روی کارهای پروژه‌ای، باید همون موقع مشخص بشه این موضوع و بدونیم:- الان چرا این کار لازمه؟- قراره تا کی ادامه داشته باشه؟- چه زمانی دوباره به کارهای محصولی برمی‌گردیم؟وگرنه خیلی راحت، ممکنه مدیر محصولی که قرار بود «ارزش خلق کنه»، می‌بینه مدت‌هاست فقط داره تسک و کار تحویل می‌ده. :‌(اینجا یه شباهت جدی با همون چیزیه که یه بار درباره‌اش حرف زدم: «آچارفرانسه بودن».وقتی همه از تو انتظار هرچیزی دارن، تو عملاً تبدیل می‌شی به پاسخِ فوریِ آدم‌ها… و نه کسی که راه محصول رو روشن نگه.ممکنه هم‌پوشانی نقش‌ها اولش جذاب باشه! چون بالاخره داری کمک می‌کنی ولی اگه شفاف و زمان‌دار نشه، به مرور ممکنه کار اصلی محصولی بره تو سایه و همه‌چیز بشه پیشبرد کار و تحویل.مسئله از جایی شروع می‌شه که این وضعیت:• شفاف نباشه• زمان‌دار نباشه• و به‌عنوان یه انتخاب آگاهانه دیده نشهپست مربوط به «آچارفرانسه بودن؛ همه‌فن‌حریف یا هیچ‌فن‌حریف؟» رو از این قسمت می‌تونی مطالعه کنی.چرا این اتفاق توی سازمان‌ها می‌افته؟اینکه مدیر محصول در عمل به سمت مدیریت پروژه هل داده می‌شه، معمولاً بیشتر حاصل ساختار، مرحله‌ی رشد سازمان و نوع مسئله‌ایه که شرکت باهاش درگیره. البته این موضوع که تعریف پوزیشن مدیریت محصول، یک تعریف یکپارچه نداره و جا به جا ممکنه متفاوت باشه هم می‌تونه مزید بر علت باشه!چند تا از رایج‌ترین دلایلش رو تو تجربه‌ی خودم و چیزهایی که خوندم این‌ها دیدم:۱. نبود تعریف شفاف از نقش‌هاتو خیلی از سازمان‌ها، مخصوصاً تیم‌های در حال رشد مرز بین مدیر محصول، مدیر پروژه، اسکرام‌مستر دقیق مشخص نشده.وقتی نقش‌ها مبهمن، مسئولیت‌ها هم شناور می‌شن و معمولاً می‌افتن روی کسی که بیشترین دید و تعامل رو داره؛ یعنی مدیر محصول.۲. فشار دلیوری و فرهنگ «رسوندن»سازمان‌هایی که موفقیت رو بیشتر با «تحویل به‌موقع» می‌سنجن تا «تصمیم درست» ناخواسته نقش‌هایی رو تقویت می‌کنن که به دلیوری کمک می‌کنه.تو این فضا، کارهای محصولی مثل کشف مسئله، اعتبارسنجی یا اولویت‌بندی، ممکنه لوکس به نظر بیاد و عقب می‌افتن.۳. کوچکی تیم یا مرحله‌ی اولیه‌ی رشدتو استارتاپ‌ها یا تیم‌های کم‌منبع، ادغام نقش‌ها چیز عجیبی نیست اما مشکل از جایی شروع می‌شه که سازمان بزرگ‌تر می‌شه ولی نقش‌ها و انتظارات همون شکل اولیه رو حفظ می‌کنن.۴. مهارت بالای PM در هماهنگیخیلی وقت‌ها خود PM به خاطر مهارت ارتباطی و مسئولیت‌پذیری بالا، ناخواسته تبدیل می‌شه به نقطه‌ی اتکای همه. کاری که بقیه شاید انجامش ندن، PM انجام می‌ده تا کار نخوابه؛ و همین، نقش پروژه‌ای رو براش تثبیت می‌کنه.مدیر محصول چه راه‌هایی برای مواجهه با این وضعیت داره؟واقعیت اینه که همیشه نمی‌شه از این شرایط فرار کرد، اما می‌شه آگاهانه‌تر باهاش برخورد کرد.۱. شفاف‌سازی فعالانه‌ی نقشPM نباید منتظر بمونه سازمان نقش‌ها رو براش تعریف کنه. بیان شفاف اینکه «الان دارم چه کاری می‌کنم و چرا» اولین قدمه.۲. زمان‌دار کردن نقش پروژه‌ایاگه قراره PM یه مدت روی مدیریت پروژه تمرکز کنه، باید از همون اول مشخص باشه این وضعیت موقته و خروجی مورد انتظار چیه.۳. حفظ حداقل‌های محصولیحتی تو شلوغ‌ترین دوره‌های دلیوری، PM می‌تونه برای کارهای محصولی حداقلی، جا باز کنه؛ حتی اگه شده با اسکوپ کوچک‌تر یا افق کوتاه‌تر.۴. بازتاب دادن هزینه‌ی این جابه‌جایی نقشیکی از وظایف PM اینه که نشون بده تمرکز بیش‌ازحد روی پروژه، چه چیزهایی رو ممکنه عقب بندازه؛ با زبان اثر و پیامد میشه این توضیح رو داد.در نهایت تو یه برهه‌هایی مدیریت پروژه می‌تونه واقعا لازم باشه و مدیر محصول بهتره بتونه پیش ببرتش.مثلا وقت‌هایی که برای اولین بار بخوایم یه پایلوت برای یه محصول یا فیچر بزرگی رو داشته باشیم.تو این جور موقعیت‌ها، وقتی مدیر محصول مستقیم درگیر هماهنگی‌ها و پیشبرد کار می‌شه، معمولاً تصویر دقیق‌تری از روند اجرا، گلوگاه‌ها و پیچیدگی‌های واقعی پیدا می‌کنه.همین تجربه بعداً می‌تونه کمک کنه که تصمیم‌های محصولی واقع‌بینانه‌تر گرفته بشه و مسیر توسعه‌ی بعدی دقیق‌تر طراحی بشه. فاطمه بشکوه فاطمه بشکوه Sat, 09 May 2026 00:00:21 +0330 https://virgool.io/@m_53134823/%D8%A2%DA%86%D8%A7%D8%B1%D9%81%D8%B1%D8%A7%D9%86%D8%B3%D9%87-%D8%A8%D9%88%D8%AF%D9%86-%D9%87%D9%85%D9%87-%D9%81%D9%86-%D8%AD%D8%B1%DB%8C%D9%81-%DB%8C%D8%A7-%D9%87%DB%8C%DA%86-%D9%81%D9%86-%D8%AD%D8%B1%DB%8C%D9%81-uenvp86tbzrw تا حالا تو شرکت بهتون گفتن آچارفرانسه‌ای؟برای من، آچارفرانسه بودن مساویِ بی‌ارزش بودن کاری بود که انجام می‌دادم. از افراد مختلف هم این رو شنیده و خونده بودم که «آچار فرانسه» نباشید توکارها.تو خیلی از سازمان‌ها، آچارفرانسه به کسی می‌گن که هر کاری از دستش برمیاد انجام می‌ده؛ از کارهای محصولی و پروژه‌ای گرفته تا هماهنگی‌ها، محتوا، اجرا و حتی کارهای ریز و به‌ظاهر نامرتبط. البته یه تعبیر دیگه هم داره؛ اینکه هر کاری رو زمین مونده باشه، میدن به اون شخص که انجامش بده.برای بعضی‌ها ممکنه این برچسب چیز مثبتیه.آدم‌هایی که از تنوع لذت می‌برن، حالشون با انجام دادن کارهای مختلف خوبه و از اینکه می‌تونن چند مسئله متفاوت رو هم‌زمان هندل کنن، حس ارزشمندی می‌گیرن.اما بعضی دیگه ترجیح می‌دن روی یک تخصص مشخص عمیق بشن؛ برای این دسته، پریدن بین کارهای گوناگون می‌تونه خسته‌کننده و حتی آزاردهنده باشه.به نظرم اینجا اصلاً بحث خوب یا بد مطرح نیست.بیشتر از هر چیزی به شخصیت، مسیر شغلی و حتی مرحله‌ای که هر آدم تو زندگیشه برمی‌گرده.(در مورد این تفاوت‌ها احتمالاً یه پست جداگانه می‌نویسم.)برگردیم به تجربه خودم.من تو یه دوره‌ای از کارم، آچارفرانسه بودم؛ مدیر پروژه‌ای که هر کاری لازم بود انجام می‌داد:از درآوردن نیازمندی‌ها و سر و سامون دادن هزینه‌ها، تا نوشتن کپشن، ضبط ویدئو برای پروژه‌ها و کلی کار دیگه که شاید حتی تو شرح شغل هم تعریف نشده بود. یکی از دلایلی که از اون محیط اومدم بیرون همین موضوع بود؛ چون حس می‌کردم کم‌کم جنس کارهام به قدری داره متنوع و بی‌ربط به هم میشه که شاید برام آورده‌ای نداشته باشه.خیلی از کارهایی که من به‌تنهایی انجام می‌دادم، واقعاً نیاز به یک یا حتی دو نیروی فول‌تایم داشت تا درست پیش بره. نه به خاطر خارق‌العاده بودن من، بلکه به خاطر حجم، تنوع و سطح مسئولیتی که تو اون نقش وجود داشت.با این حال، اینجا یه نکته خیلی مهم وجود داره.اینکه یه نفر بتونه کارهای متنوعی رو انجام بده، به هیچ‌وجه مجوزی نیست برای اینکه مرز نقش‌ها نادیده گرفته بشه یا مسئولیت چند نفر روی دوش یک نفر بیفته بدون اینکه با مسیر شغلی که شخص تو ذهنش هست همراستا باشه!ارزشمند بودن این تجربه، به معنی درست بودن ساختارهای ناسالم سازمانی نیست.همدلی فرد با تیم، یا پتانسیلش برای انجام کارهای مختلف، نباید تبدیل به بهانه‌ای برای فرسایش یا سوءاستفاده بشه.این اتفاق تو بعضی فضاهای کاری، مخصوصاً استارتاپ‌ها بیشتر دیده می‌شه؛ جایی که به خاطر کوچکی تیم، سرعت بالا و محدودیت منابع، آچارفرانسه بودن از کارمندها بیشتر خواسته می‌شه.در چنین شرایطی، مسئولیت شفاف‌سازی نقش‌ها و ظرفیت‌ها، بیشتر از هر کسی، به نظرم با سازمانه و بعد از اون خود شخص.از طرف دیگه، با حضور پررنگ‌تر هوش مصنوعی، ادغام نقش‌ها داره طبیعی‌تر می‌شه. اینکه یه نفر بتونه از صفر تا صد بخشی از یه محصول رو جلو ببره، دیگه خیلی دور از انتظار نیست.احتمالاً تو آینده نزدیک، مفهوم آچارفرانسه بودن رو پررنگ‌تر از قبل تو محیط‌های کاری می‌بینیم؛ اما تفاوت اصلی، جاییه که این انتخاب آگاهانه باشه، نه تحمیلی. فاطمه بشکوه فاطمه بشکوه Fri, 01 May 2026 19:11:00 +0330 https://virgool.io/@m_53134823/%D9%84%DB%8C%D8%A8-xi4ywmozlkfh مدتی بود حس می‌کردم تو کار، بخشی از کارهام «کار گِل» هستن.کارهایی که نه جذاب بودن، نه دیده می‌شدن؛ بیشتر شبیه وقت‌کُشی‌هایی که باید ازشون رد می‌شدم. چیزهایی مثل هم‌راستا کردن تیم، یا گفتن نه‌های تکراری، بی‌سروصدا، بدون اینکه هیچ‌وقت قهرمان داستان بشی!البته خیلی به این فکر کردم که اولین بار که من اصطلاح «کار گِل» رو شنیدم کِی بود و چه کاری بود دقیقا ولی هر چی فکر کردم یادم نیومد!بعد از یه مدت فهمیدم مشکل از خود کارها نیست. مشکل از لیبلی میاد که من بهشون زده بودم.همون لیبل باعث شده بود به‌جای انجام اون کارها، دنبال فرار باشم؛ فقط می‌خواستم زودتر برسم به بخش‌های «باحال‌تر» کار.بارها دیدم یه کار توی یه موقعیت «جزء کار» حساب می‌شه و انجامش می‌دیم، اما همون کار، فقط با عوض شدن نقش یا جایگاهمون، می‌شه «کار گِل».در حالی که این‌ها دقیقاً همون کارهایی هستن که اگه انجام نشن، ممکنه همه‌چیز از هم بپاشه.چیزی که این تجربه به من یاد داد این بود که:وقتی به کاری لیبل می‌زنم، در واقع دارم انتخاب می‌کنم با حال بد انجامش بدم، یا طوری بهش نگاه کنم که بشه ازش اثر مثبت ساخت.اگه بخوام این تجربه رو به چند نکته‌ی قابل‌استفاده تبدیل کنم:قبل از اینکه از کاری فرار کنی، از خودت بپرس واقعا مشکلی هست یا نه به خاطر لیبلیه که ممکنه ته ذهنت بهش نسبت بدی.خیلی از کارهای غیرجذاب، همون‌هایی هستن که اثر بلندمدت دارن.به نظرم مدیرمحصول بودن، بیشتر از تصمیم‌های هیجان‌انگیز، یعنی ساختن چیزهایی که قراره بارها استفاده بشن.الان هنوز هم بعضی از این کارها جذاب نیستن ولی دارم سعی می‌کنم جهان‌بینی‌م نسبت به انجام کارها رو عوض کنم و متفاوت‌تر بهشون نگاه کنم.تو دنیای مدیریت محصول و حتی تو زندگی عادی خودمون فارغ از شغل، خیلی اوقات همین کارهای گِل داره کل فرآیند اصلی رو میسازه!کنجکاوم بدونم تو هم کاری هست که توی ذهنت بهش لیبل زدی و هی عقب می‌ندازیش یا ترجیح می‌دی یکی دیگه انجامش بده؟! فاطمه بشکوه فاطمه بشکوه Fri, 24 Apr 2026 19:10:23 +0330