اُکیان برای ادامه مسیرش به دو Product Owner نیاز داره.
ما تا اینجا بدون PO جلو رفتیم، اما برای سرعت بیشتر و نظم روزانه تیم، وقت اضافه‌شدن مالک محصول تا در متدولوژي اجایل مسولیت بپذیره.
اگر کسی رو می‌شناسید، ممنون می‌شم معرفی کنید.
جزییات آگهی پایین هست یا اگر سوالی دارید از من بپرسید.
رزومه هم در جاب‌ویژن ارسال کنید.


https://www.linkedin.com/feed/update/urn:li:activity:7397981336373813248/

ما برای این موقعیت شغلی هنوز نفر دوم رو جذب نکردیم ( مالک محصول یا مدیر محصول آشنا به فرایند های اسکرام).
- لطفا اگر ساکن تهران هستید
- اماده به کار هستید (‌فرایند استعفا ندارید)
- کارکردن روی پلتفرم های هوش مصنوعی براتون جذابیت داره
- تفکر داده محور دارید
- و هارد اسکیل محصولی دارید و سافت اسکیلی منعطف هستید و اداپت می‌شید، خوشحال میشم بهم پیام بدهید.
* شرح شغل رو از مسیر جاب اینجا بخونید :)

https://lnkd.in/ex-f2EnC

بعد از لانچ MVP، توسعه محصول از بک‌لاگ شروع نمی‌شود؛ از تحلیل رفتاری تعامل انسانی با محصول شروع می‌شود

برای مدیر محصول، سخت‌ترین بخش مسیر بعد از لانچ MVP شروع می‌شود.
بعد از MVP دیگر سؤال این نیست که «چه فیچری بسازیم؟»
سؤال واقعی این است:
«کدام درد واقعیِ کدام کاربر، همین حالا بیشترین ارزش را دارد؟»
و پاسخ این سؤال، نه در بک‌لاگ است، نه در فیگما،
بلکه در فیدبک‌های خام، ناقص، گاهی متناقض و اغلب احساسی کاربران.

چالش اول: فیدبک زیاد، فهم کم
بعد از لانچ، در صورتی که بودجه کافی برای تبلیغات و ورود کاربر داشته باشیم، معمولاً با سیلی از فیدبک‌ها مواجه می‌شویم:
• «این رو دوست ندارم»
• «این برام کار نکرد»
• «کاش این‌طوری بود»
• «من نفهمیدم این بخش چیکار می‌کنه»
مشکل اینجاست که بخش زیادی از کاربران هنوز شناخت درستی از محصول ندارند.آن‌ها محصول را با ذهنیت، عادت‌ها و تجربه‌های قبلی خودشان قضاوت می‌کنند، نه با منطق طراحی ما.
در این مرحله، نقش مدیر محصول فقط شنیدن نیست؛
ترجمه کردن است:
• ترجمه احساس به مسئله
• ترجمه گلایه به نیاز
• ترجمه سردرگمی به نقص تجربه کاربری
و این ترجمه، انرژی‌برترین بخش کار است.

چالش دوم: توسعه مرحله‌ای تعامل کاربر، نه فقط محصول
یکی از بزرگ‌ترین اشتباه‌ها بعد از MVP این است که: محصول جلوتر از کاربر حرکت کند
در حالی که در واقعیت:
• کاربر باید قدم‌به‌قدم با محصول رشد کند
• یاد بگیرد
• اعتماد کند
• و کم‌کم عادت بسازد
این یعنی:
• بعضی فیچرها زود هستند
• بعضی قابلیت‌ها هنوز «قابل درک» نیستند
• و بعضی ایده‌های خوب، فقط به خاطر زمان‌بندی غلط، شکست می‌خورند
مدیر محصول اینجا باید همزمان:
• مربی کاربر باشد
• مدافع سادگی
• و دشمن پیچیدگی زودهنگام
چالش سوم: تصمیم‌گیری بین صداهای بلند و داده‌های آرام
همه فیدبک‌ها برابر نیستند.همه کاربرها هم نماینده اکثریت نیستند.
در این مرحله، داده‌ها حرف می‌زنند و مدیر محصول باید بتواند صدای داده ها را بشنود!
• DAU چند نفر هر روز برمی‌گردند؟
• WAU چند بار در هفته محصول را انتخاب می‌کنند؟
• MAU آیا محصول جایی در زندگی ماهانه‌شان پیدا کرده؟
• Retention چه تعداد از کاربران، وفادار می‌شوند؟
این اعداد، مکمل فیدبک‌ها هستند، نه جایگزین آن‌ها. گاهی کاربری خیلی پرصداست، اما فقط یک‌بار آمده. گاهی کاربری هیچ نمی‌گوید، اما هر هفته برمی‌گردد.
هنر مدیر محصول این است که:
بین صدای بلند احساسات و صدای آرام داده‌ها تعادل برقرار کند.

