פרודקטיבי 38: איך עושים גרות׳ למוצר שלנו? (שיר ירקוני, מאנדיי)

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

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

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

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

חוות גדולות זה בעצם הצורך בדשבורדים וריפורטים. אז בעצם הפתרון שחשבנו עליו זה להוסיף שלב לוויזארד שעוזר למשתמשים לקנפג בצורה יחסית פשוטה את הדשבורד שמתאים לצרכים שלהם. זאת אומרת כבר לעזור להם לחבר להם לערך משמעותית מה שאנחנו מדמיינים שהם רוצים לראות בצורת ה-reporting, נכון? זאת אומרת לשים להם דשבורד שעוזר להם כבר, שהמטרה היא בעצם לראות כבר את ה-value בשלב הזה? בדיוק, בדיוק. וגם עוד יתרון שזה נתן לנו זה שתהליך, אם אני שנייה חושבת על מה, נניח ואני יודעת שהמשתמשים שלנו מעוניינים ביכולות ריפורטינג, ועכשיו אני מנסה לדמיין מה תהליך שהמשתמשים שלנו צריכים לעבור מהרגע שהם מגיעים למערכת עד שהם מצליחים לבנות לעצמם כזה דשבורד. אז בעצם אם אתה מפרק את זה אתה רו שהם צריכים לעבור הרבה מאוד שלבים. הם צריכים קודם כל לנחות על המערכת, להכיר את המוצר, לבנות את הבורד בעצם עם האייטמים במבנה שמתאים להם ומשרת את הצוות שלהם. אחר כך הם צריכים להבין איך בכלל הם בונים דשבורד. צריכים לקסטם את הדשבורד. בשלב הזה כבר איבדנו את המשתמש. כן, בטח ב-onboarding. בעצם אנחנו רואים עוד לפני שאתה בכלל יכול לעשות ריפורטינג על דאטה אתה צריך את הדאטה. אתה צריך להיות מסוגל לתהליך העבודה ורק זה קשה להם. בדיוק. ואז בעצם מה שעשינו זה תפרנו את כל חוויית ה-wizard ככה שכל משתמש יוכל לקסטם לעצמו את הדשבורד ממש מההתחלה בצורה שהיא אינטואיטיבית גיימיפייד ממש תוך כמה קליקים. אוקיי, אז מה בעצם… בואי נדמיין שאנחנו עכשיו המשתמשים. מה קורה בסוף התהליך עכשיו של ה-onboarding המחודש הזה? מה אני מקבל בעצם? מה קיבלתי לפני ומה אני מקבל עכשיו? אז בעצם בתהליך הראשוני אתה מקבל בורד יחסית פשוט מקוסטם עם הקולומים שבחרת לעצמך. זאת אומרת, טבלה, עמודות, זה מה שאני מכיר עד עכשיו, סבבה? נכון, ועכשיו מה שאתה מקבל זה בעצם טבלה עם עמודות בורד מקוסטם, אבל עכשיו אתה מקבל אותו גם עם עוד דשבורד שמחובר ישירות אליו שעוזר לך בעצם להבין את ההתקדמות של הצוות שלך. אז הדשבורד הזה בעצם כולל ניתור של המשימות, מה בוצע ומה לא בוצע, איזה משימות נמצאות היום בריסק. אתה יכול לראות אם זה גם איזשהו גאנץ שעוזר לך להבין מה ההתקדמות הפרויקט וכולי. וזה לכל המשתמשים או רק לאוכלוסייה הספציפית הזאת? אז ה ת שזו שאלה טובה כי המוטיבציה ליצי לדרך הזו זה היה המשתמשים מהסגמנט הזה. אבל בעצם ברגע שהתחלנו לעבוד על הפרויקט הזה הבנו שזה צורך שיכול לענות גם ל-SMBs ובגלל זה בתור התחלה הפעם בחרנו לא להגביל את עצמנו. כשפתחנו את הניסוי פתחנו אותו לכל האוכלוסייה ו רנו שמה שכן בשלב הניתוח אנחנו נרצה לנתח את הטסט לפי סגמנטים שונים. נכון, ואני חושב שזו תובנה מאוד משמעותית שבעצם הרבה פעמים כשאנחנו נעשה A-B טסט אנחנו נרצה להסתכל על כמה אוכלוסיות בטסט ולשמור את זה לניתוח של הסוף. זאת אומרת לא להגביל את עצמנו עם ההטייה שלנו שזה רק לגדולים אז בוא נעשה את זה רק לגדולים אלא לפתוח את זה רחב ואז לשלוט מתוך הדבר הזה את המידע שמעניין אותנו. אולי נגלה דבר שלא היינו מדמיינים. בדיוק. אוקיי, אז אתם עכשיו בשלב הזה של A-B טסט כבר? כן, בדיוק. אוקיי, אז אני רק רוצה לעשות איזשהו ריקאפ שנייה נקודתי. אז רנו בעצם התחלנו באיזשהו דיסקאברי רחב של קודם כל בעיה. אחר כך רנו בוא נבנה מהדבר הזה הזדמנויות עשינו opportunity sizing וזיהינו opportunity שהיא ממש מעניינת. יעדפנו הזדמנויות ולא פתרונות. אחר כך בנינו את עץ ההיפותזות ומתוך ההיפותזות איך בנינו אותם? חלק הגיע מהדתה, חלק הגיע מהמשתמשים וניסינו להעלות את ה-confidence בהיפותזות. כאשר לא עצרנו בהיפותזה הראשונה שאומרת בואו נעריך את הטרייל, אלא הסתכלנו על כל ההיפותזות. אחרי שעשינו את זה בעצם עברנו ועשינו solution sizing, עשינו את יעדוף לפתרונות על כל ההיפותזות האלה והתחלנו מזרוק חכה שרצינו לראות רגע את המקסימום אפקט מבלי להסתכל במימוש הקונקרטי. עכשיו אחרי שעשינו את זה וזיהינו את הבעיה, הלכנו ושינינו את הוויזארד ועכשיו אנחנו יוצאים ל-A-B טסט כדי לבדוק ב ת את הדבר הזה. כמה נגיד טסטים אתם עושים בסדר גודל בריבון על הדבר הזה? רק כדי לעזור להבין בסדר גודל. אז אנחנו עושים סדר גודל של למעלה מ-30 ניסויים בריבון. וואו, זה מטורף. זה כאילו ניסוי כל שלושה ימים. אז איך עושים את זה כל כך מהר? אז ה ת שגם פה יש לנו תהליך מאוד משמעותי של פריוריטיזציה שאנחנו עושים. בתחילת הריבון אנחנו מנסים לבנות איזשהו גאנט יחסית כללי ואנחנו מנסים לתעדף את הניסויים בצוות בצורה שהיא חכמה.

