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