[נעימת פתיחה]

רן: שלום לכולם, אני רן ארז ואתם הגעתם לפודקאסט שבו אנחנו מדברים עם מנהלי ומנהלות מוצר מחברות שונות על בעיות מוצריות שנתקלו בהן, איך הן ניגשו לפתור אותן ומה הלמידות שהיו להן בדרך. ובפרק של היום נדבר על הבעיה המוצרית הבאה. איך מוודאים שהמוצר שלנו מתפתח בהתאם ל-Scale של החברה? ומי שתספר לנו על ההתמודדות שלה עם האתגר היא מיכל פרנקל, Senior Product Manager במאנדיי. היי מיכל, מה שלומך?

מיכל: היי רן, איזה כיף להיות פה.

רן: ממש ממש כיף שאת איתנו ונראה לי אתגר ממש מעניין, אבל לפני שאנחנו ככה צוללים לכל הפרטים, תספרי לנו קצת קונטקסט עלייך ועל מה שאת עושה במאנדיי.

מיכל: מגניב. טוב, אז אני מיכל, כמו שכבר ציינת, מנהלת מוצר בעצם לצוות הבורדים, שזה צוות פלטפורמי במהותו. זאת אומרת שחלק מהעבודה שלנו זה בעצם לבנות את כל חלקי הלגו שמרכיבים את המוצרים שנמנים על גבי הבורדים, בין אם זה CRM, כמו ירון קימחי כבר סיפר, או מוצרים אחרים שנבנים על גבי מאנדיי. והתפקיד שלנו היא באמת לוודא שהמוצר באמת פוגש את כל ה-use cases -ים השונים, את כל הצרכים השונים, שבעצם המוצרים השונים מביאים איתם.

רן: אוקיי, אז ממש היכולת הזאת שאפשר יהיה לבנות כל מוצר על גבי מאנדי, זה בעצם הצוות שלך.

מיכל: לגמרי.

רן: אוקיי, מעולה. אז נראה לי שהבנו את הקונטקסט, אבל בואי ננסה להגדיר כזה קצת יותר טוב מה הייתה הבעיה ולמה זה רלוונטי למאזינים והמאזינות שלנו?

מיכל: אז אני אגיד שאחד הדברים שבאמת אנחנו פוגשים הרבה וגם הרבה חברות פוגשות, זה באמת המוצר גדל, המוצר מתפתח, מביאים עוד אנשי מרקטינג, עוד אנשי סיילס, באמת יש אקו סיסטם שלם שתומך Scale, אבל אז בסוף המוצר שלנו הרבה פעמים לא משתנה בהתאם לScale שנדרש. זה ממש עניין של איך אנחנו עדיין מייצרים את הקסם הזה שנקרא Monday, שהוא Optimized לצוותים קטנים, אבל שאפשר למצוא בו ולייצר בו Workflows לצוות שלי ואני כיוזר קצה, ובמקביל גם לנהל תהליכים הרבה יותר מורכבים, פתאום מנהלים נכנסים לפלטפורמה. אז זה באמת היה אתגר ממש גדול, ואני חושבת שהרבה חברות פוגשות אותו בסופו של דבר, כשהן מבינות שהן צריכות קצת להתבגר. כאילו הם עשו מוצר, עובד, פגשו Product Market Fit, עכשיו הגיע השלב לעשות Scale. צריך שנייה לבוא ולשאול איך אנחנו פוגשים את המוצר בעוד שנתיים קדימה, איזה יעדים אנחנו רוצים לעצמנו, ואיך אנחנו גוזרים מוצר ותשתיות שיפגשו את הדבר הזה.