چالش چهارم: اولویت‌بندی در شرایط ابهام
بعد از لانچ MVP
• بک‌لاگ همیشه پر است
• منابع همیشه محدودند
• و تصمیم‌ها همیشه خاکستری‌اند
اینجا دیگر «بهترین تصمیم» وجود ندارد؛ فقط تصمیمی وجود دارد که بیشترین یادگیری را ایجاد کند.
توسعه بعد از MVP باید:
• فرضیه‌محور باشد
• قابل اندازه‌گیری باشد
• و قابل بازگشت
هر فیچر یک سؤال است، نه یک جواب.
چالش پنهان اما حیاتی: Engagement Rate
اگر DAU، WAU و MAU به ما بگویند کاربر برگشته یا نه، Engagement Rateبه ما می‌گوید: وقتی برگشته، واقعاً با محصول چه‌کار کرده؟
• آیا فقط اپ را باز کرده؟
• یا واقعاً وارد تجربه اصلی محصول شده؟
• آیا ارزشی که طراحی کرده‌ایم، لمس شده یا نه؟
خیلی وقت‌ها بعد از MVP با این عدد روبه‌رو می‌شویم:
• DAU بد نیست
• نصب‌ها قابل قبول‌اند
• اما Engagement پایین است
و این خطرناک‌ترین حالت ممکن است؛
چون یعنی کاربر آمده، اما چیزی او را نگه نداشته.
Engagement Rate پایین معمولاً نشانه‌ی یکی از این‌هاست:
• مسیر کاربر بیش از حد پیچیده است
• ارزش اصلی محصول دیر آشکار می‌شود
• یا فیچرهایی ساخته‌ایم که مسئله‌ی اصلی کاربر نیستند
در این شرایط، اضافه کردن فیچر جدید نه‌تنها کمک نمی‌کند، بلکه تمرکز کاربر را بیشتر پخش می‌کند.
اینجاست که مدیر محصول باید شجاع باشد:
• حذف کند
• ساده‌سازی کند
• و گاهی برگردد به ابتدایی‌ترین فرضیات MVPو تغییرات لحاظ کند تا Engagement Rate را بالا ببرد.
ادامه در مطلب بعدی 👇

ادامه مطلب قبلی 👆
جمع بندی کاربردی:
گام ۱: هر فیدبک را بلافاصله به یکی از این چهار دسته ترجمه کن:
• عدم درک (Confusion)
• اصطکاک (Friction)
• نیاز برآورده‌نشده (Unmet Need)
• ترجیح شخصی (Preference)
📌 فقط سه مورد اول، ورودی توسعه هستند.

گام ۲: هر فیچر را با یک سؤال شروع کن
قبل از اضافه شدن به بک‌لاگ، این سه سؤال باید پاسخ داشته باشند:
• این فیچر کدام رفتار کاربر را تغییر می‌دهد؟
• انتظار داریم Engagement کجا بالا برود؟
• اگر اشتباه بود، چطور سریع متوجه می‌شویم؟
📌 اگر پاسخ مبهم است،طراحی و توسعه فیچر هنوز زود است.

گام ۳: Engagement را قبل از Retention جدی بگیرید
تا وقتی کاربر وارد تجربه اصلی نشده یا ارزش را لمس نکرده صحبت از وفاداری بی‌معناست.
📌 هر اسپرینت حداقل یک تغییر باید مستقیماً روی Engagement اثر بگذارد:
• کوتاه‌تر شدن مسیر
• شفاف‌تر شدن ارزش
• حذف یک پیچیدگی

