أُطلق الـ MVP. الأسبوع الثاني هو الجزء الأصعب

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

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

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

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

في Mechabits نصمم التسليم حول ما يصمد بعد الإطلاق: نطاق ثابت أو قائم على الدورات، وملكية مسماة، وتقدم أسبوعي مرئي، وتسليم يستطيع العملاء تشغيله. الإطلاق ليس خط النهاية. بل بداية العمل الحقيقي.

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