من الفكرة إلى الإطلاق خلال أسابيع:كيف تبني فرق المنتجات المعتمدة على الذكاء الاصطناعي بسرعة من دون التضحية بالجودة.

المنتج الذي لم يُطلق بعد هو مجموعة من الافتراضات.

قد تعتقد أن الناس يعانون من المشكلة. وقد تعتقد أنهم يهتمون بها بما يكفي للبحث عن حل. وقد تعتقد أنهم مستعدون للدفع. وقد تعتقد أن الواجهة واضحة. وقد تعتقد أن الميزة التي استغرق بناؤها ثلاثة أسابيع مهمة للمستخدم.

لكن حتى يتعامل مستخدم حقيقي مع المنتج، تبقى معظم هذه الأفكار مجرد افتراضات.

كل أسبوع إضافي قبل الإطلاق هو أسبوع يتخذ فيه الفريق قرارات من دون أقوى نوع من الأدلة المتاحة: السلوك الحقيقي.

لهذا للسرعة قيمة استراتيجية. الهدف ليس فقط إنهاء العمل في وقت أقل. الهدف هو الوصول إلى الواقع في وقت أسرع.

منتج يستخدمه عشرة أشخاص حقيقيين قد يعلم الفريق أكثر من شهر كامل من الاجتماعات الداخلية.

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

هذه المعلومات مفيدة حتى عندما تكون غير مريحة.

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

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

تريد:

• مجموعة الميزات الكاملة
• تجربة إعداد مثالية
• جميع أنواع الحسابات
• تحليلات متقدمة
• معالجة كل الحالات الاستثنائية
• أدوات إدارة متكاملة
• أتمتة كاملة
• تكاملات متعددة
• إعدادات مرنة للغاية
• وبنية تحتية لحجم استخدام افتراضي لم يصل بعد

كل طلب من هذه الطلبات قد يبدو منطقيًا وحده. لكن جمعها معًا يصنع منتجًا قد يستغرق أشهرًا قبل أن يصل إلى الأشخاص الذين بُني من أجلهم.

للإصدار الأول وظيفة أضيق. يجب أن يثبت وجود القيمة الأساسية.

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

هذه الأسئلة أهم بكثير من وجود ثمانية خيارات تخصيص داخل صفحة الإعدادات.

يجب تقييم الإصدار الأول بناءً على ما يعلمك إياه، لا على مدى شبهه بالرؤية النهائية.

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

وهذا قرار يخص المنتج والتصميم والهندسة في الوقت نفسه.

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

القائمة الثانية عادةً أكبر بكثير.

قد يبدو الأمر بديهيًا، لكنه صعب جدًا في الممارسة. المؤسس يرى الرؤية الكاملة. والمصمم يستطيع تخيل كل حالة ممكنة. والمهندس يعرف البنية التي قد تصبح مفيدة لاحقًا. وأصحاب المصلحة يرون فرصًا في كل اتجاه.

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

هناك اختبار بسيط يمكن استخدامه:

إذا حذفنا هذه الميزة من الإصدار الأول، هل سيؤثر ذلك فعلًا في قدرة المستخدم المستهدف على تجربة القيمة الأساسية واتخاذ قرار بالعودة؟

إذا كانت الإجابة لا، فمن المحتمل أن الميزة لا تنتمي إلى النسخة الأولى.

مسار واحد متكامل أفضل من خمسة مسارات ناقصة. منتج صغير يحل مشكلة واحدة بوضوح أكثر فائدة من منتج ضخم يجبر المستخدم على المرور بين أفكار نصف مكتملة.

تحديد النطاق الجيد لا يعني القيام بعمل أقل. بل يعني التأكد من أن العمل الحالي يجيب عن أهم سؤال أولًا.

تتحدث الفرق غالبًا عن سرعة التطوير من خلال عدد ساعات البرمجة. لكن أكبر تكلفة في تطوير المنتجات تكون في كثير من الأحيان العمل الموجه في الاتجاه الخطأ.