گام ۴: شجاعت حذف داشته باشید
بعد از MVP هر چیزی که Engagement را بالا نمی‌برد، بدهی است، نه دارایی
• حذف = پیشرفت
• ساده‌سازی = استراتژی
جمع‌بندی: سخت‌ترین بخش مدیریت محصول
توسعه محصول بر اساس فیدبک کاربران سخت است چون:
• کاربران همیشه دقیق حرف نمی‌زنند
• داده‌ها همیشه کامل نیستند
• و زمان همیشه علیه توست
اما دقیقاً همین‌جاست که مدیریت محصول معنا پیدا می‌کند

جبر جغرافیا؛ وقتی نقشه دنیا ابزارهای ما را محدود می‌کند

ما دوست داریم باور کنیم که در عصر اینترنت، جغرافیا دیگر معنا ندارد.
این‌که اگر ایده‌ای داشته باشی، اگر انگیزه داشته باشی، ابزارها همیشه در دسترس‌اند.
اما واقعیت برای خیلی از ما چیز دیگری‌ست.

جبر جغرافیا فقط یعنی این‌که کجا به دنیا آمده‌ای؛
یعنی این‌که کجا زندگی می‌کنی، به چه زیرساختی وصل هستی، و چه چیزهایی ممکن است ناگهان از دسترس خارج شوند.

برای بعضی‌ها جبر جغرافیا یک مفهوم تئوریک است؛
برای بعضی دیگر، یک تجربه‌ی روزمره.

برای ما که کارمان با ساختن، برنامه‌ریزی، محصول، استراتژی و رودمپ گره خورده،
ابزارها فقط «وسیله» نیستند؛
بخشی از جریان فکر ما هستند.

حالا تصور کن:
ابزارهای تخصصی‌ات — به هر دلیلی — دیگر در دسترس نیستند.
نه به‌خاطر ضعف تو، نه به‌خاطر نداشتن دانش،
بلکه صرفاً به‌خاطر جایی که روی نقشه ایستاده‌ای.

در این نقطه دو راه وجود دارد:

- یا متوقف شوی و بپذیری که «نمی‌شود»

- یا تصمیم بگیری که امید به آینده را عملی کنی
امید، وقتی واقعی است که ابزار بسازد

امید فقط یک احساس نیست؛
اگر قرار است معنا داشته باشد، باید به عمل تبدیل شود.

فایل و توضیحات شیوه استفاده از رودمپ در ۲ مطلب بعدی⬇️

برای من، این تصمیم به یک سؤال ختم شد:

اگر ابزار آنلاین ندارم، چرا ابزار آفلاین نسازم؟

در ادامه فایل رودمپ اکسل رو براتون می فرستم. هر چند قدیمی و خسته کننده است و کامپوننت های فیگما یا جیرای کلود خودشون به بهترین نحو رودمپ دارن،‌اما جبر جغرافیا منو مجبور کرد که این فایل رو بسازم،‌حالا با شما شیر میکنم شاید به کار شما هم آمد.
فایل در کامنت همین مطلب در دسترس است. دانلودش کنید و فیدبک بدهید.

ادامه در مطلب بعدی ⬇️

این فایل یک رودمپ آفلاین، تیم‌محور و نتیجه‌گرا (Outcome-Driven) است؛
طوری طراحی شده که حتی بدون دسترسی به ابزارهای آنلاین، بتوانید کار را جلو ببرید، اولویت‌بندی کنید و پیشرفت واقعی بسازید.

در این رودمپ:
تمرکز روی نتیجه (Outcome) است، نه صرفاً انجام تسک
زمان‌بندی به‌صورت هفتگی (W1–W4) و ماه‌به‌ماه دیده می‌شود
هر ردیف نماینده‌ی یک تیم است (Product، Design، Marketing، Tech، Support)

رنگ‌ها فقط نشان‌دهنده‌ی «در حال انجام بودن» نیستند؛ بلکه تعهد زمانی به یک Outcome مشخص را نشان می‌دهند

خروجی/Outcome یعنی چه در این رودمپ؟
خروجی/Outcome یعنی:

«بعد از این بازه زمانی، چه تغییری باید رخ داده باشد؟»
نه این‌که:
چه کارهایی انجام شده
یا چه تسک‌هایی تیک خورده

