البحث في الموقع

لقد كُتب الكثير حول كيفية بناء شركات الإنترنت لبرمجياتها، بدءًا من الكتب مثل كتاب "The Lean Start-Up" (بناء الشركات بسلاسة) وحتى منشورات شركة (Google Ventures)، مع ذلك لا توجد الكثير من الأمثلة لشركات ناشئة تتحدث حول آلية عمل فرق المنتجات لديها. وفي عام 2013 تحدثت شركة Spotify عن آلية عملها، مع ذلك لا توجد الكثير من هذه الأمثلة. ويرجع السبب في ذلك ربما إلى عدم ارتياح الشركات تجاه الحديث أمام جمهورها عن واقع عملها، والذي قد تسوده الفوضى في بعض الأحيان. صحيح أن هنالك الكثير من النصائح المقتضبة، ولكن هناك غياب واضح لأمثلة عملية حول آلية عمل الشركات الناشئة، وخصوصًا تلك التي تحقق نموًا سريعًا، لذلك قررت شركة (Intercom) مشاركة طريقة عملها مع الجمهور. خلال الشهور الـ 12-18 الماضية، أنجزت الشركة العشرات من التحسينات التدريجية، بالإضافة إلى العديد من عمليات إعادة التصميم، وقد تعلمت الشركة خلال هذه الفترة الكثير حول كيفية توسيع فرق بناء المنتجات، وتفاصيل إخراج المنتج إلى النور في أسرع وقتٍ ممكن. وتستند آلية عمل الشركة إلى أربعة مبادئ رئيسية: تحديد قواعد اتخاذ القرار توزيع المسؤوليات وضع خارطة طريق بسيطة وشاملة وشفافة تبني ثقافة تحديد الأهداف ولكن تذكر دومًا: هذه الآلية ليست ملائمة بالضرورة لجميع الشركات، فهي تنبع من الثقافة الخاصة بشركة Intercom أما شركتك فلها ثقافتها الخاصة، وهو ما يتطلب آلية عمل مختلفة. هذه الآلية ليست مثالية بأي حال من الأحوال، إذ تعمل شركة Intercom على إعادة صياغتها باستمرار. وربما تكون الشركة قد غيرت هذه الآلية أو جزءًا منها، وأنت تقرؤها الآن. هذه الآلية ملائمة بالنسبة لشركة Intercom في الوقت الحالي، وفي ظل الفريق الحالي (أربعة مدراء مشاريع، أربعة مصممين، 25 مهندسًا) لكنها لم تكن ملائمة عندما كان الفريق أصغر حجمًا، وربما لن تكون ملائمةً أيضًا عندما يتضاعف حجم الفريق. مع ذلك تأمل الشركة من نشر آلية عملها أن تساعد الآخرين على بناء آليات العمل الخاصة بهم. 1. تحديد قواعد اتخاذ القرار تحتاج الشركات إلى وجود مجموعة من القيم التي تؤمن بها وتساعدها على اتخاذ قرارات صحيحة تتفق مع ما تؤمن به الشركة. وتؤمن شركة Intercom بعدد من القواعد المهمة لتحقيق النمو وتوسيع فريق المنتجات: خطوات صغيرة ومتتابعة أفضل من القفزات الكبيرة تؤمن شركة Intercom بأن مسيرة الألف ميل تبدأ بخطوة، لذلك تراها تميل دائمًا إلى اتخاذ أسهل وأسرع وأبسط الطرق التي تقربها من تحقيق الهدف الكلي. وتقسم الشركة جميع مشاريعها إلى إصدارات صغيرة ومستقلة يضيف كل منها قيمة إلى الزبائن. ويسعى العاملون في الشركة دومًا إلى تبسيط الأمور والتحرك بالسرعة، وعدم إهدار الوقت على أمور ليست مهمة. التركيز على المهام اليومية والأسبوعية تسابق شركة Intercom الزمن، فكل يوم مهم ويجب أخذه في الحسبان، لذلك تكلف الفرق العاملة بمهام أسبوعية تنقسم إلى مهام يومية، وبذلك يعرف كل فرد في بداية كل يوم ما الذي يجب عليه فعله، وكيف يرتبط عمله بالهدف الأسبوعي الخاص بالفريق، وكيف يرتبط عمل الفريق بالمشروع الكلي. التعاون وجهًا لوجه تعتقد شركة Intercom أن الأمور تسير على نحو أسرع عندما تُدار وجهًا لوجه، إذ يستطيع شخصان إنتاج أفكار أكثر وعلى نحو أسرع عندما يكونان معًا. نعم، هناك مزايا للعمل عن بُعد، ولكن سرعة وفعالية اتخاذ القرار ليست من بينها. ولهذا السبب تعمل جميع فرق الشركة في مكان واحد، ويمتلك كل فريق منها غرفة عمليات خاصة به. وتسير الشركة على مبدأ إنجاز الأعمال وجهًا لوجه طالما كان ذلك ممكنًا. البُعد عن التعقيد إن استعمال برنامج لبناء برنامج يستغرق في أغلب الأحيان وقتًا أطول من استعمال اللوحة البيضاء وأوراق الملاحظات. لذلك تميل الشركة إلى آلية عمل مبسطة تتضمن استعمال الحد الأدنى من الأدوات البرمجية لإنجاز العمل. وعندما تتطلب إدارة المنتج استعمال كل من Google Docs وTrello وGithub وBasecamp وAsana وSlack وDropbox وConfluence فهناك مشكلة كبيرة للغاية. النتائج أهم من الخطة الخطة مهمة للنجاح، ولكن الأمور لا تسير دائمًا بحسب الخطة، فالخطط تُوضع عادةً وفق البيانات المتاحة، ولكن البيانات تصبح أكثر وضوحًا بمجرد البدء في التنفيذ. وتتسم أفضل الفرق بالقدرة على استيعاب المعلومات الجديدة والتفاعل معها بحسب المتغيرات، والعمل من أجل الوصول إلى ذات النتيجة في ذات الإطار الزمني. 2. توزيع المسؤوليات تعمل شركة Intercom ضمن فرق منتجات صغيرة الحجم يتولى كل فريق منها جزءًا من عمل الشركة، ويتكون كل فريق من مدير مشاريع، ومصمم منتجات، وكبير مهندسين، وما بين مهندسيَن إلى أربعة مهندسين. ولهذا السبب، يجب أن تكون حدود المسؤولية واضحة لدى الجميع، وهو ما دفع الشركة إلى وضع القائمة التالية: إذا لم يكن تحليل المشكلة صحيحًا، فالمسؤولية تقع على عاتق مدير المشروع، إذ يجب عليه التأكد من إجراء بحث وافٍ حول المشكلة. إذا لم يكن التصميم يعالج المشكلة، فالمسؤولية تقع على المصمم، إذ يتوجب عليه فهم البحث والمشكلة. إذا كان التصميم يعالج المشكلة، ولكنه ضعيف أو لا يتوافق مع سياسات الشركة، فالمسؤولية تقع إذًا على المصمم، الذي يجب عليه فهم سياسات الشركة ومبادئها. إذا لم يسلّم المهندس التصميم، أو سلمه متأخرًا، فتلك مسؤولية كبير المهندسين والذي يتوجب عليه فهم المشكلة والتصميم، ووضع خطة دقيقة وملائمة قبل البدء بكتابة الكود البرمجي. إذا كان هناك الكثير من المشاكل البرمجية ومشاكل الاستخدام، فالمسؤولية تقع على عاتق مدير المشاريع إذ الواجب عليه التأكد من إجراء اختبارات واقعية للبرامج قبل إصدارها. إذا كان الفريق يقضي الكثير من الوقت في إصلاح الأخطاء والمشاكل دون إضافة أي قيمة وفقًا لخارطة الطريق الموضوعة، فتلك مسؤولية كبير المهندسين والذي يجب عليه التأكد أن كل مشروع يحسن جودة الكود البرمجي بصفة عامة. إذا لم يكن هناك تقييم واضح لأداء البرنامج، فتلك مسؤولية مدير المشاريع والذي يتوجب عليه تحديد معايير النجاح بوضوح. إذا لم يكن المنتج يوفر حلًا للمشكلة، فتلك مسؤولية مدير المشاريع والذي يجب عليه التأكد من عدم إجراء أي تغييرات ما لم تكن تعالج المشكلة بالكامل. يتسم عمل فرق بناء المنتجات بالكثير من الضبابية، وهو ما يستوجب التعاون والتنسيق لتحقيق أفضل النتائج، ولذلك يجب على الأفراد العاملين في هذه الفرق الجلوس معًا لتحديد حدود المسؤولية تحديدًا واضحًا للغاية. 3. وضع خارطة طريق بسيطة وشاملة وشفافة خارطة الطريق هي خطة المنتجات التي ستبنيها الشركة على مدار الشهور التالية، وهي تتكون من ثلاثة أطر زمنية: 4-6 أسابيع قادمة: مواعيد مؤكدة لإصدار البرمجيات. الشهور القادمة: خطط مصحوبة بمعلومات واضحة ومفصلة حول المشاكل والفرص المتاحة. ما وراء الشهور القادمة: أفكار عامة ترتبط بطبيعة عمل الشركة. تضع الشركة جميع أفكار المنتجات التي قد تبنيها في قائمة واحدة تخضع لإدارة مدير المشاريع، ويطلع عليه بقية أفراد الفريق بانتظام. وتستمد الشركة خارطة طريقها من ثلاثة مصادر أساسية وهي: معتقدات الشركة: لا تستند المعطيات في هذا المصدر إلى البحث، وإنما لآراء العاملين في الشركة وأفكارهم، وخصوصًا فريق إدارة المنتجات. ردود فعل الزبائن: وهناك ثلاثة مصادر لهذه الردود: ردود فعل تسعى الشركة للحصول عليها بواسطة الدراسات التي يجريها فريق البحث، والحوارات التي يجريها مدراء المشاريع مع الزبائن. ردود فعل تطوعية يقدمها الزبائن عبر موقع الشركة، إذ يختار فريق مساعدة الزبائن مئات الحوارات في كل أسبوع ليطلع عليها مدراء المشاريع، وذلك قبل إضافتها إلى قائمة المنتجات التي قد تبنيها الشركة في المستقبل، أو إضافتها إلى خارطة الطريق الخاصة بالشركة. ردود فعل يجمعها فريق المبيعات من واقع حديثه مع الزبائن ويشاركها مع مدراء المشاريع، وذلك حتى يتسنى لهم فهم المعيقات التي تواجه الزبائن عند استعمال منتجات الشركة. وتستعرض كل من إدارة المبيعات والمنتجات خارطة الطريق بصفة شهرية للتأكد من إزالة هذه المعيقات. بيانات نوعية مستمدة من قياس أداء المنتجات الحالية: وهناك مصدران لهذه البيانات النوعية في هذه الحالة: معايير النجاح المحددة في كل مشروع. معايير نجاح المنتج والفريق القائم عليه. وكما يتضح هنا، تُقسم خارطة الطريق إلى أهداف موزعة على الفرق، ويُقسم كل هدف إلى مشاريع متعددة، ويُقسم كل مشروع إلى عدد من الإصدارات البرمجية المنفصلة. وتسعى الشركة من خلال هذه الاستراتيجية إلى تزويد المستخدمين بأكبر قيمة في أسرع وقتٍ ممكن، ولكن هناك سمات استراتيجية تشترك فيها جميع المنتجات، والفرق، والأهداف، والمشاريع. وفيما يلي ملخص لآلية عمل الشركة في جميع هذه المراحل. السمات العامة لاستراتيجية المنتجات تملك شركة Intercom في الوقت الحالي ثماني سماتٍ عامة تلخص عمل الشركة بأكملها، ولهذا السبب وضعت الشركة لوحة لكل سمة من هذه السمات على جدران المكتب. وتحتوي كل لوحة على عنوان السمة، وسبب أهميتها، والمشكلة التي تعالجها، والفرصة التي توفرها، بالإضافة إلى رسومات توضيحية لمفهومها. أهداف الفرق يمتلك كل فريق منتجات هدفًا استراتيجيًا يستغرق بضعة شهور لإنجازه، ويمثل مجموع هذه الأهداف استراتيجية المنتجات العامّة. وصف المشروع وصف المشروع هو عبارة عن وثيقة تقع مسؤولية إعدادها على عاتق مدير المشروع، وهي تتكون من صفحة واحدة فقط لا غير، وتتناول بإيجاز المشكلة، ومعايير قياس النجاح، ونطاق المشروع، ولكنها لا تقترح أية حلول والتي تأتي في مرحلة لاحقة. وتهدف هذه الوثيقة إلى خلق فهم مشترك للمنتج الذي تسعى الشركة إلى بنائه، وسبب ذلك. خارطة الطريق في Trello تتحرك شركة Intercom بسرعة كبيرة، فقد تتراوح فترة إصدار البرمجيات بين يوم واحد وأسبوعين، كما أنها قد تعمل على 5 أو 6 مشاريع، إضافةً إلى عشرات الإصدارات البرمجية في ذات الوقت. ولهذا السبب تستخدم الشركة موقع Trello لضبط إيقاع العمل. ويخضع كل شيء في Trello لمدير المشاريع والذي يخصص بطاقة لكل إصدار برمجي، وتتضمن هذه البطاقة روابط لأعمال التصميم الجارية. ويشير لون البطاقة إلى فريق المنتجات المسؤول عن العمل فيها، إذ تمتلك الشركة خمسة فرق مختلفة. وتخول الشركة فريقًا واحدًا لكل إصدار برمجي، وذلك لتعزيز المسؤولية والمحاسبة، وفي حال وقوع خلل تُوضع علامة حمراء على البطاقة الخاصة بالإصدار البرمجي لمتابعته. بطاقة المشروع في Trello يمتلك كل مشروع بطاقة خاصة في Trello وتضم هذه البطاقة الروابط الخاصة بوثيقة وصف المشروع، وجميع الإصدارات البرمجية في إطار ذلك المشروع، كما أنها تحتوي قائمة مهام للتأكد من عدم نسيان أي شيء. بطاقة الإصدار البرمجي في Trello تخصص الشركة بطاقة لكل إصدار برمجي، وتتضمن هذه البطاقة روابط أعمال التصميم، وجميع الوثائق المساعدة التي توضح المنتج وآليات تصميمه. كذلك تحتوي البطاقة قائمة مهام مقسمة إلى خمسة أقسام وهي: التصميم، البناء، ضمان الجودة، الإصدار التجريبي والكامل، وما بعد الإصدار. 4. تبني ثقافة تحديد الأهداف الأهداف الأسبوعية تسعى الشركة إلى التركيز والحفاظ على مسارها من خلال تحديد أهداف أسبوعية لكل فريق، وتشمل هذه الأهداف إصدار برمجيات وفق خارطة الطريق، أو تقليل عدد الأخطاء البرمجيات، أو تحسين النظام على نحو يمكن الشركة من المضي قُدمًا في المستقبل. ولتحقيق هذه الغاية أنشأت الشركة أداةً أطلقت عليها اسم Hustle وهي تجمع في مكان واحد كلاً من الأهداف، وخارطة الطريق من الواجهة الخاصة بموقع Trello، وكذلك ملخص المشاكل البرمجية المفتوحة في موقع Github. والخلاصة أن الفرق تضع أهدافًا أسبوعية، وتُحاسب عليها. الأهداف اليومية واللوحة البيضاء يضع العاملون في الشركة أهدافًا يومية، وحتى أقل من ذلك، لضمان تحقيق الأهداف الأسبوعية، وهو ما ينبع من اعتقاد الشركة بأهمية كل يوم، لذلك يمتلك كل فريق منتجات في الشركة لوحة بيضاء يستعملها لتسجيل ومتابعة أهدافه اليومية. اللقاءات الأسبوعية في نهاية كل أسبوع يتجمع العاملون في الشركة أمام الشاشة الكبيرة في مطعم الشركة، ويستعرض المهندسون المنتجات التي كانوا يعملون عليها خلال الأسبوع. وتعزز هذه اللقاءات إيمان الشركة بأهمية ضبط إيقاع العمل، فهي في سباق مع الزمن، لذلك تقسّم العمل إلى خطوات يمكن إنجازها خلال أسبوع واحد فقط. هذه الآلية تغيّرت تدرس شركة Intercom آلية عملها وتعدلها باستمرار، إذ يتعلم العاملون في الشركة أشياء جديدة في كل أسبوع. وقد تناول هذا المقال دروسًا لم يكن تعلمها سهلًا أبدًا، ولكنهم استطاعوا الوصول إليها بالمحاولة مرةً بعد مرة، وخصوصًا أن بناء منتج في شركة سريعة النمو يُعد أمرًا صعبًا للغاية. وفي الختام، تأمل الشركة أن يساعدك هذا المقال على تحسين آلية عملك. ترجمة -وبتصرف- للمقال Lessons learned from scaling a product team Rate لصاحبه Paul Adams

