بعد از لانچ 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 را بالا ببرد.
ادامه در مطلب بعدی 👇
4January 2, 2026 262 1 8