بلکه:
-چه مسئله‌ای حل شده؟
-چه چیزی برای کاربر، تیم یا محصول بهتر شده؟
-چه تصمیمی ممکن یا غیرممکن شده؟

مثال:

❌ طراحی ۳ صفحه
✅ آماده شدن MVP قابل تست برای کاربر واقعی

ساختار ستون‌ها

تیم/Team
تیمی که مالک آن Outcome است (حتی اگر چند تیم در اجرا درگیر باشند)

خروجی/Outcome
یک جمله‌ی شفاف، قابل فهم و قابل قضاوت
(طوری که آخر ماه بتوان گفت: «اتفاق افتاد یا نه؟»)

الویت/Priority
اهمیت Outcome نسبت به بقیه (High / Medium / Low یا عددی)

هفته‌ها/Week Blocks (W1–W4)
تعهد زمانی تیم به آن Outcome
اگر خانه‌ای رنگی شده، یعنی:
این تیم در این هفته متعهد است روی این Outcome کار کند

ابزارهای آنلاین؛ مفید، اما همیشه در جبر جغرافیای ما در دسترس نیستند.

امروز پلتفرم‌های آنلاین قدرتمندی برای رودمپ، برنامه‌ریزی و همکاری تیمی وجود دارند؛ ابزارهایی مثل Miro، FigJam، Productboard، Aha!، Jira Product Discovery و Notion که در شرایط عادی می‌توانند کار تیم‌ها را سریع‌تر و شفاف‌تر کنند. ابزارهای دیگری مانند ClickUp، Linear، Trello، Asana و Monday هم هر کدام بخشی از این نیاز را پوشش می‌دهند.
مسئله اما کیفیت این ابزارها نیست؛ مسئله اینجاست که در جغرافیایی زندگی می‌کنیم که تحریم، قطعی اینترنت یا محدودیت دسترسی می‌تواند هر لحظه این ابزارها را از «امکان» به «عدم دسترسی» تبدیل کند. درست در همین نقطه است که جبر جغرافیا خودش را نشان می‌دهد و وابستگی کامل به ابزارهای آنلاین، به‌جای مزیت، به ریسک تبدیل می‌شود.

وقتی شفاف نیست کدوم مدل هوش مصنوعی می تونه جواب نیازهای تخصصی اتون رو بده می تونید به سایت:

https://arena.ai/

مراجعه کنید و مدل هایی که بینش شک دارید رو انتخاب کنید ،‌با یک سوال یکسان ببینید هر کدوم چه جوابی می دهن،‌ و بعد تصمیم بگیرید و اشتراک اونی رو بخرید که بیشتر مورد نیازتونه.

بعد مدت ها،‌سلام.
امشب باید یه بیزنس پلن اماده می کردم. یه تمپلیت کانواس دارم.

اینجا می گذارم شاید به کار شما هم بیاد.
ارادت

ساختن یک استارتاپ سلامت با منابع محدود یعنی حتی ساده‌ترین خروجی‌ها هم پشت‌صحنه سختی دارند.

در DLady، تولید محتوای قابل اعتماد درباره باروری، پریود، PMS، سلامت اسپرم، تخمک‌گذاری و بارداری فقط «تولید محتوا» نیست؛ مخصوصاً وقتی باید همزمان به فارسی، عربی و انگلیسی نوشته شود، با دقت پزشکی، احترام فرهنگی و لحنی انسانی.

English: https://dlady.app/blog/
العربی:‌ https://lnkd.in/dxH9hn99
فارسی: https://lnkd.in/d_XmfUuM


باروری یک مسیر مشترک است.
نه فقط زنانه است.
نه فقط مردانه.

عامل مردانه در بسیاری از مسیرهای ناباروری نقش دارد، اما وقتی بارداری اتفاق نمی‌افتد، بار روانی، اجتماعی و اغلب بخش زیادی از بار جسمی و درمانی همچنان بیشتر روی زن می‌افتد.

ما می‌خواهیم این گفت‌وگو را تغییر دهیم؛
از سرزنش به آگاهی،
از سکوت به همراهی،
از فشار به مراقبت مشترک.

