کمتر بساز، بهتر بشو: هنر حذف فیچر
خلاصهٔ کاملتر
یه تحقیق جالب از دانشگاه ویرجینیا هشت آزمایش مختلف انجام داده که توی همهشون از شرکتکنندهها خواسته شده یه چیزی رو بهتر کنن. نتیجه؟ تقریباً همه رفتن سراغ اضافهکردن، نه حذفکردن. حتی توی یه آزمایش که حذف یه بلوک لگو رایگان بود ولی اضافهکردن پول میخواست، باز هم ۶۰٪ آدمها گزینه حذف رو در نظر نگرفتن. این یعنی ما بهصورت طبیعی سیمکشیمون به سمت «بیشتر» هست.
این ذهنیت توی دنیای محصول خیلی خطرناکه. گزارش Pendo در سال ۲۰۱۹ که روی ۶۱۵ نرمافزار مختلف بررسی انجام داد، نشون داد که ۸۰٪ فیچرها بهندرت یا اصلاً استفاده نمیشن. فقط ۱۲٪ از فیچرها هستن که ۸۰٪ استفاده روزانه رو پوشش میدن؛ یه نمونه کلاسیک از اصل پارتو.
مشکل اینجاست که فیچرهای اضافهشده فقط «بیفایده» نیستن؛ اونا «ارزش منفی» دارن. یعنی هزینه دارن، پیچیدگی ایجاد میکنن و گاهی اوقات تجربه کاربری رو بدتر میکنن. مثال خوبش همون اتفاق اولین نسخه AI Overviews گوگل بود که پیشنهادات کاملاً اشتباه و خطرناک میداد.
از نظر روانشناسی هم یه اصل معروف به اسم قانون هیک (Hick's Law) وجود داره که میگه هرچقدر تعداد انتخابها بیشتر باشه، زمان تصمیمگیری بیشتر میشه. پس هر فیچر جدید عملاً بار شناختی کاربر رو زیاد میکنه و محصول رو سختتر میکنه، نه آسونتر. Des Traynor، یکی از بنیانگذاران Intercom، این رو خیلی خوب گفته: «راه رسیدن به نرمافزار بدردنخور با 'فقط یه فیچر دیگه چون مشتری نیاز داره' سنگفرش شده.»
از طرف مهندسی هم وضع فرقی نداره. تخمین زده میشه که نگهداری نرمافزار بیش از ۷۰٪ از کل هزینههای عمر یه محصول رو میبلعه. پس اون فیچر «سریع و ساده»ای که دو سال پیش شیپ کردین، هنوز داره هزینه میده. بعلاوه، هر دقیقهای که صرف نگهداری این پیچیدگیها میشه، میتونست صرف چیز باارزشتری بشه. Jason Fried، بنیانگذار Basecamp، هم میگه: «محصول خوب یعنی گفتن نه به تقریباً همه چیز، تقریباً همیشه.»
حالا با ورود AI این مشکل داره بدتر هم میشه. چون سرعت توسعه بالا رفته، خیلی از تیمها دارن بدون فکر فیچرهای AI میسازن که کسی نخواسته. یه سوال رایج اینه که «وقتی میشه توی چند ساعت چیزی ساخت، چرا discovery بکنیم؟» ولی این سوال دقیقاً همون تله «بیشتر = بهتر» هست. سرعت بیشتر در جهت اشتباه کمکی نمیکنه. نتیجهاش میشه یه SaaS که مثل ریموت کنترل تلویزیون با ۵۰ دکمهست که کسی ازشون استفاده نمیکنه.
یه پروداکت منیجر خوب باید مهارت «حذف کردن» رو تمرین کنه. بهترین محصولها سادهان. شلوغ نیستن. وظیفه PM اینه که فعالانه علفهای هرز رو بزنه. discovery هنوز هم مهمه؛ نه فقط برای پیدا کردن بهترین راهحل، بلکه برای جلوگیری از ساختن چیزی که کسی نمیخواد یا بدتر، چیزی که تجربه کاربر رو خراب میکنه.
نکات کلیدی:
- ۸۰٪ فیچرهای نرمافزارها بهندرت یا اصلاً استفاده نمیشن
- فیچرهای اضافه فقط بیفایده نیستن؛ ارزش منفی دارن و هزینه نگهداری ایجاد میکنن
- قانون هیک میگه انتخابهای بیشتر = تصمیمگیری سختتر برای کاربر
- نگهداری نرمافزار بیش از ۷۰٪ از کل هزینه عمر محصول رو میگیره
- AI سرعت توسعه رو بالا برده ولی این به معنی ساختن همه چیز نیست
- discovery هنوز ضروریه؛ هدفش کاهش ریسک شیپکردن چیز اشتباهه
- مهارت اصلی PM اینه که بدونه چه چیزی رو نسازه




