The Lean Startup – الجزء الثاني: كيف تعرف أن منتجك يسير في الاتجاه الصحيح؟

في الجزء الأول من هذه السلسلة، تحدثنا عن الفكرة الأساسية في كتاب The Lean Startup للمؤلف Eric Ries: لا تبنِ المنتج بناءً على افتراضاتك، بل اختبر هذه الافتراضات وتعلم من سلوك العملاء.

لكن هنا يظهر سؤال أصعب:

كيف تعرف أن ما تعلمته فعلًا صحيح؟

قد تطلق ميزة جديدة، وتحصل على آلاف الزيارات، وتزداد أعداد المستخدمين، وتشعر أن المنتج يسير في الاتجاه الصحيح.

لكن ماذا لو كانت كل هذه الأرقام لا تعني شيئًا؟

هنا ينتقل الكتاب من مجرد فكرة Build → Measure → Learn إلى طريقة أكثر دقة لقياس التعلم واتخاذ القرارات.

لا تقِس النجاح بالأرقام التي تبدو جميلة

هناك أرقام تجعل الفريق يشعر بالنجاح:

• عدد المستخدمين المسجلين.

• عدد الزيارات.

• عدد تحميلات التطبيق.

• عدد الحسابات الجديدة.

• عدد المشاهدات.

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

يسمي Eric Ries هذا النوع من الأرقام Vanity Metrics، أي المقاييس التي تبدو جيدة لكنها لا تساعدك بالضرورة على اتخاذ قرار.

تخيل أنك أطلقت منتج SaaS جديدًا ووصل عدد المستخدمين المسجلين إلى 10 آلاف مستخدم.

يبدو الرقم رائعًا.

لكن إذا كان 95% منهم لم يستخدموا المنتج بعد التسجيل، فماذا تعلمت فعلًا؟

ربما لا شيء.

المقياس الأفضل قد يكون:

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

هنا تبدأ الأرقام في الإجابة عن أسئلة حقيقية.

من Vanity Metrics إلى Actionable Metrics

المقياس الجيد ليس مجرد رقم.

المقياس الجيد هو رقم يساعدك على اتخاذ قرار.

لنفترض أنك أطلقت صفحة تسجيل جديدة.

يمكنك قياس:

عدد الزوار: 100,000

لكن هذا الرقم وحده لا يخبرك بالكثير.

يمكنك بدلًا من ذلك قياس:

عدد الزوار الذين بدأوا التسجيل: 8,000

ثم:

عدد من أكملوا التسجيل: 4,500

ثم:

عدد من استخدموا المنتج لأول مرة: 2,100

الآن أصبح بإمكانك اكتشاف مكان المشكلة.

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

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

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

التعلم المثبت أهم من مجرد التعلم

من أهم المفاهيم في Lean Startup:

Validated Learning

أي التعلم المثبت.

الفكرة هنا بسيطة:

ليس كل ما تتعلمه عن العملاء دليلًا حقيقيًا.

إذا قال لك عشرة أشخاص:

"فكرة رائعة، بالتأكيد سأستخدمها."

فأنت تعلمت شيئًا، لكنك لم تثبت أن هناك طلبًا حقيقيًا.

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

هناك فرق كبير بين:

"العملاء قالوا إنهم يريدون المنتج."

و:

"العملاء اتخذوا إجراءً يدل على أنهم يريدون المنتج."

والإجراء قد يكون:

• الدفع.

• التسجيل.

• استخدام ميزة أساسية.

• دعوة أعضاء آخرين.

• العودة إلى المنتج باستمرار.

• ترقية الاشتراك.

كلما اقترب القياس من سلوك حقيقي، أصبح التعلم أكثر قيمة.

التجربة الجيدة تبدأ بفرضية

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

بدلًا من قول:

"سنضيف هذه الميزة لأنها مهمة."

قل:

"نعتقد أن إضافة هذه الميزة ستزيد استخدام المنتج من قبل هذه الفئة من العملاء."

هنا أصبحت لديك Hypothesis، أي فرضية قابلة للاختبار.

مثلًا:

نعتقد أن إضافة قوالب جاهزة ستزيد نسبة المستخدمين الذين ينشئون أول مشروع لهم من 30% إلى 45%.

الآن تستطيع بناء تجربة صغيرة لاختبار هذا الاعتقاد.

إذا ارتفعت النسبة فعلًا، حصلت على دليل.

وإذا لم ترتفع، فقد تعلمت أن فرضيتك كانت خاطئة أو أن المشكلة في مكان آخر.

وهذا بالضبط هو الهدف.

لا تبنِ المنتج كاملًا لاختبار فكرة واحدة

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

تأتي فكرة جديدة، فيبدأ الفريق في:

• تصميم الواجهات.

• كتابة الـ API.

• بناء قاعدة البيانات.

• تطوير لوحة التحكم.

• كتابة الاختبارات.

• إعداد التوثيق.

• إطلاق الميزة.

وبعد أسابيع أو أشهر يكتشف أن العملاء لا يهتمون بها.

