موجز · البودكاست، في دقايق · mujaz.co
موجز · اقرأ النسخة الكاملة والتفاعلية على mujaz.co
الرئيسية ← برودكت ممتاز ← خطأ PayPal في محطات الوقود، قصص لم يتحدث ع…
برودكت ممتاز

خطأ PayPal في محطات الوقود، قصص لم يتحدث عنها أحد، مع هشام إبراهيم

هشام إبراهيم يشرح لماذا تفقد حتى شركة بحجم PayPal تركيزها على العميل، وكيف يدمج Lean Startup وDesign Thinking وJobs to be Done في نموذج واحد: 4D.

⏱ يُقرأ في ١٥ دقيقة
الضيف: هشام إبراهيم · برودكت ممتاز · ١٨ أغسطس ٢٠٢٦ · يُقرأ في ١٥ دقيقة

الخلاصة في سطرين

هشام إبراهيم بدأ مهندسًا في Oracle، ثم قضى سنوات طويلة في product management بسيليكون فالي بين Intuit وPayPal، ويعمل اليوم ضمن فريق Lean Startup Co. يبدأ من فكرة واحدة: الـcustomer empathy ليست task تنجزها ثم تشطبها، بل mindset يبدأ من القيادة. يفرّق بين الـdata والـinsight بقصة زيارات منزلية في PayPal اكتشف فيها الفريق أن ناسًا يخبئون الكاش في بيوتهم، ثم يصحح المفهوم الشائع للـMVP، ويشرح نموذجه 4D: Discovery وDefine وDesign وDeliver. وفي القلب قصتان من PayPal: صفقة مع شركة بترول كبرى لإدخال PayPal في محطات البنزين أوقفتها التجربة مع العملاء، وصفقة Home Depot التي اكتشف فيها أن مديري المنتجات لا يعرفون لماذا يبنون أكبر مشروع في الشركة.

نموذج 4D كما يرسمه هشام إبراهيم

خريطة الحلقة في ٤ خطوات.

النموذج continuous، فيمكن أن تبدأ من أي مرحلة فيه، حتى من Deliver حين يأتي قائد بفكرة مقتنع بها: تجربة سريعة، ثم تدور الحلقة.

Discovery: افهم العميل

عمل الـempathy في أول الطريق: interviews وobservation وحتى surveys. وهنا يدخل Jobs to be Done: يقول للفريق «أنتم job hunters»، ارجعوا بالـjobs to be done في هذا السياق، وبـinsights توضحها.

Define: حدّد المشكلة وجذرها

مرحلة تحليلية خالصة: تفصيص ما رآه الفريق وسمعه حتى يخرج بـproblem statement واضح ومحدد، لا يكتمل إلا إذا حمل الـroot cause، بخمسة مستويات على الأقل من التعمق.

Design: الحل بمعناه الواسع

ليس UX design بل تصميم الحل نفسه. لا يتحرك الفريق قبل خمسين فكرة تحل المشكلة، ثم تُفلتر إلى قائمة قصيرة بأفضلها.

Deliver: إلى السوق بماكينة Lean Startup

اختبار الأفكار بأسرع وأرخص طريقة قبل بناء أي شيء: MVPs وexperiments بحدود نجاح محددة مسبقًا، ثم persevere أو pivot.

لمن هذه الحلقة؟

product manager في بداية الطريق، أو مهندس يفكر في التحولهشام بدأ مسيرته في software engineering قبل أن ينتقل إلى product management، والحلقة تعطيك اختباره للـPM العظيم، وأول سؤال يجب أن تسأله قبل أي حل.
فريق يتجادل: Lean أم Design Thinking أم Jobs to be Done؟يرى أن الصراع بين هذه المعسكرات يعطّل الشركات، ويشرح كيف تضعها كلها في صندوق أدوات واحد، وكيف يرتبها نموذجه 4D خطوة بعد خطوة.
مؤسس عنده فكرة ولا يعرف من أين يبدأ الـdiscoveryكم customer تكلم، وكم تستغرق المحادثة، ولماذا تطلب قصة حقيقية بدل سؤال مباشر، وكيف تفرّق بين الـMVP والمنتج الرديء المتخفّي في اسمه.
قائد في شركة كبرت وبدأت تبتعد عن عملائهاقصتا محطات البنزين وHome Depot في PayPal تريان كيف ينتقل التركيز تدريجيًا من مشكلة العميل إلى إدارة الشركة نفسها، وكيف تعيده تجربة صغيرة مع العملاء.

