فخّ تضخّم النطاق: كيف تقول لا للميزات التي تبدو جيدة لكنها ليست كذلك

أطلقتَ تطبيقاً. وظهر المستخدمون. والآن صار صندوق وارِدك مليئاً بطلبات ميزات تبدو كلّها أفكاراً جيدة.

“هل يمكننا إضافة التصدير إلى Excel؟” منطقي. “هل يمكن إرسال الفواتير تلقائياً؟” معقول. “هل يمكننا التكامل مع Stripe؟” هنا يعيش المال الحقيقي. “هل يمكنك إضافة تطبيق جوّال؟” الكلّ يطلب ذلك. “هل يمكننا تقديم هذا بعلامتنا التجارية الخاصة لعملائنا؟” آه، الآن صار هناك نموذج عمل.

كل طلب على حدة يبدو ذكياً. ومجتمعةً، تبدو وكأنك تبني خمسة منتجات مختلفة.

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

كيف يقتل تضخّم النطاق تطبيقاً يعمل

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

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

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

بنيتَ شيئاً يعمل. وأفسدتَه بمحاولة أن تكون كل شيء.

إطار اتّخاذ القرار

أنت بحاجة إلى بوّابة. كل طلب ميزة يمرّ عبر ثلاثة أسئلة:

السؤال الأول: هل ينتمي هذا إلى هذا التطبيق، أم أنه تطبيق مختلف؟

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

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

ستردك طلبات مثل “تكامل مع نظام إدارة علاقات العملاء (CRM) لدينا”. وما يعنيه ذلك فعلاً هو “كن نظام إدارة علاقات العملاء الخاص بنا”. هذا تطبيق مختلف. يمكنك التكامل مع نظام CRM لاحقاً. لكنك لا تستطيع إضافة ما يعادل ميزات نظام CRM دون أن تصبح نظام CRM بنفسك.

السؤال الثاني: هل يحلّ هذا مشكلة لمعظم مستخدميك، أم لهذا الشخص وحده؟

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

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

هذا هو السؤال الخطِر لأن العميل الوحيد الذي يسأل قد يكون أهمّ عملائك. قد تحتاج إلى إبقائه راضياً. هذا قرار يخصّ العمل، لا قرار يخصّ المنتج. لكن ادخل وأنت مفتوح العينين: إن بنيتَ شيئاً لعميل واحد، فأنت لا تُنمّي تطبيقك، بل تبني نشاطاً استشارياً.

السؤال الثالث: ماذا يكلّف هذا، وما تكلفته على الفكرة الأصلية؟

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

اسأل بوضوح: “إن بنيتُ هذا، فما الذي لن أبنيه؟” إن كان الجواب “لا شيء، لدينا وقت لا نهائي”، فأنت لا تصدُق نفسك. ليس لدينا. الوقت محدود.

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

مثال واقعي: نموذج استقبال العملاء

بنى أحدهم نموذج استقبال عملاء بسيطاً. يملؤه العملاء، ويراجعه المدرّب، ثم يحدّدون موعداً. هذا هو التطبيق.

الطلب الأول: “هل يمكنني وَسْم حالات الاستقبال العاجلة؟” نعم، هذه نسخة من سير العمل الأساسي. ابنِها.

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

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

الطلب الرابع: “هل يمكن للمدرّبين إرسال متابعات الاستقبال عبر الرسائل النصية القصيرة (SMS)؟” الآن صرتَ نظام تواصل. لا.

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

كيف تقول لا

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

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

غالباً ما يتفهّم العميل. لقد طلب لأن الفكرة خطرت له، لا لأنه يختبرك.

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

إغراء أن تكون كل شيء

أصعب جزء في بناء منتج صغير هو أن تقول لا. “لا” تبدو كأنك تترك مالاً على الطاولة. ماذا لو كان ذلك العميل سيدفع فعلاً مقابل الاثنين؟ ماذا لو كانت تلك الميزة ستجعلك أكبر عشر مرات؟

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

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

قل لا. احمِ الأساس. افعل ذلك، وستبني شيئاً يريد الناس استخدامه فعلاً.