نقش product manager تو دورهٔ ساخت ارزون
خلاصهٔ کاملتر
تو این مقاله از وبلاگ base14 اومده که کار یه product manager امروز به سه سؤال خلاصه میشه: چی بسازیم، بعد از ship کردن چی شد، و کی داره میسازه. نویسنده میگه یه تیم کوچیک با ابزارهای AI میتونه یه بعدازظهر prototype بسازه. ولی ساختن ارزون شده، مسئولیت نه. هر فیچر برای جلب توجه مشتری رقابت میکنه، محصول رو پیچیدهتر میکنه و شاید سالها باید پشتیبانی بشه. پس محدودیت واقعی انتخاب اینه که چی ارزش ساخته شدن داره.
به گفتهٔ نویسنده، roadmap یه تصمیم خرجه. PM باید هدف استراتژی رو به یه عدد تبدیل کنه که تیم بتونه همین فصل تکونش بده، مثلاً نرخ تبدیل trial به اشتراک پولی. بعد شرطها رو رتبهبندی کنه و یه لیست هم از ایدههای خوبی که فعلاً سراغشون نمیرن بنویسه. ایدهها هم معمولاً از مشتری، مهندسها، پشتیبانی و فروش میان. نویسنده هشدار میده که demoهای آماده فقط ثابت میکنن «میشه ساختش»، نه اینکه ارزش نگه داشتن داره.
برای کشف نیاز، مقاله از ایدهٔ jobs to be done کمک میگیره، یعنی آدمها محصول رو برای پیشرفت تو یه کار مشخص «استخدام» میکنن. مثال معروف Clayton Christensen اینه که مسافرها میلکشیک میخریدن تا رانندگی طولانی کمتر خستهکننده باشه. اگه یه شرط ارزون و برگشتپذیره، بذاریدش جلوی چند تا مشتری. اگه گرون یا غیرقابل برگشته، اول مصاحبه و تست prototype.
مهمترین توصیهٔ مقاله اینه که قبل از ساخت، پیشبینی رو تو یه خط بنویسید: کدوم عدد، چقدر، تا کی، با چه هزینهای، و چه نتیجهای باعث حذف فیچر میشه. بعد از انتشار، اگه ترافیک کافیه یه control group (یعنی گروهی از کاربرها که تغییر رو نمیبینن) نگه دارید. نویسنده به مقالهٔ ۲۰۰۹ Ronny Kohavi از Microsoft اشاره میکنه که فقط حدود یکسوم آزمایشهای خوب، عدد هدف رو بهتر کردن. پس شکست طبیعیه؛ دیر فهمیدنش مشکله.
بخش آخر دربارهٔ تیمه. با ارجاع به Marty Cagan، نویسنده میگه تیم باید «missionary» باشه، یعنی به مسئله باور داشته باشه، نه مزدوری که فقط دستور اجرا میکنه. PM باید دانش مشتری رو با تیم شریک بشه و آخرین فیلتر کیفیت قبل از انتشار عمومی باشه. نویسنده معتقده با AI کار «قابل قبول» زیاد شده، پس PMی ارزش داره که فرق قابل قبول و خوب رو تشخیص بده.
نکات کلیدی:
- کار PM سه سؤاله: چی بسازیم، چی شد، کی میسازه
- قبل از ساخت یه پیشبینی یهخطی با عدد، زمان، هزینه و شرط حذف بنویسید
- طبق تحقیق ۲۰۰۹ Microsoft فقط حدود یکسوم آزمایشها عدد هدف رو بهتر کردن
- کنار roadmap یه لیست از ایدههای خوبی که انجام نمیدید هم نگه دارید
- چهار سؤال هفتگی: چرا اولویت اول اینه، عدد تکون میخوره، تیم دلیلش رو میدونه، و اسمتون رو پای این انتشار میذارید؟




