بدأ الاجتماع بسؤال بسيط:

ما الأولوية التي يجب أن يعمل عليها الفريق في الإصدار القادم؟

لم تمر دقائق حتى أصبحت القائمة مزدحمة.

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

كل طلب بدا منطقيًا.

وكل صاحب مصلحة كان يملك أسبابًا مقنعة.

وفي نهاية الاجتماع، ظهرت المشكلة المعتادة: عندما تكون جميع الطلبات عاجلة، لا تعود هناك أولوية حقيقية.

الطلب العاجل ليس دائمًا الطلب الأهم

تصل طلبات أصحاب المصلحة إلى فريق المنتج بصيغ مختلفة:

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

غالبًا لا تكون هذه الطلبات غير مهمة، لكن وصفها بالعاجلة لا يعني بالضرورة أنها الأكثر تأثيرًا.

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

دور مدير المنتج ليس رفض الطلبات، ولا قبولها جميعًا. دوره أن يحول النقاش من:

من طلب هذه الخاصية؟

إلى:

ما القيمة التي ستحققها؟ وما أثر عدم تنفيذها الآن؟

لا تبدأ بالدفاع عن قرارك

من الطبيعي أن يشعر مدير المنتج بالضغط عندما يطالب كل طرف بأولوية مختلفة. وقد يقع في خطأ شائع: الدفاع مباشرة عن خارطة الطريق الحالية.

يقول مثلًا:

ليس لدينا وقت.

أو:

الفريق يعمل على أولويات أخرى.

أو:

هذا الطلب غير موجود في الخطة.

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

الاستجابة الأفضل تبدأ بالأسئلة:

• ما المشكلة التي يعالجها الطلب؟
• من المستخدم المتأثر؟
• كم مرة تحدث المشكلة؟
• ما أثرها المالي أو التشغيلي؟
• ماذا يحدث إذا أجلناها؟
• هل توجد طريقة مؤقتة لمعالجة المشكلة؟
• كيف سنقيس نجاح الحل؟

هذه الأسئلة لا تهدف إلى تعقيد الطلب، بل إلى نقله من مساحة الرأي إلى مساحة الأدلة.

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

لكل طلب قصة، لكن الأرقام تكملها

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

هذه ملاحظة مهمة، لكنها لا تكفي وحدها لاتخاذ القرار.

يحتاج الفريق إلى معرفة:

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

قد يكتشف الفريق أن المشكلة تسبب انسحاب 30% من المستخدمين، وهنا تصبح ذات أولوية عالية. وقد يكتشف أنها حدثت مرتين فقط بسبب حالة استثنائية، وهنا يمكن معالجتها بطريقة مختلفة.

القصص تقرّب المشكلة، والبيانات توضح حجمها. والقرار الجيد يحتاج إلى الاثنين معًا.

الأولوية مقارنة وليست حكمًا منفصلًا

أحد أكبر الأخطاء في ترتيب الأولويات هو تقييم كل طلب بمفرده.

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

قد تكون هناك ثلاثة طلبات مهمة:

1. تحسين خطوة تتسبب في مغادرة المستخدمين.
2. إضافة خاصية مطلوبة من عميل رئيسي.
3. تحديث تقني يقلل احتمالية تعطل النظام.

كل طلب يحقق قيمة مختلفة:

• الأول يحسن تجربة المستخدم.
• الثاني يدعم الإيرادات.
• الثالث يقلل المخاطر التقنية.

لا توجد إجابة صحيحة دون معرفة هدف المنتج في هذه المرحلة.

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

ترتيب الأولويات لا يتم في الفراغ؛ بل يعتمد على الاتجاه الذي اختارته المنظمة للمنتج.

استخدم معايير واضحة للجميع

لا يحتاج فريق المنتج إلى معادلة معقدة لترتيب الطلبات، لكنه يحتاج إلى معايير ثابتة ومفهومة.

يمكن تقييم كل طلب من خلال مجموعة أسئلة، مثل:

ما حجم الأثر؟

كم عدد المستخدمين المتأثرين؟ وما حجم التحسن المتوقع؟

ما ارتباطه بالهدف الحالي؟

هل يدعم أحد أهداف المنتج أو المنظمة، أم أنه طلب منفصل لا يخدم الاتجاه الحالي؟

ما درجة الاستعجال؟

هل توجد مهلة نظامية، أو التزام تعاقدي، أو خطر حقيقي من التأجيل؟

ما حجم الجهد؟

هل يحتاج الطلب إلى أيام قليلة، أم يتطلب أشهرًا وتكاملات معقدة؟

ما مستوى الثقة؟

هل توجد بيانات تدعم القيمة المتوقعة، أم أن القرار مبني على افتراض لم يُختبر؟

ما المخاطر؟

هل يؤدي عدم التنفيذ إلى خسارة، أو تعطل، أو مشكلة أمنية، أو أثر سلبي على المستخدمين؟

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

لا تقل «لا» فقط، بل وضّح المقابل

قد يقرر فريق المنتج عدم إعطاء أحد الطلبات أولوية في الوقت الحالي.

هنا تظهر أهمية طريقة التواصل.

القول:

لن ننفذ الطلب.

قد يُفهم على أنه تجاهل للاحتياج.

أما القول:

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

فهو يوضح أن القرار لا يعني عدم أهمية الطلب، بل يعني وجود أولوية أعلى في الوقت الحالي.

الشفافية لا تجعل الجميع راضين دائمًا، لكنها تجعل القرار مفهومًا.

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

احذر من «التعديل البسيط»

تبدأ بعض الطلبات بعبارة:

الموضوع مجرد تعديل بسيط.

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

وفي المقابل، قد يبدو طلب آخر كبيرًا، لكن الفريق يستطيع اختباره بطريقة بسيطة دون بناء الحل الكامل.

لذلك لا ينبغي أن يحدد صاحب الطلب حجم الجهد المتوقع. يحتاج الفريق التقني والتصميمي إلى فهم الطلب وتقديره قبل إدخاله ضمن الأولويات.

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

السؤال ليس فقط: هل نستطيع تنفيذها بسرعة؟

بل: هل تستحق أن ننفذها أصلًا؟

ما الذي حدث بعد الاجتماع؟

عاد مدير المنتج إلى الطلبات التي طُرحت في بداية الاجتماع.

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

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

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

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

لم يحصل الجميع على ما طلبه، لكن القرار أصبح واضحًا ومبنيًا على منطق مشترك.

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

الخلاصة

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

لكن مدير المنتج يستطيع تحسين جودة القرار عندما:

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

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

وعندما يقول الجميع إن طلبه عاجل، لا تسأل من يصرّ أكثر.

اسأل: أي قرار سيصنع الأثر الأكبر الآن؟