عبدالله عبدالرحيم الكندي: ما بعد MVP، متى تضيف ميزة ومتى تقول لا؟

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

قبل أي ميزة جديدة: ثلاث أولويات تسبقها

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

وعشان تعرف وين الاحتكاك، ما تحتاج أدوات معقدة. راقب الخطوة اللي يطلع منها أكثر الناس في الرحلة الأساسية، واقرأ رسائل الدعم الأولى بعناية، وجرّب تطلب من شخصين أو ثلاثة يستخدمون التطبيق قدامك بدون ما تشرح لهم شي. اللحظة اللي يسألونك فيها «وين أضغط؟» هي بالضبط المكان اللي يحتاج شغل قبل أي ميزة.

المصفاة: أربع أسئلة لكل طلب

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

وفيه سؤال خامس يوفّر كثير: هل تنحل بدون كود؟ أحياناً المستخدم يطلب ميزة، والحل شرح أوضح في الواجهة، أو إعداد موجود ما لقاه، أو خدمة يدوية مؤقتة لين تتأكد إن الطلب يتكرر.

اسمع المشكلة، مو الحل اللي يقترحه المستخدم

المستخدمين ممتازين في وصف اللي يزعجهم، وأقل دقة في اقتراح الحل. اللي يقول «أبي تصدير Excel» ممكن مشكلته الحقيقية إن المحاسب يطلب منه تقرير شهري، والحل الأنسب تقرير جاهز يطلع بضغطة، مو ملف خام يرتبه بيده. واللي يطلب «محادثة داخل التطبيق» ممكن مشكلته إنه ما يعرف حالة طلبه، والحل إشعار واضح عند كل تغيّر. لما يوصلك طلب، اسأل: «وش كنت تحاول تسوي لما احتجت هالشي؟». الجواب غالباً يقودك لحل أبسط وأنفع من اللي انطلب.

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

التكلفة اللي ما تنكتب في تقدير الميزة

تقدير «يومين برمجة» يغطي جزء من الحقيقة. كل ميزة تضيفها تجيب معها حالات طرفية تنختبر، وصلاحيات لازم تنضبط، وأسئلة دعم جديدة، وشاشة إضافية تزاحم الموجود. وفي تطبيقات الجوال، كل تحديث يمر على مراجعة المتجر من جديد، والميزة اللي تمس الحسابات أو المحتوى أو الدفع ممكن تجيب ملاحظات ما كانت في الحسبة. اسأل نفسك: لو هالميزة ما استخدمها إلا قليل، هل أنا مستعد أصونها سنة؟ لأن حذف ميزة بعد ما تعوّد عليها أحد أصعب بكثير من إنك ما تضيفها.

الطلبات اللي عدّت المصفاة: بأي ترتيب؟

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

كيف تقول لا، ومتى تقول نعم بسرعة

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

وبالمقابل، فيه حالات تقول فيها نعم بدون تردد:

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

قائمة «بعدين» اللي تنكتب وقت تخطيط النسخة الأولى ما المفروض تنرمى بعد الإطلاق. ترجع لها وتقرأها من جديد، بس هالمرة بعيون المستخدمين الحقيقيين بدل التخمين. وهذا جزء من طريقة الشغل في منصة أزهل الرقمية. وطريقة عبدالله عبدالرحيم بن سنكر الكندي فيها بسيطة: كل «لا» تقولها اليوم تحمي «نعم» أهم بكرة، والمنتج اللي يقول نعم لكل أحد ينتهي ما يخدم أحد بشكل جيد.