https://virgool.io/feed/@m_33382600 من ریحانه‌ام، مدیر محصول در شروع مسیر. تجربه‌ام رو از شرکت‌های مختلف آوردم و حالا قراره، از چالش‌ها و دغدغه‌هام توی کار جدیدم بنویسم. fa 2026-06-18 20:00:45 https://files.virgool.io/upload/users/4141351/avatar/t9BkF8.png?height=120&width=120 https://virgool.io/@m_33382600 https://virgool.io/@m_33382600/%D8%AA%D8%B1%D9%81%D9%86%D8%AF%DB%8C-%D9%85%D8%B9%D8%AC%D8%B2%D9%87-%D8%A2%D8%B3%D8%A7-%D8%A8%D9%87-%D8%AE%D8%B5%D9%88%D8%B5-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%D8%A7%D9%86-%D9%85%D8%AD%D8%B5%D9%88%D9%84-l3312lm7zufs توی زندگی، گاهی پیش‌ میاد با افرادی مواجه شویم که نظراتی مخالف ما دارند یا رفتاری از خود نشان می‌دهند که خوشایند ما نیست و قانع کردن آن‌ها نیازمند تلاشی بی‌پایان است که نتیجه‌ای جز خستگی روحی برای ما به ارمغان نمی‌آورد. این موضوع هم در زندگی شخصی افراد اتفاق می‌افتد و هم در محیط کاری.مثال‌های ملموس فرض کنید به صورت اتفاقی تصویری در سوشال مدیا مشاهده می‌کنید که دوستان شما دورهمی‌ای ترتیب دادند و شما به آن دورهمی دعوت نبودید. طبیعتا این موضوع می‌تواند احساس ناخوشایند کنار گذاشته شدن از جمع دوستان را در شما ایجاد کند. اما راهکار چیست؟ جنگ و دعوا؟ قهر و دوری؟ یا بی‌تفاوتی؟اجازه بدید مثال دیگری بزنم و بعد وارد اصل موضوع شوم؛ فرض کنید به عنوان یک مدیر محصول در یک جلسه‌‌ای با حضور مدیران تیم‌های مختلف هستید و قرار است بر سر نیازمندی‌های مختلف تیم‌ها و اولویت آن‌ها تصمیم‌گیری کنید. مدیر مارکتینگ بر روی پیاده‌سازی هر چه سریع‌تر فیچر جدیدی اصرار دارد که می‌تواند با مانور بر آن مشتریان بیشتری جذب کند، از سوی دیگر مدیر پشتیبانی با دغدغه‌ی تماس‌های مکرر کاربران، درخواست فیچری برای آسان کردن خدمات پشتیبانی دارد. در مقابل همه‌ی این درخواست‌ها مدیر تیم توسعه به بدهی فنی خیلی زیاد اشاره می‌کند و اینکه پیاده‌سازی این فیچرها او را از توجه به بدهی‌های فنی باز می‌دارد. در این شرایط هر کدام از این تصمیم‌ها می‌تواند سایدافکت‌های زیادی را با خود به همراه آورد که اگر بخواهیم شفاف باشیم، مسئول نهایی این سایدافکت‌ها شما هستید. در اصول و قواعد مدیریت محصول برای همچین شرایطی راهکارهای منطقی زیادی توصیه شده اما همه‌ی این راه‌ها بدون وجود این ترفند از شما انرژی مضاعفی می‌گیرد تا مدیر تیم‌ها را قانع کنید.راهکار کلیدیمی‌خواهم راهکاری را معرفی کنم که Mel Robbins آن را با عنوان تئوری «Let them» بیان کرده است. اگرچه این تئوری در حوزه‌ی روانشناسی فردی مطرح شده است اما می‌تواند مهارتی کلیدی برای مدیران محصول باشد. به صورت خیلی خلاصه بخواهم این تئوری را توضیح دهم اینگونه است که «اجازه بده دیگران همان‌گونه که هستند باشند و به جای تمرکز بر دیگران بر اقدام خودت متمرکز شو!». حالا این یعنی چی؟خیلی خودمونی بخوام توضیح بدم اینجوریه که اگر دیگران حرفی زدند که برای تو خوشایند نبود،‌ درگیر اون آدم نشو، انرژیت رو برای پیشرفت خودت حفظ کن. اگر دوستات باهم رفتن بیرون و به تو نگفتن، سعی نکن اون‌ها رو با دعوا یا قهر کنترل کنی، بذار همونجوری که هستن باشن، تو تمرکزت رو روی روابطی که برات مهمه حفظ کن و توی اون‌ها فعال باش.این مثال‌ها توی زندگی شخصی بود، در محیط کاری هم همین است؛ توی جلسه حرف‌های همه رو می‌شنوی، یادداشت می‌کنی اما قرار نیست اون‌ها رو راضی کنی، پس انرژیت رو نگه میداری برای تمرکز روی اهداف خودت. از نکاتی که توی جلسه مطرح شد استفاده می‌کنی برای اینکه دقیق‌تر بتونی تصمیمی بگیری که با کمترین ساید افکت بیشترین آورده را برای محصول داشته باشد.مرز باریکنکته‌ی خیلی مهم این ترفند رعایت مرز باریک بین این تئوری و بی‌تفاوتی است. باید حواستون باشه که بخش اول Let them به تنهایی به شما کمک نمی‌کند، باید به صورت فعالانه در راستای رسیدن به اهداف خود اقدام کنید. عملا بدون Let Me رفتار شما معنای بی‌تفاوتی پیدا می‌کند که تأثیرات آن بر زندگی حرفه‌ای و شخصی شما می‌تواند لطمه وارد کند.چرا این دیدگاه کلیدی است؟چون ما به‌طور سنتی یاد گرفتیم:تلاش بیشتر = نتیجه بهترکنترل بیشتر = اطمینان بیشتررضایت دیگران = موفقیتاما Robbins می‌گه: گاهی برعکسه.تو فقط زمانی به بالاترین بهره‌وری، خلاقیت و تمرکز می‌رسی که بپذیری نمی‌تونی همه‌چیز و همه‌کس رو کنترل کنی.و به‌جای اون، روی چیزی که تحت کنترل توئه تمرکز کنی: خودت. مسیرت. انتخاب‌هات. واکنش‌هات.و در نهایت...اگر دنبال کتابی هستی که با حرف‌های کلیشه‌ای پر نشده باشه،اگر می‌خوای از چرخه‌ی بی‌پایان تأیید گرفتن و کنترل کردن خلاص شی،و اگه واقعاً می‌خوای «رهبری» کنی،کتاب The Let Them Theory همونیه که باید بخونی.این فقط یک کتاب روان‌شناسی نیست.یک منشور برای تصمیم‌گیری با قدرت، رهبری با آرامش و ساخت محصول با ذهنی آزادتره. ReyMind ReyMind Mon, 04 Aug 2025 10:37:06 +0330 https://virgool.io/@m_33382600/%D9%88%D9%82%D8%AA%DB%8C-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DB%8C-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D9%85%D9%87%D9%85%D9%87-%D9%88%D9%84%DB%8C-%DA%AF%D8%B1%D9%81%D8%AA%D9%86-%D9%85%D8%AC%D9%88%D8%B2-%D9%85%D9%87%D9%85-%D8%AA%D8%B1-ozfybnebxnml مقدمه:به‌عنوان مدیر محصول، همیشه بهمون می‌گن باید صدای کاربر باشی. اما بعضی وقت‌ها، مخصوصاً وقتی محصولت تو بازارهای حساس و رگوله‌شده فعالیت می‌کنه، واقعیت اینه که کاربر اول تو، خودِ کاربر نهایی نیست.من اخیراً عضو تیم محصولی در بازار مالی شدم، با تمرکز روی تأمین مالی جمعی. محصولی که قبل از رسیدن به هر کاربری، باید از هفت‌خان گرفتن مجوز از فرابورس عبور کنه. یعنی اولویت‌ها، از طراحی گرفته تا تجربه‌ کاربری و حتی ترتیب توسعه‌ی فیچرها، نه بر اساس خواسته‌های کاربر، بلکه بر اساس نیازهای رگولاتور تعیین می‌شن.چالش: تضاد بین طراحی برای کاربر و طراحی برای ناظرفرض کن باید فرآیند ثبت‌نام رو طراحی کنی. به‌عنوان یک PM دغدغه‌مند، احتمالاً دنبال کمترین اصطکاکی. ولی وقتی فرابورس الزام می‌کنه که احراز هویت چندمرحله‌ای، تطبیق اطلاعات هویتی با مراجع مختلف، و ذخیره‌سازی لاگ‌های مشخصی انجام بشه، اون تجربه‌ی دل‌چسب و مینیمال عملاً غیرممکن می‌شه.در چنین شرایطی، ممکنه وسوسه بشی بگی: «این دیگه از کنترل من خارجه و قید فکر کردن به کاربر رو بزنی.»اما دقیقاً همین‌جا جاییه که مدیر محصول بودن شروع می‌شه...راه‌حل: بازطراحی نقش خودم از "مدیر تجربه" به "معمار تعادل"برای اینکه از این چالش عبور کنم، به‌جای تقابل با قوانین، تصمیم گرفتم باهاشون هم‌مسیر بشم. نه به‌عنوان یک مانع، بلکه به‌عنوان یک چارچوب. این رویکرد به من کمک کرد از یک وضعیت «محدودکننده» به یک موقعیت «قابل مدیریت» برسم.تحلیل‌گر قوانین شدم، نه فقط دریافت‌کننده‌ی نیاز:به‌جای اینکه صرفاً چک‌لیستی از الزامات رو تحویل بگیرم، سعی کردم منطق پشت هر الزام رو بفهمم. اینکه چرا فلان فیلد باید اجباری باشه؟ چرا باید لاگ خاصی ذخیره بشه؟فهم این منطق کمکم کرد تا با تیم طراحی، نسخه‌هایی از فیچرها رو بسازیم که در عین رعایت قانون، تا حد ممکن تجربه‌ کاربری رو حفظ کنن.گاهی البته منطق مشخصی پشت برخی الزامات نبود. اما این هم نباید بهانه‌ای برای کنار کشیدن می‌شد. وقتی متن قانون شفاف باشه، همیشه راهی هست که هم قانون رو رعایت کنه و هم کاربر رو آزار ندهاز "نه" به "چطور؟" تغییر موضع دادم:هر جا تیم گفت: «این تجربه‌ی کاربری خوبی نیست»، سعی نکردم قانع‌شون کنم که الزام درسته یا شکایت کنم. تنها سوالی که مطرح کردم این بود:«درسته... حالا چطور می‌تونیم این الزام رو با کمترین اصطکاک اجرا کنیم؟»همین تغییر زاویه باعث می‌شد گفت‌وگو از سطح مقاومت، به سطح حل مسئله منتقل بشه.داستان ساختیم، نه فقط فیچر:بعضی فیچرها صرفاً برای گرفتن مجوز طراحی می‌شن. نه خوشگل‌ان، نه مفید، و نه حتی گاهی قابل دفاع از دید کاربر. ولی به‌جای اینکه صرفاً به چشم بار اضافی بهشون نگاه کنیم، سعی کردم با تیم طراحی و محتوا براشون داستان بسازیم. مثلاً یک گزارش‌گیری پیچیده که صرفاً برای ناظر بود، تبدیل شد به داشبورد تحلیلی قابل‌فهم برای کاربران حرفه‌ای.گاهی لازم نیست ماهیت فیچر رو تغییر بدی، فقط کافیه زاویه‌ی دید کاربر بهش رو دوباره طراحی کنی.جمع‌بندی:ساخت محصول در فضای رگوله‌شده، مثل راه رفتن روی طنابیه بین خواسته‌های قانون‌گذار، انتظارات کاربر، و منطق تیم محصول.و شاید بزرگ‌ترین مهارت مدیر محصول این فضا، نه طراحی تجربه‌ی بی‌نقص، بلکه خلق تعادلی قابل‌قبول در یک شرایط غیرایده‌آله.اگر جای جنگیدن با قوانین، سعی کنی بفهمیشون، می‌تونی راهی پیدا کنی برای اینکه هم محصول مجوز بگیره، هم کاربر حس کنه احترامش حفظ شده.گاهی اولین وظیفه‌ی ما اینه که زمین بازی قانونی رو بسازیم؛ بازی تجربه‌ کاربری، بعداً شروع می‌شه. ReyMind ReyMind Wed, 30 Jul 2025 09:08:32 +0330