The Lean Startup — Eric Ries
المجال: ريادة الأعمال · بناء المنتجات · الابتكار · اتخاذ القرار
مدة القراءة: نحو 6 دقائق

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

قد يكون التصميم رائعًا، والتقنية متقدمة، والمزايا كثيرة، والفريق عمل ليلًا ونهارًا. ثم يأتي يوم الإطلاق… ولا يستخدم الناس المنتج كما توقع الفريق.

كتاب The Lean Startup يحاول قلب هذه الطريقة في التفكير.

فالسؤال في بداية المشروع ليس:

كيف نبني المنتج كاملًا بأعلى جودة ممكنة؟

بل:

ما أهم افتراض لدينا، وما أسرع وأقل طريقة تكلفة لاختباره مع مستخدم حقيقي؟

---

💡 الفكرة الأساسية

الشركة الناشئة تعمل في بيئة مليئة بعدم اليقين.

أنت لا تعرف يقينًا:

هل المشكلة مهمة بما يكفي؟

هل العميل مستعد للدفع؟

ما الميزة التي يهتم بها؟

ما السعر المناسب؟

هل سيعود بعد أول استخدام؟

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

إنها تنتج معرفة موثوقة عن العميل والسوق.

ولهذا يقترح الكتاب دورة متكررة:

ابنِ → قِس → تعلّم.

ثم استخدم ما تعلمته في الدورة التالية.

---

1. الفكرة الجميلة ليست دليلًا

تخيل أنك تريد إنشاء تطبيق يساعد الناس على قراءة الكتب.

تسأل أصدقاءك:

«هل يعجبكم تطبيق يعطيكم أفضل أفكار الكتب في سبع دقائق؟»

يقولون:

فكرة ممتازة!

هل أثبتنا وجود سوق؟

لا.

الناس يجاملون، ويتخيلون سلوكًا مختلفًا عن سلوكهم الحقيقي.

السؤال الأقوى ليس:

هل يعجبك 7MIN؟

بل أن تضع المنتج أمامهم ثم تراقب:

هل سجلوا؟

هل أكملوا أول قراءة؟

هل عادوا غدًا؟

هل عادوا بعد أسبوع؟

هل اختاروا وقت الإشعار؟

هل دفع أحدهم عندما طلبت منه الاشتراك؟

السلوك أقوى من الرأي.

---

2. ابنِ MVP لاختبار فرضية، وليس نسخة رديئة من حلمك

مصطلح Minimum Viable Product يُساء فهمه كثيرًا.

البعض يعتقد أنه يعني:

«أطلق أي شيء ناقص بسرعة.»

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

لنفترض أن رؤيتك لـ7MIN مستقبلًا تشمل:

تطبيق iOS وAndroid، ذكاء اصطناعي، صوت، Streaks، مجتمع، توصيات شخصية، مسارات، اشتراكات، عشر لغات.

هل تحتاج كل ذلك لتعرف هل الفكرة الأساسية تعمل؟

لا.

يمكن أن يبدأ الاختبار بـ:

صفحة تسجيل → اختيار ثلاثة اهتمامات → قراءة يومية ممتازة → إشعار في الوقت المختار → قياس العودة لمدة 14 يومًا.

إذا لم يعد المستخدمون، فإضافة مجتمع وAI وعشر لغات قد لا تعالج المشكلة الأساسية.

---

3. لا تقِس الأرقام التي تجعلك تشعر بالنجاح فقط

تخيل أن لديك:

100,000 مستخدم مسجل.

رقم رائع في العرض التقديمي.

لكن ماذا لو كان المستخدمون النشطون يوميًا 700 فقط؟

الرقم الأول كبير.

لكن الثاني يخبرك بشيء أكثر أهمية عن المنتج.

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

في المقابل، نحتاج مقاييس قابلة للتصرف بناءً عليها.

مثل:

كم نسبة من سجلوا وأكملوا أول قراءة؟

كم عادوا في اليوم التالي؟

كم استمروا سبعة أيام؟

كم مستخدمًا تحول من مجاني إلى مدفوع؟

ما تكلفة الحصول على عميل؟

كم تبلغ قيمة العميل خلال حياته؟

المقياس الجيد لا يقول فقط:

نحن نكبر.

بل يساعدك في معرفة:

ماذا يجب أن نفعل بعد ذلك؟

---

4. اختبر أخطر افتراض أولًا

لنفترض أنك تريد بناء منصة حجوزات.

لديك عشرات الأسئلة:

ما اللون؟

هل نضيف Apple Pay؟

هل نحتاج تطبيقًا؟

هل نضيف AI؟

لكن هناك افتراضًا أخطر:

هل توجد منشآت مستعدة أصلًا لاستخدام النظام ودفع المال مقابله؟

إذا كانت الإجابة «لا»، فإن لون الزر لا يهم.

لهذا رتّب الافتراضات حسب خطورتها.

في أي مشروع جديد اسأل:

ما الشيء الذي إذا اكتشفنا أنه غير صحيح، ينهار المشروع كله؟

اختبره أولًا.

هذه الفكرة وحدها تستطيع توفير أشهر من العمل.

---

5. التجربة الفاشلة قد تكون نتيجة ناجحة

لنفترض أنك بنيت ميزة تتوقع أنها سترفع الاحتفاظ 20%.

أطلقتها لمجموعة من المستخدمين.

النتيجة:

لم يحدث أي تحسن.

هل فشل الفريق؟

من زاوية Lean Startup، ليس بالضرورة.