לבין איזה ניסויים אנחנו יכולים להריץ במקביל. למשל, אם עכשיו אני מריצה ניסוי שהוא נמצא בתחילת הפאנל, או למשל בשלב הסיינאפ, אז יכול להיות שבמקביל אליו אני יכולה להריץ ניסויים שהם יותר דאון דה פאנל, אם אני חושבת שהאפקטים לא יתנגשו. לחשוב גם על ניסויים בעולמות של… אם עכשיו אני רוצה לעשות ניסוי שנוגע במסאג'ינג, אז יכול להיות שהניסוי הזה, אני יכולה להריץ אותו ביחד עם ניסוי תשתיתי במוצר. ובעצם ככה אנחנו מייצרים כל הזמן את הבלנס הזה, שמאפשר לנו להריץ כל כך הרבה ניסויים בסקייל. אוקיי, מעולה. אז בעצם מה בסוף קרה? כאילו, סיפרנו רגע על הטסטים וכל הדברים האלה, מה בסוף קרה? הניסוי היה הצלחה אדירה. כן. כן. הרצנו את הניסוי, וראינו שהצלחנו לשפר את ה-conversion to pay של מנדיי בעשרות אחוזים. זה מטורף. ואם אנחנו מסתכלים על הסגמנט הזה ספציפית, אז שם בכלל המטריקות עפו באוויר. וואו. אני חושבת שאין דבר יותר מספק מלראות את הגרף של ההוקיסטיק, כשאתה רו את ה-conversion to pay של הסגמנט הזה, וזה היה פשוט מטורף. כן, מעטים הרגעים בחיים של מנהל המוצר, שבו רואים שפשוט זה עובד, וזו חוויה מטורפת. אבל גם כמו שאנחנו יודעים בתור מנהל המוצר, זה גם הרבה דברים שלא עובדים, או שניסינו, ולא זה אז כזה. איזה דברים את לומדת מהדברים שדווקא לא עבדו? אני חושבת שנגענו בזה קצת, אבל המלצות צריכות להיות המלצות קונטקסטואליות לרוב, זה מה שאנחנו רואים. לחשוב על איפה נמצא המשתמש בשלב העבודה שלו, בשלב הבנייה שלו במקרה שלנו, כי יש גבול בעצם לכמות התוכן שאנחנו יכולים לזרוק על המשתמש שלנו עם פופ-אפים וכו'. זה דבר אחד. וגם אני חושבת שמבחינת עוד למידה משמעותית שהייתה לנו, זה היה בעצם הלמידה של ה-show, don't tell, שהרבה פעמים ב ת סרטונים וכו'. אני יכולה לספר למשתמש שלי מה הכלי שלי יכול לעשות. כן. אבל בסופו של דבר הם רוצים להרגיש את זה, הם רוצים להבין את זה, הם רוצים לקבל את הערך ה יתי מהמערכת. אני חושב שזה מעולה, וב ת מה שאני לוקח מהפרק הזה זה קודם כל הנושא הזה של כמה זה חשוב לתעדף הזדמנויות, עוד לפני שדיברנו על הפתרון זה דבר אחד מרכזי. הדבר השני זה ב ת המודל החכה הזה, של לשאול רגע איך אני זורק בכמה זמן, כמה שיותר מהר, משהו שיעזור לי להבין בכלל את האפקט, לפני שאני מדבר על המימוש, וגם אם זה לשים את זה in front of users בפנים, גם אם למדנו מהסרטון שאנשים רוצים לקבל את זה, זה מהר מאוד הבנו שזה לא הפתרון, וזה מאפשר לנו לרוץ מהר. הדבר האחרון זה ב ת הנושא הזה של הרבה מאוד טסטים במקביל, לא לחכות שכל אחד יסתיים ואז להמשיך, זה ב ת לנסות למפות את כל התהליך ולזהות איפה אנחנו יכולים להריץ במקביל, כי בסוף אנחנו מאפתמים ללמידה, והזמן הוא המשב הצר, לא שום דבר אחר. לגמרי. אז תודה רבה שיר. היה ממש ממש כיף לדבר איתך. ורגע לפני שנסיים אני רק אגיד שאם אתם רוצים לדעת כל פעם שיוצא פרק חדש בתוכנית שלנו, אתם מוזמנים לעקוב אחרינו בכל אחת מהאפליקציות. אז שוב, המון המון תודה. תודה לך רן. ותודה לכם שהעזנתם. תודה.