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

ثمة نسخة من النقاش حول المنتج الأولي القابل للتطبيق (MVP) تتكرر في كل شركة ناشئة في مراحلها المبكرة تقريباً، وعادة ما تجري على النحو التالي. لدى المؤسس فكرة كبيرة، فيجلس مع مطوّر أو شركة تطوير، وفي غضون الساعة الأولى يكون قد بدأ بسرد الميزات: لوحة تحكم، ومحرك توصيات، وإشعارات فورية، ومشاركة على الشبكات الاجتماعية، ولوحة إدارة، ونظام إحالة، وربما طبقة ذكاء اصطناعي لأن الجميع يضيف واحدة في الوقت الراهن. وبحلول نهاية الاجتماع، تكون فكرة المنتج المركزة قد تحولت إلى خارطة طريق لشيء يحتاج بناؤه إلى ثمانية أشهر وفريق هندسي كامل. وفي مكان ما من ذلك الاجتماع، استُخدمت كلمة «MVP» لوصف كل ذلك، وهنا تحديداً بدأت الأمور تسير في الاتجاه الخطأ. والمنتج الأولي القابل للتطبيق واحد من أكثر المفاهيم استخداماً وأكثرها سوء فهم في عالم الشركات الناشئة. فمعظم الناس يسمعون كلمة «الحد الأدنى» فيظنون أنها تعني جودة متدنية، أو منتجاً غير مصقول، أو منتجاً نصف مكتمل تطلقه لمجرد أن تقول إنك أطلقت. ويؤدي هذا التفسير إلى دفع منتجات سيئة فعلاً إلى السوق بذريعة أنها مجرد منتج أولي. لكن ليس هذا ما يعنيه المفهوم، والمؤسسون الذين يعملون بهذا الافتراض يبنون عادة المنتج الخطأ، ويربكون مستخدميهم الأوائل، ويهدرون في الطريق أشهراً من التمويل المتاح لهم. فالمنتج الأولي ليس منتجاً معطلاً، بل منتج مركّز. وهذا الفارق أهم مما يدرك معظم الناس. والطريقة الصحيحة للتفكير في المنتج الأولي هي التالية: تبدأ بسرد كل ميزة تظن أن المنتج يحتاجها. اكتبها جميعاً، وأخرجها من رأسك إلى الورق. لا تصفِّ بعد، بل اسرد فقط. وسينتهي معظم المؤسسين بما بين خمسة عشر وثلاثين بنداً عندما يفعلون ذلك بصدق. ثم تنظر إلى تلك القائمة وتطرح سؤالاً واحداً عن كل ميزة: لو أزلنا هذه الميزة، هل تبقى المشكلة الجوهرية التي نحلها معالَجة؟ إذا كان الجواب نعم، فالميزة لا مكان لها في نسختك الأولى. وتواصل الحذف حتى يتبقى لديك شيئان أو ثلاثة أساسية فعلاً كي يعمل المنتج على مستوى بسيط. تلك هي ميزاتك الجوهرية. وكل ما عداها يذهب إلى قائمة المهام المؤجلة، وهي تسمية مهذبة لما يتحول غالباً إلى مقبرة. وهذه العملية أصعب مما تبدو لأن المؤسسين مرتبطون عاطفياً بأفكارهم. فكل ميزة في تلك القائمة بدت مهمة حين أُضيفت. نظام الإحالة بدا وسيلة للنمو، ومحرك التوصيات بدا قيمة مضافة، والميزات الاجتماعية بدت وسيلة للاحتفاظ بالمستخدمين. وربما تكون كل هذه الأمور مهمة في نهاية المطاف. لكن بناءها قبل التحقق مما إذا كان أحد يريد فعلاً المنتج الجوهري هو من أكثر الأخطاء شيوعاً وكلفة في الشركات التقنية بمراحلها المبكرة. أنت لا تحذف الميزات لأنك لا تستطيع تحمل كلفة بنائها، وإن كان ذلك صحيحاً أحياناً أيضاً، بل تحذفها لأنها تشتت الانتباه عن السؤال الذي تحتاج فعلاً إلى الإجابة عنه بنسختك الأولى: هل تعمل هذه الوظيفة الجوهرية، وهل يريدها الناس؟ وفي منظومة الشركات الناشئة في باكستان، تأتي الأمثلة الأكثر دلالة على ذلك من قطاع التقنية المالية. فقد بدأ عدد من أكثر المنصات المالية الرقمية رسوخاً في البلاد بوظيفة واحدة مركزة. لا حزمة كاملة من الميزات المصرفية، ولا أهداف ادخار ومنتجات استثمار ودفع فواتير دفعة واحدة، بل وظيفة واحدة تُنجز بموثوقية. محفظة تعمل. مسار دفع لا يتعطل. طلب قرض لا يتطلب زيارة فرع. ولم تكن البساطة قيداً، بل خياراً متعمداً أتاح للفريق التحقق من الطلب، وفهم سلوك المستخدمين، والتطوير المتكرر بسرعة قبل إضافة التعقيد. أما المؤسسون الذين حاولوا بناء كل شيء دفعة واحدة فلم يتحركوا أسرع، بل تحركوا أبطأ، وأنفقوا أكثر، وغالباً ما غيّروا مسارهم بعد الإطلاق على أي حال ما إن اكتشفوا الميزات التي يهتم بها المستخدمون فعلاً. ومقبرة الميزات حقيقية، ومعظم المؤسسين الذين أطلقوا منتجاً لديهم واحدة. إنها مجموعة الأشياء التي بُنيت وأُطلقت ثم تجاهلها المستخدمون بصمت. تبويب التحليلات الذي لم يفتحه أحد. الخلاصة الاجتماعية التي بقيت فارغة. نظام التصفية الذي تجاوزه الناس كلياً لأن العرض الافتراضي كان كافياً. لم تكن هذه الميزات أفكاراً سيئة بالضرورة، بل كانت أفكاراً سابقة لأوانها. بُنيت لأن أحداً في الفريق ظنها مهمة، أو لأن مستثمراً محتملاً ذكر أن المنافسين يملكونها، أو لأن المؤسس لم يستطع تخيل المنتج من دونها. لكن المستخدمين أوضحوا أولوياتهم لحظة بدأوا باستخدام المنتج، وكبرت المقبرة. وكلّف بناء تلك الميزات وقتاً ومالاً وتركيزاً كان يمكن أن يذهب إلى تحسين التجربة الجوهرية. ومن معايير القرار المفيدة لأي ميزة في قائمتك الأولية أن تسأل ما إذا كانت جوهرية للمشكلة أم مجرد إضافة مستحسنة. فالجوهرية تعني أن المنتج من دونها لا يستطيع تقديم قيمته الأساسية للمستخدم. والمستحسنة تعني أنها ستحسّن التجربة أو تضيف راحة أو تزيد التفاعل، لكن المنتج يعمل من دونها. فإذا كانت الميزة جوهرية فمكانها منتجك الأولي، وإذا كانت مستحسنة فلا، مهما كانت محببة إليك. والجزء الصعب هو أن تكون صادقاً مع نفسك بشأن الفئة التي تندرج فيها الميزة فعلاً، لأنه من السهل جداً أن تقنع نفسك بأن شيئاً ما جوهري بينما هو في الحقيقة مجرد شيء يحمسك أو تقلق من استبعاده. وعلى صعيد الجدول الزمني، فإن الأرقام التي ينبغي لمعظم الفرق أن تستهدفها هي ما بين أسبوعين وأربعة أسابيع تقريباً لمنتج أولي على الويب، وبين أربعة وستة أسابيع لمنتج على الهاتف المحمول. ليست هذه قواعد جامدة، وسيؤثر فيها تعقيد منتجك تحديداً، لكن إذا كان بناؤك الأولي يستغرق ستة أشهر، فأنت على الأرجح لم تعد تبني منتجاً أولياً. لقد انزلقت إلى بناء النسخة الأولى من المنتج، وهو أمر مختلف. فالنسخة الأولى يمكن أن تكون أكثر اكتمالاً وصقلاً وغنى بالميزات، لكنها تتطلب رأس مال أكبر ووقتاً أطول ومخاطر أعلى، لأنك تتعمق في مجموعة افتراضات عن سلوك المستخدمين لم تتحقق منها بعد مع أشخاص حقيقيين. والغاية الكاملة من الانضباط في الجدول الزمني للمنتج الأولي