الأفكار الرئيسية

الـcustomer empathy تبدأ من القيادة3:12 ↗
لتصبح الـcustomer empathy جزءًا صلبًا من ثقافة الشركة، وخصوصًا مع من جاؤوا من خلفية برمجية ويميلون كما يلاحظ حسين إلى البدء بالحل لا بالعميل، يبدأ الأمر من الـleadership، فلا يُتخذ قرار، سواء في المنتج أو التسويق أو المبيعات أو الهندسة، بلا مرجعية للعميل. ويستحضر مثال Jeff Bezos في Amazon الذي يضع كرسيًا فارغًا على طاولة الاجتماع ويقول لفريقه إن العميل جالس معنا، فلنأخذ قراراتنا على هذا الأساس.
الـcustomer empathy عند هشام ليست task تذهب وتنجزها ثم تكتب «تمت»، بل mindset. يظهر ذلك في أبسط موقف: حين يعرض عليك أحد فكرة، ردّك الطبيعي يكون «احكِ لي قصة أو قصتين عن عملاء أوصلوك لهذه الفكرة». لا بد أن يكون العميل دائمًا على لسانك، وكأنه جالس بجوارك.
يطبّق هشام ما يسميه customer storytelling في كل مراحل الـproduct lifecycle، من فكرة وليدة إلى منتج عمره عشرون عامًا في السوق: كل ما فهمه الفريق عن عميل يُصفّى في قصة باسم شخص حقيقي، حتى في منتجات الـB2B، لأن داخل كل مؤسسة بشرًا هم من سيستخدمون المنتج. والسبب: حين يعطيك أحد أربع أو خمس نقاط تنساها، أما القصص فلا تُنسى.
يربط هشام القصص بفكرة الثقافة نفسها: في مجتمعاتنا نتوارث القصص من أجدادنا، وكل جيل يحكي القصة للجيل الذي بعده، وهكذا تتكون الثقافة. لذلك نصيحته العملية للمكاتب: كلما تعرفتم على عميل، خذوا صورته واكتبوا قصته وعلّقوها على الحائط حتى يبقى حاضرًا في البال دائمًا.
بدأ هشام مسيرته في software engineering، من مبرمج إلى مدير فرق هندسة وQA. التحول حدث في Intuit: كانت الـrequirements تصله من مديري المنتجات، فيسأل في كل مرة من الـtarget customer؟ وما المشكلة التي فهمتموها منه؟ واكتشف أن عمل المنتج لا يُدار كما ينبغي: أشياء سمعوها من عميل أو قالها الـVP فوُضعت في الخطة. ضاق بالعمل على أشياء لا يفهم لماذا تُبنى، فقرر أن ينتقل إلى الناحية الأخرى ويحاول إصلاح المشكلة في ثقافة Intuit.
متى نفهم العميل بما يكفي؟ عند هشام شقان. الأول: لن يكون الفهم كافيًا أبدًا، لأنه mindset يجب أن يتطور مع السنين. والثاني: هذا لا يعني ألا نبدأ العمل، فهنا يدخل Lean Startup بوصفه continuous experimentation: نقول «فهمنا كفاية لهذه اللحظة»، ثم ندخل حلقة Build, Measure, Learn التي لا تنتهي. وشكل الـempathy يتغير حسب المرحلة: discovery لفكرة جديدة، أو قياس الـKPIs لمنتج في السوق لنعرف إلى أي مدى حل المشكلة.
يعتمد هشام قاعدة يقول إنه تعلمها من دراسة لشركة أبحاث قرأها قبل سنين: بعد عدد معين من المقابلات يبدأ ما يسمى diminishing returns، والشرط أن تكون ثماني مقابلات على الأقل مع أشخاص يطابقون الـtarget customer profile بالضبط. لذلك يجري مع فرقه نحو اثنتي عشرة مقابلة ليبقى هامش أمان، لأن واحدًا أو اثنين أو ثلاثة غالبًا لا يتعلم الفريق منهم ما يكفي. وإن ظهر pattern في ثمانية منهم أمكن القول بثقة عالية إنه ينطبق على هذا الـsegment. ومدة المحادثة عنده ساعة ونصف.
قبل أن تدخل أي مقابلة يجب أن تحدد بالضبط ماذا تريد أن تتعلم. ثم يأتي الخلط الأكبر: كثيرون يعرضون عليه «الـinsights التي تعلمناها من مقابلات الأسبوع الماضي»، فيجد أغلبها ليس insights بل data: العميل قال إنه يحتاج كذا، أو رأيناه يفعل كذا. الكلمة تتداول بسهولة، لكنها غير مفهومة جيدًا.
أثناء عمله مع فريق الـwallet في PayPal أرسل هشام الفريق، مقسمًا إلى ثلاثة فرق صغيرة، في home visits إلى بيوت أمريكيين ممن يعيشون paycheck to paycheck، لأنه يحب أن تتم المقابلات في سياقها الحقيقي. عادت الفرق الثلاثة بالملاحظة نفسها: الناس يحتفظون بكميات كبيرة من الكاش في بيوتهم، تحت المرتبة، في خزنة، في ظرف داخل الكومودينو، وأحدهم في الفريزر. سألهم: لماذا؟ فلم يعرف أحد. ورأوا الأمر غير مهم: «إحنا PayPal ديجيتال، مالناش دعوة بيهم».
هنا غضب هشام، لأن عنده قاعدة يعلّمها للناس: حين ترى behavior يفاجئك ولا يركب في دماغك، فغالبًا وراءه opportunity. فأعاد الفرق لزيارة عملاء آخرين بمهمة واحدة: إن رأيتم هذا السلوك مرة أخرى، افهموا لماذا.
يقسم هشام كلمة insight نصفين. الـsight هو ما رأيتموه وما قاله لكم الناس. أما الـin فهو ما يدور في دماغهم أو قلبهم ويبرر هذا السلوك. إذا استطعتم أن تبنوا causal relationship بين ما يدور بداخلهم وبين السلوك، فقد اكتشفتم actionable insight، أي شيء تستطيع أن تبني عليه، لا مجرد ملاحظة.
في الجولة الثانية سأل الفريق أسئلة أعمق، فظهر السبب الرئيسي: الناس يحتفظون بالكاش ليوفّروا. حكت إحدى العميلات أنها حين تذهب لشراء شيء تحتاجه، كبنطلون المدرسة لابنها، تجد لافتات الخصم في كل مكان، ومع الكارت تشتري فوق طاقتها. أما لو اضطرت للعودة إلى البيت لتأخذ الكاش فستفكر مرتين، وبينها وبين زوجها اتفاق: لا تُصرف هذه الفلوس إلا بموافقة الطرف الآخر، فتختفي لحظة الاندفاع. وقال للفريق إن هناك عشرين سببًا محتملًا: الأمان، أو قلة الثقة في البنوك، أو صندوق للطوارئ، وكل سبب يقود إلى اتجاه منتج مختلف. بعد فهم السبب صار ممكنًا التفكير في features داخل الـwallet تساعدهم على تحقيق الـoutcome الذي يريدونه.
الـframeworks مثل Lean وDesign Thinking وJobs to be Done عقّدت الشغلانة فعلًا، والدنيا تعقدت، وفي الشركات التي يعمل معها politics داخلية: مجموعة تناصر Design Thinking وأخرى تناصر Lean Startup، فيتعطل العمل ولا تُستخدم أي منها كما يجب. لذلك يبتعد عن الـbuzzwords، ويقول للفرق ما يجب فعله: نفهم العميل، نحدد المشكلة، نخرج بحل، نجربه في السوق. تخيّل صندوق أدوات واحدًا أفرغت فيه أدوات الثلاثة، ومع الخبرة تختفي الحدود بينها تمامًا، فهي في النهاية طريقة تفكير تكمّل بعضها.
يرى هشام أن Eric Ries «لم يُوفَّق» في تسمية الـMVP، لأن الأغلبية تفهمه على أنه أول إصدار أو الـinitial prototype الذي يُطرح في السوق. الـMVP عنده أي شيء يتيح لك أن تُجري experiment مع العميل: إيميل، أو landing page نظيفة تشرح الـvalue proposition وفيها زر «Sign up»، أو واجهة منتج ليس وراءها شيء. ويضرب مثلًا بـZappos التي صوّر مؤسسها الأحذية في محلات قريبة ونشرها على موقع، وحين يأتيه طلب يشتري الحذاء ويشحنه بنفسه. ويُذكر في الحوار أيضًا Dropbox التي كان الـMVP عندها فيديو. الأهم أن تعرف ماذا تختبر: الأسئلة التي تحتاج إجابات، والـhypotheses التي يجب أن تُختبر.
ميزة Lean Startup عنده أنه process علمي لا يترك مجالًا لرأي أحد، ولا حتى رأي الـfounder. قبل أي experiment تحدد مسبقًا النتيجة التي تتوقعها والحد الذي يجعلك تكمل، وحسب النتيجة تختار: persevere فتكمل، أو pivot فتغيّر شيئًا في الـbusiness model أو المنتج أو الـtarget customer أو السوق، أو تترك الاتجاه حين يضيع الأمل. وحين ذكر حسين أنه يستخدم مع فريقه ترتيب الافتراضات في dependency tree تبدأ بالافتراض الأخطر، قال هشام إن Eric Ries يسمي هذه الافتراضات Leap of Faith Assumptions، اختصارًا LOFA، وإن فشلها لا يعني بالضرورة أن الـvision خطأ، بل ربما الطريق.
افتراض آمن به الناس في PayPal ثم ثبت خطؤه بدأ من تحدٍّ كان هشام يواجهه هناك: كثير من الأفكار الكبيرة لا تأتي من فريق المنتج بل من فريق الـstrategy الذي يعقد صفقات ثم يقول لفرق المنتج: وقّعنا، اذهبوا ابنوا. اتفق هذا الفريق مع إحدى أكبر شركات البترول، رفض هشام ذكر اسمها، على إدخال PayPal في محطات البنزين، وطُلب من فريق المنتج بناء تجربة PayPal هناك. قال لهم: نطبّق ما تعلمناه. فذهبوا إلى المحطات وأجروا discovery وبعض التجارب مع المستهلكين، وظهر بالـevidence والـdata أن أحدًا لن يستخدم PayPal في محطات البنزين. توقف المشروع، واستجابت الشركة لأنهم أروها data وفيديوهات: كلام مبني على سلوك، لا على رأي.
في مرحلة Define يجلس الفريق ليفصّص ما رآه وسمعه، ويخرج بـproblem statement أو أكثر. والـproblem statement عند هشام لا يُعد problem statement إن لم يحمل الـroot cause، لأنه يريد حلًا يعالج السبب لا الأعراض، ومعظم المنتجات في رأيه تعالج الأعراض. والـroot cause analysis تحتاج النزول خمسة مستويات على الأقل، وكثير من الفرق يقف عند المستوى الثاني أو الثالث: إما لأنهم لم يسألوا، أو لأن الخبرة تنقصهم ليعرفوا ما يعد root cause، أو لأنهم محرجون من التعمق مع العميل. وحينها يعيدهم إلى عمل الـempathy من جديد.
بعد Define يكون الحل في دماغ الفريق غالبًا، وهم متحمسون للبدء. هشام لا يدعهم يتحركون قبل أن يخرجوا بخمسين فكرة تحل المشكلة، ثم تُفلتر الخمسون حتى تبقى قائمة قصيرة بأفضلها. السبب: عمل الـproblem definition ليس سهلًا ولا يجب أن يضيع، وكثيرًا ما يكتشف الفريق بعده أنه كان سيحل مشكلة أخرى تمامًا. ويفسّر الاستعجال بأن عقل الإنسان لا يحب الـuncertainty، فيقفز إلى أول حل ليخرج منها.
توقف هشام عن تسمية المقابلات interviews، لأن الكلمة في أذهان الناس تعني قائمة من عشرة أسئلة تُشطب واحدًا بعد الآخر، والابتكار لا يأتي بهذه الطريقة. صار يسميها customer conversations يفتحها بأربع أو خمس triggers، وتقوم كلها على الـstorytelling. السبب: الناس يكذبون دون أن يقصدوا، لأنهم ينسون أو يخجلون أو يريدون أن يكونوا لطفاء. فبدل أن تسأل «كيف تدفع فواتيرك؟» وهو سؤال واسع ستأتي إجابته سطحية، اطلب: «احكِ لي عن آخر فاتورة دفعتها، من أول ما وصلتك حتى دفعتها، خطوة بخطوة»، وخذ ثلاث أو أربع قصص من الشخص نفسه. والأسئلة الأخرى open ended دائمًا، لا yes أو no، وفي المحادثة كلها يتكلم العميل وتكتفي أنت بأقل القليل.
للموازنة بين gut feeling لا تدعمه الـdata وبين الالتزام بالـprocess، نصيحة هشام في كلمة: جرّبها، فهذه ميزة Lean Startup، والـMVP هو أسرع وأرخص طريقة لتجرب الفكرة أو الـhypothesis الرئيسية التي تقوم عليها. ولأن نموذجه continuous، يمكن أن تبدأ من أي مرحلة فيه، حتى من Deliver: مع قائد مقتنع بفكرة بلا أي discovery يقول له «لنحدد ثلاثة أو خمسة أيام نجري فيها experiment، وإن نجحت ندور الحلقة». الـgut feeling مهم، لكن أن تبني منتجًا كاملًا شهرًا أو ثلاثة عليه وحده مخاطرة كبيرة.
جاء به إلى PayPal رئيسه Sam Shrauger، وكان يومها يقود global product، وقال له في حواراتهما قبل العرض إن أكبر مشكلة عنده أن فرق المنتج «باصّين تحت رجليهم»: لا vision، وتنفذ ما يُطلب منها. حين وصل وجد المنظمة كلها منشغلة بمشروع استراتيجي واحد: صفقة كبيرة مع Home Depot، سلسلة محلات home improvement الضخمة، لإدخال PayPal في الـpoint of sale، وكانت أول مرة تفكر فيها الشركة في الانتقال من online إلى offline. جلس مع عدد من مديري المنتجات كلٌّ على حدة، وسألهم من الـtarget customer وما المشكلة التي يحلها المشروع، فلم يعرف أحد. ومن أسئلته: «احكِ لي عن آخر عميل تكلمت معه». كانوا يعملون على أكبر مشروع في الشركة ولا يفهمون لماذا يبنونه.
كان جديدًا ولا يستطيع أن يقول للـVPs إن المشروع فاشل، فانتظر فرصة. سمع أن مجموعة من الـVPs قضوا أسابيع يتجادلون على اسم feature تتيح الدفع في المحل برقم التليفون المرتبط بحساب PayPal بلا كارت. أغضبه ذلك لأن هذه ليست وظيفتهم، ولأن اسم الـbrand لا يُخترع في غرفة اجتماعات. قال لسام إنه يريد أن يعزمهم هو على الغداء ليكلمهم في الأمر، فوافق سام، واستأجر فانًا، وأخذهم إلى أقرب فرع Home Depot لمقر الشركة في San Jose، ومع كل منهم sticky notes بالأسماء التي يتجادلون عليها ليعرضوها على المتسوقين. الصدمة لم تكن أن أي اسم لم ينجح، بل أن المستهلكين قالوا: لن نستخدم هذه الـfeature أصلًا، ما قيمتها؟ وفي طريق العودة كانوا صامتين في الفان.
أكبر درس خرج به من PayPal أن حتى شركة بحجمها يمكن أن تشتغل شغلًا صحيحًا. فالمشكلة لا تبدأ في البداية: PayPal بدأت startup ناجحة لأنها اكتشفت مشكلة كبيرة ومؤلمة وعرفت عميلها. المشكلة تأتي حين تكبر الشركة، وتتعدد المجموعات والـfunctions، وتصل إلى IPO ويصبح هناك shareholders، فينتقل التركيز تدريجيًا، ومن غير أن يشعر أحد، من العميل ومشكلته إلى إدارة الشركة نفسها.
أول نصيحة لمن يعمل في product management: لا تغترّ بأن الناس يسمونك product owner أو «CEO المنتج»، لأن لهذه الألقاب تبعات توحي بأن الـPM هو من يقرر كل شيء. في Intuit، حين طُلب منه رفع مستوى product management، صمم تقييم أداء مديري المنتجات كاستبيان بالسلوكيات المتوقعة منهم، يُرسل إلى شركائهم في engineering وdesign وmarketing بوصفهم «عملاء» الـPM، لأن طريقة تقييم الموظف تحدد سلوكه. الـPM التقليدي يفهم العميل وحده ثم يكتب الـrequirements، والأفضل أن يكون الفريق معه في عمل الـempathy من أوله ليشعر به كل واحد بنفسه.
اختبار هشام لأي فريق لا يعرفه: يدخل اجتماعهم وهم يناقشون قرارًا، فإن لم يستطع أن يحدد من فيهم الـproduct manager لأن الجميع يتكلمون بالطريقة نفسها، فقد نجح الاختبار. ويحكي أن مصممًا كان يعمل معه حضر ندوة عن المنتجات في Intuit وعاد يقول إنه ظن المتكلمين، وهم مصممون ومهندسون، مديري منتجات. فقال له هشام: هذا هو الصح، فالـPM عندهم ناجح. ونصيحته الثانية: العميل، العميل، العميل، ستشدك أشياء كثيرة أخرى، فاترك له دائمًا كرسيًا معك.
لو جاءه شاب من العائلة يريد أن يصبح product manager، أول ما سيخرج منه تلقائيًا: لماذا؟ لأنه يريد أن يفهم أولًا المشكلة التي يحاول حلها. ثم الإجابة المباشرة: اكتشف مشكلة تستحق أن تُحل. ويستشهد بمقولة شائعة تُنسب إلى أينشتاين: لو أُعطي عشرة أيام لحل مشكلة لقضى التسعة الأولى في فهمها. كثيرون يشعرون أن الوقت الذي لا يُبنى فيه شيء وقت ضائع، لكن الـproblem definition في رأيه مرحلة تحليلية لا يستطيع أن يصف قيمتها، وفي الحوار أن كل دقيقة تُقضى فيها عائدها كبير.
حين كان يلعب الكرة في عشريناته، أقام منتخب البرازيل معسكره قبل كأس العالم 1994 في Los Gatos بكاليفورنيا. زميل له في العمل كانت أمه في مجلس البلدية، فحصل على إذن بقضاء أسبوعين مع المنتخب: يترك العمل مبكرًا ويحضر التدريبات والمباريات ويتغدى مع الجهاز، وكان يعرف المدربين لأنهما دربا منتخب الكويت حيث عاش. ويتذكر أن مسؤول المعدات قال له وهما في الطريق إلى مباراة ودية: «خلي بالك من الشاب ده، هيبقى أحسن لاعب في الدنيا»، وكان الشاب رونالدو.