רן: אני חושב שהנקודה המרכזית בבעיה הזאת זה ש-Scale זה לא רק מהר יותר. Scale זה שינוי מחשבה שאומר- המוצר עצמו והדרך שבה משתמשים השתנתה. זה עדיין אותם יכולות אולי, זה לא רק שצריך אותם יותר מהר, אלא גם ממש צריך לחשוב עליהם אחרת. יש דברים שפתאום, גם אם הם יעבדו הכי מהר בעולם, זה לא טוב, זה לא עוזר לנו. ואני חושב שזה בעיה שהרבה מנהלים מוצר נתקלים בשאלה של אוקיי, גדלנו, מצאנו product market fit, אבל יש friction, מתחיל להיות friction מול הלקוחות, מתחילים להיות באגים, מתחילים להיות אסקלציות, זה נראה לי סופר מעניין, והייתי שמח שתסבירי לנו קצת איך בכלל ניגשים לאתגר כזה ענק? נשמע לי מלא דברים, גם לשכנע שזה חשוב, גם בכלל להתחיל את זה, אז הייתי רוצה לדעת קצת איך את לקחת את זה.

מיכל: הדבר באמת הכי חשוב שעשינו זה קודם כל למפות את הבעיות, ולהבין מי היוזרים, ומה ה- הכי basic, או למה there are jobs to be done, מה I'm failing to execute. זה במובן העמוק שזה, זה לא רק להגיד- אוקיי, הם מחפשים משהו, והחיפוש הזה לוקח 20 שניות, אז בואו נשפר את החיפוש. זה לא ברמה ה- flat הזו. זה להבין שפתאום הם פוגשים, הם רוצים למצוא את המשימות שלהם, הם רוצים למצוא את המשימות שלהם כמה שיותר מהר, אבל פתאום יש הרבה יותר צוותים שעובדים ומייצרים משימות. אז אולי שווה לבנות יכולות שיתאימו יותר לעבודה בצוותים? יכול להיות שאולי לא בנינו את החיפוש נכון ככה שהם ימצאו כמה שיותר מהר את מה שהם צריכים למצוא? זאת אומרת, בסופו של דבר, אני חושבת שה-scale הפגיש אותנו מחדש עם הצורך למפות את היוזרים שלנו ומה הם מגיעים לעשות בתוך המערכת בקונטקסט החדש הזה שהם מביאים איתו. עוד צוותים, עוד אנשים, עוד יוזרים, בורדים הרבה יותר גדולים, Workflows הרבה יותר מורכבים. אז זה היה השלב אחד. קודם כל, לבוא ולהגיד מי היוזרים, מה ה-jobs to be done שלהם, אבל שניה לנקות את כל הדברים שאנחנו מכירים מ- Monday היום. 

רן: איך את עושה את זה לא flat? כי באמת כשאמרת, אוקיי, החיפוש לוקח 20 שניות, אני אעשה את החיפוש מהיר, ואמרת: לא, לא, לא, רגע, זה רמה שטחית. אז בואי ננסה להעמיק בזה. מה זה נקרא הרמה העמוקה של לחשוב נגיד על הדבר הזה?

מיכל: אז הרמה העמוקה של לחשוב על זה, זה להבין קצת מה האינטנט שלהם. למה הם חיפשו? למה הם לא מצאו ישר את מה שהם צריכים למצוא? למה לא נתתי להם שניית ה-TLDR? הנה המשימות שלכם היום. מה בפלטפורמה שאני בניתי, לא אפשר להם לעשות את מה שהם באו לעשות כאן. ואני חושבת שזה העניין, העניין הוא לא להסתכל על דברים שעד עכשיו היו ופשוט לשפר את הפרפורמנס שלהם, אלא לקחת את כל ה-user journeys ואת כל הפרסונות השונות במערכת, ושנייה להסתכל על זה מחדש, לקחת צעד אחורה, ולהבין איך אני בונה להם פלטפורמה טובה שמתאימה למה שהם צריכים. 

רן: אוקיי, אז נגיד, אני עכשיו, כשהיינו נגיד אולי קצת יותר קטנים, אז מישהו אומר, אוקיי, אני אחפש את המשימות שלי, חיפשתי מצאתי את המשימות שלי, אבל עכשיו כשאנחנו מסתכלים על צוות ענק, זה לא הגיוני להמשיך לחפש בצורה הזאת, הוא בעצם רוצה את המשימות שלו, הוא לא רוצה לחפש את המשימות שלו. זה בדיוק דברים בסגנון הזה?

