كيف تقرّر أيّ ملاحظات المستخدمين تبنيها (وأيّها تتركها)

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

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

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

لماذا يتوقّف “ابنِها فحسب” عن النجاح

في أول عشر ميزات لك، يكون “ابنِ كل ما يطلبه أحدهم” استراتيجية جيّدة. ليس لديك مستخدمون بما يكفي ليتعارضوا في الآراء، وكل ميزة تجعل التطبيق أنفع من الشيء الفارغ الذي كان عليه الأسبوع الماضي.

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

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

ثلاثة أسئلة تفرز كل شيء تقريباً

حين يأتي طلب، مرّره عبر ثلاثة أسئلة بالترتيب. معظم الأشياء تفرز نفسها بعد أول سؤالين.

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

2. كم عدد من سيستخدمها فعلاً؟ ليس “من طلبها” — بل من سيستخدمها. شخص واحد يطلب بصوت عالٍ ليس كعشرة أشخاص يستفيدون بهدوء. كن صادقاً هنا، لأن الطلبات العالية تبدو طلبات كبيرة، وعادةً ما لا تكون كذلك. مؤشّر جيّد: اسأل الشخص ماذا يفعل اليوم بدلاً من ذلك. إن كان لديه حلّ بديل مرتبك يستخدمه يومياً، فتلك حاجة حقيقية. أما إن كان “ربما سيستخدمها أحياناً”، فهي ميزة مرغوبة لكن غير ضرورية ترتدي قناعاً.

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

الكومات الثلاث

مرّر تلك الأسئلة فيقع كل شيء تقريباً في واحد من ثلاثة أماكن.

ابنِها. تساعد فئتك الأساسية، وسيستخدمها عدّة منهم، وتكلفة حملها معقولة. هذه سهلة. افعلها، وأخبر من طلبها — فمن يرون فكرتهم تُطلَق يصبحون أكثر مستخدميك ولاءً وأفضل مصدر للفكرة الجيّدة التالية.

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

اتركها. لا تناسب ما صُنع تطبيقك من أجله، أو لن تخدم سوى شخص واحد على الإطلاق، أو ستجعل التطبيق أسوأ للجميع الآخرين. هذه تحتاج إلى رفض مهذّب وصادق. عبارة “إنها فكرة مدروسة، لكنها ليست شيئاً أنوي إضافته — إليك ما أقترحه بدلاً منها” تحافظ على العلاقة وتحمي التطبيق. قول “لا” ميزة. كل “لا” هو “نعم” لإبقاء التطبيق بسيطاً بما يكفي ليفهمه الناس.

مثال صغير

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

تجاوزت التذكيرات الأسئلة الثلاثة كلّها — مستخدمون أساسيون، وكثير منهم يتعامل مع حالات عدم الحضور، والإرسال النصّي ثقيل لكنه يستحقّ. بُنيت. وكان عرض الأب فكرة جيّدة من شخص واحد، فأجّلته؛ ثم طلبها أَبوان آخران خلال ثلاثة أسابيع فرقّت نفسها. أما الترجمة اللاتينية فحصلت على “لا” دافئة. لم يحتج أيٌّ من تلك القرارات إلى جدول بيانات. احتاجت إلى ثلاثة أسئلة، وإلى الاستعداد للإجابة عن الثالث بصدق.

الجزء الذي لا يخبرك به أحد

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

في المرّة القادمة التي تتراكم فيها الطلبات، لا تفتح منصّة بناء التطبيقات بالذكاء الاصطناعي أولاً. افتح قائمتك، ومرّر كل عنصر عبر الأسئلة الثلاثة، وافرزه في كومة. البناء هو الجزء السهل الآن. أما تقرير ما يستحقّ البناء فهو العمل الفعلي — وهو عمل تستطيع القيام به دون كتابة سطر واحد من الشيفرة.