פרודקטיבי: איך ״הורגים״ פיצ׳ר? (רוני בן אהרון, Craft.io) 

Product TV. פודקאסט המוצר של Startup for Startup. שלום לכולם, אני רן ארז ואתם הגעתם לפודקאסט שבו אנחנו מדברים מנהלי ומנהלות מוצר מחברות שונות על בעיות מוצריות שהם נתקלו בהן, איך הם ניגשו לפתור אותן ומה הלמידות שהיו להן בדרך. ובפרק של היום נדבר על הבעיה המוצרית הב . מה הדרך הנכונה להרוג פיצ'ר? ומי שיספר לנו על ההתמודדות שלו עם האתגר הזה הוא רוני בן רון, CTO, CPO ואחד היזמים בCraft.io. היי רוני. לן, מה העניינים רן? מעולה, מה שלומך? בסדר גמור, בסדר גמור, כיף להיות פה. ממש. אני אגיד גם שרוני הולך להרצות בכנס PM Live למנהלי מוצר שהתקיים ב-23 ביוני. בכנס יהיו הרצאות של אנשי מוצר מובילים, אז אם בא לכם לפגוש אנשים אחרים מהתחום ולקבל ידע מקצועי, טיפים ותובנות, זה המקום בשבילכם ואתם מוזמנים להיכנס לאתר PM Live כדי להירשם. ואני אגיד שגם אנחנו נהיה באירוע, אז אם בא לכם בואו להגיד לנו שלום ואנחנו נשמח לפגוש אתכם גם בכנס. אז רוני, לפני שנצלול ככה לעולם הבעיה, אולי תתן לנו קצת קונטקסט עליך ועל מה קרפט עושים. אוקיי, אז קרפטאיו היא פלטפורמה לצוותי מוצר, שבעצם מנהלי מוצר יכולים לעשות את כל המשימות היומיומיות שלהם, כמו איסוף פידבקים, פנית רודמפ, פרוטיזציה, קפסיטי פלנינג, כתיבת ספקים ועוד ועוד. אוקיי, אז רוני, איזה פיצ'ר רציתם להרוג? דבר שלפני זה אני רק אגיד במילה, קרפט מאפשרת למנהלי מוצר בין היתר גם לכתוב ספקים. אחד הדברים, אחד הפיצ'רים שהיה לנו זה היכולת בקרפט לא רק לכתוב פיצ'רים, כלומר לכתוב את הדיסקריפשן בטקסט, אלא גם לעשות מה שנקרא ויזואל ספק, שבעצם אתה מעלה איזשהו אימג' מסוים, נניח שזה ויירפרים או משהו כזה, ואז אתה מתחיל לסמן אזורים באימג' הזה ואתה מוסיף כל מיני הערות. שהערות האלה גם יכולות אחר כך להיבנות ולהפוך לאייטמים משל עצמם. מעולה, וב ת הוויזואל ספק הזה זה בעצם עוד דרך לאותה מנהלי מוצר לוותר רגע מה הפיצ'ר ור לעשות, זאת אומרת זה יותר לדברים של מה קורה כשלוחצים על הכפתור הזה, מה קורה כשלוחצים על הכפתור הזה, דברים בסגנון. כן, ובדיוק, וגם לייצר תקשורת סביב זה, אתה יכול לתאג אנשים וכולי. הבנתי, אז בעצם אם אני מבין רגע נכון, הפיצ'ר הזה היה לנו ספק רגיל, היה לנו עוד ויזואל ספק שמאפשר יותר ויזואלית לתאר את הפלואים שאולי במסמך לא הכי עוברים טוב, ואתם עם הדבר הזה בחוץ, נכון? פיצ'ר לייב במוצר? נכון מאוד. ואז מה קורה? ואז אנחנו מגלים שכמו הרבה פיצ'רים טובים ורבים שנכתבו בהיסטוריה, אין הרבה שימוש לזה. עכשיו, זה הדבר הראשון גילינו, לא משתמשים בזה. הדבר השני הוא שגם ראינו שאם הזמן התחילו לבצר אלטרנטיבות, כלומר, כשאנחנו הצאנו את הפיצ'ר הזה לפני כמה שנים, היינו בנקודת זמן מסוימת. מאז הגיעו כל הפיגמות למיניהם והאנביז'ן, ויש לך יכולת תקשורת על ויזואליזציה מאוד מתקדמת, והדבר השני שאנחנו רואים שצוותי מוצר ממלא משתמשים בזה כבר. אז היה לנו אופציה אחת להמשיך לתחזק את הדבר הזה ולנסות לייצר תחרות או להיות אטרקטיבי מול הפיגמות למיניהם, או שהאפשרות השנייה הייתה פשוט להלך לעשות להם אינטגרציה, שדווקא נלכת את האופציה השנייה, כי ממלא צוותי מוצר משתמשים בזה. אני חושב שאתה נוגע בנקודה סופר מעניינת, כי ב ת הנטייה הטבעית שלי בתור מנהל מוצר זה, אם זה לא עבד ואפילו אם יש תחרות, אז אני אעשה את זה יותר טוב, אז אני אעשה את זה עוד, אז אני אשקיע בדבר הזה, ואני חושב שזה דורש איזושהי בגרות מסוימת לבוא ולהגיד, רגע, שנייה, לא כל אנחנו צריכים לבנות, יש תחרויות שאנחנו לא צריכים להשתתף בהן. אתה יכול לתת על זה אולי טיפה יותר צבע? כן, בדיוק, אז עוד פעם, הדוגמה הכי בולטת זה ב ת אינטגרציות. אתה מגיע לנקודה מסוימת, יש לך פיצ'ר, עכשיו, אנחנו סטארט-אפ, יש לנו הרבה מאוד דברים שאנחנו רוצים לבנות, אני יכול להמשיך ללכת, להמשיך ולחקור ולראיין ולהוסיף עוד פיצ'ר ולעשות A-B טסטים והכול, אבל אני נוגע בנקודה מאוד ספציפית בזמן הזה, הסמיכה קצרה, דברים אחרים לא מפותחים. אז החלטנו בעקבות זה, עדיף לנו עוד פעם, ללכת לעשות אינטגרציה עם פיגמה. כיום יש לנו אינטגרציה עם פיגמה שאתה יכול לעשות את כל הדברים האלה פחות או יותר ב צעות פיגמה. ואז נוצר לנו בעיה. יש לנו עכשיו שני פיצ'רים שמתחרים אחד בשני. זאת אומרת, יש נקודה בזמן שאתה אומר, אוקיי, אני מבין שאני לא הולך לנצח את התחרות בזווית הזאתי ואני עושה אינטגרציה, אבל עכשיו אתה בעצם נמצא במצב שבו יש לך שני דברים שעושים דברים מאוד מאוד דומים. נכון אם אני מבין נכון? נכון מאוד. אבל מעבר לזה, ואולי הדבר שהכי הכי הכי גרם לנו להרוג את הפיצ'ר הזה, שפשוט תקף פיצ'רים אחרים. מה הכוונה תקף פיצ'רים אחרים? אז המערכת שלנו מורכבת.

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

