مدیر محصولپاسخ‌های مصاحبه

من تحقیق کاربری، استراتژی کسب‌و‌کار و داده‌ها را ترکیب می‌کنم تا یک بک‌لاگ اولویت‌بندی‌شده بسازم. از چارچوب‌هایی مثل RICE (Reach, Impact, Confidence, Effort) یا ICE برای امتیازدهی یکسان به فرصت‌ها استفاده می‌کنم. تیم را به حلِ مشکلات کاربران و نه صرفاً ساختِ امکانات تشویق می‌کنم. مهندسین را از ابتدا در ارزیابی امکان‌سنجی وارد می‌کنم تا چیزهایی را در اولویت قرار ندهم که از نظر فنی در بازهٔ زمانی مورد نیاز غیرممکن‌اند. و اولویت‌بندی را شفاف می‌کنم — تیم و ذی‌نفعان باید "چرایی" پشت هر تصمیم را بفهمند.

من روش‌های کیفی و کمی را ترکیب می‌کنم. کیفی: مصاحبه‌های عمیق (10–15 در هر چرخهٔ کشف)، آزمایش قابلیت استفاده و پرس‌وجوی زمینه‌ای برای درک "چرایی" رفتار. کمی: تحلیل استفاده، داده‌های قیف، نظرسنجی‌ها و نتایج آزمون‌های A/B برای درک "چی" به مقیاس. من بینش‌ها را به حوزه‌های فرصت تبدیل می‌کنم، نه درخواست‌های ویژگی — کاربران مشکل را به شما می‌گویند، وظیفهٔ مدیر محصول است که راه‌حل را طراحی کند.

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

من مهندسین را وارد مرحلهٔ کشف می‌کنم — دیدگاه آن‌ها دربارهٔ محدودیت‌ها و امکان‌سنجی کیفیت راه‌حل‌هایی را که پیشنهاد می‌دهم بهبود می‌بخشد. من داستان‌های کاربری واضح با معیارهای پذیرش می‌نویسم، اما "چگونگی" را به مهندسین واگذار می‌کنم. در طول اسپرینت‌ها برای پاسخ به سوالات در دسترس هستم و تیم را از تغییرات دامنه در میانهٔ اسپرینت محافظت می‌کنم. با طراحان، از آغازِ تعریف مسئله همکاری می‌کنم — طراحی عالی و محصول عالی جریان‌های کاری جدا نیستند. معتقدم بهترین محصولات از تیم‌های چندوظیفه‌ای که واقعاً به هم اعتماد دارند پدید می‌آیند.

من معیارهای موفقیت را پیش از ساخت تعریف می‌کنم — معیارهای نتیجه‌ای که به مشکلی از کاربران که حل می‌کنیم پیوند دارند، نه فقط معیارهای خروجی مثل ویژگی‌های منتشرشده. برای اینکه یک ویژگی بتواند نگهداری کاربران را بهبود دهد، ممکن است نگهداری 30 روزه و 90 روزه را برحسب کوهورت پیگیری کنم. یک حداقل آستانهٔ موفقیت قبل از عرضه تعیین می‌کنم و در هفتهٔ چهارم و هشتم پس از عرضه بازبینی می‌کنم. آماده‌ام ویژگی‌هایی که به سطح موردنظر نمی‌رسند حذف یا تکرار شوند. اندازه‌گیری بی‌معنی است مگر اینکه آمادهٔ عمل بر اساس یافته‌ها باشید.

من هر درخواست را جدی می‌گیرم و نیاز زیرین را بررسی می‌کنم. متوجه شده‌ام که "من می‌خواهم ویژگی X" اغلب به این معنی است که "من مشکل Y دارم" — و راه‌حل مناسب ممکن است کاملاً متفاوت از آنچه درخواست شده باشد. من یک نقشهٔ راه شفاف و عمومی نگهداری می‌کنم و تصمیمات اولویت‌بندی را با استفاده از همان معیارها برای همهٔ درخواست‌ها توضیح می‌دهم. وقتی می‌گویم نه، دلیلش را می‌گویم و یک جدول زمانی برای زمان بازنگری احتمالی پیشنهاد می‌کنم. گفتن نه یکی از مهم‌ترین مهارت‌های مدیر محصول است.

من در سه افق برنامه‌ریزی می‌کنم: اکنون (اسپرینت جاری)، بعد (سه‌ماههٔ بعدی)، و بعدتر (6–12 ماه). کوتاه‌مدت با تحویل‌دادنی‌های متعهدانه جزئی‌نگری شده است؛ بلندمدت هدایت‌گر و عمداً منعطف است. نقشهٔ راه را به‌صورت فصلی با تیم بازبینی می‌کنم و آن را به‌طور گسترده به اشتراک می‌گذارم — شفافیت انتظارات ناسازگار را کاهش می‌دهد. نقشه‌ها را بر اساس نتایج (مسئله‌ای که حل می‌کنیم) نه ویژگی‌ها (آنچه می‌سازیم) ارائه می‌دهم، که تمرکز را بر ارزش نه خروجی نگه می‌دارد.

خلاصه و متمرکز بر کسب‌وکار نگه می‌دارم: استراتژی چیست، انتظار نتیجه چیست، ریسک‌های کلیدی کدام‌اند. داده‌هایی برای پشتیبانی تصمیم‌ها ارائه می‌دهم، نه برای نمایش حجم کار. تصمیمات محصول را بر اساس تاثیر بر مشتری و کسب‌وکار چارچوب‌بندی می‌کنم. انتظارات را به‌صورت فعال مدیریت می‌کنم — مدیران اجرایی نباید در زمان بازنگری غافلگیر شوند. و درخواست تصمیم می‌کنم، نه صرفاً تأیید — آمدن با یک پیشنهاد، گفتگوهای اجرایی را بسیار سازنده‌تر می‌کند.