خطوات عملية تبدأها اليوم

خطواتك أنت، كل خطوة موصولة بدقيقتها.

  • حين يعرض عليك أحد فكرة، اطلب منه قبل أي نقاش قصة أو قصتين عن عملاء حقيقيين أوصلوه إليها 4:49 ↗
  • بعد كل لقاء مع عميل، اكتب قصته باسمه وصورته وعلّقها حيث يراها الفريق 7:28 ↗
  • خطط لثماني محادثات على الأقل مع أشخاص يطابقون الـtarget customer profile بالضبط، واحجز نحو اثنتي عشرة ليبقى هامش أمان 14:36 ↗
  • إذا رأيت سلوكًا يفاجئك أثناء الـdiscovery فلا تتجاوزه: ارجع واسأل لماذا يحدث 19:10 ↗
  • بدل «كيف تفعل كذا؟» اطلب: «احكِ لي آخر مرة فعلت فيها كذا، خطوة بخطوة»، واترك الكلام للعميل 49:41 ↗
  • لا تقبل problem statement لا يحمل الـroot cause، وانزل خمسة مستويات على الأقل قبل أن تتوقف 42:14 ↗
  • قبل اختيار الحل، أخرج خمسين فكرة ثم فلترها، بدل أن تقفز إلى أول حل 44:54 ↗
  • قبل أي experiment، اكتب النتيجة التي تتوقعها والحد الذي يجعلك تكمل أو تعمل pivot 33:12 ↗
  • إن جاءت فكرة من صفقة أو من رأي قائد، اختبرها مع العملاء في مكان الاستخدام نفسه قبل أن تبني 37:54 ↗