אז הדבר הראשון זה כאילו סגמנטציה עמוקה של היוזרים, זה ההתחלה שלכם. מה השלב הבא? אז השלב הבא זה ב ת לתקשר עם הלקוחות. דיברנו איתם, ראינו שזה אפשרי, ראינו שספציפי הפיצ'ר הזה זה משהו שיכול לעבור בגרון, והגענו למסקנה שאפשר להיפרד מהפיצ'ר לשלום. שלחתם להם את זה במיילים? זה אנשי הקסטמר סקסס שדיברו איתם? איך ניהלתם את החלק הזה? כל הכוח הוא special snowflake? אז היה שילוב של דברים. דבר ראשון, דיברנו עם הצ'מפיון שלנו ועם אנשי המפתח בכל אחד מהחברות שראינו שימוש בה, ודיברנו איתם. דיברנו איזה אנשי ה-CS. והדבר השני זה כמובן לידה ב צעות אימייל, להודיע מראש, לאפשר זמן, להכין את זה שהפיצ'ר הזה הולך להיות סנסיט. ואז בעצם גם לאפשר לתת להם זמן להארך לכך בהתאם. עכשיו, הנקודה היא מה עושים עם הדאטה? במקרה שלנו, עוד פעם אני מזכיר, זה פיצ'ר עם דאטה. השאלה מה עושים עם הדאטה? אז יש שני קצוות של הפתרון. הקצה הראשון זה להגיד אוקיי, אנחנו לא עושים כלום. אנחנו מודים ליוזר, אנחנו מודים ליוזרים, הם צריכים לדעת, נותנים להם מספיק זמן, והם בסופו של דבר יזיזו את הדברים ויעבירו את זה לדברים אחרים. הקצה השני של הסקאלה זה כל הפונקציונליות שהייתה לך, שנתת, אתה נותן להם תחליף, אתה עושה בעצם מיגרציה, ואז בעצם היוזר מקבל תחליף אחר. שבעצם הטרייד אוף המרכזי זה המורכבות של הפיתוח, הזמן של הפיתוח, גם בסופו של דבר האם אתה רוצה להמשיך לתחזק את הדבר הזה שאתה לא בטוח שאתה רוצה לתחזק, למול הפריקשן האפשרי שיהיה לך מהיוזר. זאת אומרת בסנסט, באופציה של הסנסט, אתה אומר אני נותן טווח זמן ממש ממש ארוך, שהמשתמשים, להעביר את הבעיה למשתמשים, הם יסתדרו, ובפתרון של המיגרציה, אתה אומר אני לוקח את הheavy lifting עליי, אני עוזר להעביר את הדאטה הזה בצורה הדרגתית, ואז התהליך נם הוא בשליטתך, אבל המחיר שאתה משלם הוא הרבה יותר גבוה אם אני אביא נכון. כן, רק בשני המקרים מדובר בסנסטינג. כן. ויש את כל הדברים שב צע. אז אנחנו השתמשנו בפתרון שהוא ב צע, כלומר רוב הדאטה של היוזרים, שזה בעצם האימג'ים עצמם והתוכן, אנחנו שמרנו, עשינו מיגרציה ושמנו את זה במקומות אלטרנטיביים. לעומת זאת, יש דברים שלא שמרנו, למשל התיוגים הספציפיים על איפה כל קומט נמצא על כל איזה אימג' לא עשינו את זה, ובשלב הזה זה תקשרנו ללקוחות, תקשרנו ליוזרים שהם צריכים לטפל את זה עוד פעם. צריך לזכור, מדובר על מספר מאוד מצומצם של יוזרים, אבל אפשר גם לערך לזה בהתאם. אגב, עוד אפשרות שיש, זה לעזור ליוזרים ולקחת את זה על עצמנו. כלומר, לקחת צוותי ספורט, צוותי CS, לעשות את זה מאיזשהו אוטסורס, שממש באופן ידני להעביר את הדאטה למקומות מבטחים. אני חושב שזה נקודה טובה, כי בעצם אתה אומר פה, אם אני חושב רגע על המוצר, אתה אומר את הקור אנחנו העברנו, אנחנו עזורים להעביר את התמונות, את הקור, אבל כל השיחות שקרו בקונטקסט, כל המסביב, רנו, אוקיי, או שאתם מסתדרים עם זה, או אפילו נעזור לכם עם ספורט בצורה ידנית, כי זה כאילו, זה בדיוק הפריפריה. בדיוק הפריפריה, יש את הטווייל המרכזי ויש את הפריפריה, ואתה אומר, הטווייל המרכזי ווידאתי שאני מעביר כמו שצריך, זה עליי. כל השאר עליכם. כן, אני חושב שזה מציף את האתגר הגדול בלהרוג פיצ'ר. כי זה לא כמו אתגר רגיל של להגדיר פיצ'ר, לפתח אותו, להוציא, לעשות A-B טסטינג ולריין. בסופו של דבר זה שילוב של טכנולוגיה, שילוב של ראיית מוצר נוכחית וראיית מוצר לאן אתה רוצה להגיע. שילוב של סופט סקילס, איך אתה מדבר עם הלקוחות, איך אתה מתקשר את זה, ואחר כך גם באיזה דרך אתה פותר להם את הבעיות. בסופו של דבר, היוזרים שלנו מאוד חשובים לנו, אז רצינו לתת להם ככל הניתן שזה יהיה כמה שיותר פריקשן לדבר הזה. כן, וזה נשמע שב ת בטרייד אוף הזה אז בחרתם שנייה בין מקצה אחד זה יוזרים תסתדרו בהצלחה לבין עליי הכל, ואתה נותן לי איזושהי נקודת טרייד אוף טובה של להגיד אוקיי, הקור עליי, הפריפריה עליכם וגם לתת את הזמן הזה. אני חושב שהנקודה של הזמן היא מאוד משמעותית. זאת אומרת, את הזמן להקל את השינוי הזה. כן, ובסופו של דבר אני חושב שאולי הדבר הכי חשוב זה להיות שרוב היוזרים שלך עדיין לא פגשת אותם, והמוצר שלך בסופו של דבר, רוב היוזרים של המוצר שלך הם עדיין לא שם, הם יבואו בעתיד. אז אתה צריך לשלב כאן גם את הוויז'ן הפרודקטיאלי שלך והפתרון שלך לסנסיטינג צריך לכלול בסופו של דבר לאן אתה רוצה להגיע.

