دليل المنتج الأولي القابل للتطبيق: لماذا الإطلاق المبكر يتفوق دائماً على السعي نحو الكمال

المقدمة

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

موّل Y Combinator أكثر من 5,000 شركة ناشئة منذ تأسيسه في عام 2005، منتجاً أكثر من 80 شركة يونيكورن ومحققاً أكثر من 800 مليار دولار في التقييم المجمع لمحفظته. النمط الذي يراه المسرّع بشكل متكرر هو عكس ما يفترضه معظم المؤسسين: المؤسسون الذين يطلقون شيئاً بسيطاً بشكل محرج، ويضعونه أمام مستخدمين حقيقيين، ويكررون بقوة، يتفوقون على المؤسسين الذين يقضون أشهراً في بناء منتج مصقول في عزلة.

Michael Seibel، شريك في YC والمؤسس المشارك لـ Twitch، أوصل هذه الرسالة لآلاف مؤسسي الشركات الناشئة من خلال برنامج Startup School التابع لـ YC. أطروحته المركزية: يجب أن يستغرق بناء منتجك الأولي القابل للتطبيق أسابيع وليس أشهراً. يجب أن يحتوي على وظائف محدودة. ويجب أن يستهدف مجموعة صغيرة من المستخدمين الذين يحتاجون بشدة إلى ما تبنيه. كل شيء آخر هو إلهاء.

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

فخ الإفراط في التفكير

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

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

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

Paul Buchheit، شريك في YC ومبتكر Gmail، يصيغ هذا على أنه البحث عن «حل 90/10» — حل يمنحك 90 بالمئة من القيمة بـ 10 بالمئة من الجهد. قد لا يكون مثالياً، لكنه جيد بما يكفي لوضعه أمام المستخدمين والبدء في التعلم. الـ 90 بالمئة المتبقية من الجهد يجب أن تُوجَّه بما يحتاجه هؤلاء المستخدمون فعلاً، وليس بما تتخيل أنهم قد يريدونه.

لماذا خوفك من الإطلاق غير عقلاني

أكبر حاجز نفسي أمام إطلاق المنتج الأولي هو خوف غير محدد: «إذا رأى الناس منتجي ولم يعجبهم، تموت شركتي.» شهد YC هذا الخوف وهو يشل آلاف المؤسسين. إنه غير عقلاني في معظم الحالات، لثلاثة أسباب.

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

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

لا تتعلم شيئاً بدون مستخدمين حقيقيين. الفجوة بين ما تعتقد أن المستخدمين يريدونه وما يحتاجونه فعلاً هائلة. كل أسبوع تقضيه في البناء دون تغذية راجعة من المستخدمين هو أسبوع من تراكم الافتراضات الخاطئة. كلما أسرعت في وضع شيء بين أيدي المستخدمين، أسرعت في تصحيح المسار. Eric Migicovsky، شريك في YC ومؤسس Pebble، يُدرّس وحدة كاملة في Startup School حول هذه النقطة: أفضل المؤسسين يحافظون على اتصال مباشر مع مستخدميهم طوال عمر شركتهم بالكامل، مستخرجين المعلومات في كل مرحلة لتوجيه قرارات المنتج.

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

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

Airbnb

في عام 2007، كان Brian Chesky وJoe Gebbia يكافحان لدفع إيجار شقتهما في San Francisco. عندما لاحظا أن حضور مؤتمر للتصميم الصناعي مكتمل الحجز يواجهون صعوبة في إيجاد إقامة بأسعار معقولة، اشتريا ثلاث فرشات هوائية ونصباها في غرفة معيشتهما وأنشآ موقعاً إلكترونياً بسيطاً يقدم «AirBed & Breakfast» لحضور المؤتمر.

كان الموقع بسيطاً للغاية — لا تدفق حجز متطور، لا بحث قوي، لا نظام تقييمات. العرض كان محدوداً بموقع واحد (شقتهما)، نوع إقامة واحد (فرشات هوائية على أرضيتهما)، ومناسبة واحدة (مؤتمر واحد). كانا يتقاضيان 80 دولاراً في الليلة بعملية دفع بسيطة لا تشبه بأي شكل نظام المعاملات السلس الذي تستخدمه Airbnb اليوم.

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

Twitch

بدأ Twitch تحت اسم Justin.tv — منصة تعرض المؤسس المشارك Justin Kan وهو يبث حياته مباشرة على مدار الساعة باستخدام كاميرا ويب مثبتة على قبعة بيسبول. عند إطلاقها في 19 مارس 2007، لم تكن هناك طريقة لأشخاص آخرين للبث. المنتج بأكمله كان بثاً مرئياً واحداً لحياة شخص واحد اليومية.