يمكن لفريق أن يتحرك بكفاءة شديدة نحو وجهة خاطئة. وهذا لا يزال هدرًا.

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

لهذا لا ينبغي قياس سرعة المنتج فقط بسرعة انتقال المهام من "قيد التنفيذ" إلى "مكتمل". السؤال الأهم هو: كم بسرعة يستطيع الفريق اكتشاف ما يستحق أن يُبنى؟

وهذا هو الغرض الأعمق من النماذج الأولية واختبارات المستخدمين والتحليلات والإطلاق المبكر. إنها تقلل تكلفة الخطأ.

وكل منتج جديد سيكون مخطئًا في شيء ما. الهدف ليس القضاء على عدم اليقين. بل جعل عدم اليقين أقل تكلفة.

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

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

كل سؤال يحتاج إلى نوع مختلف من النماذج الأولية. بعضها يحتاج إلى شاشات قابلة للنقر. وبعضها يحتاج إلى تجربة تقنية حقيقية. وبعضها يمكن اختباره بخدمة تُدار يدويًا خلف واجهة تبدو مكتملة. وبعضها لا يحتاج إلى أي برمجة.

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

هذا يعكس وظيفة النموذج الأولي.

يجب أن يكون النموذج الأولي رخيصًا بما يكفي لرميه إن لزم الأمر. وهذه الحرية هي ما يجعله مفيدًا.

نحن نحافظ على النماذج الأولية في المراحل الأولى مركزة ومؤقتة عمدًا. ثم نضعها أمام مستخدمين حقيقيين بينما لا يزال تغيير الاتجاه سهلًا وغير مكلف.

ما يجب أن ينجو من مرحلة النموذج الأولي ليس بالضرورة الشاشات أو الشيفرة. بل القرارات.

يختفي قدر كبير من وقت تطوير المنتج بين التخصصات.

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

لا يعني هذا أن أحدًا يعمل بشكل سيئ. المشكلة ببساطة أن النموذج نفسه مكلف.

يتعامل نموذج التسليم التقليدي مع تطوير المنتجات كسباق تتابع: ينهي كل تخصص مرحلته ثم يسلم العمل إلى التخصص التالي.

الفرق السريعة تعمل بطريقة مختلفة. التصميم والمنتج والهندسة يعملون كنظام قرار واحد.

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

وهذا يقلل إعادة العمل لأن عددًا أقل من القرارات يُتخذ في عزلة.

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

وهذه هي الفكرة الأساسية. السرعة تأتي من تغيير النظام، لا من مطالبة الأفراد بالعمل أسرع.

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

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

يمكن للذكاء الاصطناعي المساعدة في:

• البحث الأولي حول المنتج
• صياغة المتطلبات
• تحسين قصص المستخدم
• التخطيط التقني
• استكشاف البنية
• استكشاف اتجاهات الواجهة
• إنشاء المحتوى
• إنشاء الهياكل الأولية للشيفرة
• تنفيذ الأعمال المتكررة
• اكتشاف الأخطاء
• توليد الاختبارات
• كتابة التوثيق
• مراجعة الشيفرة
• تحليل البيانات
• إعداد ملاحظات الإصدارات
• فحوصات الجودة
• تحليل ملاحظات المستخدمين بعد الإطلاق

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

وهذا مهم لأن جزءًا كبيرًا من تطوير المنتجات ليس القرار النهائي نفسه. بل العمل المحيط بالقرار.

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

وتوضح أبحاث McKinsey الحديثة الفرق بين مجرد استخدام أدوات الذكاء الاصطناعي وإعادة تصميم عملية التطوير حولها. ففي استطلاع أُجري عام 2026 على قادة المنتجات والهندسة، كانت المؤسسات التي أعادت تصميم عملياتها قبل دمج AI أكثر احتمالًا بأكثر من الضعف لتحقيق تحسينات في الإنتاجية تتجاوز 20% مقارنة بالمؤسسات التي أضافت AI فوق طرق العمل الحالية فقط.

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