מיכל: לגמרי. אני חושבת שגם במאנדיי בשנה האחרונה הוקם צוות פרודקטיביטי, למשל, בדיוק מהסיבה הזו. זה צוות שהתפקיד שלו בא ואומר- אני עכשיו מבין שיש יוזרים, יוזרים קצה בתוך ארגון גדול ואני עכשיו רוצה לתת להם את הvalue של למצוא כמה שיותר מהר את מה שהם מחפשים. זה פתרון לפתור 20 שניות חיפוש, זה צד אחד של המטבע. אבל לבוא ולייצר כ-Essence, כ-ערך, לבוא ולתת פרודקטיביות עם כל הכלים שזה מביא איתו, לייצר אפילו במקום שיוזר יצטרך לחפש, אז ליצור לו איזשהו מקום שבו יש לו את כל המשימות שלו. זה פתרון. זה פתרון שפוגש   Scale, לחפש. אם אני צריכה עכשיו לחפש בתוך מיליון משימות את המשימות שלי, זה מצביע על איזושהי בעיה. כאילו, כי לא חשבנו על היוזר ומה שהוא מנסה לעשות, אלא פשוט נתנו לו דאמפ של משימות שהוא היה צריך למצוא את עצמו בתוך הסיפור הזה. וגם היינו מספרים את החיפוש לשנייה, לשלוש שניות, עצם זה שהוא היה צריך לבוא ולחפש אותם בכלל, ולא שמנו לו את זה, ואמרנו הנה הן, זו הבעיה.

רן: מעולה, אז אני חושב שאנחנו ניגע עוד מעט באמת בנושא הזה של גם אם שיפרנו מ-20 שניות לשנייה, זה לא באמת משנה משהו בעולם האמיתי ספציפית, אבל מעניין אותי רגע עדיין להישאר בשלבים. אז שלב ראשון, את אומרת רגע, בוא נמפה מה אנשים בכלל מנסים להשיג עכשיו כשאנחנו חושבים על Scale. מה עוד? 

מיכל: אז מעולה, אחרי שניסינו להבין מה ה-Jobs to be done ומה האנשים מנסים להשיג, אז השלב הבא היה לפרוש את זה בעצם על איזה שהיא, לעבוד עם ה-Engineering, להבין מה הדרישות ברמת ה-KPI'S, זאת אומרת שאנחנו רוצים לתת, או אם יש לנו נגיד מוצרים חדשים שחסרים לנו אל מול הדבר הזה, או יכולות חדשות שחסרות לנו אל מול הדבר הזה שהם מנסים להשיג, ואז לבוא לאנג'יינג ולהגיד רגע, תקשיבו, אלה ה-requirement בעצם שאנחנו רוצים מהתשתית הזאת, ככה אנחנו רוצים שזה יעבוד. ואז השלב הבא הוא לשים את זה באמת על איזה שהוא רודמפ, זאת אומרת, מה אנחנו פוגשים מחר בבוקר? ה-PFS, לשפר את הפרפורמנס, שה-20 שניות האלה שתיארתי מקודם, באמת יעבדו תוך שנייה, כי אנחנו, יהיה לנו קשה לייצר את המוצר החדש הזה תוך רגע, ולהבין איך הוא נראה, אז לפחות שנייה ב- PFS שזה יעבוד, שזה יעבוד כמו שצריך. בשלב הבא היה להגיד, רגע, אוקיי, אז אנחנו מייצרים עוד Building Blocks נוספים, או מייצרים עוד יכולות נוספות, איפה התשתית צריכה לעמוד, באיזה יכולות התשתית צריכה לספק לנו עכשיו, ואיפה היא צריכה לפגוש אותנו בעוד שנתיים. עכשיו, בסוף כשבונים תשתית ושעובדים מול Engineering, וזה משהו שחשוב להגיד, אני חושבת שה-clarity  הזה, לבוא ולהגיד, קודם כל, רגע, אנחנו מטפלים עכשיו בנקודה הזאתי, בעוד X זמן אנחנו נטפל בבעיה הזאתי, ובעוד Y זמן אנחנו נפגוש לבעיות האלה, אז בואו נתכונן לדבר הזה. פשוט נתן הרבה שקט, קודם כל בEngineering, לבוא ולהגיד, אוקיי, אנחנו בונים תשתית, אנחנו בוחרים את הדבר הנכון שיתמוך אותנו moving forward בכל ה-use cases שאני רוצה. אז זה פעם אחת. העבודה מול Engineering הייתה נורא חשובה, בלשים את זה על רודמאפ ולהגיד אלה הדרישות שלנו לאורך זמן. obviously גם בצד המרקטיאלי, כאילו בצד של הפרודקט, היה חשוב רגע להגיד, רגע, חבר'ה, למה אנחנו לא עושים עכשיו עוד פיצ'רים, עוד יכולות? למה אנחנו כפלטפורמה משקיעים בדבר הזה זמן? אני חושבת שלאור הפריסה הזאת, חוץ מה-functional requirement שנתנו ל- Engineering כדי שיבחרו נכון יותר את התשתית, אז גם שמנו לזה לאורך הזמן, וגם נורא מפינו לאורך הזמן מה יהיה ה-value שיוזרים שלנו יקבלו, ולאיזה Scale נוכל להגיע ברמת הצוותים, ברמת ה-addressable market הזה שנוכל להגיע אליו, וגם למרקטינג ול-Sales זה עשה הרבה מאוד סדר, זאת אומרת, לבוא ולהבין לאיזה Scale נוכל להגיע moving forward. 