مذكور في الحلقة (١٠)
  • The Lean Startup · Eric Ries · مصدر مفهوم الـMVP والـLeap of Faith Assumptions (LOFA) · ٣٤:٥١
  • Jobs to be Done · Clayton Christensen · رشّح كتابه عنها، وقال إنها غيّرت طريقة تفكيره في فهم العميل · ١:١٣:٥١
  • Design Thinking · أحد الثلاثة التي دمجها في نموذج 4D · ٢٣:٥٨
  • كرسي Jeff Bezos الفارغ في Amazon · يمثل العميل في كل اجتماع · ٣:٥٥
  • Zappos وDropbox · مثالان على MVP ليس منتجًا مكتملًا: موقع بصور أحذية، وفيديو · ٢٩:٢٠
  • PayPal في Home Depot · الدفع في المحل برقم التليفون، الصفقة التي حكى عنها · ٥٦:١٤
  • Paul English، مؤسس Kayak · صاحب أفضل نصيحة وصلته: Just do it، وعمل معه في Intuit · ١:١٦:٠٢
  • بودكاست Eric Ries · بودكاست يستضيف فيه Eric Ries مؤسسين، ينصح به · ١:١٥:١٩
  • Canva · آخر product أعجبه، صمم به حتى بطاقة عمله · ١:١٣:٢٢
  • السيرة الذاتية للفنانة نادية لطفي · ترشيحه خارج عالم المنتجات · ١:١٤:٤٨

