منتجك الـ SaaS فيه ميزات أكثر من اللازم. إليك كيف تعالج ذلك دون حذف أي شيء

معظم المؤسّسين الذين يعانون من تخمة الميزات جرّبوا الحل البديهي بالفعل.

فكّروا في حذف ميزات.

ثم أعدّوا قائمة بالعملاء الذين يعتمدون على كل ميزة، فتوقّفوا.

المشكلة ليست فيما بنيته، بل في أنك بنيت ٤٠ شيئاً وواجهتك تعرض الأربعين كلها في اليوم الأول.

الترتيب التسلسلي هو الحل الذي لا يتحدّث عنه أحد، لأنه أقل ظهوراً من إعادة التصميم وأصعب في كتابته ضمن ملاحظات الإصدار.

لكنه يكاد يكون دائماً الخطوة الأولى الصحيحة.

وإليك كيف يعمل.

لماذا حذف الميزات عادةً خطوة أولى خاطئة

حين نراجع منتجاً سطراً بسطر مع عميل، نادراً ما نجد ميزات لا يستخدمها أحد.

فمعظم الميزات موجودة لأن عميلاً احتاجها، أو فريقاً اعتمد عليها، أو لأن سير عمل ما صار مهماً مع الوقت.

المشكلة أن المنتجات الناضجة غالباً ما تعامل كل ميزة كأنها تستحق القدر نفسه من الظهور.

وحذف الميزات قد يحلّ المشكلة الخطأ. فالقدرة قد تكون قيّمة ومع ذلك تُعرض في اللحظة الخطأ، أو للمستخدم الخطأ، أو في المكان الخطأ.

التعقيد لا ينشأ من كثرة القدرات وحدها.

بل يظهر حين لا يتطابق ظهور الميزة مع مدى تكرار استخدامها، أو مع من يحتاجها، أو مع اللحظة التي تصبح فيها مفيدة.

كيف تعرف أن منتجك يعرض أكثر مما ينبغي وقبل أوانه

عادةً ما تلاحظ الفرق الأعراض قبل أن تحدّد السبب.

١. المستخدمون يسألون أين توجد الأشياء، لا عن شيء جديد

حين يواصل العملاء السؤال «أين أجد هذا»، فالميزة نادراً ما تكون مفقودة. إنها موجودة.

لكن المستخدمين لا يستطيعون توقّع مكانها أو سبب أهميتها في تلك اللحظة.

وإذا كان المنتج يعتمد على عرض توضيحي من المبيعات لشرح تخطيطه، فالمشكلة في الترتيب لا في النطاق.

ولهذا أيضاً تطول دورات البيع: فالبائع يعوّض عن مشكلة وضوح ما كان ينبغي أن تصل إلى العرض أصلاً.

٢. المستخدمون الجدد يستكشفون بدل أن يُنجزوا شيئاً

منح المستخدمين الجدد كل شيء منذ أول تسجيل دخول ينبع عادة من حدس سليم: أرِهم القيمة الكاملة وبسرعة.

لكن عملياً يمضون جلستهم الأولى في تصفّح التقارير والإعدادات بدل إتمام سير العمل الواحد الذي يثبت لهم أن المنتج ينجح.

والتجارب التي تتعثّر قبل أول إجراء ذي معنى هي في الغالب مشكلة ترتيب لا مشكلة ميزات.

٣. الفريق يشرح المنتج أفضل مما يشرح المنتج نفسه

في التدقيقات، هذه من أوضح الفجوات التي نراها. فالفريق يعرف سبب وجود كل قسم لأنه من بناه، والمستخدمون يصلون بلا ذلك التاريخ.

وحين يحتاج المنتج إلى شخص يرافق المستخدمين الجدد ليشرح كيف تترابط أجزاؤه، فالتجربة لم تواكب ما صار إليه المنتج.

أين تبدأ منتجات SaaS بعرض الأشياء الخطأ

نرى الموقفين نفسيهما يتكرّران عبر التدقيقات.

ميزة تتفوّق في الترتيب على سير العمل الذي يُفترض أن تدعمه.

في أحد أنظمة إدارة العلاقات، كان نموذج تقييم العملاء المحتملين وإدارة المناطق وحاسبة العمولات تتصدّر لوحة المعلومات الرئيسية لكل الأدوار، بما فيها مندوب مبيعات يسجّل الدخول عدة مرات يومياً لمجرد تحريك الصفقات.

ولم تكن أي من تلك الأدوات سيئة البناء.

بل يمكن القول إن حاسبة العمولات كانت أكثر أجزاء المنتج تطوّراً. لكن المندوبة كان عليها أن تتجاوزها بصرياً كل صباح لتصل إلى مسار صفقاتها.

كان المنتج يُصعّب عليها الوصول إلى ما تحتاجه أكثر من غيره، خدمةً لميزات تلمسها مرة في الشهر.

التنقّل يحفظ التاريخ بدل الأولوية.

في لوحة معلومات لمنتج مالي، كان العنصر الأول في الشريط الجانبي أقدم ميزة في المنتج: أداة تسوية يدوية يستخدمها أقل من خمسة بالمئة من الحسابات.

وكانت فوق سير عمل المدفوعات الذي يلمسه كل عميل يومياً، لأنها أُطلقت أولاً ولم يراجع أحد الترتيب منذ ذلك الحين.

وأسفل الشاشة نفسها، حملت أداة تصدير محفظة تُستخدم أحياناً وزناً بصرياً مماثلاً لذلك السير اليومي.

ولم يكن أي من هذين قراراً اتخذه أحد عن قصد.

