تحليل التخلي عن المنتج (Product Abandonment)

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

تتساءل مباشرةً: "لماذا لا يستخدم الناس المنتج؟"، لكنّ هذا ليس هو السؤال المناسب. السؤال المناسب والمفيد هو: "كيف يمكنني أن أجد كل أسباب استخدام الناس للمنتج وتحديد الأولوية فيها؟".

اللماذات الخمس والسبب الجذري

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

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

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

البحث يؤثر على قرارك في التحسين

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

إنّ اختبارات A/B تساعدك على إجراء التغييرات التي توصل منتجك إلى مرحلة الحد الأقصى المحلي Local Maxima، لكنّها لا تتيح لك الفهم الحقيقي. غيّر لون أي زر من الأخضر إلى الأحمر وسترى فرقًا دقيقًا في الإنتاجيّة، لكنّ هذا الفرق تعود جذوره إلى الجماليات، وليس إلى رغبة المستخدم، دافعه، أو فهمه للمنفعة من المنتج.

صنف المشاكل

افهم وحدّد السبب الجذري، لأنّ ذلك يحدد أولويات مشاكلك، ويتيح لك تحديد المشاريع حسب تجربة المستخدم، مثلًا،" يجب أن يكون المشترك الجديد قادرًا على توليد تقرير بنجاح بدون الاتصال بالدعم" (الأمر الذي يمكنك إجراء اختبارات المستخدم من أجله التحقق منه)، وحسب المقاييس، على سبيل المثال "يجب أن يتناقص عدد طلبات الدعم لكل تقرير يتم توليده" (الأمر الذي بإمكانك رصده).

من الأفضل أن تقوم بإلغاء الخاصيّة إذا كانت أغلب مشاكلك تتمحور حول دوافع المستخدم، ثم تتحرى عن سبب إضافتك لهذه الخاصيّة من البداية؛ على الأرجح سيكون السبب هو أنّك لا تقول “لا” إلا نادرًا وتُحاول إضافة جميع الاقتراحات التي تصلك . أمّا إذا كانت أغلب المشاكل تتعلّق بالواجهة، فيجب أن تفكّر في تصميم جديد (بدلًا من التّمحور حول تصميم عاطل).

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

ترجمة -وبتصرّف- للمقال Analyzing Abandonment in Your Product لصاحبه: Des Traynor.