ما الذي يجب أن يتضمنه منتجك الأولي SaaS عند الإطلاق — وما الذي لا يجب
نصف الميزات التي تخطط لإصدارك الأول لا مكان لها فيه. هذا دليل هادئ وعملي لرسم الخط الفاصل: ما الذي يحتاجه المنتج الأولي فعلاً، وما الذي يُغرقه بصمت، وكيف تطلق شيئاً حقيقياً.

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

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

طريقة بسيطة لرسم الخط
معرفة المبدأ شيء؛ وتطبيقه على مواصفاتك الخاصة، حيث تبدو كل ميزة وكأنها طفلك، أصعب. إليك طريقة تنجح لأنها تفرض قراراً على كل بند بدلاً من ترك كل شيء ينجرف نحو «أساسي».
- 1اسرد كل ميزة تخيّلتهاأفرغها كلها — بلا تصفية بعد. ضع قائمة الأمنيات كاملة على الطاولة كي لا يكمن شيء غير مذكور ثم يعود في منتصف البناء كمفاجأة.
- 2قيّم كل واحدة في مقابل المهمة الأساسيةلكل ميزة، اسأل: هل يحتاج المستخدم إليها لإتمام المهمة الأساسية الوحيدة من البداية إلى النهاية؟ صنّفها «أساسية» أو «مفيدة» أو «يوماً ما». كن صادقاً — معظمها يقع في الفئتين الأخيرتين.
- 3أبقِ على «الأساسية» فقط للإصدار الأولمنتجك الأولي هو كومة «الأساسية» ولا شيء غيرها. كومتا «المفيدة» و«يوماً ما» ليستا مرفوضتين — إنهما خارطة طريقك، مركونتان حيث تنتميان.
- 4تحقّق من سلامة الاقتطاعانظر إلى ما تبقّى واسأل: هل يستطيع مستخدم حقيقي الحصول على قيمة حقيقية من هذا وحده؟ إن كانت الإجابة نعم، فقد حدّدت نطاق منتج أولي. وإن كان شيء يكسر فعلاً المسار الأساسي، فأعِد ذلك البند وحده — ولا شيء غيره.
الانضباط يكمن في الخطوة الرابعة. هناك دائماً إغراء بـ«إعادة شيء واحد فقط»، ثم آخر، حتى تكون قد أعدت بناء المنتج الكامل بصمت. اسمح لنفسك بإنقاذ البنود التي تكسر فعلاً المسار الأساسي فقط — لا البنود التي ستجعله مجرد أجمل. الأجمل هو ما وُجد له الإصدار الثاني.
| الميزة | أولي؟ | لماذا |
|---|---|---|
| تسجيل دخول/تسجيل وحيد | نعم | كل شيء يعتمد على معرفة المستخدم |
| سير العمل الأساسي الوحيد | نعم | إنه الغاية الكاملة من المنتج |
| تسجيل أساسي/واجهة إدارة | نعم | لا يمكنك التعلّم مما لا تراه |
| فوترة وخطط آلية | لاحقاً | خذ المال يدوياً حتى تعرف أنهم سيدفعون |
| الأدوار والصلاحيات | لاحقاً | نوع مستخدم واحد يكفي دائماً تقريباً في البداية |
| تكاملات الطرف الثالث | ربما واحد | فقط إن كان جزءاً من المهمة الأساسية |
| تطبيقات الجوال الأصلية | لاحقاً | تطبيق ويب متجاوب يغطي الهواتف اليوم |
| لوحة التحليلات | لاحقاً | لا شيء لعرضه بصرياً حتى ينشئ المستخدمون البيانات |
قابل للتطبيق يظل يعني أنه يجب أن يبدو حقيقياً
هناك نمط فشل على الجانب الآخر من الخط، ويستحق التسمية. في عجلة الإطلاق الصغير، يطلق بعض المؤسسين شيئاً رثّاً — ويسمّونه منتجاً أولياً. مسار أساسي يضيّع عملك، وتسجيل يعطي خطأ 404، ونصوص مليئة بكلمات نائبة. هذا لا يختبر فكرتك بإنصاف؛ بل يختبر ما إذا كان المستخدمون سيتحمّلون تجربة مكسورة، والجواب دائماً لا. ستستنتج أن الفكرة فشلت بينما الذي فشل في الحقيقة هو التنفيذ.
«الأدنى» ينطبق على النطاق، لا على جودة الجزء الذي تبقيه. ميزات أقل، كل واحدة صلبة. سير العمل الوحيد الذي تطلقه ينبغي أن يبدو مكتملاً — سريعاً، وواضحاً، وجديراً بالثقة — حتى لو كان الشيء الوحيد الذي يفعله المنتج. منتج ضيّق أُتقن يتفوّق على منتج واسع أُسيء كل مرة، خاصةً حين تطلب من غرباء أن يأتمنوك على عملهم.
“الأدنى يتعلق بكم تبني، لا بمدى جودة بنائك. أطلق شيئاً صغيراً يبدو مكتملاً، لا شيئاً كبيراً يبدو مهجوراً.”
المنتج الأولي ليس خط النهاية — إنه القراءة الأولى
إليك الجزء الذي يعيد تأطير كل شيء: الإطلاق ليس الهدف. الهدف هو ما تتعلّمه في الأسابيع التي تليه. منتج أولي يُطلَق ويخبرك «المستخدمون يحبون الجوهر لكنهم يطلبون باستمرار X» نجاح صاخب — حتى لو عنى X شهر عمل إضافي. ومنتج أولي يُطلَق في صمت، بلا أحد يعود، قد أدّى مهمته أيضاً: فقد أنقذك من بناء الثلاثين ميزة الأخرى فوق أساس لم يرغب فيه أحد.
لذا خطّط للأسابيع الأولى بالعناية نفسها التي خطّطت بها للبناء. راقب ما يفعله الناس فعلاً، لا ما يقولونه في الاستبيانات. تحدّث إلى من عادوا ومن لم يعودوا. دع الاستخدام الحقيقي — لا مواصفاتك الأصلية — يقرّر ما يدخل في الإصدار الثاني. خارطة الطريق التي ركنتها سابقاً ليست وعداً؛ إنها فرضية، ومستخدموك على وشك أن يصحّحوها.

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

Have a nice day هو استوديو برمجيات يساعد الشركات الصغيرة والمتوسطة على التحول الرقمي — أتمتة وذكاء اصطناعي وبرمجيات مخصصة تعمل في العمليات اليومية، لا على الشرائح فقط.