רן: אוקיי. אבל כשאני חושב על עצמי בתור מנהל מוצר, כל פעם שהייתי צריך להתעסק בשאלה הזאתי של, אוקיי, Scale-אפ למוצר, תמיד היו אלפי דרישות. כאילו, באמת, היה החל מדברים ממש ממש קטנים, והיו דברים סופר תשתיתיים ענקים. ואת אומרת, אוקיי, עשינו את המיפוי הזה, זיהינו את הפערים, שמנו רודמפ, אחלה, עד כאן נשמע כזה כמו מה שכולנו עושים, אבל בתכל'ס, אני יודע שזה לא ככה. כאילו, אני יודע שהיה לך אלף דרישות ובגדלים שונים, איך את זה, איך עם זה התמודדת? איך את זה פירקת? 

מיכל: כן, אז קודם כל ממש הרמת לי להנחתה, שזה מעולה. אני חושבת, אבל באמת, אחרי שהיה לנו את הרודמאפ, כאילו, זה היה חשוב רגע שנייה, לייתר את ה-clarity הזה לכולם, ושנייה לתת לנו זמן ואורך נשימה לעבוד ולהתחיל להבין איך עושים את הטריידופים האלה ואת הפריירוטיזציה. ואז הגיע השלב שאני הכי אוהבת, שזה ה- GUIDELINE. בסופו של דבר אמרנו, מה ה-key values שאנחנו כפלטפורמה לא מוותרים עליו? או איזה דברים אנחנו צריכים לשנות במיינסט שלנו כפלטפורמה, כדי שנוכל לקבל החלטות הרבה יותר בקלות. ואז זה לא רק עניין של לדבר על פיצ'ר אחד כזה או אחר, אלא זה עניין של, בסופו של דבר, איזשהו ערך מסוים שאנחנו מגדירים כפלטפורמה שחשוב לנו לקחת אותו בחשבון. אני אסביר, לצורך העניין דיברנו על ה-search, ה-search הייתה דוגמה. איך אני לוקחת 20 שניות, הופכת את זה לשנייה אחת. ואז אמרנו לעצמנו שאנחנו כ-Mandy עד היום נתנו הכל. זאת אומרת, once הפלטפורמה עלתה, קיבלת את כל המידע הכי מהר, היית יכול לחפש עליו, כל המידע ממש היה יושב בתוך הפלטפורמה. ואז אמרנו כ- GUIDELINE, בסופו של דבר, אנחנו לא צריכים לתת ליוזר את מה שהוא לא צריך. ואז התחלנו להבין שבסופו של דבר ה- GUIDELINE האלה עזרו לנו למפות כל מיני אזורים שאנחנו מבינים שאנחנו רוצים להתמקד בהם או לא להתמקד בהם. כמובן יש פה עוד עניין של חישוב כזה ריץ' וכמה יוזרים עושים את הפעולה וכמה אפילו היא מעצבנת בפנאל וכן הלאה וכן הלאה, אבל אני חושבת שמה שהיה יותר חשוב זה לבוא ולהגיד, אנחנו כפלטפורמה איזה שינוי של מיינדסט אנחנו עושים כשאנחנו מבקשים Scale, ואחד מהם זה הדוגמה של ה-search, בדיוק את זה. אנחנו לא רוצים לתת ליוזר את מה שהוא לא אמור לקבל.