فهي تتراكم لأن كل ميزة تُطلق بالعناية نفسها ولا يعيد أحد النظر في السطح كاملاً بعد ذلك.

الإطار الذي نستخدمه لتحديد ما يراه المستخدمون أولاً

سؤال واحد يحسم معظم الأمر: هل يحتاج المستخدم الجديد هذا ليبلغ أول نتيجة ذات معنى؟

• إن كان الجواب نعم: فهو يستحق الظهور في اليوم الأول.
• إن كان الجواب لا: اسأل هل يصبح مفيداً فقط بعد إتمام سير العمل الأساسي. فإن كان كذلك، أظهره بعد تلك النقطة لا قبلها.
• وما تبقّى: الميزات التي تخصّ دوراً بعينه أو تُستخدم نادراً مكانها الإعدادات أو العروض الخاصة بالأدوار أو تنقّل ثانوي لا ينافس سير العمل اليومي.

معظم الميزات ترسب في السؤال الأول في اليوم الأول. وليست تلك مشكلة في الميزة.

بل هي معلومة عن الوقت الذي ينبغي أن تظهر فيه.

كيف يبدو هذا عملياً

أثناء تدقيق منصة لوجستية للأعمال، كانت لوحة المعلومات تعرض ١٤ عنصر تنقّل رئيسياً منذ أول تسجيل دخول: تتبّع الشحنات وإدارة الناقلين والتفاوض على الأسعار والتقارير المخصّصة والوصول البرمجي وأدوار الفريق والفوترة وغيرها.

وكان لكل عنصر الموضع نفسه لأن الفريق لم يتفق على ما يُحذف، فلم يحذفوا شيئاً.

طبّقنا المرشّح على الأربعة عشر جميعاً. والنتيجة:

بقيت الميزات الأربع عشرة كلها في المنتج. ووصل المستخدمون الجدد إلى أول شحنة مكتملة أسرع. وانخفض حجم طلبات الدعم المتعلقة بالتنقّل.

لم يُحذف شيء، بل تغيّر الترتيب.

ثلاثة أمور تفحصها قبل إعادة تصميم أي شيء

لا تتطلّب هذه مصمّماً، بل تتطلّب صدقاً حيال ما تُظهره تحليلاتك وتجربتك الشخصية.

١. قابِل أكثر ميزاتك استخداماً بمدى ظهورها الحالي

استخرج تحليلاتك وحدّد الميزات الخمس الأكثر استخداماً، ثم اعرف موضع كل منها في الواجهة الحالية.

فإن لم تكن أكثر ميزاتك استخداماً في أبرز المواضع، فالتنقّل منظّم حول التاريخ لا حول الاستخدام.

وهذا التفاوت هو أكثر ما نجده في التدقيقات، وأسهل ما يُصلَح دون المساس بالمنتج نفسه.

٢. جرّب منتجك من الصفر

سجّل الدخول كأنك لم تستخدمه قط، واحسب الوقت اللازم لإتمام المهمة الأهم لمستخدم جديد، بلا مساعدة ولا شرح للتنقّل.

فإن استغرق أكثر من دقيقة، فهذا تقريباً ما يعيشه المستخدمون الجدد في جلستهم الأولى.

الميزات موجودة على الأرجح كلها، لكن الطريق إليها ليس واضحاً بما يكفي.

٣. قارن بنية التنقّل بطريقة عمل المستخدمين فعلاً

حين يطابق تجميع الشريط الجانبي التنظيمَ الداخلي لفريق الهندسة بدل انسياب المهمة من منظور المستخدم، فتلك بنية موروثة لم يخترها أحد عن قصد غالباً.

والسؤال الذي ينبغي طرحه: لو كنت تبني التنقّل اليوم لمستخدم لم يرَ المنتج من قبل، هل كنت ستبنيه هكذا؟

ما الذي يتغيّر حين تتخذ قرار الترتيب

معظم الفرق التي نعمل معها على هذا لم تُجب رسمياً قط عن سؤال أي الميزات تنتمي للجلسة الأولى مقابل الثانية مقابل ما بعدها.

لم يُتّخذ القرار صراحةً قط، فاتُّخذ ضمناً عبر ترتيب البناء: فما أُطلق أولاً نال أبرز موضع، وبقي فيه.

واتخاذ القرار صراحةً يغيّر:

• ما يظهر في لوحة المعلومات الافتراضية
• ما يظهر في التنقّل الرئيسي
• ما يظهر فقط بعد إجراء محدّد من المستخدم
• ما يظهر فقط في عرض خاص بدور معيّن

ولا يتطلّب أي من هذا حذف ميزة واحدة من المنتج.

كما يغيّر المحادثات التي تدور حول المنتج.

فالمستخدمون الذين يبلغون أول نتيجة ذات معنى في الجلسة الأولى يعودون.

ومن يمضون جلستهم الأولى في التنقّل ليفهموا ما يحتويه المنتج كثيراً ما لا يعودون.

ويظهر هذا الفرق في تحويل التجارب، وفي زمن الانضمام، وفي حجم ما يضطر فريق المبيعات لشرحه قبل إغلاق الصفقة.

المنتج لا يحتاج أن يصير أبسط، بل أن يتوقّف عن عرض تعقيده الكامل قبل أن يكون لدى المستخدمين سبب للتعامل معه.

ذلك قرار ترتيب. وهو أهدأ من إعادة التصميم وأسرع تنفيذاً عادةً.

ويكاد يكون دائماً الخطوة الأولى الصحيحة قبل تغيير أي شيء آخر.