طلب الميزة الذي ينبغي أن تبنيه فعلاً (وكيف تعرفه)

أنت تعرف كيف تقول لا لطلبات الميزات السيّئة. تعلّمتَ التمييز بين تضخّم النطاق والميزات الأساسية. أنت تحمي حدود منتجك.

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

أيّ ثلاثة؟

هنا تخطئ معظم قرارات المنتج. يختار المؤسّسون تلك التي تبدو أكثر إبهاراً، أو أكثر ربحية، أو تلك التي جاءت من أهمّ عملائهم. أحياناً يكونون محقّين. وعادةً يكونون مخطئين.

الإشارات التي تهمّ

الإشارة 1: التكرار غير المطلوب

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

والعكس مهمّ: إن طلب مستخدم واحد ولم يطلبه سواه، وبنيتَه، فقد صرتَ الآن تصون ميزة لا يستخدمها أحد آخر، وقد يظلّ ذلك المستخدم الواحد غير راضٍ عنها (لأنك بنيتَها بشكل خاطئ قليلاً).

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

الإشارة 2: الحلّ البديل يهمّ

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

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

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

انتبه إلى أيّ الطلبات عوائق. أحدهم يقول “لا أستطيع استخدام هذا حتى تفعل X” مقابل أحدهم يقول “سيكون رائعاً لو كان لديك X”. ذلك التمييز ذهب خالص.

الإشارة 3: الميزة تتلازم مع نموذج العمل

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

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

أنجح إضافات الميزات هي تلك التي يكشف فيها إطلاق الميزة عن سوق لم تكن تعرف بوجوده. بنيتَ التصدير. فتبيّن أن الشركات تريد تضمين تصديرك في سير عملها. والآن صار لديك حكاية تكامل لم تخطّط لها.

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

الإشارة 4: طلب المساعدة

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

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

ومن يطلبون فقط هم أناس يأملون أن تبني سحرياً ما يتخيّلونه. أحياناً ستفعل. وغالباً لن تفعل.

ابنِ مع المختبِرين أولاً. وكل ما عدا ذلك ثانوي.

إغراء بناء ميزة الوجاهة

لكل منتج ميزة واحدة، إن أطلقتها، تجعلك تبدو أكثر إبهاراً. لتطبيقات الجدولة، إنها التكامل مع Calendly. ولتطبيقات المهام، إنها التكامل مع Slack. الكلّ يعرف ما هي. والكلّ يريدها.

لكن إليك الأمر: الكلّ يحصل عليها أيضاً من شخص آخر. إن لم تكن ميزتك هي التكامل الأفضل والأسهل مع Slack، فهي تضيف فقط تعقيداً إلى تطبيقك دون أن تجعلك مشهوراً.

الميزات التي تجعلك مشهوراً هي تلك التي تكون في موضع فريد لبنائها لأنك تفهم مشكلات مستخدميك المحدّدين أفضل من أي شخص آخر. وتلك ليست ميزات الوجاهة. بل هي الميزات المملّة التي تحلّ مشكلات حقيقية لأناس حقيقيين.

التكامل مع Slack مبهر. لكن أداة تتيح لمستخدميك أداء شيء محدّد واحد أسرع بكثير ممّا فكّر فيه Slack يوماً قيّمة.

كيف تقرّر فعلاً

حين يكون لديك دفعة من طلبات الميزات تجتاز كلّها اختبار “هل هذا ضمن النطاق؟”، رتّبها بحسب:

1. كم مستخدماً طلبها (بشكل مستقلّ)؟ الأكثر أفضل.
2. هل هذا عائق أم يُحبّذ وجوده؟ العوائق أكثر إلحاحاً.
3. هل يستطيع مستخدموك إيجاد حلّ بديل لهذا اليوم؟ إن لم يستطيعوا، فهو أكثر أهمية.
4. هل سيساعدك أحد في اختبار هذا؟ إن كان نعم، فابنِه أولاً.
5. هل سيكشف هذا عن سوق جديد؟ إن كان ربما، فتلك إضافة، لا سبب.

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

الميزة التي لن تبنيها (بعد)

ستردك طلبات لا تتأهّل. لا تتظاهر بأنك ستبنيها يوماً ما. أخبر المستخدم: “لن نبني ذلك الآن. إليك السبب. وإليك ما نبنيه. وإليك بديل قد ينفعك.”

تلك الصراحة تهمّ أكثر مما تظنّ. يفضّل المستخدمون أن يعرفوا أنك لن تفعله على أن ينتظروا ستة أشهر آملين.

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

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