רן: אוקיי, אז ממש ה-– GUIDELINE ים האלה זה עזר לכם להיות רגע המסננת של בכלל מה נכנס ומה לא נכנס? 

מיכל: אז אני חושבת שזה בעיקר חידד לנו כל מיני דברים. למשל, אני אתן דוגמה, היום כל דבר במאנדיי עובד לייב, את הטבלה- עבדנו עד היום בצוותים קטנים, אתה מקבל עדכון בלייב, רואה שמישהו עדכן משהו, אתה עבדת עם חמישה אנשים, זה לא בעיה. אתה רואה שיש איתך collaborators, 

רן: זה כייף.

מיכל: זה כייף, אבל תדמיין לעצמך שאתה עובד על מצגת. הייתה לנו עכשיו דוגמה כזאת. עבדנו על מצגת מאה אנשים, בסדר? הכנו משהו לכנס, אין דבר יותר מפחיד שהכל קורה בלייב, פתאום מישהו מביא לך את הסלייד למעלה, אתה לא רואה את זה,

רן: חרדות.

מיכל: אתה לא מבין מה קרה שם, ועבדת על זה המון זמן. אז פתאום אתה אומר לעצמך- רגע, יכול להיות שכשאנשים, הרבה אנשים עובדים בסקייל ביחד, החוויה לא צריכה להיות כזאת מיידית, יכול להיות שזה בעצם מה שהתכוונו אינג'נירית, לתמוך בו, שהכל יהיה נורא מהר, מפחיד את היוזרים שלנו. אז אני חושבת שזה היה עניין, כאילו לבוא ולהגיד שלא כל דבר חייב להיות בלייב. אנחנו אפילו צריכים לספק את זה ליוזרים שלנו כדי שהם ירגישו ביטחון.

רן: מעולה, אני חושב שזה דוגמה שמבהירה ממש ממש טוב את העובדה שגם אם נעשה את הכל יותר מהיר כמו שזה עכשיו, זה לא ייתן את המענה של מה שאנחנו צריכים, כי זה באמת יפגוש טבלה עם מיליון משתמשים פתאום, שרואים הכל קופץ להם מול העיניים, וזה חבל שגם אם היא תעבוד טכנית והצלחנו וניצחנו בפרויקט האנג'נירי, אז נכשלנו בעולם האמיתי, אז בעיניי זה מרתק. יש עוד כזה טרייד אופים שנתקלתם בהם, כי אני בטוח שזה כזה שבונים פלטפורמה זה לא הכל קל, ויש כזה ווינים שבלייב זה חוסך לנו גם אפורטים וזה גם טוב ליוזרים.

מיכל: נכון, אז ציירתי תמונת מצב הרבה יותר פשוטה. אין בעיה עושים רודמפ כזה, יש גיידליין, זה כל נכנס, הכל נכנס, קליל, נכון? לא, אבל obviously היו דברים שהם באמת יותר מורכבים. ואני אתן דוגמה, כאילו, ושוב, אנחנו חוזרים לעולם שאני הכי אוהבת שזה דוגמת ה-Search, אבל באמת אחד הדברים שראינו זה שבעצם עד אותה נקודה היוזרים שלנו חיפשו על כל המידע, בעצם חיפשו על כל סוגי העמודות. ואז כשעשינו אנליזה שהיא קצת יותר מעמיקה, ראינו שבעצם בסך הכל הדאטה  שהם מקבלים חזרה, זה בעצם, מחפשים בעצם על עמודה אחת, שתיים, שלוש, גם אם בטבלה שלהם יש בערך חמש מאות. ואז אמרנו אוקיי, השתמשנו בגיידלן הראשון שנתתי, לא הכל, כאילו, יוזר לא צריך לראות מה שהוא לא צריך לקבל, ואמרנו שהפכנו אותה כגישה, הסתכלנו הרבה יותר על גישה של opt-in versus להביא את הכל מיד. ובדוגמה של ה-search, אז באמת אם פעם חיפשנו על כל הטבלה ונתנו את כל האייטמים מכל הטבלה, אז צמצמנו את החיפוש, קראנו לזה limited search, או אפילו שיווקנו את זה גם כאיזה feature, אמרנו הנה, אתה עכשיו יכול לעשות, 