اقتباسات تستحق الحفظ

"الـcustomer empathy مش task يروح يتعمل وتـcheck: خلاص إحنا عملنا كده. هو في الأساس mindset."
"حد يديك أربع خمس نقط هتنساهم، لكن القصص ما بتتنسيش."
"لما تشوف behavior يفاجئك ومش راكب في دماغك، غالبًا بيبقى وراه opportunity."
"انتوا شفتوا حاجة وقال لكم حاجة: ده sight. الـin بقى هو اللي في دماغهم أو في قلبهم، اللي بيبرر الـbehavior."
"الـframeworks دي بالنسبة لي طريقة تفكير، مش مسألة هنا تستعمل Design Thinking وهنا تستعمل Jobs to be Done."
"مافيش حاجة اسمها شغالين على الـMVP وبعد تلات شهور هنطلّعه، انت هتعمل ١٠٠ MVP."
"الـproblem statement اللي ما فيهاش الـroot cause مش problem statement."
"معظم الحلول والـproducts بتـaddress الأعراض، مش الـroot cause."

الموجز ده كان مفيد؟

موجزات تانية هتعجبك

١:١٣:٢٤
برودكت ممتاز

كيف تتم صناعة القرار داخل شركة «طلبات»؟ مع إسلام أمين

⏱ ١٨ دقيقةبرودكت ممتاز·اتخاذ القرار، القيادة والإدارة
١:٠٧:٢٢
برودكت ممتاز

لماذا تفشل أطر العمل الإدارية الجاهزة في أغلب الشركات؟ مع نادين منصور

⏱ ١٤ دقيقةبرودكت ممتاز·القيادة والإدارة، المسار المهني
النشرة

متفوّتش أي موجز جديد.

اشترك، ونبعتلك كل موجز جديد أول ما ينزل على إيميلك. من غير إزعاج.

بنحترم خصوصيتك، تقدر تلغي الاشتراك في أي وقت.
تمام! سجّلنا إيميلك، هنكلّمك أول ما ينزل موجز جديد.
هذا الموجز من إنتاج «موجز» بالذكاء الاصطناعي مع مراجعة تحريرية بشرية، وهو دعوة للاستماع لا بديل عنه.
كل الحقوق للمصدر الأصلي: الحلقة كاملة على قناة برودكت ممتاز ↗
💡 اقترح حلقة