بحلول أكتوبر 2007، فتح Justin.tv أبوابه للجمهور، مما سمح لأي شخص بإنشاء قناة. ظهرت فئة الألعاب بشكل عضوي ونمت بأسرع وتيرة، متجاوزة في النهاية كل أنواع المحتوى الأخرى. في يونيو 2011، فصلت الشركة محتوى الألعاب في منصتها الخاصة باسم TwitchTV. استحوذت Amazon على Twitch مقابل 970 مليون دولار في أغسطس 2014.

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

Stripe

تصوّر Patrick وJohn Collison فكرة Stripe في أواخر عام 2009، محبطين من صعوبة قبول المدفوعات عبر الإنترنت بالنسبة للمطورين. نموذجهم الأولي، الذي بُني خلال شهر في Buenos Aires، سُمي «/dev/payments» — واجهة برمجة تطبيقات (API) تسمح للمطورين بدمج نظام دفع في موقعهم الإلكتروني بسطور قليلة فقط من الكود.

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

جاء أوائل عملاء Stripe من شبكة YC — حوالي 20 شركة ناشئة كان الأخوان Collison يعرفانها شخصياً. أول مستخدم لهم على الإطلاق، Ross Boucher، كان لديه طلب بسيط: تحويل الأموال فعلاً إلى حسابه المصرفي. استمر الأخوان في التكرار بناءً على هذا النوع من التغذية الراجعة المباشرة. أُطلق Stripe رسمياً في سبتمبر 2011، بعد قرابة عامين من النموذج الأولي، وبحلول ذلك الوقت كان المنتج قد تطور بشكل كبير عما بدأ عليه.

إيجاد العملاء «ذوي الحاجة الملحة»

ليس كل المستخدمين متساوين بالنسبة للمنتج الأولي. المستخدمون المهمون هم أولئك الذين مشكلتهم ملحة جداً ومؤلمة جداً بحيث سيستخدمون أي حل — حتى المعطل — لمعالجتها.

يسمي YC هؤلاء عملاء «hair on fire» (الشعر يشتعل). القياس واضح: إذا كان شعرك يشتعل وعرض عليك أحد حلاً، لن تسأل عما إذا كان مصمماً بأناقة. لن تتحقق من التقييمات. ستستخدم أي شيء متاح. يجب أن يكون عملاؤك الأوائل بهذا القدر من اليأس.

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

التمرين بسيط: حدد أكثر مستخدم محتمل يأساً لمنتجك. ما هو الحد الأدنى الذي يمكنك بناؤه لتلبية حاجته الأكثر إلحاحاً؟ هذا هو منتجك الأولي. كل شيء آخر هو النسخة الثانية.

عملاء Chesky وGebbia «ذوو الحاجة الملحة» كانوا حضور مؤتمر لم يستطيعوا حرفياً إيجاد غرفة فندقية. مشاهدو Kan الأوائل كانوا أشخاصاً فضوليين بما يكفي حول البث المباشر لمشاهدة أي شيء. أوائل مستخدمي الأخوين Collison كانوا شركات YC الناشئة التي كانت بحاجة لعمل المدفوعات بالأمس ولم تكن تهتم بما إذا كانت الواجهة الخلفية تُدار يدوياً.

فخ «Steve Jobs المزيف»

اعتراض شائع على نهج المنتج الأولي يستحضر Steve Jobs: «Jobs لم يكن ليطلق شيئاً قبيحاً أبداً. كان يهتم بجودة المنتج فوق كل شيء. يجب أن أفعل المثل.»

هذا يُسيء فهم ما فعله Jobs فعلاً بشكل جوهري. أُطلق أول iPhone في يونيو 2007 بدون App Store — الذي جاء بعد عام كامل مع iPhone OS 2.0 في يوليو 2008. الكاميرا لم تستطع تصوير فيديو. كان يدعم فقط اتصال EDGE (الجيل الثاني) — إنترنت بطيء بشكل مؤلم حتى بمعايير 2007، عندما كان الجيل الثالث متاحاً بالفعل على نطاق واسع. لم تكن هناك تطبيقات طرف ثالث على الإطلاق.