רן: קלאסי.

מיכל: כן, ממש, לעשות פילטר על החיפוש. זאת אומרת, לחפש חיפוש שהוא יותר מדויק לצרכים שלך. אז כן, זה היה trade-off, כי בסופו של דבר יש יוזרים שרוצים לחפש על הכול, ועבור אותם יוזרים גם אמרנו להם, אתם יכולים לחפש על הכול, אבל שימו לב, זה ייקח קצת יותר זמן, אפילו קראנו לזה חיפוש רחב, כדי שהם יבינו שזה אכן המצב. ואני חושבת שזה היה trade-off שחשבנו איך לעשות אותו, אבל לקחנו גם הרבה זמן לפצח את זה, אבל בסופו של דבר כשידענו to position את הדבר הזה בצורה שבה גם מביאה ערך למשתמשים שלנו, ראינו שהרבה משתמשים דווקא נהנים מה-limited search ומוצאים תוצאות הרבה יותר מדויקות להם. אז גם הרווחנו פה מהירות, שהיא לא בדיוק מהירות אנג'נירית, היא מהירות בגלל שהיוזר מחפש על פחות קולומים. זו הייתה הדרך שבה באמת פתרנו את הבעיה הזאת, אבל זה היה trade-off . היום אין חיפוש על כל העמודות. 

רן: ויתרנו על היכולת הזאת, ולטובת באמת הפרפורמנס שכן יעמוד בזה. 

מיכל: לגמרי. 

[נעימת מעבר] 

רן: זרקת כזה רגע במשפט על הערך, וזה כזה העלה לי שאלה של בכלל, איך מודדים את זה? כאילו, איך יודעים שאת עושה עבודה טובה, חוץ מזה שאולי אנשים פחות מתלוננים?

מיכל: וואי, אני חושבת שזה כאילו נקודה טובה, כי פרפורמנס זה משהו שיוזר מצפה לו. יש אנשים שאתה מוציא פיצ'ר, אתה אומר, אה, אדופשן, יוזרים מרוצים, משתמשים שוב ושוב בפיצ'ר. פרפורמנס זה פשוט הצורך הכי בסיסי שהמערכת פשוט תעבוד. אז אני כן אגיד שבסופו של דבר מה שהפתיע אותנו, זה שיוזרים שלנו באמת ראו שיפור, זאת אומרת ממש עשינו איזשהו טסט, ממש ראינו, העלינו פעם אחת את הגרסה עם תשתית החדשה, פעם אחת בלי, וראינו באמת, השווינו את התוצאות, וראינו שיוזרים אכן מרגישים שיפור בתשתית החדשה. ראינו שהבורד נטען מאוד מהר.

רן: הזמן טעינה, השתפר אובייקטיבית.

מיכל: אובייקטיבית, השתפר אובייקטיבית. אבל אז, הבנו שהם לא, שאלנו אותם שאלה, שנייה רגע, האם אתם מרוצים? ואז הופתענו לגלות שתשובות לא כל כך היו significant. הם לא באמת הרבה יותר מרוצים מה-Monday platform עכשיו. 

רן: איזה תסכול, איזה רגע שנייה של לחשוב שעבדת ממש קשה על פלטפורמה, שיפרת באמת, את רואה שיפור אובייקטיבי ואז הביקורות כזה- תאכלס מה השתנה? כאילו לא, לא מרגישים שינוי בתחושה.

