خواطر مالك منتج: لماذا نبقي العمل بسيطًا وعمليًا في البداية

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

أود أن أشارككم شيئًا تعلمته من تجربتي رائد أعمال لم يكتب له النجاح، ومن قراءة قصص الشركات الناشئة، ومن عملي مديرًا للمنتج والتسويق في شركة ناشئة احتضنها مسرّع Y Combinator. معظم البدايات متواضعة وبسيطة إلى حد يصعب تصديقه. أول مثال يخطر في بالي هو DoorDash (بتقييم 16 مليار دولار): بنى مؤسسوها المنتج الأولي القابل للتطبيق (MVP) في عصر يوم واحد. جمعوا قوائم طعام المطاعم القريبة من مكان سكنهم، ووضعوها في صفحة هبوط (landing page)، وأضافوا أرقام هواتفهم الخاصة ليستقبلوا الطلبات. ثم اتصل أول شخص ليطلب طعامًا تايلانديًا، وهكذا كانت البداية: يستقبلون المكالمات، ويستلمون الطلبات من المطاعم، ويوصلونها بأنفسهم.

"لم يكن لدينا سائقون، ولا خوارزميات، ولا backend. لم نقضِ ستة أشهر في بناء نظام توزيع متطور، لم يكن لدينا شيء من ذلك. أطلقنا الخدمة فحسب، لأن البداية تدور كلها حول اختبار الفكرة، ومحاولة إطلاق المشروع، ومعرفة ما إذا كان الناس يريدونه أصلًا. ولا بأس في تجميع الأشياء بحلول سريعة مؤقتة في البداية." ستانلي تانغ، أحد مؤسسي DoorDash.

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

هيكل وثيقة متطلبات المنتج المختصرة:

• الشخصية (أو الشخصيات) الرئيسية للمستخدم
• المشكلة الرئيسية
• الحل
  • قائمة ميزات MVP
  • مقياس أو هدف محوري (north star) لهذا الـ MVP
  • رسومات تصميم بالقلم الرصاص وتدفق أساسي لواجهة المستخدم
• قائمة مهام خطية عالية المستوى
  • المهام الأكثر صعوبة أو التي تعيق غيرها أولًا، وكل مهمة منجزة تفتح الطريق للتي تليها
• بعض الأفكار للدخول إلى السوق والمبيعات

يمكنكم الحصول على نسخة من قالب وثيقة متطلبات المنتج المختصرة على Google Drive.

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

"افعلوا أشياء لا تتوسع." بول غراهام، أحد مؤسسي YC.

أثناء عملي على مشروعي الجانبي tagmate.io، كان بإمكاني بناء backend يولّد الكود ويضيف نطاق كل مستخدم تلقائيًا إلى قائمة السماح (allowlist). لكنني اخترت بدلًا من ذلك أن أنسخ مجلد كود الـ widget البسيط وأضيف النطاقات إلى قائمة السماح بنفسي لكل عميل. كنت أعرف أن شركات ناشئة مثل Hotjar أو FullStory تقدم لمستخدميها تجارب مشابهة لما يقدمه tagmate.io، لكنني لم أكن أعرف إن كانوا يريدون هذه الوظيفة كخدمة من طرف ثالث، ولا إن كانوا مستعدين لدفع اشتراك مقابلها أم يفضلون تطويرها داخليًا.

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

ينعكس ذلك أيضًا على جوانب من عملي مالكًا لمنتج SlimWiki (منتج مملوك لـ OOZOU)، حيث نحاول تطبيق المبادئ نفسها: نبقي التوثيق عند الحد الأدنى، ونقلّص نطاق المنتج لنركز على القيمة الجوهرية التي نقدمها.

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

"مع الحد الأدنى من التخطيط، تتقدمون مع المستخدم. ومع التخطيط المفرط، يتقدم المستخدم من دونكم."

هل تدفعكم تجربتكم إلى الموافقة؟ أم إلى الاعتراض؟ يسعدني أن أسمع آراءكم.