المنتج الأول: كيف تحدد أقل ما يكفي لتتعلم من مستخدمين حقيقيين

ابدأ من السؤال لا من الميزات

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

والمنتج الذي يبنى بلا افتراض مكتوب لا يمكن الحكم عليه: مهما جاءت النتيجة ستفسرها كما تحب.

كيف تفصل الضروري عن المرغوب

1. اكتب المسار الأساسي الواحد الذي يقطع فيه المستخدم رحلته من البداية للنهاية.
2. احذف كل ما ليس على هذا المسار — مهما بدا مهما.
3. لكل ما بقي اسأل: هل يفشل المستخدم في إتمام الرحلة بدونه؟ إن كان لا، أجله.
4. أعد القراءة بعد يومين — ستجد ثلاثة بنود أخرى قابلة للتأجيل.

ما لا يجوز تأجيله

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

الحلول اليدوية خلف الواجهة

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

معايير القرار بعد الإطلاق

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

أسئلة شائعة

ألا يضر إطلاق منتج ناقص بسمعتنا؟

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

كم يجب أن تستغرق النسخة الأولى؟

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

ماذا لو طلب العملاء مميزات لم نبنها؟

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