کاربری را تصور کنید که در مسیر رفت‌وآمد روزانه مشغول گوش‌دادن به یک پادکست است. اینترنت برای چند ثانیه قطع می‌شود، پخش متوقف می‌شود و بعد از اتصال مجدد، برنامه به‌درستی ادامه نمی‌دهد. کاربر چند بار تلاش می‌کند و در نهایت اپلیکیشن را می‌بندد.
حالا تیم محصول تصمیم گرفته تجربه کاربران با اینترنت ضعیف را بهبود دهد. یک نفر پیشنهاد می‌کند امکان دانلود محتوا اضافه شود، دیگری سراغ کاهش کیفیت پخش می‌رود و طراح محصول معتقد است باید صفحه اصلی را سبک‌تر کنیم.
هر سه پیشنهاد می‌توانند مفید باشند، اما کدام‌یک واقعا مسئله اصلی کاربر را حل می‌کند؟
این همان تصمیمی است که در سؤال یازدهم مجموعه هزار سؤال مصاحبه مدیر محصول بررسی می‌کنیم.
سؤال مصاحبه چیست؟
اگر کاربران یک اپلیکیشن محتوا اینترنت ناپایداری داشته باشند، کدام بخش محصول را بازطراحی می‌کنید؟
در نگاه اول، سؤال درباره طراحی رابط کاربری به نظر می‌رسد؛ اما مصاحبه‌کننده بیشتر از آنکه دنبال یک قابلیت جدید باشد، می‌خواهد شیوه تصمیم‌گیری مدیر محصول را بسنجد.
یک پاسخ قوی باید نشان دهد که می‌توانیم:
- مسئله واقعی را از راه‌حل‌های پیشنهادی جدا کنیم.
- گروه مشخصی از کاربران و مهم‌ترین نیازشان را انتخاب کنیم.
- چند راه‌حل را با توجه به ارزش، هزینه و ریسک مقایسه کنیم.
- تصمیمی بگیریم که امکان آزمایش و اصلاح آن وجود داشته باشد.
- موفقیت را با رفتار واقعی کاربر بسنجیم، نه تعداد قابلیت‌های منتشرشده.
پاسخ ضعیف معمولا با فهرستی از قابلیت‌ها شروع می‌شود. پاسخ حرفه‌ای از این سؤال شروع می‌کند که کاربر دقیقا کجا و چرا از انجام کارش بازمی‌ماند.
۱. اول مشخص کنیم اینترنت ناپایدار چه مشکلی ایجاد کرده است
اینترنت ناپایدار برای همه کاربران یک معنی ندارد.
کسی که مقاله می‌خواند، ممکن است با بازنشدن تصاویر یا بارگذاری دوباره صفحه مشکل داشته باشد. کاربری که ویدئو تماشا می‌کند، احتمالا از توقف‌های مکرر پخش ناراضی است. برای کسی که پادکست گوش می‌دهد، حفظ موقعیت پخش و ادامه‌دادن بدون دردسر می‌تواند مهم‌تر باشد.
حتی نوع اختلال هم یکسان نیست. گاهی سرعت پایین است، گاهی اتصال برای چند ثانیه قطع می‌شود و گاهی شبکه ظاهرا متصل است، اما دریافت داده عملا پیش نمی‌رود.
بنابراین قبل از طراحی، چهار موضوع را روشن می‌کنیم:
کاربر کیست؟ کاربران روزانه، مخاطبان تازه‌وارد یا افرادی که بیشتر هنگام رفت‌وآمد از محصول استفاده می‌کنند؟
می‌خواهد چه کاری انجام دهد؟ خواندن مقاله، گوش‌دادن به پادکست، تماشای ویدئو یا ذخیره محتوا برای بعد؟
اختلال کجا اتفاق می‌افتد؟ هنگام ورود، جست‌وجو، شروع پخش، ادامه مصرف محتوا یا بازگشت به برنامه؟
محدودیت ما چیست؟ زمان توسعه، ظرفیت ذخیره‌سازی دستگاه، هزینه انتقال داده، حقوق انتشار محتوا و امکانات فنی فعلی محصول؟
تا زمانی که به این پرسش‌ها پاسخ نداده‌ایم، انتخاب یک صفحه برای بازطراحی بیشتر حدس است تا تصمیم محصولی.
۲. به جای همه کاربران، یک گروه مشخص را انتخاب کنیم
فرض کنیم با یک اپلیکیشن پادکست و ویدئو روبه‌رو هستیم که کاربران آن اغلب با اینترنت موبایل محتوا مصرف می‌کنند.
برای شروع، یک گروه محدود انتخاب می‌کنیم: کاربران فعالی که هنگام رفت‌وآمد به محتوای صوتی گوش می‌دهند و در همان مسیر با قطع‌ووصلی اتصال روبه‌رو می‌شوند.
این انتخاب به معنی بی‌اهمیت‌بودن نیاز سایر کاربران نیست. هدف این است که مسئله‌ای مشخص، پرتکرار و قابل بررسی پیدا کنیم.
سه معیار می‌توانند در این انتخاب کمک کنند:
- شدت مشکل: اختلال فقط چند ثانیه تأخیر ایجاد می‌کند یا کاربر را از ادامه کار منصرف می‌کند؟
- تکرار مشکل: چند بار در یک هفته یا در یک جلسه مصرف محتوا اتفاق می‌افتد؟
- راه‌حل فعلی کاربر: منتظر می‌ماند، کیفیت را تغییر می‌دهد، دوباره تلاش می‌کند یا سراغ محصول دیگری می‌رود؟
برای پاسخ، داده‌های محصول را با مشاهده و گفت‌وگو ترکیب می‌کنیم. رویدادهای توقف پخش، تلاش مجدد و خروج از برنامه می‌توانند نشانه باشند؛ اما به‌تنهایی علت رفتار کاربر را توضیح نمی‌دهند.
مثلا خروج از پخش همیشه به معنی شکست نیست. ممکن است کاربر به مقصد رسیده باشد یا عمدا ادامه محتوا را به زمان دیگری موکول کرده باشد.
این تفاوت اهمیت زیادی دارد؛ چون قرار نیست هر خروجی را به حساب اینترنت ضعیف بگذاریم.
۳. کدام بخش را بازطراحی کنیم؟
اگر بررسی‌های اولیه نشان دهد بیشترین اختلال در زمان مصرف محتوا رخ می‌دهد، پیشنهاد من بازطراحی تجربه پخش و ادامه مصرف محتوا است، نه تغییر کامل صفحه اصلی یا همه بخش‌های اپلیکیشن.
سه مسیر اصلی پیش روی ما قرار دارد.
مسیر اول: سبک‌کردن رابط کاربری و بارگذاری محتوا
می‌توانیم تصاویر غیرضروری را دیرتر بارگذاری کنیم، حجم درخواست‌ها را کاهش دهیم و اطلاعات متنی یا فهرست محتوای ذخیره‌شده را زودتر نشان دهیم.
این راهکار زمانی ارزش بیشتری دارد که کاربران حتی پیش از رسیدن به محتوا با صفحه‌های خالی، جست‌وجوی ناموفق یا انتظار طولانی روبه‌رو باشند.
اما اگر مشکل اصلی توقف پخش در میانه یک پادکست باشد، سبک‌ترشدن صفحه اصلی احتمالا تأثیر محدودی خواهد داشت.
مسیر دوم: مقاوم‌کردن تجربه پخش در برابر اختلال شبکه
در این رویکرد، روی حفظ پیوستگی تجربه تمرکز می‌کنیم:
- ذخیره مطمئن موقعیت پخش و ادامه از همان نقطه
- تلاش مجدد کنترل‌شده پس از قطع اتصال، بدون درخواست‌های بی‌پایان
- نمایش وضعیت قابل فهم برای کاربر، مثل انتظار برای اتصال یا آماده‌بودن محتوای ذخیره‌شده
- تنظیم کیفیت متناسب با شرایط شبکه، در قالب‌هایی که از آن پشتیبانی می‌کنند
- جلوگیری از نابودی وضعیت فعلی پخش هنگام جابه‌جایی میان صفحه‌ها
این انتخاب برای کاربری مناسب است که اتصالش نوسان دارد، اما کاملا و برای مدت طولانی آفلاین نیست.
برای نمونه، مستندات رسمی Apple توضیح می‌دهد که HLS می‌تواند میان جریان‌های رسانه‌ای با نرخ بیت متفاوت جابه‌جا شود تا پخش با شرایط شبکه سازگارتر شود. البته این قابلیت به تنظیم درست فایل‌های رسانه‌ای، زیرساخت توزیع و پخش‌کننده هم وابسته است.
مسیر سوم: طراحی تجربه آفلاین
اگر کاربران در مسیرهای طولانی یا مناطق فاقد پوشش شبکه از محصول استفاده می‌کنند، مقاوم‌کردن پخش آنلاین ممکن است کافی نباشد.
در این شرایط می‌توانیم دانلود انتخابی، ذخیره محتوا برای استفاده بعدی، نمایش وضعیت دانلود و ادامه انتقال فایل پس از اختلال را بررسی کنیم.
اما طراحی آفلاین فقط اضافه‌کردن یک دکمه دانلود نیست.
باید مشخص شود محتوا تا چه زمانی قابل استفاده است، فایل ناقص چگونه مدیریت می‌شود، چه میزان فضا مصرف می‌کند، آیا کاربر اجازه ذخیره آن را دارد و اطلاعاتی مثل موقعیت پخش چطور بعد از اتصال مجدد هماهنگ می‌شوند.
در معماری Offline-first نیز هدف این نیست که همه قابلیت‌ها لزوما بدون اینترنت کار کنند؛ بلکه بخش‌های ضروری محصول باید تا حد امکان به اتصال لحظه‌ای وابسته نباشند.
راهنمای رسمی Android درباره طراحی Offline-first و مستندات Google برای ذخیره داده در برنامه‌های وب، مبانی فنی این انتخاب را توضیح می‌دهند.
تصمیم اولیه من چیست؟
با فرض اینکه کاربران عمدتا با قطع‌ووصلی کوتاه شبکه روبه‌رو هستند و مشکل در زمان پخش رخ می‌دهد، مسیر دوم را در اولویت قرار می‌دهم.
ابتدا تجربه پخش و بازیابی آن را اصلاح می‌کنیم. اگر شواهد نشان دهند کاربران برای مدت طولانی بدون اتصال می‌مانند، دانلود آفلاین را به‌عنوان مرحله بعد بررسی می‌کنیم.
این تصمیم تعادلی میان ارزش قابل مشاهده برای کاربر، پیچیدگی فنی و سرعت یادگیری ایجاد می‌کند. البته اگر داده‌ها نشان دهند کاربران اساسا نمی‌توانند محتوای موردنظرشان را پیدا یا باز کنند، باید اولویت را به صفحه فهرست، جست‌وجو یا بارگذاری اولیه تغییر دهیم.
۴. یک مثال نرم‌افزاری فرضی
سناریوی فرضی: یک اپلیکیشن محتوای صوتی به نام «آوا» داریم. تیم پشتیبانی پیام‌هایی دریافت می‌کند که کاربران هنگام ورود به تونل یا جابه‌جایی میان شبکه‌های موبایل، بخشی از تجربه شنیدن پادکست را از دست می‌دهند.
این گزارش‌ها هنوز اثبات نمی‌کنند که مشکل از اینترنت است؛ ممکن است خطای پخش‌کننده، محدودیت سرور یا مشکل ذخیره موقعیت شنیدن هم وجود داشته باشد.
مدیر محصول همراه تحلیلگر داده، طراح و توسعه‌دهندگان ابتدا مسیر کاربر را بررسی می‌کند: انتخاب اپیزود، شروع پخش، بروز اختلال، تلاش برای ادامه و خروج احتمالی.
تیم پشتیبانی نمونه‌های خطا را دسته‌بندی می‌کند و تیم فنی با شبیه‌سازی سرعت پایین و قطع موقت شبکه، رفتار پخش‌کننده را آزمایش می‌کند.
در این سناریو فرض می‌کنیم شواهد اولیه نشان می‌دهند قطع کوتاه شبکه گاهی باعث توقف طولانی پخش و از دست رفتن موقعیت شنیدن می‌شود.
دو راه‌حل عملی داریم:
گزینه A: بازطراحی رفتار پخش‌کننده؛ حفظ موقعیت شنیدن، تلاش مجدد کنترل‌شده، بازیابی وضعیت و پیام‌های روشن.
گزینه B: ساخت سامانه دانلود آفلاین با مدیریت فایل، فضای ذخیره‌سازی و هماهنگ‌سازی اطلاعات.
گزینه B برای کاربرانی که اتصال ندارند ارزش بیشتری ایجاد می‌کند، اما احتمالا هزینه توسعه و نگهداری بالاتری دارد. همچنین باید مسائل حقوق انتشار، امنیت فایل‌های ذخیره‌شده و مصرف حافظه دستگاه را بررسی کنیم.
برای این فرض مشخص، گزینه A نقطه شروع مناسب‌تری است.
تیم نسخه آزمایشی را ابتدا در شرایط شبکه شبیه‌سازی‌شده و سپس روی گروه محدودی از کاربران واقعی بررسی می‌کند. اگر بازیابی پخش بهتر شود، اما کاربران همچنان به دلیل قطعی‌های طولانی نتوانند محتوا را مصرف کنند، تصمیم بعدی می‌تواند سرمایه‌گذاری روی دانلود آفلاین باشد.
نکته مهم این است که انتخاب اولیه، تعهد همیشگی به یک راه‌حل نیست.
۵. موفقیت بازطراحی را با چه شاخص‌هایی می‌سنجیم؟
اگر فقط تعداد دانلودها یا تعداد بازدید از صفحه پخش را اندازه بگیریم، ممکن است تصویری اشتباه از موفقیت به دست بیاوریم.
برای این مسئله، سه نوع شاخص نیاز داریم.
شاخص نتیجه: مصرف موفق محتوا
برای نمونه، می‌توانیم سهم جلساتی را اندازه بگیریم که کاربر پس از شروع پخش، بخش معناداری از محتوای موردنظرش را بدون شکست فنی مصرف می‌کند.
اگر برای یک نوع اپیزود، رسیدن به ۸۰ درصد مدت محتوا را به‌عنوان معیار آزمایشی انتخاب کنیم، باید تعریف کنیم چرا این آستانه مناسب است؛ این عدد یک استاندارد عمومی نیست.
مخرج شاخص نیز اهمیت دارد: تعداد جلسات واجد شرایطی که پخش را شروع کرده‌اند، نه تعداد کل کاربران نصب‌کننده برنامه.
همچنین نتیجه را باید برای گروه‌های دارای اتصال پایدار و ناپایدار جداگانه ببینیم.
شاخص تشخیصی: تجربه اختلال
مواردی مانند تعداد توقف‌های ناخواسته، زمان لازم برای ادامه پخش پس از اختلال و نرخ بازیابی موفق می‌توانند نشان دهند مشکل از کجا می‌آید.
توقف عمدی کاربر باید تا حد امکان از توقف ناشی از خطای فنی تفکیک شود.
شاخص محافظتی: هزینه و کیفیت
باید مراقب باشیم بهبود یک بخش به بخش دیگری آسیب نزند.
مصرف اینترنت به ازای هر دقیقه پخش موفق، مصرف باتری، اشغال حافظه، خطاهای برنامه و هزینه انتقال داده برای کسب‌وکار از شاخص‌های محافظتی هستند.
مثلا اگر پخش مقاوم‌تر شود، اما درخواست‌های تکراری مصرف اینترنت کاربر را به‌شدت افزایش دهند، نمی‌توانیم بدون بررسی این هزینه، نتیجه را موفق بدانیم.
بهتر است پیش از آزمایش، مقدار پایه، بازه مشاهده، معیار تصمیم و شرایط توقف یا بازگشت را مشخص کنیم؛ مثلا عملکرد را در جلسات واجد شرایط طی دو هفته پس از انتشار آزمایشی با گروه مقایسه بررسی کنیم.
۶. یک ریسک کمتر دیده‌شده: هماهنگ‌سازی و اعتماد کاربر
فرض کنیم کاربر بخشی از پادکست را بدون اتصال گوش داده و هم‌زمان روی دستگاه دیگری موقعیت پخش متفاوتی ثبت شده است.
وقتی اتصال برمی‌گردد، کدام موقعیت باید نگه داشته شود؟
اگر برنامه بدون منطق مشخص، آخرین داده دریافتی را جایگزین کند، ممکن است تجربه کاربر خراب شود.
این مسئله در نشان‌کردن محتوا، دانلودهای نیمه‌تمام و تغییر وضعیت «شنیده‌شده» هم وجود دارد.
به همین دلیل ذخیره محلی و هماهنگ‌سازی، مسئله‌ای صرفا فنی نیست. مدیر محصول باید همراه تیم فنی درباره رفتار مورد انتظار، مدیریت تعارض و پیام‌هایی که کاربر می‌بیند تصمیم بگیرد.
برای برنامه‌های وب هم نباید فرض کنیم هر قابلیت هماهنگ‌سازی در پس‌زمینه روی همه مرورگرها قابل استفاده است. مستندات MDN نشان می‌دهد Background Synchronization API پشتیبانی یکسانی در مرورگرهای مختلف ندارد. بنابراین باید مسیر جایگزینی مانند هماهنگ‌سازی هنگام بازشدن مجدد برنامه در نظر بگیریم.
۷. پاسخ پیشنهادی در مصاحبه
نمونه پاسخ شفاهی یک داوطلب:
«من قبل از انتخاب بخشی برای بازطراحی، می‌خواهم بدانم کاربران دقیقا کجا با مشکل روبه‌رو می‌شوند. چون اینترنت ناپایدار می‌تواند روی جست‌وجو، بارگذاری صفحه یا پخش محتوا تأثیر متفاوتی داشته باشد.
اگر فرض کنیم محصول ما یک اپلیکیشن پادکست است و بیشتر کاربران هنگام رفت‌وآمد با قطع‌ووصلی کوتاه شبکه مواجه می‌شوند، اول سراغ تجربه پخش می‌روم.
بررسی می‌کنم چند بار پخش ناخواسته متوقف می‌شود، چقدر طول می‌کشد دوباره ادامه پیدا کند و آیا کاربر موقعیت شنیدنش را از دست می‌دهد یا نه.
بعد چند راه‌حل را مقایسه می‌کنم؛ مثلا بازیابی خودکار پخش، کاهش کیفیت متناسب با شبکه و دانلود آفلاین.
با این فرض، ترجیح می‌دهم ابتدا یک نسخه کوچک برای حفظ موقعیت و بازیابی پخش بسازیم و روی گروه محدودی آزمایش کنیم. شاخص اصلی‌ام مصرف موفق محتواست و در کنارش زمان توقف، مصرف اینترنت و خطاها را هم می‌سنجم.
اگر مشخص شود قطعی‌ها طولانی‌اند یا بیشتر شکست‌ها پیش از شروع پخش اتفاق می‌افتند، اولویتم را تغییر می‌دهم. برای من مهم است راه‌حل را بر اساس مسئله واقعی انتخاب کنم، نه اینکه از ابتدا روی یک قابلیت خاص اصرار داشته باشم.»
این پاسخ نشان می‌دهد داوطلب هم می‌تواند تصمیم بگیرد و هم می‌داند چه شواهدی باید باعث تغییر تصمیمش شوند.
۸. سؤال‌های تکمیلی مصاحبه
اگر فقط دو هفته برای بررسی و تصمیم‌گیری فرصت داشته باشید، چه می‌کنید؟
این پرسش در منبع اصلی سؤال یازدهم مطرح شده است.
در دو هفته نباید تلاش کنیم یک سامانه آفلاین کامل بسازیم. هدف این است که مهم‌ترین فرض را با کمترین هزینه ممکن بررسی کنیم.
در چند روز نخست، رخدادهای پخش و گزارش‌های پشتیبانی را بررسی می‌کنیم، با تعدادی از کاربران دارای تجربه اختلال گفت‌وگو می‌کنیم و رفتار برنامه را روی شبکه ضعیف بازسازی می‌کنیم.
سپس یک نمونه محدود، مثل ذخیره مطمئن موقعیت پخش و بازیابی پس از قطعی کوتاه، پیاده‌سازی یا نمونه‌سازی می‌کنیم.
در پایان دوره، نتیجه آزمایش را با مقدار پایه مقایسه می‌کنیم و درباره ادامه، اصلاح یا کنارگذاشتن راه‌حل تصمیم می‌گیریم.
خروجی دو هفته، لزوما یک قابلیت کامل نیست؛ می‌تواند یک تصمیم معتبرتر با شواهد روشن باشد.
چه شواهدی باعث می‌شوند راه‌حل پیشنهادی خودتان را رد کنید؟
این دومین پرسش تکمیلی منبع اصلی است.
اگر بفهمیم بیشتر کاربران قبل از رسیدن به پخش از محصول خارج می‌شوند، بازطراحی پخش‌کننده اولویت درستی نیست.
اگر داده‌ها نشان دهند بیشتر کاربران در دوره‌های طولانی فاقد اینترنت هستند، بازیابی اتصال کوتاه کافی نخواهد بود.
اگر آزمایش نسخه جدید بهبود معناداری در مصرف موفق محتوا نشان ندهد، یا هزینه مصرف داده و خطاها افزایش پیدا کند، باید راه‌حل را اصلاح یا متوقف کنیم.
توانایی ردکردن پیشنهاد خودمان، بخشی از تصمیم‌گیری حرفه‌ای است.
۹. اشتباهات رایج در پاسخ به این سؤال
شروع با قابلیت‌ها به جای مسئله: گفتن «دانلود آفلاین اضافه می‌کنم» بدون اینکه بدانیم کاربر کجا متوقف شده، نشان‌دهنده عجله در انتخاب راه‌حل است.
طراحی برای همه کاربران: نیاز کسی که مقاله می‌خواند با مخاطب ویدئوی زنده یکسان نیست. پاسخ باید مشخص کند کدام گروه را اول انتخاب کرده‌ایم و چرا.
برابر دانستن اتصال و تجربه موفق: متصل‌بودن دستگاه به اینترنت تضمین نمی‌کند محتوا به‌درستی بارگذاری یا پخش شود.
تمرکز صرف بر شاخص‌های ظاهری: افزایش تعداد پخش‌ها یا دانلودها، بدون بررسی مصرف موفق و رضایت کاربر، اثبات‌کننده رفع مشکل نیست.
نادیده‌گرفتن هزینه و محدودیت‌ها: ذخیره آفلاین می‌تواند با محدودیت حافظه، حق انتشار یا هماهنگ‌سازی روبه‌رو شود. پخش مجدد خودکار هم ممکن است مصرف اینترنت را افزایش دهد.
قطعیت بی‌دلیل: مدیر محصول قرار نیست بدون داده، با اطمینان اعلام کند کدام راه‌حل بهترین است. باید فرض‌ها و شرایط تغییر تصمیم را توضیح دهد.
در این مسئله نقش مدیر محصول انتخاب مسئله و نتیجه مطلوب است؛ طراح و مهندسان در طراحی و امکان‌سنجی راه‌حل مشارکت می‌کنند. اگر تیم از Scrum استفاده کند، Product Owner نسبت به بیشینه‌کردن ارزش محصول و مدیریت مؤثر بک‌لاگ پاسخ‌گوست و Project Manager، در صورت وجود این نقش، بیشتر بر هماهنگی تحویل در محدوده و محدودیت‌های پروژه تمرکز دارد. تقسیم دقیق مسئولیت‌ها به ساختار سازمان بستگی دارد.
جمع‌بندی
اگر قرار باشد یک بخش از اپلیکیشن محتوا را برای کاربران با اینترنت ناپایدار بازطراحی کنیم، با فرض اینکه اختلال اصلی هنگام مصرف محتوا رخ می‌دهد، تجربه پخش و ادامه مصرف محتوا انتخاب مناسب‌تری است. حفظ موقعیت، بازیابی پس از قطع اتصال و نمایش وضعیت روشن، می‌توانند نقطه شروعی کوچک و قابل آزمایش باشند.
اما این انتخاب مطلق نیست. اگر شواهد نشان دهند کاربران اصلا نمی‌توانند محتوا را پیدا کنند، باید از مسیر جست‌وجو و بارگذاری شروع کنیم. اگر مدت زیادی آفلاین می‌مانند، دانلود و مصرف آفلاین اهمیت بیشتری پیدا می‌کند.
در مصاحبه مدیریت محصول، ارزش پاسخ در تعداد قابلیت‌هایی نیست که پیشنهاد می‌دهیم؛ در این است که نشان دهیم برای چه کسی، کدام مشکل را، با چه شواهدی و در برابر چه هزینه‌ای حل می‌کنیم.
منابع
- Android Developers — Build an offline-first app
- Apple Developer — HTTP Live Streaming
- web.dev — Offline data
- MDN — Background Synchronization API
- Reforge — Product Manager Interview Questions
سؤال اصلی و دو پرسش تکمیلی از نسخه آموزشی سؤال Q0011 در مجموعه هزار سؤال مصاحبه مدیر محصول گرفته شده‌اند.
مثال «آوا» فرضی است و منابع فنی برای بررسی راهکارها به کار رفته‌اند.
مقاله Reforge درباره شیوه ارزیابی داوطلبان مدیریت محصول است، نه مدرکی مبنی بر اینکه همین سؤال مشخص در مصاحبه شرکتی مطرح شده است.