سه مقاله اخیر ما درباره ورزش‌های آرامی است که می‌توانند در روزهای PMS، دوران پریود و پنجره باروری به حال بهتر بدن کمک کنند.

بخوانیدشان و اگر برایتان مفید بود، به اشتراک بگذارید.
گاهی یک آگاهی کوچک می‌تواند شروع مراقبتی بهتر برای یک نفر دیگر باشد.

آگاهی می‌تواند شرم را کمتر کند.
همراهی می‌تواند فشار را سبک‌تر کند.
و امید، گاهی از همین فهم مشترک شروع می‌شود.

#DLady #FertilityHealth #HealthTech #FemTech #MaleFertility #WomenHealth #StartupJourney

یکی از مهم‌ترین درس‌هایی که تاکنون،‌از کار در تیم‌های کراس فانکشنال، یاد گرفته‌ام.
صادقانه بگویم، سخت‌ترین بخش ساختن محصول، ساختن فیچر نیست.
سخت‌ترین بخش این است که یک تیم، بالاخره روی یک تعریف مشترک از موفقیت به توافق برسد.
در ساخت محصولات دیجیتال، به‌خصوص محصولاتی که AI در بخشی از آن‌ها نقش دارد، خیلی راحت می‌شود مدل جدید اضافه کرد، قابلیت جدید ساخت، داشبورد جدید بالا آورد و تعداد تسک‌ها را بیشتر کرد.
اما این‌ها لزوماً به معنی رشد محصول نیست.
اگر تیم نداند:
— دقیقاً کدام مسئله کاربر را حل می‌کند؛
— قرار است چه رفتاری را تغییر دهد؛
— موفقیت را با چه عددی بسنجد؛
— و چه کسی واقعاً مسئول نتیجه است؛
محصول فقط پیچیده‌تر می‌شود، نه بهتر.
‏
مکنزی در بررسی اخیر خود نوشته است که فقط ۷٪ شرکت‌ها توانسته‌اند هوش مصنوعی را در مقیاس سازمانی توسعه دهند. یکی از موانع اصلی هم نبود داده‌ای است که قابل‌اعتماد، قابل‌ردیابی و قابل‌استفاده مجدد باشد.
هاروارد بیزنس ریویو هم روی یک نکته مهم تأکید می‌کند:
تیم محصول نباید فقط مسئول تحویل پروژه باشد؛ باید بعد از انتشار هم مالک نتیجه، پذیرش و عملکرد محصول بماند.

اما بخش مهم‌تر برای من، راهکار عملی است.
قبل از شروع هر فیچر، این ۵ سؤال باید پاسخ روشن داشته باشد:
۱. مسئله دقیقاً چیست؟
نه اسم فیچر، نه درخواست مدیر، نه چیزی که رقبا ساخته‌اند.
مسئله واقعی کاربر باید در یک جمله ساده و شفاف نوشته شود.
۲. قرار است چه رفتاری تغییر کند؟
کاربر سریع‌تر به ارزش برسد؟
بیشتر برگردد؟
پرداخت کند؟
اشتراک خود را تمدید کند؟
اگر تغییر رفتار مشخص نیست، احتمالاً هنوز مسئله را درست نفهمیده‌ایم.
۳. معیار موفقیت چیست؟
یک معیار اصلی انتخاب کنید.
با نقطه شروع، عدد هدف و بازه زمانی مشخص.
«بهبود تجربه کاربر» معیار نیست.
«افزایش نرخ بازگشت از ۲۰٪ به ۳۰٪ در سه ماه» معیار است.
۴. منبع حقیقت کجاست؟
تعریف متریک، منبع داده، منطق محاسبه و زمان به‌روزرسانی باید برای همه یکسان باشد.
وقتی هر تیم عدد خودش را دارد، جلسه دیگر جلسه تصمیم‌گیری نیست؛ جلسه دفاع از برداشت‌هاست.
۵. مالک نتیجه کیست؟
برای هر نتیجه باید یک مالک مشخص وجود داشته باشد.
نه یک تیم مبهم.
نه چند نفر هم‌زمان.
نه مسئولیتی که در نهایت روی زمین بماند.
قانونی که امروز برای جلسات محصول دارم
هر جلسه باید با این چهار خروجی تمام شود:
یک تصمیم، یک معیار، یک مالک و یک موعد بررسی.
اگر جلسه فقط با چند تسک جدید تمام شد، احتمالاً هنوز تصمیم محصولی نگرفته‌ایم؛ فقط کار توزیع کرده‌ایم.
مهم‌ترین درس من در اکیان این بوده است:
محصول با تعداد چیزهایی که می‌سازیم رشد نمی‌کند؛
با کیفیت تصمیم‌هایی که می‌گیریم رشد می‌کند.
و هر داشبوردی که نتواند یک تصمیم روشن ایجاد کند، فقط نسخه شیک‌تر و حرفه‌ای‌تری از حدس‌زدن است.
منابع
تجربه شخصی من در مدیریت تیم‌های کراس فانکشنال و رشد محصول و جذب یوزر

