كيف تختار الحدود التي يتوجّب على منتجك عدم تجاوزها

إنّ أفضل شيء يفعله مدير مُنتج ما هو أن يقرّر أين تنتهي حدود مُنتجه، وأين تبدأ مهمّة مُنتج آخر.

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

مثال: تطبيق تعقب الوقت Time tracking

يعتبر تعقّب الوقت، كحد أدنى مطلق (أي في صورته القاعدية)، مجرّد جمع قائمة من الأرقام، وإذا كان هذا هو أقصى ما يقدّمه التّطبيق فسيكون عديم الفائدة. حيث أنّ مستندات جوجل أو اكسل تقوم بهذه المهمة بالفعل. وسندرك عند هذه النّقطة أنّ البساطة مبالغ فيها، وأنّه ليس هنالك ما يمكن إضافته لتحسين التّطبيق، لا مجموعة من الخطوط، ولا خصائص HTML5 ولا المؤثّرات الصّوتيّة.

وكحد أعلى، يمكن أن يشتمل تعقّب الوقت على إدارة المشاريع، الميزانيّات، المتعاقدين، قوائم الحسابات، تعقّب وصولات الاستلام، ورصد الموظّفين. إنّ التّطبيقات التي تتضمن العديد من المهام تتجاوز حدودها لتتخطاها إلى أراضي مُنتجات أخرى يعتمد عليها المُستخدم بالفعل (كـ Xero، Ballpark، Basecamp، إلخ.)

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

إذا كنت تقوم ببناء تطبيق يساعد الفريق على طلب وجبات الغداء كل يوم، يمكن أن يكون تدفّق العمل كالتالي:

1. يجوع أحدهم.
2. يقوم أحدهم بإخبار بقية أفراد الفريق.
3. تتم المناقشة حول الخروج لتناول الطعام أم القيام بالطلب.
4. تتم مناقشة أخرى حول المكان الذي يُطلب منه.
5. يتم تمرير قائمة بأماكن مختلفة بين الجميع.
6. يتم التّوصل إلى قرار ما بسرعة.
7. يُعيّن شخص ما لجمع طلبات الجميع.
8. يقوم ذلك الشخص بالطلب.
9. يقوم ذلك الشخص بإخبار الجميع عن وقت التسليم وكلفة الطلب.
10. الوقت يمضي.
11. يصل الطعام، ويؤكل.
12. يتحقق الشخص الذي قام بالطلب من الأشخاص الذي دفعوا والذين لم يدفعوا مقابل الوجبة.
13. تتم التّسوية المالية، أو أنّها تؤجل إلى الغد.
14. سيتحدّث بعضهم عن الوجبة في فيس بوك أو تويتر، وبعضهم يقوم بنشر الصور على إنستجرام، وآخرون يقيمونها على Yelp.
15. يعود الجميع إلى العمل.

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

من أين يجب أن تبدأ؟

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

من الأمثلة الواقعية على ذلك تطبيق TripIt. يقوم هذا التطبيق بتقديم الحلول لإدارة الرحلات. يمكن أن تكون خطوة البداية لهذا التطبيق هي البحث عن الرحلات، لكنّ TripIt لم يستطع إضافة قيمة في هذه الحالة. إنّ أوّل مرحلة يمكنهم إضافة قيمة عندها هي بعد أن يتم الحجز. قام TripIt بإضافة حل رائع وذلك بفهم تدفّق العمل بالكامل. إنّ آخر أمر يمكن أن يحدث قبل أن يستطيع TripIt إضافة قيمة هو أن "يفتح المستخدم رسالة تأكيد الحجز"؛ هذه هي المرحلة الأولى التي يستطيع فيها TripIt إضافة قيمة لكي يبدأ مع تلك الرسالة ويقوم بالاستيراد من هناك. وبالمثل، يبدأ إنستجرام عن طريق استيراد شبكات التواصل الاجتماعي الخاصة بك، أو يبدأ تطبيق تعقّب الوقت عن طريق استيراد المشاريع من Basecamp. إنّ واجهات التّطبيقات الجيّدة وميزات الاستيراد تساعد المستخدمين على الاستمتاع ببداية سهلة التّشغيل.

أين يجب أن تتوقف؟

يجب أن تقوم ميزانيّتك، سواءً كانت ميزانية الوقت أو المال، بحد نطاق المُنتج من دون تحديده (أي من دون تحديد/تعريف نطاق المُنتج) . يجب أن تحدّد الميزانية الكبيرة كيفية حل المشكلة وليس عدد المشاكل التي تعالجها، حيث أنّه من شبه المستحيل أن تحاول معالجة تدفّق العمل بأكمله من البداية حتّى النهاية ولجميع فئات المستخدمين.

يجب أن يتوّقف مُنتجك عندما:

• تسعى وراءه شركات رائدة ومعروفة في السوق (مثل PayPal، IMDB، Expedia) وأنت لست على استعداد للمنافسة.
• تنتهي المرحلة التالية من المنتج بالعديد من الطرق المختلفة باستخدامه من قبل العديد من الفئات المختلفة من المستخدمين. مثلًا، محاولة معالجة الرواتب في تطبيق تعقّب الوقت قد تكون صعبة أو معقّدة.
• تشتمل المرحلة التالية على مستخدمين نهائيين end users مختلفين عن المستخدمين في المراحل السابقة، مثلًا المدراء، المحاسبين، إلخ.
• يصل إلى مرحلة لا تستطيع فيها تقديم أي قيمة.

حدد وألغ الخطوات عديمة المعنى

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

غالبًا ما يكون البريد الإلكتروني مصدرًا للخطوات عديمة المعنى التي نادرًا ما تحمل معلومات كافية ("قام شخص ما بنشر تعليق")، أو أنّها لا تحيل إلى إجراءات بديهيّة (التأكيد، التأشير كـ "محلول"، إلخ).

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

الخطوات المستقبلية

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

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

كثيرًا ما يُكتب هذه الأيام حول تحري البساطة، لكن هناك التباس في الأمر؛ حيث أنّ هنالك فرق أساسي بين تبسيط المُنتج وعمل مُنتج بسيط.

إنّ تبسيط المُنتج يؤكّد على إزالة جميع التعقيدات غير الضّرورية لكي يستطيع كل المستخدمين حل مشاكلهم بأكبر كفاءة ممكنة. أمّا عمل مُنتج بسيط يعني التركيز على مجال معين واختيار أصغر المجموعات الجزئية من تدفّق العمل حيث يمكن للمُنتج أن يقدم قيمة. ولذلك ينطوي المُنتج الفعّال القاعدي MVP على خطر تصنيفه كحلّ جزئي أو نقطي point solution، أو حتّى أسوء من ذلك؛ اعتباره "خاصيّة وليس مُنتج".

لذلك يجب أن تراعي "أين ترسم الخط" عندما تقوم ببناء مُنتج بسيط.

ترجمة -وبتصرّف- للمقال Where to Draw the Line لصاحبه: Des Traynor.

حقوق الصورة البارزة: Designed by Freepik.