قد تساعد هذه النصائح عملك على المدى القريب، ولكن ربما تتركك في غفلة عن البيانات المهمة على المدى البعيد. إذًا، كيف يمكنك الانتقال من مجرد استعراض الأرقام كأي مبتدئ إلى الإجابة على الأسئلة المهمة حول منتجك وشركتك؟ بالأحرى، هل تطرح الأسئلة الصحيحة في المقام الأول؟ ليست جميع المنتجات متشابهة في الأيام الأولى لفريق الإحصائيات في Intercom، انحصر تركيزه -في الغالب- على تتبع المقاييس المالية التقليدية لشركات البرمجيات كخدمة (SaaS)، مثل معدل التحويل لعملائنا من النسخ التجريبية إلى المدفوعة، إضافةً إلى الإيرادات الشهرية المتكررة (MRR). وعلى الرغم من أهمية هذه المقاييس لفهم الملاءة المالية للشركة واستراتيجيتها، إلا أنها تبقى "قاصرة" بالنسبة لفريق تطوير المنتج لأنها لا تجيب على جميع الأسئلة المهمة بالنسبة له، مثل: "هل يجد العملاء هذه الميزة ذات قيمة؟ " أو "ما مدى سهولة استخدام منتجنا؟". وبدون وجود مقاييس إضافية تركز على تجربة المستخدم، سيمتلك فريق الإحصائيات تأثيرًا أقل على القرارات التي يتخذها فريق تطوير المنتج. شرعنا بقراءة ما قامت به الشركات الأخرى. فوجدنا أن الكثير من النصائح عن "أفضل الممارسات المتعلقة بمقاييس المنتج" كانت مفيدة في تقديم المفاهيم، ولكن لا يمكن تطبيقها بصورة موحدة. وإنما يعتمد ذلك على نوع الشركة. فالتفاعل مع تطبيق خدمي للشركات الموجهة لشركات الأخرى بقيمة 99$ سيختلف عنه تمامًا في حالة المتاجر الإلكترونية. المبدأ الأساسي الذي يسير عليه فريق الإحصائيات في Intercom هو "البدء بالسؤال الصحيح". فإذا طبّقنا الأُطُر البالية بشكل اعتباطي، فسننطلق من سؤال شخص آخر، لا سؤالنا. وإذا لم تبدأ المقاييس التي تنتجها هذه الأُطُر بالسؤال الصحيح، فلن يكون لها تأثير على كيفية بناء المنتج أو توجّه الشركة. وبذا تصبح هذه المقاييس عبارة عن مؤشرات زائفة: تبدو جيدة على الورق، لكنها تحرمك من رؤية حقيقية لمستقبل المنتج وجوانب تحسينه. الأخطر من ذلك، هو أن مجموعة المقاييس المخصصة لخدمة شركة كاملة تصبح أقل فعالية مع نمو حجم الشركة. حيث تبدأ الفرق في الاختلاف حيال المقاييس التي تهمها. وعلى الرغم من أن جميعها قد تشترك في مهمة عُليا، إلا أنها تساهم فيها بطرق مختلفة ولذا يجب قياس نجاحها بشكل مختلف أيضًا. ففي حين يركز فريق النمو على المشاركة في جزء معين من المنتج، يركز فريق التسويق على جزء مختلف تمامًا. ما هي مقاييس المنتج؟ مقاييس المنتج هي مقاييس متفق عليها تساعد مديري المنتجات والمسوقين على تقييم نجاح منتجاتهم. تساعد مؤشرات الأداء الأساسية "KPIs" هذه أصحاب القرار في أي مؤسسة على تحديد كيفية تفاعل العملاء مع منتج ما، والقيمة التي يحققها للشركة وكيف يمكن تحسينها. 4 أمثلة لمقاييس منتج من نوع البرمجيات كخدمة (SaaS) توجد العديد من المقاييس التي يمكن لمديري المنتجات الاستعانة بها في قياس نجاح منتجاتهم. فيما يلي بعض الأمثلة على مقاييس التفاعل التي تستخدمها شركات SaaS: متوسط عدد مرات انتقال مستخدم من النسخة التجريبية للمدفوعة. النسبة المئوية لمستخدميّ ميزة محددة. متوسط عدد مرات تنفيذ مستخدم مهمة أساسية. متوسط عدد المهام الأساسية المنفذة في كل جلسة. تبدأ المقاييس الصحيحة بالأسئلة الصحيحة عندما تنطلق معظم الشركات الناشئة، فهي تجهل كيفية طرح الأسئلة الصحيحة قبل بدءها عملية القياس. يتطلب ذلك شراكة تعاونية بين كلٍ من المحللين وفريق المنتجات، بدلاً من العلاقة التقليدية القائمة على المصالح المتبادلة. لتوجيه هذه الشراكة، استلهمنا تجربة غوغل في طرحها إطار عملها (HEART)، والذي يُسدي النصيحة بشأن تحديد مقاييس المنتجات التي تليّ تحديد أهداف المنتج. على سبيل المثال، إليك بعض الأسئلة التي نطرحها على فرق المنتجات لدينا لمساعدتنا على فهم أهدافها، وبالتالي مساعدتها في تحديد المقاييس المهمة: إذا تخيلنا عميلًا مثاليًا حقق فائدة من منتجاتنا، فما هي الإجراءات التي اتخذها؟ ما هي الخطوات التي يتطلبها تحقيق هدف معين (خطوة بخطوة)؟ هل صُممت هذه الميزة لحل مشكلة يواجهها جميع مستخدمينا، أم لقسمٍ منهم؟ 3 نقاط تواصل لتحديد مقاييسك لمساعدة شركاء منتجاتنا في الإجابة على هذه الأسئلة، نستخدم مفاهيم استعمال المنتج التي أصبحت مع مرور الوقت مفهومة جيدًا ويمكن الاعتماد عليها. يمكن أن ترتبط هذه المصطلحات بشكل مباشر بالمحطات الرئيسية خلال رحلة العميل مع المنتج: هدف الاستخدام: الإجراء/الإجراءات التي يتخذها العملاء والتي تخبرنا -بشكل قطعي- بنيّتهم استخدام المنتج/الميزة. التنشيط: النقطة التي يحصل فيها العميل على قيمة المنتج/الميزة الحقيقية. التفاعل: مقدار استمرار العميل في الحصول على قيمة من المنتج أو الميزة (مقدار الوقت وعدد المرات …إلخ). يمكننا -بالاستعانة بهذه المفاهيم البسيطة- أن نبحث عن الإجابات للأسئلة التي طرحناها آنفًا. الخطوة التالية هي البحث عن علامات فارقة بالمنتج/الميزة تدّل على هذه المفاهيم. لقد وجدنا أن التعاون الواضح بين أعضاء فرق منتجاتنا -المديرين والمصممين والباحثين والمهندسين- ينتج عنه العديد من المؤشرات المفيدة التي يمكننا استخدامها لتطوير مقاييس نجاح المنتج. طالما أنك تطرح الأسئلة الصحيحة، ستحصل على رؤى مهمة تعمل بموجبها. باختصار، انطلق من المشكلة لا من البيانات. تطوير المقاييس المهمة لمنتجك على غرار فلسفتنا المتمثلة في "غامر لتتعلم"، فإن تحديد مقاييس نجاح المنتج هو البداية فحسب. ولضمان نجاح الفريق، يجب أن ندافع عنهم، ونتواصل معهم ، وحتى ننتقدهم. تمامًا كما هو الحال مع المنتج الذي نقيس نجاحه، يجب علينا قياس نجاح المقياس. هل المقاييس تعطينا صورة حقيقية عن نجاح المنتج؟ هل تؤثر على طريقة تفكيرنا في المنتج؟ هل تحفز الفريق الذي يبني المنتج؟ هذه هي الأسئلة التي يجب على المحللين طرحها باستمرار حول المقاييس التي ينتجونها ويدافعون عنها ويقدمّون تقارير حولها. أدى هذا النهج التعاوني في تعريف المقاييس إلى وجود علاقة أكثر سلاسة بين فرق التحليل وفرق المنتجات. وبالمثل، فإن استخدام طريقة شائعة ومناسبة للعمل يعني تسهيل فهم أي شخص في المؤسسة لأي مقاييس وماذا تمثل ولما هي مهمة. هذا يعني أن التغييرات التي تطرأ على المنتج يمكن نشرها (أو حتى قيادتها للرؤى المكتسبة من استكشاف البيانات التي تأطّرها هذه المقاييس). مثال عملي: كيف اخترنا مقاييس المنتج لإصدار مهم (مقالات قاعدة المعرفة) شاركت فرق التحليل والمنتج لدينا في هذا المشروع من الفكرة إلى مرحلة الإطلاق. حددت المقاييس في البداية، باستخدام نهج الأسئلة -آنف الذكر- البسيط والواضح. هذا يعني أن امتلاك النسخ التجريبية الأولى للمنتج مجموعة قوية من المقاييس تساعدنا في اختبار فرضياتنا. على سبيل المثال، افترضنا أنه من المهم بمكان فهم كم احتجنا للفت انتباه لصفحة إنشاء المقالات (هدف الاستخدام) إلى جذب انتباهه لتلك المقالات (التنشيط) بكفاءة. إذا تمكن العميل من رؤية القيمة من المنتج بسرعة، فستسهل عملية تحوله من المنتج التجريبي إلى المنتج المدفوع. تشير إحصائيات تفاعل عملاء نسخ الاختبار "Beta" مع الإصدارات المبكرة من المنتج إلى أنه استغرق وقتًا طويلاً للوصول إلى هذه النقطة للعملاء. نتيجة لذلك، بسّطنا المنتج للسماح بتجربة أكثر سلاسة. وهكذا عند إطلاقنا للمنتج النهائي، لاحظنا تحسنًا في معدلات وقت التنشيط في جميع المجالات، وكان لذلك تأثير إيجابي على التحويل الكلي للعملاء من التجربة إلى الدفع. نحن حريصون على استكشاف تصميم أفضل للبيانات. هذه ليست سوى البداية، ولدينا العديد من المجالات للتحسين. ولكن الانطلاق من أسلوب قائم على الشراكة وضعنا على مسار جيد نحو التحول إلى مؤسسة خبيرة بالبيانات بالفعل. ترجمة -وبتصرف- للمقال Finding the metrics that matter for your product لصاحبيه Kevin Mcnally و Nick Odlum