حدّد نطاق منتجك الأولي حول قرار واحد، لا حول قائمة ميزات

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

نقطة البداية الأفضل ليست “ماذا يجب أن يفعل المنتج؟” بل “ما القرار الذي أحتاج أن أتخذه بعد الإطلاق؟”

المنتج الأولي أداة لاتخاذ قرار

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

اكتب هذا القرار في جملة واحدة بهذه الصيغة:

بعد الإطلاق، سنقرر [الاستثمار أكثر / تغيير الاتجاه / التوقف] بناءً على ما إذا كانت [فئة محددة] تقوم بـ[فعل محدد].

إن لم تستطع إكمال هذه الجملة، فالمشكلة ليست في النطاق، بل في أن الرهان نفسه غير واضح بعد، ولن يحل ذلك أي قدر من البرمجة.

اعمل بالعكس انطلاقاً من الدليل الذي تحتاجه

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

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

احذف كل ما لا يلامس المسار

راجع قائمة الميزات الأصلية وضع كل بند في واحد من ثلاثة أعمدة:

• على المسار. بدونه لا يستطيع المستخدم إنتاج الدليل. ابنِه، وابنِه جيداً.
• يدعم المسار. يجعل المسار أسهل لكن يوجد بديل يدوي. نفّذه بيدك لأول المستخدمين: أرسل التذكير بنفسك، وافق على الحسابات من جدول بيانات، أصدر الفواتير يدوياً.
• لا علاقة له بالقرار. أجّله. اكتبه في قائمة “لاحقاً” حتى لا يشعر أحد أن فكرته ضاعت.

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

حافظ على الجودة حيث تهم

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

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

اتفقوا على معنى “انتهينا” قبل البدء

قبل كتابة أي سطر برمجي، اكتب معيار النجاح بجانب جملة القرار: “إذا أجرت 20 عيادة على الأقل من أول 50 عيادة تنضم إلينا حجزاً حقيقياً خلال أسبوعيها الأولين، نستمر.” الأرقام تختارها أنت، والمهم أن تختارها مسبقاً حتى يُنتج الإطلاق قراراً لا جدالاً.

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

نطاق من صفحة واحدة يمكنك مشاركته

في نهاية هذا التمرين يجب أن تكون لديك صفحة واحدة تحتوي على خمسة أشياء:

1. جملة القرار.
2. الدليل ومعيار النجاح.
3. مسار المستخدم خطوة بخطوة.
4. ما ستنفذه يدوياً حالياً.
5. قائمة “لاحقاً”.

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

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