تنشر CB Insights تقريراً سنوياً يحلّل أسباب فشل الشركات الناشئة. منذ سنوات، كان السبب الأول نفسه دائماً: "لا حاجة في السوق". ليس تنفيذاً سيئاً. ليس نفاد الأموال. ليس فريقاً ضعيفاً. ببساطة، المنتج لم يحلّ مشكلة يهتم بها الناس بما يكفي لتغيير سلوكهم.
هذه الإحصائية مذهلة حين تفكّر في حجم الجهد الذي يُبذل في بناء المنتجات. تقضي الفرق أشهراً — وأحياناً سنوات — في تصميم الأنظمة، وكتابة الكود، والجدل حول الهندسة المعمارية، وصقل تدفقات العمل. والسبب الأكثر شيوعاً لفشلها أن أحداً لم يسأل ما إذا كان كل ذلك يحلّ مشكلة حقيقية.
بناء المنتجات التي يريدها الناس فعلاً ليس موهبة. إنه انضباط. له منهج، وهذا المنهج يمكن تعلّمه.
أكثر أخطاء المنتجات شيوعاً هو الوقوع في حب الحلّ قبل أن تفهم المشكلة بعمق. هذا شبه عالمي بين المؤسسين لأول مرة ومفاجئ في شيوعه بين ذوي الخبرة. النمط دائماً نفسه: لدى شخص ما فكرة، يجدها مقنعة، ويبدأ في البناء. العميل فكرة لاحقة — شخص يجب إقناعه، لا فهمه.
الترياق ليس معقداً لكنه يتطلب انضباطاً: اقضِ وقتاً أطول في المشكلة مما تظن أنه مبرر، قبل أن تفكر في الحلول أصلاً. تحدث مع أناس يعانون من المشكلة. راقبهم وهم يعملون. افهم الحلول البديلة التي يستخدمونها اليوم ولماذا هي غير مثالية. عندها فقط يكون لديك السياق الكافي لتصميم شيء يناسب فعلاً.
تطوير المنتج الجيد ليس خطاً مستقيماً — إنه حلقة. كل دورة حول الحلقة هي فرصة لاستبدال الافتراضات بالأدلة. الفرق التي تبني منتجات يريدها الناس هي تلك التي تكمل هذه الحلقة بسرعة وكثيراً.
الحلقة ليست شكليات. لكل مرحلة مخرج محدد يصبح مدخلاً للمرحلة التالية. تخطّي المراحل — وأكثرها شيوعاً القفز مباشرة من المشكلة إلى البناء — هو ما ينتج منتجات تفوتها الهدف.
ليست كل المشاكل تستحق الحل. المشكلة الجيدة للمنتج لها ثلاث صفات: متكررة (تؤثر على الناس كثيراً، ليس نادراً)، ومكثّفة (يشعر الناس بها بما يكفي لطلب الراحة منها)، والحلول الموجودة غير كافية فعلاً (ليس مجرد مختلفة قليلاً عما ستبنيه).
الخطأ هو تحسين الصفة الأولى وتجاهل الاثنتين الأخريين. "يضيع الناس وقتاً في الاجتماعات" أمر متكرر. لكن إذا كان الألم منخفضاً — إذا وجد الناس حلولاً بديلة مقبولة — فقد لا تكون المشكلة تستحق الحل تجارياً. وإذا كانت هناك بالفعل اثنا عشر أداة تفعل ما تريد فعله، فأنت تحتاج إلى سبب محدد جداً لاختيار أداتك.
للبحث سمعة سيئة في أوساط المنتجات — إنه مرتبط بشركات استشارية بطيئة، وتقارير ضخمة، ونتائج لا يقرأها أحد. هذا فشل في التنفيذ، ليس في الممارسة. البحث الجيد في المنتجات سريع ومحدد ويغيّر ما تبنيه.
هدف البحث ليس التأكد من أن المشكلة حقيقية. يجب أن تؤمن بذلك قبل الاستثمار بكثافة في البحث. الهدف هو فهم المشكلة بعمق كافٍ لمعرفة شكل الحل الجيد: من يعاني منها تحديداً، في أي سياق، ما الذي جربوه مسبقاً، ما الكلمات التي يستخدمونها لوصفها، وماذا يعني "الحل" لهم.
الفرضية تنبؤ محدد وقابل للدحض حول ما تعتقد أنه صحيح. إنها تفرض الوضوح. إذا لم تستطع كتابة فرضية واضحة، فأنت لم تفهم المشكلة بعد بما يكفي لبناء حل.
للفرضية المفيدة للمنتج ثلاثة أجزاء:
الإشارة هي الجزء الأهم — والأكثر إغفالاً. بدون إشارة محددة مسبقاً، كل تجربة "نجحت نوعاً ما". تجد الفرق طرقاً لتفسير البيانات الغامضة بشكل إيجابي. الفرضية بدون شرط دحض هي مجرد أمنية.
مرحلة البناء هي المكان الذي تقضي فيه معظم الفرق وقتاً أطول مما ينبغي. الهدف ليس بناء المنتج — بل بناء الحد الأدنى الذي يعطيك إشارة حول فرضيتك. هذان هدفان مختلفان ويُنتجان مخرجات مختلفة جداً.
بالنسبة لمعظم الفرضيات في المراحل الأولى، الحد الأدنى أصغر بكثير مما تظن الفرق. هل يمكنك يدوياً فعل ما ستفعله البرمجيات، لعشرة أشخاص، لاختبار ما إذا كانوا يُقدّرون النتيجة؟ هل يمكنك ربط أدوات موجودة واختبار سير العمل قبل بناء بنية تحتية جديدة؟ هل يمكنك رسم نموذج أولي وعرضه على خمسة مستخدمين قبل كتابة أي كود؟
الانضباط هنا هو السؤال، قبل بناء أي شيء: "ما الذي أحاول تعلّمه؟" و"ما الحد الأدنى الذي سيتيح لي تعلمه؟" الإجابة دائماً تقريباً أصغر مما يريد الفريق بناءه.
بعد الإطلاق — سواء كان نموذجاً أولياً أو تجريباً يدوياً أو ميزة منشورة — مرحلة القياس هي المكان الذي تُخدع فيه الفرق في الغالب. يسألون المستخدمين إن أعجبهم الأمر. يقول المستخدمون نعم. تُعلن الفرقة التجربة مُتحقَّقاً منها.
المشاعر ليست إشارة. الإشارة الوحيدة الموثوقة هي السلوك: هل فعل الناس الشيء؟ هل عادوا؟ هل دفعوا؟ هل أخبروا أحداً آخر؟
للقياس الكمي، اعمل أدوات القياس قبل الإطلاق. اعرف الإجراءات المحددة التي تتتبعها. ضع عتبة مسبقاً — "سنعتبر هذا مُتحقَّقاً منه إذا أكمل X% من المستخدمين Y في غضون Z يوماً." للقياس النوعي، أجرِ مقابلات متابعة منظّمة، ليس استطلاعات رضا مفتوحة.
مرحلة التعلم تتعلق بتحديث نموذجك الذهني للمستخدم والمشكلة، لا مجرد تحديد ما ستبني بعد ذلك. الفرق التي تتخطى هذه الخطوة تجمع البيانات لكنها لا تراكم الفهم. تنفّذ بسرعة لكنها لا تُحسّن حكمها بمرور الوقت.
جلسة التعلم الجيدة تسأل: ما الذي توقعناه؟ ما الذي حدث فعلاً؟ ماذا تخبرنا الفجوة عن افتراضاتنا؟ ما أهم شيء لا نعرفه الآن؟
مخرج مرحلة التعلم هو تعريف مشكلة أحدّ، أو فرضية مُراجعة، أو — إذا فشلت التجربة بوضوح — قرار بالسير في اتجاه مختلف تماماً. كل هذه النتائج ذات قيمة. أسوأ نتيجة هي الغموض: "تعلّمنا أشياء لكننا لسنا متأكدين مما يجب فعله بعد ذلك." هذا دليل على أن التجربة لم تكن محددة بما يكفي.
تطوير المنتجات لا يصل أبداً إلى مرحلة تتوقف فيها عن تشغيل هذه الحلقة. الأسئلة تتغير — في البداية تتحقق مما إذا كانت المشكلة حقيقية؛ لاحقاً تتحقق مما إذا كان عنصر حل محدد يعمل — لكن البنية دائماً نفسها. راقب، افترض، اختبر، تعلّم.
الفرق التي تبني المنتجات التي يريدها الناس ليست تلك التي تمتلك أذكى رؤية أولية. إنها تلك التي تكمل الحلقة بأسرع ما يمكن وبأكبر قدر من الصدق. سرعة التعلم، لا سرعة الشحن، هي الميزة التنافسية.