<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های thesararoshani</title><link>https://virgool.ir/feed/@thesararoshani</link><description></description><language>fa</language><pubDate>2026-11-11 00:05:25</pubDate><image><url>https://files.virgool.ir/upload/users/4930348/avatar/qobAFG.png</url><title>thesararoshani</title><link>https://virgool.ir/@thesararoshani</link></image><item><title>جغرافیای مدیر محصول بودن</title><link>https://virgool.ir/@thesararoshani/جغرافیای-مدیر-محصول-بودن-qpvnijlbtim2</link><description>یک عنوان شغلی مشترک، اما محیط‌هایی که از ما مدیر محصول‌های متفاوتی می‌سازند.زمانی که Product Management (مدیریت محصول) را برای ادامه مسیر حرفه‌ای‌ام انتخاب کردم، نمی‌دانستم جایی که این نقش را در آن شروع می‌کنم، چقدر می‌تواند روی مدل فکری، تصمیم‌گیری و حتی مدل برخوردم با تیم اثر بگذارد.فکر می‌کردم مدیر محصول بودن یک نقش مشخص است.یک‌سری مهارت دارد که باید یاد بگیری، تجربه‌ای که باید به دست بیاوری و طبیعتاً هرچه جلوتر بروی، در آن بهتر می‌شوی.اما کم‌کم فهمیدم ماجرا به این سادگی نیست.اینکه مدیر محصول یک تیم کوچک باشی که هنوز دارد محصولش را می‌سازد یا تازه می‌خواهد کسی آن را بشناسد، با مدیر محصول یک کسب‌وکار فعال که محصول، کاربر، درآمد و تیم‌های مشخص دارد، می‌تواند دو تجربه کاملاً متفاوت باشد.حتی اگر عنوان شغلی هر دو نفر دقیقاً یکی باشد.من این نقش را در یک تیم کوچک تجربه کردم.و در تیم کوچک خیلی زود می‌فهمی که جمله‌ی «این کار من نیست» همیشه جواب نمی‌دهد.یک روز درگیر طراحی هستی.یک روز با کاربر صحبت می‌کنی.یک روز باید بفهمی چرا چیزی که ساختید درست کار نمی‌کند.یک روز محدودیت فنی مسیر محصول را تغییر می‌دهد.یک روز زمان آن‌قدر کم است که به‌جای پیدا کردن بهترین راه‌حل، باید بین چند راه‌حل نه‌چندان ایده‌آل یکی را انتخاب کنی.و بعضی روزها هم مسئله‌ای جلوی پایت قرار می‌گیرد که دقیقاً نمی‌دانی باید مدیر محصول حلش کند، مدیرعامل، طراح یا تیم فنی.فقط می‌دانی اگر کسی حلش نکند، محصول جلو نمی‌رود.این مدل کار کردن کم‌کم روی خودت هم اثر می‌گذارد.یاد می‌گیری با ابهام کنار بیایی.یاد می‌گیری همیشه قرار نیست اطلاعات کامل داشته باشی.یاد می‌گیری با آدم‌های کم، منابع محدود و زمان کم تصمیم بگیری.و شاید مهم‌تر از همه، محصول را فقط از داخل یک Figma (فیگما) یا Roadmap (نقشه راه) نبینی.مجبوری کمی از تکنولوژی بفهمی، کمی از مارکتینگ، کمی از رفتار کاربر، کمی از بیزنس و خیلی وقت‌ها از چیزهایی که اصلاً فکر نمی‌کردی روزی بخشی از کارت شوند.این قسمت ماجرا برای من جذاب است.اما یک روی دیگر هم دارد.وقتی تیم کوچک است، مرز مسئولیت‌ها خیلی راحت محو می‌شود.گاهی کاری را انجام می‌دهی نه چون بخشی از نقش توست، بلکه چون آدم دیگری برای انجام دادنش وجود ندارد.گاهی بخشی از طراحی دوباره روی میزت برمی‌گردد چون قبلاً طراح بوده‌ای.گاهی یک تصمیم محصولی وسط یک بحث فنی گرفته می‌شود.و گاهی مسئول نتیجه‌ای هستی که تمام تصمیم‌های منتهی به آن، دست خودت نبوده.اگر این وضعیت ادامه پیدا کند، یک سؤال عجیب برایت ایجاد می‌شود:کدام قسمت از این‌ها واقعاً مدیریت محصول است و کدام قسمت فقط نتیجه‌ی کار کردن در یک تیم کوچک؟فکر می‌کنم اینجا تفاوت با یک کسب‌وکار جاافتاده‌تر بیشتر خودش را نشان می‌دهد.وقتی محصول کاربر دارد، داده دارد، درآمد دارد و آدم‌های بیشتری مسئول بخش‌های مختلف هستند، جنس سؤال‌های مدیر محصول هم تغییر می‌کند.دیگر فقط این نیست که:«با همین آدم‌ها و همین زمانی که داریم چطور چیزی بسازیم که کار کند؟»حالا سؤال می‌تواند این باشد که چرا کاربران در یک مرحله محصول را رها می‌کنند؟کدام مسئله ارزش حل کردن بیشتری دارد؟کدام تصمیم می‌تواند روی رشد محصول اثر بیشتری بگذارد؟بین چند فرصت، کدام را باید انتخاب کنیم؟و چطور چند تیم مختلف را برای رسیدن به یک هدف هم‌جهت کنیم؟در تیم کوچک شاید بیشتر درگیر این باشی که چطور با چیزی که داری حرکت کنی.در تیم بزرگ‌تر، شاید بیشتر درگیر این باشی که از بین تمام کارهایی که می‌توانی انجام بدهی، بفهمی کدامشان ارزش انجام دادن دارند.هیچ‌کدام لزوماً بهتر یا راحت‌تر نیست.جغرافیایشان متفاوت است.و دقیقاً همین کلمه برای من جالب است:جغرافیا.دو نفر می‌توانند یک عنوان شغلی داشته باشند، اما محیطی که در آن رشد کرده‌اند، محدودیت‌هایی که دیده‌اند، آدم‌هایی که کنارشان بوده‌اند و مسئله‌هایی که هر روز حل کرده‌اند، در نهایت دو مدل متفاوت از یک مدیر محصول بسازد.کسی که مدیریت محصول را در یک تیم کوچک یاد گرفته، احتمالاً خیلی زود با ابهام، کمبود منابع و تصمیم‌های خارج از شرح وظایفش روبه‌رو شده.کسی که همین مسیر را در یک سازمان بزرگ و ساختاریافته شروع کرده، ممکن است از همان ابتدا کار با داده، فرآیند، تیم‌های تخصصی و ساختار مشخص تصمیم‌گیری را تجربه کرده باشد.هر دو مدیر محصول‌اند.اما احتمالاً چیزهای متفاوتی را خوب بلدند.و احتمالاً Blind Spot (نقطه کور)‌های متفاوتی هم دارند.این تفاوت حتی می‌تواند روی آدم‌هایی که برای یاد گرفتن از آن‌ها انتخاب می‌کنیم هم اثر بگذارد.چون بعضی وقت‌ها نیاز نداری کسی تعریف درست Product Management (مدیریت محصول) را برایت توضیح دهد.نیاز داری با کسی حرف بزنی که جغرافیای تو را می‌شناسد.کسی که خودش در یک تیم کوچک کار کرده و می‌فهمد وقتی چهار نفر هستید، خیلی از نسخه‌های ایده‌آل مدیریت محصول اصلاً آن شکلی که در کتاب نوشته شده قابل اجرا نیست.یا برعکس، کسی که تجربه یک سازمان بزرگ را دارد و می‌تواند از مسئله‌هایی بگوید که شاید تو هنوز هیچ‌وقت با آن‌ها روبه‌رو نشده‌ای.شاید حتی Community (جامعه حرفه‌ای) مدیران محصول هم همیشه نباید فقط بر اساس عنوان شغلی شکل بگیرد.گاهی آدم‌هایی که در یک جغرافیای کاری مشابه‌اند، حرف‌های بیشتری برای گفتن به هم دارند.و شاید یکی از مهم‌ترین بخش‌های رشد حرفه‌ای همین باشد:اینکه بعد از مدتی از خودت بپرسی محیطی که در آن رشد کرده‌ام، چه چیزهایی در من ساخته؟کدام رفتارم واقعاً یک مهارت است؟کدام قسمت نتیجه محدودیت‌هایی است که به آن‌ها عادت کرده‌ام؟کجا یاد گرفته‌ام مسئولیت بیشتری قبول کنم و کجا فقط یاد گرفته‌ام مرز نداشته باشم؟و اگر فردا وارد یک جغرافیای کاملاً متفاوت شوم، چقدر از چیزی که امروز به اسم «مدیر محصول بودن» می‌شناسم، همچنان کار خواهد کرد؟شاید عنوان شغلی ما روی کاغذ یکی باشد.اما جایی که آن نقش را زندگی کرده‌ایم، بخش بزرگی از مدیر محصولی است که در نهایت می‌شویم.من این جنس تجربه‌ها و چیزهایی که در مسیر Product Management (مدیریت محصول) یاد می‌گیرم را در PMBuzz (پی‌ام‌باز) هم می‌نویسم؛ فعلاً یک کانال کوچک تلگرامی برای حرف زدن درباره تجربه واقعی کار در محصول.شاید کم‌کم آدم‌هایی با جغرافیاهای متفاوت آنجا کنار هم جمع شوند.</description><category>thesararoshani</category><author>thesararoshani</author><pubDate>Wed, 16 Sep 2026 19:21:47 +0330</pubDate></item><item><title>قبل از اینکه آماده باشم، وارد یکی از جدی‌ترین نقش‌های کاری‌ام شدم!</title><link>https://virgool.ir/@thesararoshani/قبل-از-اینکه-آماده-باشم-وارد-یکی-از-جدی-ترین-نقش-های-کاری-ام-شدم-wwqjwvmusgsl</link><description>آن زمان در یک استارتاپ کوچک، Product Designer (طراح محصول) بودم.به Product Management (مدیریت محصول) علاقه داشتم، اما نه از این جهت که بخواهم آخر مسیرم مدیر محصول شدن باشد. چیزی که برایم جذاب بود، نزدیک شدن به خودِ کسب‌وکار بود؛ اینکه فقط طراحی نکنم، بلکه بفهمم چرا یک محصول ساخته می‌شود، چه مسئله‌ای را حل می‌کند، چرا بعضی تصمیم‌ها گرفته می‌شوند و اصلاً چه چیزی باعث می‌شود یک محصول زنده بماند.در یک تیم کوچک هم معمولاً نمی‌توانی فقط داخل مرز عنوان شغلی خودت بمانی.من طراحی می‌کردم، اما کم‌کم پایم به تست محصول، تماس با کاربر، بررسی مشکل‌ها، ایده‌های مارکتینگ و تصمیم‌های روزمره محصول هم باز شده بود.بعد جای Product Manager (مدیر محصول) در تیم خالی شد.من قبلاً علاقه‌ام را به این نقش نشان داده بودم و یک روز CEO (مدیرعامل) خیلی جدی پیشنهاد داد که مسئولیتش را قبول کنم.راستش برایم هیجان‌انگیز بود.و ترسناک.چون یک چیز علاقه داشتن به یک نقش است و یک چیز دیگر اینکه ناگهان مسئول تصمیم‌هایی شوی که روی تیم، محصول و کسب‌وکار اثر واقعی دارند.قبول کردم.و از همان‌جا یکی از جدی‌ترین دوره‌های یادگیری من شروع شد.CTO (مدیر ارشد فناوری) اما به‌اندازه مدیرعامل مطمئن نبود که من برای این نقش آماده‌ام.در جلسات زیاد با هم بحث می‌کردیم. تصمیم‌هایم را زیر سؤال می‌برد و یکی از حرف‌هایی که زیاد می‌شنیدم این بود:دانش کافی نداری.و اگر بخواهم امروز به آن روزها نگاه کنم، می‌گویم بخشی از حرفش درست بود.من واقعاً دانش عمیقی از مدیریت محصول نداشتم. خیلی از Framework (چارچوب)ها را نمی‌شناختم. برای خیلی از کارهایی که انجام می‌دادم حتی اسم حرفه‌ای مشخصی در ذهنم نداشتم.اما یک چیز را داشتم:کنجکاوی.خیلی زیاد.می‌خواستم بفهمم محصول چرا کار می‌کند یا چرا کار نمی‌کند. کاربر چرا می‌ماند یا چرا رها می‌کند. تیم فنی چرا با یک تصمیم مخالف است. مدیرعامل چرا روی یک موضوع پافشاری می‌کند. و اگر یک تصمیم جواب نداد، دقیقاً کجای فکرمان اشتباه بوده.بعدها فهمیدم قبل از اینکه اسم خیلی از این کارها را بدانم، داشتم بخشی از آن‌ها را تجربه می‌کردم.User Research (تحقیق کاربر)، Usability Testing (تست کاربردپذیری)، Voice of Customer (صدای مشتری)، Prioritization(اولویت‌بندی) و Product Discovery (کشف محصول).آن زمان شاید این اصطلاحات را بلد نبودم، اما سؤال‌هایم تقریباً همیشه یکی بود:کاربر کجا گیر کرده؟چرا این اتفاق افتاده؟این مسئله واقعاً مهم است یا فقط ما فکر می‌کنیم مهم است؟و چه چیزی را باید تغییر دهیم؟همین تجربه یک چیز مهم به من یاد داد:بلد بودن اصطلاحات، با فهمیدن واقعی یک مسئله یکی نیست.اما طرف دیگرش هم به همان اندازه مهم است.اینکه چند بار یک کار را تجربی انجام داده‌ای، به این معنا نیست که دیگر نیازی به یادگیری عمیق نداری.Experience (تجربه) به تو شهود می‌دهد.Knowledge (دانش) کمک می‌کند بفهمی آن شهود کجا قابل اعتماد است و کجا ممکن است گولت بزند.من امروز بیشتر از قبل به هر دو نیاز دارم، چون چشم‌اندازم دیگر فقط داشتن یک عنوان شغلی بهتر نیست.من می‌خواهم روزی کسب‌وکار خودم را بسازم.و برای ساختن کسب‌وکار، فقط دانستن محصول کافی نیست.باید آدم‌ها را بفهمی، پول را بفهمی، بازار را بفهمی، تکنولوژی را بفهمی، تصمیم بگیری، اشتباه کنی، مذاکره کنی، گاهی روی حرفت بایستی و گاهی هم آن‌قدر بالغ باشی که بگویی: «این‌جا من اشتباه کردم.»شاید به همین دلیل امروز به آن دوره فقط به چشم زمانی که مدیر محصول شدم نگاه نمی‌کنم.برای من، آن دوره یکی از اولین جاهایی بود که یاد گرفتم چطور کم‌کم از «انجام دادن یک کار» به سمت «فهمیدن یک کسب‌وکار» حرکت کنم.و فکر می‌کنم هنوز هم دقیقاً وسط همین مسیرم.</description><category>thesararoshani</category><author>thesararoshani</author><pubDate>Mon, 07 Sep 2026 15:30:47 +0330</pubDate></item></channel></rss>