בסופו של דבר, אימג' אטאצ'מנטס, משהו שסיפקנו במגרציה, זה דבר שממילא רצינו לשמור בתור פיצ'ר. אבל לעשות את התיוג הספציפי ב-X וה-Y של הפיקסל של האימג' את ההערה, זה משהו שהגענו למסקנה שהוא לא נכון לנו בתור מוצר, לכן גם לא ראינו טעם להילחם בזה ולמצוא איזה פתרונות, כי אחרת אנחנו מייצרים עוד product depth. אוקיי, אז אני בעצם בהתחלה רת איזושהי נקודה, זה שיש גם את האינטגרציה וגם את הפיצ'ר הזה קיים, ואתם ככה ממשיכים בתהליך שאתם עושים של להרוג את הפיצ'ר. אתה יכול לספר קצת על דברים שהתנגשו או דברים שלא עבדו בהקשר הזה? אז דווקא הרגע של הפיצ'ר הזה היה תהליך מאוד ארוך, אגב. זה היה תהליך מאוד ארוך. כמה ארוך נגיד? זה שבועות על שבועות של רק המחשבה והתכנון וישיבות עם ה-CES ואחר כך בדיקאים על הכוחות ואחר כך הפיתוח והדרגתי. זה לוקח הרבה מאוד זמן, לוקח הרבה מאוד זמן, מאשר לפתח את הפיצ'ר, זה דבר אחד. בסופו של דבר זה עבר יחסית חלק. כלומר, היוזרים קיבלו את זה בצורה בהבנה, תקשרנו עם זה כנר בצורה נכונה, יש לנו גם אחלה יוזרים, אז הם קיבלו את זה ויש לנו מערכת יחסים טובה. זה אגב לזכות צוות ה-CES הנפלא שלנו, אני צריך לציין כאן, שהם גרמו לזה לאפשר. מה שאומר כלמידה, שיהיה לכם מערכת יחסים טובה עם צוותי ה-CES, כי הם עוזרים לכם. אז הפיצ'ר הזה דווקא הצלחנו להרוג אותו בצורה גרייספול. אני יכול לספר לכם על הפיצ'ר אחר, שבלי להיכנס יותר לפרטים, שהגענו שם, שהיה לנו תוכנית נפל גם כן איך להרוג את הפיצ'ר, זה קרה אחרי ה… אחרי הלימידות עוד. אחרי הלימידות, הזמנו עם ביטחון, וזה לא עבד. למה זה לא עבד? אז זה היה יוסקייס אחר, וגם שם רנו, אוקיי, אנחנו רוצים להרוג איזשהו פיצ'ר, וגם שם אנחנו התחלנו בזה שביטלנו את היכולת להשתמש בפיצ'ר, בעצם, ה ת, שם עשינו משהו קצת אחר. בנקודת זמן מסוימת, רנו, כל מי שישתמש בפיצ'ר הזה יוכל להמשיך להשתמש בפיצ'ר הזה, וכל מי שעדיין לא ישתמש בפיצ'ר הזה לא יקבל את זה יותר. ו רנו, אוקיי, זה זמני, אוקיי? ואז לאט לאט נדבר, ראינו, לא היה לנו יותר מדי יוזרים, ה נו שזה משהו שאפשר לעשות, ואז רנו, אוקיי, עם הזמן נעביר אותם אחד אחד, בסופו של דבר נהרוג את הפיצ'ר לחלוטין. כשכמובן לתחזק מערכת דואלית שיש לך גם שלחלק מהיוזרים יש פיצ'ר, ולחלק מהיוזרים אין פיצ'ר, זה לא דבר בריא באופן כללי. כי תחשבו על הסייקלים, רק הסייקלים של ה-QA, עולה פיצ'ר חדש, צריך לראות האם זה עובד כאן, האם זה לא עובד כאן. מוסיפים עוד פונקציונליות, אתה צריך לחשוב, רגע, מה קורה על היוזרים שעדיין לא קיבלו את הפיצ'ר הזה ויש תלות? מובינג פסט פורוד, אנחנו עדיין תומכים, לא הצלחנו לגמול את היוזרים שהשתמשו בפיצ'ר הזה, שהשתמשו באלטרנטיבות, גילינו שזה יותר מסובך ממה שחשבנו, ואנחנו במצב שיש עדיין קבוצה מאוד קטנה של יוזרים, אבל היא קשת שעדיין משתמשת בפיצ'ר הזה. וזה מונע מיט, אבל הפיצ'ר הזה מספיק חשוב עבורם, שאנחנו לא יכולים לבטל אותו. אנחנו נמצאים עכשיו במערכת דואלית, וזה מייצר בעיה. כי היוזרים האלה, דבר ראשון, כל הסייקל שלנו יותר ארוך של ה-QA, והדבר השני, היוזרים האלה לא יכולים לקבל פיצ'רים מתקדמים שהסתמכו על העובדה שהפיצ'ר המקורי לא קיים. וזאת בעיה, ואנחנו עדיין מקווים שיגיע הזמן ושנצליח להזיז אותם לעשות. אגב, התוכנית שלנו הייתה, יש לנו תוכנית, אוקיי? אנחנו יודעים מה צריך לעשות, זה פשוט צריך להשקיע זמן על הדבר הזה. והזמן של רנו, אנחנו לא נגיד ליוזרים לעשות את זה עצמם, אנחנו נעשה את זה עבורם. ולא הגענו לזמן הזה, כי יש דברים עמוסים, וזה אחד האילוצים, ואנחנו כל פעם מסתכלים על זה בתוגה ואומרים, אוקיי, אולי עכשיו אנחנו נעשה את המיגרציה בעצמנו, אבל אנחנו לא שם. אני מביא לגמרי. אז אם אני ככה לוקח אותך ומנסה לזקק את התובנה המרכזית שלך מהתהליך עבור מנהלי ומנהלות מוצר שעכשיו נמצאים בדילמה הזאת, מה כזה התובנות המרכזיות שלך מהדבר הזה? הדבר הראשון לפני שאתם הורגים מוצר…