هناك تفسير خطير لفكرة التطوير المعتمد على الذكاء الاصطناعي، وهو أن المراجعة البشرية لم تعد ضرورية.

الواقع أقرب إلى العكس. كلما أصبح الإنتاج أسرع، أصبحت عملية التحقق أهم.

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

دور الإنسان لا يختفي. بل ينتقل إلى مستوى أعلى.

وقت أقل في إنتاج المسودات المتكررة. ووقت أكبر في التوجيه، والمراجعة، واتخاذ القرار، والاختبار، وفهم النتائج.

وهذا استخدام أفضل للخبرة البشرية. لكن فقط إذا صُمم سير العمل لذلك.

هناك نسخة من فكرة "تحرك بسرعة" لا تفعل أكثر من نقل الدين التقني إلى المستقبل. وهذا ليس النموذج الذي نؤمن به.

الإطلاق السريع المبني على أساس هش هو وقت مستعار.

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

لهذا تهم الأجزاء غير المثيرة من تطوير المنتجات منذ اليوم الأول.

المنتج المبكر الجاد يحتاج إلى:

• التحكم بالإصدارات
• نشر قابل للتكرار
• اختبارات آلية أساسية
• تتبع الأخطاء
• تحليلات المنتج
• التسجيل والمراقبة
• صلاحيات وصول منطقية
• نسخ احتياطية عند الحاجة
• هيكل واضح للبيئات
• وبنية تقنية بسيطة بما يكفي لتتغير

لا تحتاج البنية إلى دعم 50 مليون مستخدم منذ اليوم الأول. لكنها تحتاج إلى دعم التغيير. وهذا فرق مهم.

الهندسة في المرحلة المبكرة يجب أن تُحسن قابلية التكيف، لا التعقيد النظري.

نفضّل إطلاق خمس ميزات ممتازة فوق بنية قابلة للتطور على إطلاق خمس عشرة ميزة فوق نظام لا يفهمه أحد.

MVP الجيد صغير في نطاقه. ولا يجب أن يكون صغيرًا في جودته.

من أسهل الطرق لإبطاء منتج جديد بناء بنية تحتية لمستقبل قد لا يأتي.

تبني الفرق معماريات خدمات معقدة. وأنظمة صلاحيات ضخمة. وأدوات داخلية متقدمة. وطبقات متعددة من التجريد. وبنية تشغيلية ثقيلة. كل هذا قبل وصول أول مئة مستخدم.

هناك مشكلات توسع يجب توقعها. لكن معظمها لا يحتاج إلى حل منذ اليوم الأول.

هناك فرق بين تجنب الأخطاء التقنية الواضحة وبين هندسة النظام من أجل حركة استخدام متخيلة.

تحتاج المنتجات المبكرة إلى بنية مفهومة، وقابلة للمراقبة، وآمنة بما يتناسب مع سياقها، وسهلة التعديل.

سيتغير المنتج. وسيتغير نموذج البيانات. وستتغير الواجهة. وستتغير الافتراضات. يجب أن تتوقع البنية ذلك.

التعقيد المبكر خطير لأنه يجعل التعلم المستقبلي مكلفًا.

التفكير التقليدي في المشاريع غالبًا ما يتعامل مع الإطلاق كخط النهاية. كل شيء يتجه نحو يوم الإطلاق. وبعده يُعتبر المشروع مكتملًا.

تطوير المنتجات لا يعمل بهذه الطريقة. الإطلاق هو اللحظة التي تبدأ فيها أكثر المعلومات موثوقية بالوصول.

قبل الإطلاق، يوجد المستخدمون أساسًا في شخصيات افتراضية، ومقابلات، وافتراضات، واختبارات محدودة. بعد الإطلاق، يبدأون في إنتاج سلوك حقيقي.

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

هذا السلوك يجب أن يؤثر مباشرة في خارطة الطريق.

لهذا لا يمكن أن تكون التحليلات فكرة تأتي لاحقًا. يجب أن تعرف ما الذي حدث. لكن الأرقام وحدها لا تكفي.

