<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های هادی محمدزاده</title><link>https://virgool.ir/feed/@Hadi_mz</link><description>مدیر محصولی که هم عاشق ساخت محصول‌های باارزشه، هم حواسش به جیب مدیرعامله</description><language>fa</language><pubDate>2026-11-11 19:41:08</pubDate><image><url>https://files.virgool.ir/upload/users/3959608/avatar/64TFB9.jpg</url><title>هادی محمدزاده</title><link>https://virgool.ir/@Hadi_mz</link></image><item><title>پروداکت دیسکاوری یعنی چی؟ و چرا ما فقط داریم حدس می‌زنیم؟</title><link>https://virgool.ir/@Hadi_mz/پروداکت-دیسکاوری-یعنی-چی-و-چرا-ما-فقط-داریم-حدس-می-زنیم-ifuifmwjehe2</link><description>تقریباً همه‌مون تو تیم‌های محصول یه بار این سناریو رو تجربه کردیم: ایده‌ای داریم، حس می‌کنیم خیلی کاربرپسنده، سریع می‌ریم سراغ طراحی و توسعه. بعد چند هفته، لانچش می‌کنیم... و هیچی! نه کسی استفاده می‌کنه، نه تاثیری روی عددها می‌ذاره.مشکل کجاست؟ خیلی وقتا مشکل از همون اول راهه. ما فقط حدس زدیم. نه نیازی رو کشف کردیم، نه تأیید گرفتیم، نه حتی با کاربر حرف زدیم. فقط “فکر کردیم” که فلان چیز می‌تونه جواب بده.اینجا دقیقاً جاییه که پروداکت دیسکاوری می‌تونه نجاتمون بده.پروداکت دیسکاوری یعنی قبل از اینکه بری تو دل توسعه، اول بری بفهمی اصلاً مسئله چیه، مخاطب واقعیش کیه، و اینکه اصلاً چیزی که در ذهن تو هست واقعاً براش ارزش داره یا نه. یعنی به‌جای ساختن و بعداً فهمیدن، اول بفهمی، بعد بسازی.اما چرا توی فضای استارتاپی ایران معمولاً این مرحله یا انجام نمی‌شه یا خیلی سطحی برگزار می‌شه؟چند تا دلیل داره:تیم‌ها تحت فشار زمانی‌ان و حس می‌کنن پروداکت دیسکاوری سرعتشون رو می‌گیره.منابع انسانی محدود دارن و آدمی که کاربر رو خوب بشناسه، ندارن.تیم هنوز تجربه‌ی آزمون و خطا نداره، برای همین اهمیت تحقیق اولیه رو نمی‌فهمه.گاهی از بالا به تیم دیکته می‌شه که &#34;فلان فیچر رو بساز&#34; بدون اینکه اصلاً مسئله‌ای تأیید شده باشه.ولی خب، اینا به‌معنای غیرممکن بودنش نیست. حتی با منابع خیلی محدود هم می‌شه دیسکاوری رو درست انجام داد.مثال واقعی بزنم:چند وقت پیش تیم Linear (یه ابزار محبوب مدیریت تسک بین دولوپرها) می‌خواست تجربه‌ی کاربر رو موقع گزارش باگ بهبود بده. به‌جای اینکه خودشون حدس بزنن کاربر دنبال چیه، یه فرم خیلی ساده طراحی کردن که وقتی کسی باگ گزارش می‌کرد، چند تا سؤال ازش می‌پرسید. خروجی چی شد؟ فهمیدن مشکل اصلی کاربرها اصلاً سادگی فرم نیست، بلکه اینکه نمی‌دونن سرنوشت اون باگ چی می‌شه. نتیجه؟ تمرکز تیم رفت روی شفاف‌سازی وضعیت باگ‌ها، نه طراحی مجدد فرم.نکته‌ش اینه که نه مصاحبه‌ی پیچیده‌ای گرفتن، نه ریسرچر اختصاصی داشتن. فقط یه فرم ساده گذاشتن و خوب گوش دادن. همین.حالا چطوری می‌شه این کار رو تو ایران و با منابع محدود انجام داد؟اول، هر هفته با حداقل یه مشتری حرف بزن. نه برای فروش، نه برای تعریف محصول. فقط برای اینکه بفهمی آخرین باری که اون مشکل رو تجربه کرده، چی کار کرده، چه راه‌حلی پیدا کرده، از چی شاکی بوده.دوم، از چیزهایی که همین الان داری استفاده کن. داده‌های پشتیبانی، دایرکت‌های اینستاگرام، پیام‌های تلگرام فروشنده‌ها، همه‌شون طلا هستن اگه درست تحلیلشون کنی.سوم، برای تست یه ایده لازم نیست حتماً بری یه فیچر واقعی بسازی. می‌تونی یه فایل Figma نشون بدی، یه Google Form راه بندازی، یا حتی با یه تماس تلفنی بفهمی کاربر اصلاً دغدغه‌ش اون چیزیه که تو فکر می‌کنی یا نه.و آخر اینکه همیشه قبل از شروع به توسعه، یه فرضیه بساز. به‌جای اینکه بگی &#34;این فیچر خوبه&#34;، بگو &#34;ما فکر می‌کنیم فلان کاربر، به دلیل فلان نیاز، به این راه‌حل علاقه‌منده&#34;. بعد برو تایید یا ردش کن.اگه بخوام خلاصه کنم، پروداکت دیسکاوری یعنی این که قبل از خرج کردن منابع ارزشمند (چه زمان باشه، چه پول، چه انرژی تیم)، اول بدونی داری دقیقاً چی رو، برای کی و چرا می‌سازی.تو هم تو تیم محصولت این مرحله رو جدی می‌گیری؟ یا هنوزم بیشتر بر اساس &#34;حس‌مون می‌گه خوبه&#34; تصمیم می‌گیرین؟اگه خواستی می‌تونم ادامه‌ش رو هم برات بنویسم، مثلاً یه چک‌لیست ساده برای اجرای پروداکت دیسکاوری تو تیمای کوچیک، یا راه‌های مصاحبه با کاربر تو فضای B2B ایران کافیه فقط بگی.</description><category>هادی محمدزاده</category><author>هادی محمدزاده</author><pubDate>Thu, 17 Apr 2025 09:59:37 +0330</pubDate></item></channel></rss>