المشكلة هنا ليست أن الفريق لم يعمل جيدًا.

المشكلة أنه تعلم متأخرًا.

كان يمكن اختبار الفكرة بتجربة أبسط بكثير.

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

Landing Page → CTA → طلب تجربة أو اشتراك

قبل بناء المنتج بالكامل.

إذا لم يتفاعل أحد، فقد وفرت أسابيع من التطوير.

سرعة التعلم أهم من سرعة التطوير

هذه نقطة مهمة جدًا بالنسبة لفرق المنتجات والهندسة.

أحيانًا نقيس أداء الفريق بعدد الميزات التي يطلقها.

كم Feature أطلقنا هذا الشهر؟

كم Story انتهينا منها؟

كم سطر Code كتبنا؟

لكن هذه ليست بالضرورة المقاييس الصحيحة لشركة ناشئة.

السؤال الأفضل هو:

كم مرة اختبرنا فرضية حقيقية هذا الشهر؟

قد يكون فريق صغير أطلق ثلاث تجارب فقط، لكنه اكتشف أن السوق يريد اتجاهًا مختلفًا تمامًا.

بينما فريق آخر أطلق 20 ميزة دون أن يعرف لماذا.

الأول قد يكون أقرب إلى النجاح.

لأن هدف الشركة الناشئة ليس إنتاج أكبر كمية من البرمجيات.

بل تقليل عدم اليقين بأسرع طريقة ممكنة.

Cohort Analysis: لا تنظر إلى المستخدمين كرقم واحد

من الطرق المهمة لفهم سلوك المستخدمين استخدام Cohort Analysis.

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

مثلًا:

المجموعةالمستخدمونبعد 30 يومًايناير1,00018%فبراير1,20024%مارس1,50031%

هنا يظهر شيء مهم.

عدد المستخدمين يزداد، لكن الأهم أن نسبة الاحتفاظ بالمستخدمين Retention تتحسن أيضًا.

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

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

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

ومتى تعرف أن الوقت قد حان للـ Pivot؟

في الجزء الأول تحدثنا عن:

Pivot or Persevere

لكن الـ Pivot لا يعني أن ترمي كل شيء وتبدأ من الصفر.

الـ Pivot هو تغيير استراتيجي في اتجاه المنتج مع الاحتفاظ بما تعلمته حتى الآن.

قد تغير:

• الشريحة المستهدفة.

• المشكلة التي تحاول حلها.

• نموذج التسعير.

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

• طريقة تقديم المنتج.

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

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

هنا لا يعني الـ Pivot أنك فشلت.

بل يعني أنك استخدمت البيانات لاكتشاف فرصة أفضل.

أخطر شيء هو الاستمرار بدون دليل

أحيانًا لا يكون القرار الصعب هو تغيير الاتجاه.

بل الاعتراف بأن الاتجاه الحالي لا يعمل.

الفريق يكون قد قضى أشهرًا في بناء المنتج.

والمؤسس أصبح متعلقًا بالفكرة.

والشركة استثمرت أموالًا في المشروع.

فيصبح من السهل التفكير:

"نحتاج فقط إلى المزيد من الوقت."

لكن السؤال الصحيح ليس:

كم استثمرنا حتى الآن؟

بل:

ماذا تقول البيانات؟

إذا كانت كل تجربة جديدة تؤكد أن العملاء لا يريدون المنتج، فإضافة المزيد من الميزات لن تحل المشكلة بالضرورة.

أحيانًا أفضل قرار يمكنك اتخاذه هو التوقف، وإعادة التفكير.

ما الذي يجب أن تتعلمه من كل تجربة؟

قبل إطلاق أي تجربة، حاول أن تحدد أربعة أشياء:

1. الفرضية

ما الذي نعتقد أنه صحيح؟

2. التجربة

ما أقل شيء يمكننا فعله لاختبار هذا الاعتقاد؟

3. المقياس

ما السلوك الذي سيخبرنا إذا كانت الفرضية صحيحة؟

4. القرار

ماذا سنفعل إذا نجحت التجربة؟ وماذا سنفعل إذا فشلت؟

بهذه الطريقة لا تصبح التجارب مجرد نشاطات منفصلة.

بل تصبح جزءًا من عملية مستمرة لاتخاذ القرارات.

الخلاصة

الـ Lean Startup لا يقول لك:

ابنِ بسرعة فقط.

بل يقول شيئًا أعمق:

تعلم بسرعة.

سرعة التطوير وحدها لا تكفي.

يمكنك بناء منتج كامل خلال أشهر، ثم تكتشف أنك كنت تحل المشكلة الخطأ.

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

لهذا، عندما تعمل على منتج جديد، لا تسأل فقط:

ماذا سنبني بعد ذلك؟

حاول أن تسأل:

ما الفرضية التي نحتاج إلى اختبارها الآن؟

ثم:

ما أرخص وأسرع تجربة يمكن أن تعطينا إجابة حقيقية؟

لأن أفضل فرق المنتجات ليست التي تبني أكثر.

إنها الفرق التي تتعلم أسرع.