يمكن للوحة التحليلات أن تخبرك أن 40% من المستخدمين غادروا مسارًا معينًا. لكنها لا تستطيع دائمًا أن تخبرك لماذا. هذا يحتاج إلى محادثات، ومراجعة الجلسات، ورسائل الدعم، ومقابلات المستخدمين، والملاحظة.

أفضل حلقة ملاحظات بعد الإطلاق تجمع بين السلوك الكمي والتفسير النوعي.

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

لكن الهدف من الإطلاق المبكر كان التعلم. إذا لم تستطع خارطة الطريق التغير بعد ظهور الدليل، فقد جمع الفريق البيانات من دون أن يحولها إلى ذكاء.

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

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

لا يمثل أي من هذا فشلًا. بل هو تطوير المنتج يعمل كما يجب.

الهدف ليس توقع شكل المنتج بشكل مثالي قبل الإطلاق. الهدف هو بناء نظام يستطيع تعلم الشكل الذي يجب أن يصبح عليه المنتج.

أهم ميزة لدورة بناء قصيرة ليست قدرة الشركة على القول إنها أطلقت بسرعة. بل أن حلقات التعلم تصبح أقصر.

بدل:

خطط ثلاثة أشهر ← ابنِ ستة أشهر ← أطلق ← اكتشف ما كان خطأ

تصبح الدورة:

افترض ← صمم نموذجًا أوليًا ← ابنِ ← أطلق ← قِس ← تعلّم ← عدّل

ثم كرر.

كل دورة تجعل المنتج أقل نظرية. ويستبدل الفريق افتراضاته تدريجيًا بالأدلة. وهكذا تصبح المنتجات أكثر دقة.

ولهذا القدرة على إطلاق التغييرات باستمرار مهمة جدًا.

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

رشاقة المنتج ليست القدرة على تغيير رأيك. بل القدرة على تغيير المنتج بعد أن يتغير رأيك.

لا توجد منهجية أو أداة AI أو إطار عمل أو تقنية هندسية تلغي القيد الأساسي في تطوير المنتجات. الوقت محدود. وكل "نعم" تستهلك جزءًا منه.

لهذا يعتمد تطوير المنتجات بسرعة على القدرة المنضبطة على الرفض.

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

هذا ليس نقصًا في الطموح. إنه ترتيب صحيح للمراحل.

لا يزال بإمكانك بناء الرؤية الكبرى. لكنك لا تتظاهر بأن الرؤية كاملة يجب أن توجد قبل أن يحصل أول عميل على القيمة.

في MoonWhale، لا تعتمد طريقتنا في تطوير المنتجات بسرعة على دفع الفرق للعمل تحت ضغط أكبر. بل على تقليل الهدر بين القرارات.

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

بعد ذلك يتحرك التصميم والهندسة معًا.

نستخدم الذكاء الاصطناعي عندما يستطيع اختصار الأعمال المتكررة، وتسريع الاستكشاف، ودعم التنفيذ، وتقوية الاختبارات، وتقليل عبء التوثيق. لكن الحكم يبقى بشريًا.

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

النتيجة ليست "تطويرًا سريعًا" كشعار تسويقي. إنها منظومة تطوير مصممة للتعلم.

المسافة بين الفكرة والنموذج الأولي. المسافة بين التصميم والهندسة. المسافة بين الشيفرة والإنتاج. المسافة بين سلوك المستخدم والقرار التالي في المنتج.

كلما أصبحت هذه المسافات أقصر، أصبح المنتج قادرًا على التحسن بشكل أسرع.

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

الهدف هو البناء بانضباط كافٍ حتى تصبح السرعة نتيجة طبيعية للوضوح.

منتج أُطلق خلال أربعة أسابيع واستمر في التحسن خلال الأشهر الستة التالية قد يصبح أقوى بكثير من منتج بقي مخفيًا ستة أشهر بحثًا عن إصدار أول مثالي.

لأن الفريق الأول أمضى تلك الأشهر يتعلم من الواقع. أما الفريق الثاني فأمضاها يحاول توقعه.

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