أُطلق Apple Maps مع iOS 6 في سبتمبر 2012 باتجاهات غير دقيقة بشكل سيء السمعة وبيانات مفقودة. كان رد الفعل العنيف شديداً لدرجة أن Tim Cook نشر اعتذاراً علنياً في 28 سبتمبر 2012 — خطوة غير معتادة جداً بالنسبة لـ Apple — وذهب إلى حد التوصية بمنافسين مثل Google Maps وBing Maps وWaze كبدائل حتى تتمكن Apple من تحسين منتجها الخاص.

مرّ iPod بست أجيال من خطه Classic وحده، بالإضافة إلى متغيرات Nano وShuffle وTouch. كل تكرار أضاف ميزات وحسّن عمر البطارية وصقل الواجهة. أول iPod لم يكن الـ iPod الذي فتح السوق — كان الـ iPod الذي أثبت أن الناس سيحملون مكتبتهم الموسيقية في جيبهم.

الدرس من Jobs ليس «ابنِ منتجات مثالية». الدرس هو «حدد الشيء الأهم، أطلقه، وكرر بلا هوادة». هذه هي فلسفة المنتج الأولي بالضبط.

كيف تبني منتجك الأولي في أيام وليس أشهر

الإطار العملي من Startup School التابع لـ YC بسيط:

الخطوة 1: اكتب كل ميزة تعتقد أن منتجك يحتاجها. كن شاملاً. ضمّن كل ما تخيلته، كل ميزة ذكرها مستخدم محتمل، كل قدرة تعتقد أنها تميزك.

الخطوة 2: حدد عرض القيمة المركزي. اسأل نفسك: إذا كان منتجي يفعل شيئاً واحداً فقط، ماذا سيكون؟ ما هي القدرة الوحيدة التي، إذا نجحت، ستحسّن حياة مستخدم يائس؟ تلك القدرة هي منتجك الأولي.

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

الخطوة 4: اختر شكل الإطلاق. ليس كل منتج أولي يحتاج أن يكون برنامجاً عاملاً. يشير Seibel إلى أن المنتج الأولي يمكن أن يكون موقعاً إلكترونياً بسيطاً، أو صفحة هبوط، أو جدول بيانات، أو حتى عملية يدوية تحاكي تجربة المنتج. إعداد «حساب التاجر اليدوي» للأخوين Collison كان فعلياً واجهة خلفية يشغلها إنسان. افعل ما يضعك أمام المستخدمين بأسرع وقت.

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

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

محرك التكرار

المنتج الأولي ليس المنتج. إنه نقطة البداية لدورة تعلم:

1. أطلق المنتج الأولي لمجموعة صغيرة من المستخدمين اليائسين
2. تحدث مع هؤلاء المستخدمين — ليس من خلال استطلاعات، بل من خلال محادثة مباشرة. شاهدهم يستخدمون منتجك. اسأل ما أحبطهم. اسأل ما تمنوا أن يفعله المنتج. المفتاح، كما يُعلّم Migicovsky، هو السؤال عن سلوكهم ومشاكلهم وليس عن افتراضات. «هل ستستخدم هذه الميزة؟» سؤال سيء. «أخبرني عن آخر مرة واجهت فيها هذه المشكلة» سؤال جيد.
3. كرر — أصلح المشكلة الأكثر أهمية التي حددوها. أضف الميزة التي يحتاجونها بأشد إلحاح.
4. أطلق التحديث وكرر

مقال Paul Graham الشهير «Do Things That Don’t Scale» يعزز هذه الدورة. يكتب Graham أن أكثر شيء غير قابل للتوسع يجب على المؤسسين فعله في البداية هو تجنيد المستخدمين يدوياً — واحداً تلو الآخر، من خلال التواصل الشخصي، من خلال الظهور حيث يتواجد مستخدموهم. كان مؤسسو Stripe يطلبون من المستخدمين المحتملين تسليم حاسوبهم المحمول، ثم يُعدّون Stripe على الفور. هذا لا يتوسع. لكنه يخلق قاعدة مستخدمين أولية تغذي محرك التكرار.

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

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

متى يفشل نهج المنتج الأولي

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

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

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

الخاتمة

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

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

المصادر والقراءات الإضافية

• How to Plan an MVP — Y Combinator Startup School (Michael Seibel)
• How to Build an MVP — Y Combinator Startup School
• Do Things That Don’t Scale — Paul Graham
• How to Talk to Users — Y Combinator Startup School (Eric Migicovsky)
• How to Get Your First Customers — Y Combinator Startup School
• Tim Cook Apologizes For Apple Maps — TechCrunch