תחשבו פעמיים כשאתם בונים מוצר. זה דבר ראשון על לימדי הראשונה, וגם זה אתם יכולים לעשות ב-A-B-Testing כל מיני דברים, דברים שקשורים באקספיריאנס או יוזביליות או פלואוס חדשים, הכל הולך. ברגע שאתם מערכת שהיוזר מתחיל לשמור דברים ושיהיה לו עטצ'מנט לדאטה שלו, כאן זה צריך להדליק לכם נורא. האם אתם ברמת קונפידננס מספיק גבוה כדי לייצר את הפיצ'ר הזה? אולי כדאי להמשיך ולחפש ולהעלות את הקונפידננס שיש לכם על הפיצ'ר הזה, כדי שלא תיקלעו להצהרה הצורה שקוראים לה להרוק פיצ'ר. התובנה השנייה זה תהליך כואב, אבל צריך לעשות את זה. ובסופו של דבר it pays off. זה המון בעל הגן והמון כאב ראש והכל מחשבות, וזה לא משהו שאתם ב ת מקבלים עליו נקודות. כשאתם הולכים אחר כך ואתם מציגים את הרודמפ שלכם לסטייקולדרים שלכם, להנהלה, ו רתם שהשקעתם ככה וככה זמן כדי להרוק פיצ'ר, בוא נגיד, לא תקבלו standing ovation בחדר הישיבות. אבל זה בכל זאת דברים שזה, איך אומרים, זה עבודה מלוכלכת אבל מישהו צריך לעשות אותה. וזה חלק ויטלי להצלחה של המוצר שלכם בסופו של דבר. כי המטרה שלכם בסופו של דבר, עוד פעם, רוב היוזרים שלכם עדיין לא משתמשים במערכת, הם עדיין לא מכירים את המוצר שלכם. וכשהם מגיעים, אתם צריכים להיות במקום שהם מקבלים את המוצר הכי טוב, וזה גם אומר להרוק פיצ'רים שפחות עובדים. כי פיצ'רים שלא עובדים הם מפריעים, הם מייצרים אומס קוגניטיבי, הם מקשים להבין את המערכת, ה-onboarding נהיה הרבה יותר מסובך, לפעמים יש לכם ולפעמים יש לכם מלחמה בין פיצ'רים על אותו אזור, וגם מבחינת ה-life cycle שלכם זה הופך להיות הרבה הרבה הרבה יותר מורכב בסופו של דבר. לכן אתם צריכים להיות יצים ולהתמודד עם האגרנות של הפיצ'רים שלכם. כי בסופו של דבר פעם בשנה כמו שעושים ניקוי וזורקים את כל הצעצום של הילד שכבר לא משתמש בהם, אז גם ככה צריך לעשות בפיצ'רים. וזה הרבה יותר כואב וצריך לעשות את זה. הפסח של הפרודקט. הקיץ של הפרודקט. ואני חושב שזה תובנות מעולות. הדבר שאני לוקח רגע מהשיחה הזאת זה קודם כל ההבדל בין העלות הישירה לעלות העקיפה. זאת אומרת העובדה שפיצ'ר קיים ואנחנו ממשיכים לתמוך בו יש לו עלות עקיפה מאוד מאוד מאוד גבוהה. דיברת על זה בסייקלים של ה-QA, דיברת על זה בעומס הקוגניטיבי, יש פה מחירים שאנחנו משלמים. זה לא המחירים שאנחנו רגילים בראש, תחשוב על העלות הישירה. כמה ייקח לי לשפר את הפיצ'ר הזה, כמה אני צריך להשקיע. זה קל. המחיר ה יתי הוא מה אתה עושה כשאתה לא משפר וזה מייצר את כל הרעש הזה שמסתובב. הדבר השני שאני לוקח זה ב ת הצורת מחשבה הזאת של בוא נעשה סגמנטציה למי משתמש ונבין רגע את הבעיות. אחר כך נעשה תקשורת מדויקת לאנשים האלה ולאו דווקא לכולם, לא נרצה להעיר את הדוב ובסוף לספק את האלטרנטיבה. אני חושב שהנקודה הזאת של יש לי אלטרנטיבה לתת לכם כי זה לא הדבר הנכון לעשות היא משהו מאוד מאוד משמעותי בעיניי בנקודה הזאת של יש לנו מה לתת והדבר האחרון זה שזה ב ת לוקח זמן. אם זה פיצ'ר שיש בו דאטה של המשתמשים והכל יש פה איזשהו תהליך ושזה לא one size fits all כמו שאתם ראיתם את זה גם הצלחתם להרוג אחד לא הצלחתם להרוג פיצ'ר אחר זה ב ת תהליך שאנחנו צריכים לעשות אותו כל פעם מחדש אבל בסוף זה משתלם כי זה בדיוק התפקיד שלנו בתור פי- ים לדייק את האימפקט של המוצר ולדייק את ה-value prop ובלי להרוג דברים שהם לא מספיק טובים אנחנו אף פעם לא נתקדם. אז תודה רבה רוני היה ממש מעניין לדבר איתך. היה ממש כיף תודה שרחתם אותי. ורגע לפני שנסיים אני רק אגיד שאם אתם רוצים לדעת כל פעם שיוצא פרק חדש בתוכנית שלנו אתם מוזמנים לעקוב אחרינו בכל אחת מהאפליקציות ושוב מזכיר לכם על כנס פי-אם לייב שהתקיים ב-23 ביוני יהיה מעולה ושוב תודה רבה רוני ותודה לכם שהזנתם. תודה רבה