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