إذا كانت التجربة مصممة جيدًا، فقد تعلمت شيئًا مهمًا:

الفرضية كانت خاطئة.

وهذه المعرفة لها قيمة لأنها تمنعك من إنفاق ستة أشهر على تطوير الفكرة نفسها.

المشكلة الحقيقية ليست أن تجرب شيئًا ويفشل.

المشكلة أن تعمل ستة أشهر ثم لا تعرف:

هل ما بنيناه أحدث فرقًا أصلًا؟

---

6. متى نستمر ومتى نغيّر الاتجاه؟

بعد عدة دورات من البناء والقياس والتعلم يأتي قرار مهم:

Persist أم Pivot؟

هل نستمر في الاتجاه نفسه لأن البيانات تشير إلى أننا نقترب؟

أم نغير جزءًا أساسيًا من النموذج؟

الـPivot لا يعني إغلاق الشركة والبدء من الصفر.

قد تغير:

نوع العميل.

السعر.

قناة التوزيع.

المشكلة التي تركز عليها.

طريقة تحقيق الإيراد.

الميزة الأساسية.

لكن يجب ألا يكون القرار مجرد رد فعل عاطفي.

البيانات والتجارب يجب أن تساعد في تحديده.

---

7. سرعة التعلم أهم من سرعة البرمجة

تخيل شركتين.

الشركة A تطلق 30 ميزة خلال ستة أشهر.

الشركة B تطلق 8 تجارب فقط.

ظاهريًا A أسرع.

لكن ماذا لو أن A لا تقيس أثر أي ميزة؟

بينما B تعرف بعد كل تجربة:

ما الذي زاد التحويل؟

ما الذي زاد الاحتفاظ؟

ما الذي لم يهتم به المستخدم؟

أي شركة تتقدم أسرع فعلًا؟

B قد تكون أسرع لأنها تقلل الجهل.

وهذا مهم جدًا اليوم مع أدوات الذكاء الاصطناعي.

أصبح من الممكن بناء البرمجيات بسرعة هائلة.

وهذا قد يخلق مشكلة جديدة:

أصبح بإمكاننا بناء الشيء الخطأ أسرع من أي وقت مضى.

لذلك لا تجعل السؤال:

«هل يستطيع AI بناء هذه الميزة؟»

السؤال الأول:

«لماذا نبنيها؟ وما الذي سيجعلنا نعرف أنها نجحت؟»

---

🧩 مثال عملي — 7MIN

لنفترض أننا نريد إطلاق 7min.online.

الرؤية النهائية ضخمة.

لكن نحدد أخطر فرضية:

الناس يريدون محتوى معرفيًا يوميًا قصيرًا، وسيعودون لاستهلاكه باستمرار.

نبني تجربة أولى.

نأتي بـ 100 مستخدم حقيقي.

في اليوم الأول يحصلون على قراءة مدتها 5–7 دقائق.

نقيس:

Activation: كم شخصًا أكمل القراءة الأولى؟

ثم:

Day 2 Retention: كم عاد غدًا؟

ثم:

Day 7 Retention: كم بقي بعد أسبوع؟

ثم نسأل المستخدمين الذين توقفوا:

ما الذي جعلك لا تعود؟

قد نكتشف مثلًا أن المشكلة ليست المحتوى.

بل أن القراءة طويلة.

أو الإشعار يأتي في وقت سيئ.

أو المستخدم يريد الصوت أثناء القيادة.

هذه المعلومة قد تجعل النسخة الصوتية أهم من عشر ميزات كنا نخطط لها.

فنضيفها.

ثم نقيس من جديد.

هذه هي الحلقة:

نبني → نقيس → نتعلم → نحسن → نقيس من جديد.

بعد عدة دورات، المنتج لا يعود مبنيًا على ما نتخيله عن المستخدم.

بل على ما تعلمناه منه فعليًا.

---

✅ طبّقها اليوم

1. اكتب أخطر افتراض في مشروع تعمل عليه.
اكتب جملة واحدة: «لكي ينجح هذا المشروع، يجب أن يكون صحيحًا أن ______.» ثم اسأل كيف تستطيع اختبارها هذا الأسبوع بدل افتراض صحتها.

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

3. أوقف ميزة واحدة وابنِ تجربة بدلًا منها.
قبل بدء أي تطوير جديد اليوم، اكتب: الفرضية → التجربة → المقياس → النتيجة التي ستجعلنا نستمر أو نتراجع. إذا لم تستطع تحديدها، فقد لا تكون الميزة جاهزة للبناء.

🧠 خلاصة اليوم

الشركة الناشئة لا تفوز لأنها بنت أكثر.

تفوز عندما تتعلم أسرع من منافسيها.

لا تنتظر المنتج المثالي.

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

ولا تنخدع بالأرقام الكبيرة التي لا تغير قرارًا.

اختبر أهم افتراض.

راقب ما يفعله المستخدم فعلًا.

تعلم.

ثم ابنِ الخطوة التالية.

وفي عصر أصبح فيه بناء البرمجيات أسرع بكثير بفضل الذكاء الاصطناعي، تصبح هذه الفكرة أكثر أهمية:

الميزة التنافسية ليست فقط أن تستطيع البناء بسرعة، بل أن تعرف بسرعة ما الذي يستحق أن يُبنى.

❓ سؤال اليوم

ما المشروع الذي تعمل عليه الآن، وما أخطر افتراض فيه لم تختبره مع عميل حقيقي حتى هذه اللحظة؟