📌 McKinsey — AI Data Readiness: The Key to Scaling Impact
🔗 https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/ai-data-readiness-the-key-to-scaling-impact

📌Harvard Business Review — Why the Digital Product Model Beats Project-Based Approaches
🔗 https://hbr.org/2026/03/why-the-digital-product-model-beats-project-based-approaches

https://lnkd.in/p/evWCuijF

حضور برای عموم ازاد است.
با لینک مایکروسافت تیمز که در کامنت گذاشتم می تونید جوین بشید .

دردناک ترین قسمت استارت اپ اینه که تو می دونی محصول خوبی ساختی، بقیه هم می دونن؛ اما به درآمد رسیدن ربطی به خوب بودن نداره.

با همه دستاورد ها، ما در آستانه جمع کردن این کسب و کاریم.

اگر جمع شد، حتما از تجاربم خواهم نوشت. از اینکه *اول باید بفروشی و بعد محصول رو بسازی*

و این نفروختن، بزرگ‌ترین اشتباه و درسی بود که من از طراحی و توسعه DLady گرفتم.


https://www.instagram.com/p/DayQlarJB3O/?igsh=ZnVqdzBkNGNxbmR4

درس n+1:
باید سراغ بیزنسی بروی که پیاده سازی و اجرای آن خیلی در دسترس نباشد، وگرنه خیلی زود رقبای زیادی خواهی داشت.
برای موفق بودن یا باید اول باشی یا دوم، سوم بودن فایده ندارد. اگر بیشتر از این هستی که سریع جمع کن!

درس n+2:

اون‌ها هم مثل ما دارن یاد می‌گیرن.
هم هارد و هم سافت!

این کتاب رو می خواهم شروع کنم به خوندن،‌شما اگر خوندیدن،‌دریافت و درکتون از کتاب رو با ما در کامنت ها به اشتراک بگذارید .


evolutionary learning alkhamis

درس سوم: ساختن یک بیزنس، با ساختن یک مزیت رقابتی فرق دارد.

هرچقدر ورود به یک بازار ساده‌تر باشد، رقابت در آن سریع‌تر و شدیدتر می‌شود.

اگر محصولی را بتوان با چند API، کمی سرمایه و یک تیم کوچک ساخت، باید فرض کنید دیگران هم می‌توانند خیلی زود همان کار را انجام دهند؛ شاید حتی بهتر از شما.

در چنین بازاری، صرفاً پول خرج کردن، تبلیغات بیشتر یا حتی زودتر شروع کردن، تضمین نمی‌کند که برنده بمانید.

مثلاً در صنعت بیمه، وقتی زیرساخت‌های اصلی از طریق API در دسترس قرار می‌گیرند، ساخت یک سرویس فروش بیمه بسیار ساده‌تر می‌شود. نتیجه؟

تعداد بازیگران بالا می‌رود، محصولات شبیه هم می‌شوند، رقابت روی قیمت شدیدتر می‌شود و در نهایت حاشیه سود کاهش پیدا می‌کند.

پس قبل از شروع یک بیزنس، فقط نپرسید:

«آیا می‌توانم این را بسازم؟»

سؤال مهم‌تر این است:

«اگر فردا ده نفر دیگر هم توانستند همین را بسازند، چه چیزی باعث می‌شود مشتری من را انتخاب کند؟»

اگر جواب روشنی برای این سؤال ندارید، احتمالاً هنوز بیزنس نساخته‌اید؛ فقط یک محصول قابل کپی ساخته‌اید.