מיכל: נכון, אז אני חושבת שבסוף אמון זה דבר שבונים, ואני חושבת שזה אחד הדברים שקצת נשברו בהתחלה, או חוו איזה  שהוא משבר קטן, ואני חושבת שבסוף מה שהרווחנו פה זה trust של היוזרים שלנו, ואני חושבת שבסופו של דבר הם אמנם לא חוו, כאילו אמרו וואו, עכשיו אני ממש ממש מרוצה מכל הפרפורמנס ומהפלטפורמה באופן כללי, כי יש לנו עוד עבודה. אבל אני לפחות יודעת שאת הפרומיס הכי בסיסי שהמערכת תעבוד, סיפקתי להם. וזה האתגר הכי קשה כמנהל מוצר, זה לבוא ו- אתה מת לראות את הגרף הזה עולה, כן? ולראות איך פתאום היוזרים מרוצים והכל happy  וטוב. אבל נתנו להם משהו שהוא הרבה יותר בסיסי מזה, ויש פה איזה בגרות מוצרית או של החברה, לבוא ולהבין שיש דברים שאנחנו לא מוותרים עליהם. ואני חושבת שזה כזה בעיקר המסר שלי, ואני חושבת שבסוף אנחנו גם היום בתוך החברה מרגישים כמה זה היה דבר שהוא משמעותי, וכמה שזה אבן פינה ל-gold and standard שאנחנו שמים moving forward.

רן: אבל כשאת אומרת בכל זאת המוצר אובייקטיבית השתפר. אז מה השתפר? זה לא רק אם האצבע נראה לי יותר מהיר, נכון? מה בפועל מדדת? 

מיכל: אז המדידה הייתה חלק סופר מאתגר, אבל מדדנו ליטרלי גם את הפרפורמנס, זאת אומרת, ממש השווינו side by side איך הפרפורמנס נראה, השווינו את זה גם ברמת הבורדים האסטרטגיים, כי לנו חשוב רגע להבין שבורדים אסטרטגיים, בורדים שיש להם הרבה מידע, שהרבה אנשים נכנסים אליהם, אכן מאוד מאוד מאוד השתפרו. אני חושבת שגם מדדנו, בסופו של דבר מדדי engagement כדי להבין האם זה גם עשה, שיפר איכשהו את איך שאנשים עובדים על הבורדים האלה, אם יותר מרוצים, האם ליטרלי זה בא לידי ביטוי באיך שהם עובדים על הבורד. וכמובן גם רצינו לראות שאנחנו לא פוגעים בשום דבר. כל הדברים שעשינו וששינינו, שאנחנו, אין פה איזושהי פגיעה משמעותית. כמובן שגם חוץ מהדברים הכי ברמת הדאטה ולראות שבסופו של דבר שיפרנו אובייקטיבית, אז גם להבין אם יוזרים באמת הרגישו את זה, וזה מה שציינתי מקודם. בעצם ה-C-SAT הזה שהוצאנו לכל הלקוחות שלנו.

רן: אוקיי, אז בעצם שלוש רמות. רמה ראשונה, ישירות על הפרפורמנס, על מה שעבדנו, האם באמת שיפרנו עבור הבורדים הגדולים ביותר את זמן הטעינה. שתיים, engagement, האם באמת המדדים העקיפים של שימוש עלו כתוצאה מהבחירות שעשינו. ושלוש, זה הריסק בעצם, אוקיי, עשינו המון trade-off'ים, קיבלנו המון המון החלטות, בוא נוודא שלא פגענו באיזושהי התנהגות שהיא משמעותית לנו, אם אני הבנתי נכון.

מיכל: נכון, כן, אז אני אוסיף את הרמה הארבע של בסוף, כאילו האם יוזרים הרגישו, והאם זה השפיע עליהם באיזשהו אופן, שזה On top of everything, וזה בסוף הדבר הכי חשוב.

רן: מגניב, נשמע שזה באמת גם ממש שיפר וגם סופר קריטי לכל חברה. אבל אני רוצה רגע לדבר על הפיל שבחדר, בתור מנהל מוצר. כאילו  אני הרבה פעמים אומר לעצמי: בוא נרוץ, נבנה את הפיצ'ר החדש, נוציא עוד דברים כאלה, ונראה לי שזה ברמה הרגשית קשה לבוא ולהגיד: אוקיי, אני מתעסקת בלשפר את הקיים, והיה מעניין אותי לשמוע איך את מתמודדת עם זה?

