چرا بیشتر تیمهای محصول، مشغول حل کردن اشتباهترین مسئله هستند؟
چند سال پیش اگر از یک Product Manager میپرسیدید محصول خوب چه محصولی است، احتمالاً از تعداد قابلیتها، نوآوری یا سرعت توسعه حرف میزد.
امروز اگر همان سؤال را بپرسید، پاسخها حرفهایتر شدهاند.
داده.
NPS.
Product Discovery.
Experimentation.
Customer Centricity.
همه اینها درستاند.
اما به نظرم یک سؤال مهم هنوز کمتر پرسیده میشود:
چرا با وجود اینکه داده بیشتری داریم، ابزارهای بهتری داریم و بیشتر از گذشته با کاربران صحبت میکنیم، هنوز تعداد زیادی محصول شکست میخورند؟
مشکل این نیست که تیمها داده ندارند.
مشکل این است که داده را با تصمیم اشتباه میگیرند.
وقتی درباره محصول صحبت میکنیم، معمولاً خروجی را میبینیم.
صفحه جدید.
قابلیت جدید.
داشبورد جدید.
اما محصول از اینها ساخته نشده است.
محصول، نتیجه هزاران تصمیم کوچک و بزرگی است که قبل از ساختن گرفته شدهاند.
اینکه چه چیزی را نبینیم.
چه چیزی را نسازیم.
چه مسئلهای را اصلاً حل نکنیم.
و مهمتر از همه...
کدام فرض را قبل از هزینه کردن، به چالش بکشیم.
اطمینان کاذب است.
خیلی از تصمیمهای بد، از کمبود اطلاعات نمیآیند.
از این میآیند که فکر میکنیم اطلاعات کافی داریم.
کاربر گفته این قابلیت را میخواهد.
داده نشان میدهد نرخ تبدیل افت کرده است.
رقیب این ویژگی را اضافه کرده است.
همه اینها ممکن است درست باشند.
اما هیچکدام الزاماً مسئله واقعی را توضیح نمیدهند.
تیمهای ضعیف سریع جواب پیدا میکنند.
تیمهای خوب، بیشتر سؤال میپرسند.
چون راهحلها قابل اندازهگیریاند.
میتوان آنها را توسعه داد.
منتشر کرد.
روی Roadmap گذاشت.
اما سؤال خوب، چنین ویژگیای ندارد.
هیچکس برای یک سؤال عالی جشن انتشار نمیگیرد.
در حالی که کیفیت یک محصول، بیشتر از کیفیت پاسخهایش، به کیفیت سؤالهایی بستگی دارد که تیمش میپرسد.
وقتی کاربران از چیزی ناراضی هستند، معمولاً اولین واکنش این است:
«چه چیزی باید اضافه کنیم؟»
اما شاید سؤال بهتر این باشد:
اگر اجازه نداشتیم هیچ فیچر جدیدی بسازیم، باز هم میتوانستیم این مشکل را حل کنیم؟
این سؤال، زاویه دید را عوض میکند.
شاید مسئله، نبود قابلیت نباشد.
شاید مسئله، ترتیب نمایش اطلاعات باشد.
شاید پیامهای سیستم مبهم باشند.
شاید کاربر نمیداند قدم بعدی چیست.
شاید محصول بیش از حد از کاربر تصمیم میخواهد.
همه اینها مشکل محصولاند، بدون اینکه به یک فیچر جدید نیاز داشته باشند.
ساختن یک قابلیت، معمولاً سادهتر از تصمیم گرفتن درباره ساختن آن است.
چیزی که هزینه واقعی ایجاد میکند، کد نیست.
پیامد تصمیم است.
هر فیچر جدید یعنی:
یک مسیر جدید برای تست.
یک سناریوی جدید برای پشتیبانی.
یک تصمیم جدید برای کاربر.
یک پیچیدگی جدید برای تیم.
به همین دلیل، بلوغ یک تیم محصول را نباید از تعداد قابلیتهایی که منتشر میکند سنجید.
بلکه باید از تعداد قابلیتهایی سنجید که آگاهانه تصمیم گرفته هرگز نسازد.
سالها تصور میکردیم نوآوری یعنی اضافه کردن.
امروز بیشتر باور دارم که نوآوری، در بسیاری از مواقع، یعنی حذف کردن.
حذف یک کلیک.
حذف یک تصمیم.
حذف یک ابهام.
حذف یک فرض اشتباه.
حذف یک فیچر که هیچوقت نباید ساخته میشد.
به همین دلیل، شاید مهمترین سؤال هر جلسه Product Review این نباشد که:
«بعدی چیست؟»
بلکه این باشد:
«اگر از امروز مجبور شویم با نصف امکانات فعلی محصول کار کنیم، کدام بخش را حفظ میکنیم و چرا؟»
پاسخ این سؤال، معمولاً هسته واقعی ارزش محصول را نشان میدهد.
به نظرم، تفاوت بین تیمهای متوسط و تیمهای بزرگ، در کیفیت کدنویسی یا حتی کیفیت طراحی نیست.
تفاوت، در کیفیت تصمیمهاست.
محصول خوب، محصولی نیست که بیشترین قابلیت را داشته باشد.
محصول خوب، محصولی است که بیشترین تعداد تصمیم درست را پشت سر هم گرفته باشد.
و شاید مهمترین مهارت یک Product Manager هم همین باشد:
نه ساختن فیچرهای بیشتر...
بلکه ساختن سیستمی که تصمیمهای بهتری بگیرد.