מיכל: קודם כל זה מבאס, חשוב להגיד. זה ממש קשה, לבוא ובמקום להוציא את הפיצ'ר שתמיד חלמתי עליו, לבוא ולהתעסק בפרפורמנס. ובסקייל ובתשתית ורגע לעשות את הפרוייקט המאוד גדול הזה. אני כן אגיד שבסופו של דבר זה כזה ה-P0 ואני חושבת שזה שלנו כיוזרים ושלנו כמנהלי מוצר, לוודא שהפלטפורמה עובדת ועובדת כמו שצריך, ואני חושבת שזה קצת תהליך התבגרות כמו של חברה, גם של מנהל מוצר, להבין שזה הבייסיק ואנחנו לא מוותרים על זה. ואני חושבת שזה היה כזה lesson learned כזה, שגם בתור מנהלי מוצר, שזה אחד התפקידים הכי מאתגרים ומעניינים בעיניי, לא כל מה שאנחנו עושים הוא רק כזה יחגגו אותו, ינצחו אותו, הוא איזה win משוגע שרואים אותו, הוא משהו שפשוט היוזרים שלנו צריכים, והם לא מספרים לנו שהם צריכים אותו. אבל כשהם לא מקבלים אותו, זה כואב. ואני חושבת שזה- היום אני ממש שמחה להגיד שהובלנו את הפרויקט הזה ושזה קרה. אני גם יודעת כמה היה impactful עבור היוזרים שלנו, גם אם הם לא תמיד מספרים את זה, כן? אבל אנחנו יודעים.

רן: מדהים. אז אנחנו ככה לקראת סיום, והייתי רוצה לדעת עם איזה תובנות היית רוצה שהמאזינים והמאזינות שלנו יישארו איתם.

מיכל: אז אני אגיד שלכם, כמנהל המוצר, יש את התפקיד הכי חשוב בעולם, וזה לשמור על היוזרים שלנו. זה לדעת מה הם רוצים, גם כשהם לא מבקשים אותו, ולהרגיש שאתם לפעמים צריכים לתעדף את הדבר הזה, שהוא לא הדבר הכי גבוה בפיצ'ר ליסט, אבל הוא באמת ישנה את החיים של היוזרים שלכם. ואני חושבת שזה הדבר שהכי חשוב שאני רוצה שהמאזינים שלנו ייקחו moving forward. 

רן: מדהים. אני, מה שאני לוקח מהפרק הזה, זה קודם כל, כשקורה את הדבר הזה, זה סימן טוב. זה אומר שהחברה גדלה, הגענו לScale חדש, זה אומר שהצלחנו, וזה אינהרנטי שתהיה את הבעיה הזאת, זאת התובנה ראשונה. הדבר השני, זה שגם אם אנחנו במצב הזה מחליטים לשפר את הScale, ואומרים בוא נעשה את הכל יותר מהיר, זה לאוו  דווקא יותר טוב. וזה בדיוק הדוגמה עם הטבלה שמיליון יוזרים מעדכנים באותו זמן, זה יכול לייצר חוויה יותר רעה אם אנחנו נעשה את הפרפורמנס ממש ממש טוב. והדבר האחרון זה שבאמת המחשבה הזאת היא דרך גיידליינס מאוד עוזרת להגיד: אוקיי, מה זה החוויה שאנחנו רוצים לייצר בעולם האמיתי, ואז לחזור חזרה לשאלות האנג'ינריות של באמת- מה אנחנו צריכים לפתור בשטח, ומה אנחנו יכולים לוותר או לשים באופטינט שזה בעיניי גם גישה מרתקת. אז מיכל, המון המון תודה לך שבאת ושיתפת מהסיפור שלנו. 

מיכל: תודה לך, תודה לכם.

רן: ורגע לפני שנסיים, אני רק אגיד שאם אתם רוצים לדעת כל פעם שיוצא פרק חדש בתוכנית שלנו, אתם מוזמנים לעקוב אחרינו בכל אחת מהאפליקציות. אז תודה למיכל, ותודה לכם שהאזנתם. 

[נעימת סיום]