Stop Building SaaS: The Agentic Revolution is Here!

פרודקטיבי, פודקאסט למוצר של סטארט-אפ פור סטארט-אפ. שלום לכולם, אני רן ארז ואתם הגעתם לפודקאסט שבו אנחנו מדברים עם מנהלי ומנהלות מוצר מחברות שונות על בעיות מוצריות שהם נתקלו בהן, איך הם ניגשו לפתור אותן ומה השיעורים שהם נולדו בדרך. ובפרק של היום אנחנו נדבר על האתגר המוצרי הבא, איך אנחנו הופכים את המוצר סאס שלנו למוצר איג'נטי. ומי שהולך לספר לנו על התמודדות שלו עם האתגר הזה הוא אמיר קסלר, VP Product ב-Jeet. מה קורה אמיר? אהלן, מה המצב? מעולה, כיף ממש שאתה פה. כיף להיות פה, תודה על ההזדמנות. בשמחה, אז ככה, אולי תספר לנו קצת עליך וקצת על ה-Jeet? בטח, אז אני VP Product ב-Jeet, אני בתחום של סייבר סקיוריטי כבר, לא יודע, 15 שנה, מאז שהשתחררתי מהצבא בערך, בחברות שונות. ב-Jeet אנחנו בסייבר סקיוריטי, ספציפית בתחום שנקרא Application Security, אנחנו עוזרים לחברות פשוט לאפתח ממש את האפליקציות שהם מפתחים קצה לקצה, מרמת הקוד, כשהם כותבים את הקוד, עד רמת הקלאוד, איפה שזה דיפלויד, וכל מה שיש באמצע, בוא נקרא לזה ככה. מדהים, אז באמת הבאנו מוצר סייבר סקיורטי, כדי שבאמת יקבלו את כל המנעד של הדעימות שאפשר לקבל, ואולי אני אספר לך קצת, תספר לנו קצת על האתגר שאנחנו יכולים לדבר עליו היום באמת לעומק?

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

בטח. אז השינוי אצלנו התחיל האמת קודם כל בשיחות עם לקוחות. אצלנו זה מקרה מאוד ספציפי שזה היה מאוד סיגנל מאוד חזק שאנחנו רוצים, צריכים לעשות את המעבר הזה, יותר נכון להגיד. כמו שאמרתי, אנחנו עושים Application Security או Product Security. זה אומר שככל שלחברות יש יותר Product, יש יותר משהו שצריך to Secure. מה שקורה לצווי... מה שקרה לצוותי security זה שהמפתחים בחברות האלה התחילו לעבוד עם כלי AI, התחילו לפתח יותר קוד, יותר תשתית, יותר הכל, יותר אפליקציה, על אותו צוות קטן של security שצריך להתמודד עם הדבר הזה ולהבין איך הוא בעצם מאבטח את זה. וזה יצר בעיה מאוד מאוד קשה של סקייל, ושמענו את זה עוד פעם ועוד פעם ועוד פעם, והבנו שאנחנו פשוט רוצים להיכנס לשם. ולראות איך אנחנו יכולים ממש להילחם באש עם אש, להילחם ב-AI עם AI, לתת לצוותי סקיוריטי כלי AI כדי שהם יוכלו לעבוד יותר מהר ולהתמודד עם העומס. אוקיי, אז באמת, רק אם אני מבין את הבעיה נכון, אז בעצם המהפכה הזאת שקורית בעצם גרמה לכל המפתחים בחברות שהם כבר עובדים מולם לרוץ הרבה הרבה יותר מהר, לייצר הרבה יותר נפח עבודה, אבל צוותי הסקיוריטי בגודל לא השתנו, ואז מתחיל בעיה שהם נעימה בוטלנק בסוף. הרבה יותר משמעותי. ממש ככה. איזה נגיד סיגנלים אתם שמעתם כאילו בשיחות? כאילו מה נגיד עכשיו מנהלי מוצר יכולים לשמוע ולהגיד, אה, זה דומה למקרה של אמיר? אני חושב שכאילו אם עושים איזשהו דיסקאברי כללי, שזה בדרך כלל איך שאנחנו מתחילים שיחות, זה ממש עלה בצורה אקספליסית של אנחנו בעומס, אנחנו לא עומדים ביעדים, אנחנו מגייסים, אנחנו צריכים יותר עזרה, אנחנו צריכים עזרה כאילו באזורים שלפני זה לא התבקשנו לעזור בהם. ממש ככה. אוקיי, אז אנחנו נמצאים עכשיו רגע באיזושהי סיטואציה שבה אתם רואים סיגנל מאוד מאוד מאוד ברור שהלקוח האידיאלי שלכם או הצוות האידיאלי שאתם בונים עבורו את המוצר נהיה עמוס מדי ויש פה סיגנל. מה עושים מכאן? מה הנקודה שאתם עושים מכאן?

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

כן, אני מבין לגמרי למה אתה מתכוון, אני חושב שבכלליות בדיסקאבר, אבל אני חושב שבטח ובטח בעולם האג'נטי, קם ונופל על שקיפות. כי אם אתה מפתח agent שפשוט, אתה יודע, אתה קם בבוקר והוא אומר לך, היי, I did it, זה יוצר בעיית trust, זה יוצר בעיית, אתה יודע, פשוט כאילו, human in the loop שאנשים הרבה פעמים רוצים להיות חלק מזה. אז אם אנחנו רגע נעשה פרפראזה למילה בעיה וניקח את זה כאילו ממש לאיזשהו task, אז מה שעשינו זה אמרנו, אוקיי, זה משהו שאנחנו יודעים שהם עושים. כל יום, כל שבוע, עשינו ולידציה שזה לוקח הרבה מאוד זמן, אנחנו קוראים לזה Workflow, אנחנו בעצם ננסה לייצר אג'נט שעושה את ה-Workflow הזה בשבילם, אבל מאוד שקוף לאורך הדרך לאיך הוא עשה את ה-Workflow הזה. ואז אתה בעצם בא לשיחה ואתה אומר, נכון יש את ה-Workflow הזה שאתה צריך לעשות כל שבוע, נכון בדרך כלל הצעדים זה 1, 2, 3, הנה תראה איך האג'נט עשה את זה בשבילך, תראה איך הוא עשה את כל הצעדים האלה, ויש לך את היכולת. To customize it, אם אתה רוצה שהוא יעבוד טיפה אחרת, אתה יכול לעשות את זה. יש לך איזושהי דוגמה כזאת על איזשהו תהליך?

כן, יש לי דוגמה, היא מאוד מאוד ספציפית כמובן לגולמות של סייבר סקיוריטי, וזה הכל ברור. כן, אז אני מקווה שאני לא אשעמם פה את מי שלא מבין בסקיוריטי, אבל בגדול יש תהליך שנקרא Risk Assessment, שבעצם אתה צריך לקחת, נגיד התגלתה איזושהי חולשה, איזושהי בעיה, איזשהו משהו בסגנון, איזשהו אישו, אתה בעצם צריך לגלות, האם הדבר הזה הוא באמת מעניין או לא מעניין. כדי לוודא אם הוא מעניין או לא מעניין, יש סט מאוד ארוך של בדיקות שאתה צריך לעשות. אתה צריך להבין האם הדבר הזה בכלל יכול לקרות. כאילו, אם זו איזושהי בעיה שהיא תיאורטית, או שזו בעיה שיש לה איזושהי מידה מסוימת של היתכנות. אתה צריך להבין אם זה יקרה, האם זה ייצור באמת אפקט מעניין על החברה. אתה רוצה להבין האם היום יש כל מיני קונטרולס, security controls in place, שימנעו. מהחולשה הזאת באמת להתממש, יש כל מיני בדיקות כאלה. אז זה היה ה-use case הראשון שאנחנו בחרנו, ואגב, אם אנחנו מדברים על להיות גנריים, אני באמת מאוד מאוד ממליץ, אם רוצים לעבור למצב אג'נטי, קודם כל לבחור use case אחד, וממש to double down עליו, כי אחרת זה נהיה בלתי אפשרי, צריך למצוא use case שהוא time consuming, והוא כואב, וקשה לעשות אותו בלי AI, שזה בדיוק העניין הזה של ה-risk assessment. ואז מה שעשינו זה בעצם אמרנו אוקיי הנה ה-risk assessment הזה, אנחנו יודעים שאנשים משקיעים בזה שעות בשבוע, אנחנו יודעים שזה באמת כואב להם ואנחנו יודעים ש-agent יכול לעשות את זה כי כל התהליך שתיארתי עכשיו הוא אינטגרציה של data, הרבה פעמים טקסטואלי, שזה דברים שה-agents טובים בהם. אז המוקאפ שיצרנו הוא מוקאפ של פשוט agent שהולך ועושה את כל הבדיקות האלה ובסוף חוזר ואומר לך אלה הבעיות הכי חשובות וזה ה-reasoning בהתאם למה שהוא מצא. אוקיי, אז בעצם אתה, אני חושב שאתה שם פה איזשהו זרקור על זה שצריך להתמקד רגע ב-use case ספציפי, time-consuming, כואב, אמיתי. איך ניגשתם לזה רגע כשהסתכלתם, לפני שבחרתם רגע את ה-workflow של risk assessment, היה לכם כאילו קנדידטים, איך תיעדפתם את זה, מה, איך ניגשתם לזה בכלל? האמת שכחלק מה-exploration הכללי שעשינו, כשניסינו להבין האם העניין הזה של... agent ולעזור בעניין הזה של scale וכאילו של work force ומעניין כחלק מאותו תהליך שאלנו מה ה use cases שהיום אתם חושבים שאם agent היה עושה בשבילכם היה יכול לעזור לכם פשוט שאלנו את זה כל פעם ובסוף זה היה ממש ברמת הטבלה אלה כל ה use cases ששמענו זה ה counter ליד כל אחד מהם ופשוט הלכנו על ה top one ממש כאילו הכי straight forward שאפשר ואז בעצם אז בסוף כשניגשתם לזה אז ממש. פירקתם את זה לשלבים של כאילו כמו שבן אדם אמיתי היה עושה, ממש פירקתם את זה לשלבים. היו מקומות שזיהיתם רגע שהיה אפשר כאילו לקצר וניסיתם או שאמרתם רגע קודם כל בוא נסמלץ כאילו ממש סטפ ביי סטפ אותו דבר? זו שאלה מעולה, אנחנו סמלצנו סטפ ביי סטפ, אני חושב שהמיינדסט שלנו היה מאוד אנחנו רוצים להראות ללקוחות שלנו שאנחנו מחליפים להם אנשים, יכול להיות שהיינו יכולים לקצר דברים מסוימים ולעשות אותם כאילו לחשוב האם האייג'נט יכול לעשות את זה יותר חכם, ממש, לגמרי, אני מקבל את זה. יכול להיות שגם נעשה את זה עוד, זה אחלה רעיון, אבל המטרה הראשונה הייתה באמת להראות איך נראה מוצר שהוא במקום לעזור לך, הוא עושה בשבילך, אז ממש הלכנו על הפלואו. אוקיי, אז בעצם אנחנו אומרים רגע, סטפ ראשון, אקספלורציה לעולם הבעיה, זיהינו שבאמת הצוותי סקיוריטי שלנו נהיים מאוד מאוד מאוד עמוסים בגלל השינוי החיצוני שקורה עם כל מהפכת הווייב קודינג, ובאמת יותר קוד נכנס, אבל עדיין קשה לצוות הזה. אחר כך אמרנו, אוקיי, אנחנו עושים רגע ולידציה לפתרון, ובוולידציה אנחנו בעצם לקחנו את מה שבן אדם היה עושה ופרטנו אותו לשלבים עם ה-reasoning, זה בעצם היה הדרך שלנו לעשות ולידציה עם הפרוטוטייפ הזה. ואחרי שזיהינו את זה ואמרנו, אנחנו עושים את זה על יוסקי ספציפי, אולי אפילו נחזור רגע צעד אחד אחורה, מה קרה בוולידציה הזאת? כאילו, הראיתם רגע את הפרוטוטייפ של התהליך המלא של ה-risk assessment הזה, מה הצד השני, מה הלקוחות אומרים, מה הפידבק על הדבר הזה? אז הפידבק הוא מאוד מאוד חיובי, הפידבק הוא גם חיובי בכלליות שהדבר הזה יכול להיות מאוד helpful ומאוד valuable וגם מה שניסינו לעשות בוולידציה זה לקבל את הסיגנל שזה יכול לחסוך להם זמן אמיתי, אז זה היה הדבר שהיה הכי חשוב לנו להתמקד בו. חשוב לי רק להדגיש משהו אחד שאולי לא מספיק הדגשתי אותו, התהליך הזה שדיירתי של ה-risk assessment, העובדה ש-agent עושה אותו. חלק מהקסם זה שזה תהליך שהוא מאוד דינמי. זאת אומרת, אם יש לקוח שרוצה שהאג'נט יעשה את ה-risk assessment קצת אחרת, הוא פשוט מדבר עם האג'נט ואומר לו, תעשה את זה אחרת. אם אחרי התהליך של ה-risk assessment, הלקוח רוצה לשאול שאלות לגבי התהליך, הוא יכול לשאול שאלות. הוא יכול לבקש מהאג'נט לעשות פעולות בעקבות ה-risk assessment. הוא יכול להגיד לו, לך תדבר עם המפתח בסלאק, לך תפתח לי ג'ירה טיקט, לך... הוא יכול לחבר בתכלס כמעט כל כלי שהוא רוצה. לאג'נט והאג'נט גם יכול לבצע בשבילו פעולות. אז זה רק היה לי חשוב להדגיש כי רק לקחת ולתהליך קיים ולעשות לו אוטומציה, כאמור זה אוטומציה. כדי שזה באמת באמת יהיה אג'נטי, אתה חייב לאפשר גמישות ו-actionability. כאילו שהאג'נט יוכל ללכת ולעשות בשבילך פעולות. אז זה ניואנס, אבל הוא ניואנס לדעתי מאוד חשוב.

אני חושב שזה ניואנס שצריך להרחיב אותו, כי בעצם אנחנו אומרים, ההבדל הזה רגע בין אוטומציה לבין אג'נט זה קודם כל אוטומציה היא... תהליך קבוע תמיד, יש לו התחלה וסוף מאוד מאוד מאוד ברורים. נכון. וכשאנחנו עושים את הקפיצת מדרגה הזאת לאג'נט הזה, אנחנו מוסיפים כמה דברים. אחד, אנחנו מוסיפים בעצם את ה-reasoning, כאילו היכולת לנתב בצורה דינמית את התהליך. בדיוק. והדבר השני, להבין שהתהליך הזה יכול להיות, כאילו להמשיך. זאת אומרת, הוא לא חייב להיעצר במקום שאנחנו דמיינו שהוא ייעצר, אנחנו בעצם לא יודעים מתי הוא אפילו ייעצר לפעמים באיזשהו מקומות, וזה נראה לי שהוא מפתח, כי הרבה פעמים אנחנו רואים... אנחנו אומרים אוקיי בוא נעשה AI agent, בסוף אנחנו בעצם עושים אוטומציה וקוראים לזה AI, אבל חשוב רגע ההבדל הזה פה בנקודות האלה. בדיוק, ממש ככה ואני חושב שנגעת בדיוק בנקודות, כאילו בין אם זה בשלב הראשון, שכשאנחנו עושים תהליך שהוא לכאורה מוגדר כאילו בצורה אוטומטית, הוא לא באמת אוטומטי, יש בו דינמיות מסוימת, בין של ה-agent עצמו שיכול להחליט לבד לנתב ימינה שמאלה במקרים מסוימים, ובין של ה-user שיכול להכווין את ה-agent לעשות דברים אחרת, אבל בעיקר זה מה שקורה אחרי, היכולת שלך to close the loop, כי אם אתה רוצה באמת להוריד לאנשים עומס, אתה צריך לעזור להם לפתור את הבעיה עד הסוף. מה שיוזרים שלנו עושים בסוף תהליך risk assessment הוא מאוד מגוון, באמת, חלקם אחר כך לוקחים את זה לג'ירה, חלקם אחר כך הולכים ופותרים את הבעיות במערכות ועושים פאצ'ים ועושים פיקסים, חלקם רוצים לעשות עוד investigation ומחברים עוד מקורות דאטה, לא משנה מה הם רוצים לעשות. אתה צריך לתת להם את התמיכה הזאת והאג'נט צריך לדעת לעשות את זה בשבילם, גם אם זה בתקשורת עם היוזר. אז זה באמת נהפך להיות מי פסיבי לאקטיבי ומי אוטומצי לאג'נט, כמו שאמרנו. אוקיי, אז בעצם אנחנו בסוף שלב הדיסקאברי, אנחנו מבינים שיש לנו use case חזק, ה-risk assessment הזה הוא חזק, הוא עבר ולידציה על ידי לקוחות. עכשיו בוא ניכנס ל-execution, מה קורה עכשיו בשטח פנימי בתוך החברה?

אוקיי, אז אני חושב שהדבר הראשון שאנחנו עושים זה להבין שאם אנחנו, קודם כל אנחנו מבינים שאנחנו מאמינים בזה, מאמינים שאנחנו מאמינים בזה ברמה האסטרטגית, שאנחנו נגיעים לנקודה הזאת שאנחנו שלמים עם זה ברמה הארגונית, לפני שאנחנו רוצים לפתח, אנחנו דווקא מבינים שכדי להיות מוצר אג'נטי, אנחנו צריכים להיות חברה אג'נטית. זה ממש ממש ממש חשוב ובסיסי. אתה יכול להרחיב על זה? כן. אתה לא יכול לפתח אג'נטס כמו שצריך ולעשות את השיפט המחשבתי הזה. אם אתה לא, אתה לא יכול לצפות מהיוזרים שלך, ואני אקרא לזה ככה, להשתמש באג'נטס, אם אתה בעצמך לא מורגל לזה ולא מבין איך הדבר הזה עובד. אז מה שאנחנו עושים זה שינוי across the board של כל המחלקות, בין אם זה בצד היותר product engineering וגם בצד של ה-go-to-market, של איך אנחנו הופכים את הורינו והופכים את העבודה שלנו ליותר אג'נטית. אז לדוגמה באנג'ינירינג, זה הדבר הראשון שעשו, זה קודם כל לסגור את הלייסנסים של כל IDE שהוא לא קרסר.

וואו. אין כזה דבר שלא עובדים יותר עם קרסר. עכשיו, מתוך הבנה שברור שלא כולם מורגלים לזה ולא כולם יודעים מה זה ואיך לעבוד עם MCPs והכל, אנחנו עושים איזשהו האקתון של שלושה ימים שאנחנו עוצרים את כל הפיתוח הרגיל, אנחנו מחלקים לצוותים, כל צוות מקבל פיצ'ר שבתכלס בתכנון המקורי שלו היה איזה שבועיים או אפילו יותר, ומקבלים, כל צוות מקבל את הפיצ'ר הזה. והם סוגרים אותו בשלושה ימים, כאילו מצליחים באמת באמת לסגור אותו, כאילו תמיד מדברים על זה ש-AI עוזר עם Velocity, אז אני ראיתי זה בעיניים, כאילו זו הייתה הנקודה באמת שזה קרה. אז זה לדוגמה איך שהצוות Engineering עשה את המהפך. גם בצד של הפרודקט, מן הסתם היינו חייבים להתאים את עצמנו. אם עכשיו כל ה-Engineering מפתחים הרבה יותר מהר, אז אנחנו הופכים להיות bottleneck, PRDs וכן הלאה, אז אנחנו מפתחים גם בצד שלנו באמצעות... Cloud ו-MCP servers, בעצם אג'נטים שעושים הרבה מהעבודה שלנו בצורה אוטומטית, אוקיי? אז אני יכול לתאר, זה אצלנו, אתה מתחיל מלדבר איתו על מה אתה רוצה לפתח, הוא עושה בשבילך את ה-competitor analysis, ממש הולך לכל הקומפטיטורס, גם לכאלה שלא חשבת עליהם, רואה מה הם עושים בתחום, מביא לך print screenים, מביא הכל, כמובן כותב לך את ה-PRD, הולך לכל הדאטאבייסים שלנו של בקשות של לקוחות, מבין איזה לקוחות הפיצ'ר הזה יכול להיות. רלוונטי אליהם, יוצר ווייר פריים, כל מה שאפשר לעשות לאוטומציה, בגדול עשינו לאוטומציה. זה שינוי די רדיקלי, גם ה-R&D השתנה לגמרי, גם הפרודקט השתנה לגמרי, שעכשיו מתחיל לעבוד עם אייג'נטים, יש עוד דברים בחברה שהשתנו?

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

זה באמת החלטה מאוד מאוד דרמטית, אני חושב שמקבלים אותה, תראה, אני עכשיו בנקודה בחיים שאני חושב שאי אפשר לקבל החלטה אחרת. כאילו שבאמת אם אתה מסתכל על תהליכים בצורה קצת יותר מקרו, התחושה שלי, ויכול להיות שאני סופר בייסט, כי אני כל כך עמוק בתוך הדבר הזה, זה שמי שלא יעשה את השיפט הזה, הוא יישאר מאחורה, במקרה הטוב. כאילו, אז באמת, פשוט לאיפה שהעולם הולך. אני בטח ובטח לא הראשון שאמר, ויש הרבה מאוד ציטוטים של בכירי התעשייה שאומרים, סאסס דיינג. כאילו, אתם צריכים לעשות את המהפך הזה. אני חושב שפשוט, אתה יודע, הבנו את זה ופשוט עשינו את זה, כי הבנו שאין לנו ברירה, כאילו זה ממש הגיע משם. ואיך אתם בתור מנהלי מוצר ידעתם בכלל מה לבנות לכם, איך לגשת בכלל לבנייה הזאת של האג'נטים עבורכם, אמרת רגע קומפטיטיב אנליסיס, איך בכלל אמרתם, אוקיי, זה סטפ שאני רוצה עכשיו לעשות אאוטסורס לאג'נט, או אני בונה לי את האג'נט לדבר הזה? אז זה מעניין שאתה שואל את זה, כי אני חושב שהתהליך הזה היה תהליך ש... עזר לנו להבין יותר טוב את הלקוחות שלנו, כי מה בעצם, שאלנו את הלקוחות, שאלנו אותם מה time consuming, what's a bottleneck, איך אתם עושים את זה היום, וזה פשוט מה ששאלנו את עצמנו, כאילו באמת, כאילו ששאלנו את עצמנו, רגע, מהרגע שאנחנו, לא שיש לנו process כזה בפיגמה, שעשינו, מהרגע שאנחנו מקבלים החלטה על איזשהו אייטם ברודמאפ שחולחים עליו, מה התהליך שאנחנו עושים, וכל שלב התהליך שאלנו את עצמנו, אפשר או אי אפשר לעשות את זה אג'נטי? צריך פה Human in the Loop או לא צריך Human in the Loop ופשוט כמה שיותר הכנסנו לאוטומציה. אני אוהב את ה-Reverse User Journey הזה שזה בעצם אתה היוזר, כאילו קודם אנחנו אומרים למנהלי מוצר אתה לא היוזר, אתה כן היוזר. הפעם אתה היוזר, בדיוק. אוקיי, אז אתה אומר רגע, אבל בעצם היה פה שלב אחד של קודם כל רגע סוג של הקאטון כזה, שקודם כל שרפתם את הספינות, ניתקתם את כל הלייסנסים ואז אומרים הקאטון. בוא נרים רגע את הפיצ'רים וראיתם שהדבר הזה עובד, עשיתם את האיג'נטים שלכם בתור פרודקט ואז כזה מה קורה. ועכשיו אנחנו צריכים להתחיל לשאול את עצמנו שאלות מאוד קשות, כי מעבר לפשוט ללכת ולפתח את הוורקפלואו שזה בסדר, אנחנו צריכים לשאול את עצמנו איך המוצר הזה ייראה בעתיד, מה זה בכלל אומר להיות מוצר אג'נטי, אז אני יכול לתת סתם דוגמאות לכל מיני דילמות. אג'נט אחד או כמה אג'נטים? כאילו מה אנחנו בעצם עושים? אנחנו מוכרים איזשהו אג'נט שהוא איזה מין אורקל יודע כל שיודע לעשות הכל ואתה מדבר איתו? או שאולי אנחנו עוזרים ליוזרים שלנו על ידי זה שאנחנו מפרקים את זה לכמה אג'נטים שכל אחד מתמחה במשהו. הוא מתמחה בריסק אססמנט, הוא מתמחה במשהו אחר. ואז נשאלת השאלה מה היוזרים צריכים לזכור עם מי לדבר? איך מעל הדבר הזה, לא משנה על כמה אג'נטים החלטנו ללכת. איך אנחנו עושים לדבר הזה פקג'ינג ופרייסינג? וכמובן, בראש ובראשונה, מה תהיה החוויה? כי אנחנו בעצם, אנחנו יכולים ללכת על כיוון שהוא, בוא נגיד, מאוד דומה למה שיש לנו היום, שהוא עדיין דשבורדים שהם יחסית כאלה סטטיים, אבל האייג'נט איך שהוא משתלב בהם, ובצד השני, אנחנו יכולים ללכת לכיוון שהוא פשוט 100% צ'אט gpt, אתה נכנס ואתה רואה פרומפט. אז איפה אתה ממקם את עצמך על הציר הזה? זה סוג השאלות שהיינו צריכים בעצם להכריע לגביהן.

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

אני ממש ממש ממש מסכים, ואני גם אגיד שיש פתרונות. כן, כאילו, אני יכול לתת דוגמאות לכל מיני פיצוחים קטנים כאלה שהיו לנו. אז אם נגיד אנחנו הגענו למצב, בואו ניקח שוב את הדוגמה של ה-Risk Assessment, שהיוזר יכול לשלוט באיך ה-Risk Assessment מתבצע, והוא יכול לשלוט באיך נראות התוצאות, ממש איך הווידג'יטים נראים, ואיך, אני מתכוון איך התוצאות נראות. הרפורט הבסוף. כן, הרפורט בסוף, והוא גם יכול לשלוט באיזה פעולות. האג'נט יכול לעשות on top of that report, כאילו ממש מה שדיברנו עליו על כל החלק של האקשנס. ברגע שהוא הגיע לנקודה הזאת, אנחנו כן נותנים לו אופציה של מין save this, save you, run this on a regular cadence, ואתה יודע, ופשוט כאילו להריץ לו את זה בצורה אוטומטית, לעשות לו כזה prompting בשבילו אם יש איזושהי בעיה שהיא מאוד מאוד חמורה, והוא כמובן יכול כאילו לעשות את זה מחדש ואם הוא רוצה איזושהי גרסה אחרת. אבל זה נגיד איזושהי נקודה שהבנו, אוקיי, כאילו... אנחנו צריכים גם לתמוך ב-capabilities הישנים האלה, הקלאסיים, כדי שהוא לא יצטרך כל הזמן להסתבך עם פרומפטים ורק לחיות בתוך הצ'אט. כן, אני חושב שנקודת פיצוח טובה היא פה צ'קפוינטים, כמו במשחק מחשב, הגעת לנקודה הזאת, הכל עבד לך, זה כבר אתה יכול להמשיך מהנקודה הזאת ולא להתחיל הכל מאפס, כי זה באמת מה שאנחנו, מה שאני לפחות רואה זה שבגלל שקשה לנו לעשות את הפעולה, אנחנו עושים אותה כל פעם מאפס, אנחנו לא יודעים לערוך אותה, היה לנו פרק מצוין עם רזי מפקאן AI, שבדיוק דיברנו על זה, נתנו כל כך הרבה כלים למשתמשים, שהם לא ידעו כבר לערוך את זה, כאילו פתרנו להם כל כך הרבה זמן שהם לא ידעו לערוך, אז הם היו מייצרים עוד תהליכים ועוד תהליכים חדשים. והפיצוח הזה של להגיד, אוקיי, עד לפה הבנתי מה קורה, בוא נמשיך מכאן, אני חושב שהוא פיצוח מאוד חשוב. הוא פיצוח חשוב, אני חושב שהוא, לקח לנו זמן להגיע אליו, אבל אם רגע מתחברים למקורות, היינו יכולים לצפות אותו. כי אם אנחנו בעצם מפתחים agent שנועד להחליף בן אדם, אז ההגבלה הכי קלאסית היא שמגיע לך חבר צוות חדש, אתה רוצה שהוא יעבוד בצורה מסוימת, מסוימת, אתה מלמד אותו, אתה מסביר לו, אתה אומר לו, אלה האינטגרציות שאתה צריך לעשות, פה יש לך הרבה חופש פעולה, תקבל את ההחלטות שאתה רוצה, אלה הפעולות שצריך לבצע על זה, אבל ברגע שסיימת את החלק הזה, אתה פשוט יכול להגיד לו, תקשיב, והדבר הזה צריך לקרות אחת לחודש. אז כאילו, זה כל הזמן לדעתי החשיבה שאנחנו צריכים לשמר, של איך שזה עובד עם בני אדם, ככה אנחנו צריכים לנסות לשחזר את זה בעבודה עם אייג'נטים. זה חוכמה ודיעבד. אבל אני חושב שזה נקודה חשובה שאנחנו בעצם אומרים, אנחנו צריכים לעשות, לעזור ליוזרים שלנו לעשות אונבורדינג לפיצ'ר הזה, לקייפביליטי הזה, כאילו להבין שיש סטפ אונבורדינגי לתוך הארגון שלי, ואז סטפ של סטדיוס. אני חושב שזה, כאילו כשאנחנו בתור מנהל נוצר נחשוב רגע על שתי הסביביות האלה, זה יעזור לנו רגע לפצח איך אנחנו עוזרים להם לעשות אונבורדינג יותר טוב, ואז איך אנחנו עוזרים לשמר את מה שפיצחנו ולעשות אותו בקיידנס קבוע כמו שאתה מדבר. ממש. אגב, עוד לרנינג, המרקטינג שלנו היה קצת יותר מדי לכיוון של אנחנו הולכים להחליף אתכם, כאילו זה אייג'נטים שממש מחליפים אנשים, שזה יצר הרבה לחץ, אגב לאו דווקא אצל אנשים שפחדו שיפטרו אותם, דווקא יותר אצל מנהלים שאמרו, רגע שנייה, אם לא יהיה לי אנטרי לבל, אז לא יהיה לי מי שביום אחד יהפוך להיות מיד לבל וסיניור לבל, זו נקודה שהיא מאוד חשובה, אז אני חושב שהדרך הנכונה to market it, זה דווקא to supercharge the team, to enforce the team. בחיים לא אמרנו את המילה to replace, אבל גם שזה לא ישתמר. כולם נשארים בעבודה שלהם, אנחנו פשוט מורידים לכם חלק מהלואוד. אז זה יותר מהgo-to-market, אבל זו נקודה שהיא חשובה.

מעולה, ומה אתם רואים מאז השינוי? אז אנחנו כרגע עוד לא עשינו אונבורדינג ללקוח חדש של הדבר הזה, זה משהו שאנחנו עכשיו בתהליך. ופשוט להתחיל להעביר אותם אחד אחד, ואנחנו רואים אדופשן, שזה דבר מאוד מאוד מגניב, ויצרנו לעצמנו גם KPI של Early Renewal, של בעצם לראות שהדבר הזה מביא להם מספיק ערך, בשביל שהם יהיו מוכנים להתחייב מראש, גם אם הרניוול שלהם רחוק, כבר יהיו מוכנים להתחייב מראש שהם רוצים להמשיך איתנו. זה היה KPI שבחרנו, וזה כבר משהו שאנחנו רואים, אז אני מאוד מחכה לראות איך זה ייראה כשנתחיל למכור את זה ללקוחות החדשים. אני חושב שזה סיגנל מרתק להגיד, אוקיי, בוא נסתכל אם אנחנו אומרים לכם, זה היכולת, קיבלתם אותה, האם אתם מוכנים לחדש היום, גם אם החידוש שלכם הוא בדצמבר, הנה, אתם ראיתם את ה-value, בואו תשימו קומיטמנט. זה בול מה שכיוונו אליו, אני חושב שאין סיגנל שאנחנו יכולים לעשות שהוא יותר טוב עם לקוחות קיימים, בסוף אתה רוצה to tie it to revenue, וזה הדרך היחידה לעשות את זה. כן, אבל ה-early renewal הוא מעניין, כי בדרך כלל הרבה חברות, הרבה צוותים אומרים, אוקיי, בוא נחכה לראות אם היה renewal, וזה סיגנל. אז אתה אומר לו לא, בוא נגרום להם גם להכניס פה איזשהו פורסט פונקשן. בול. מה כזה, אם אנחנו דיברנו על די הרבה דברים, מעניין אותי לשמוע רגע מה התובנות שלך מכל הדבר הזה, או מה היית עושה רגע אחרת.

אני חושב שתובנה ראשונה היא שכל אחד צריך לשאול את עצמו, האם המוצר שלי כרגע יכול להפוך להיות אג'נטי, וכל הזמן לשאול את עצמו את השאלה הזאת, ועל כל אחת מהיכולות, כי אם יש שם פוטנציאל, אני חושב שכדאי לעשות את זה, אני ממש חושב שזה... באמת, יש כאן פוטנציאל לכל חברה להתפוצץ ופשוט לתת הרבה יותר value ממה שהם מביאים היום. תובנה נוספת היא שאתה צריך להפוך את החברה לאג'נטיק, כאילו שזה משהו שדיברנו עליו, אני חושב שעל זה לא הייתי מדלג, אני חושב שזה באמת בלתי אפשרי, וכמו שאתה אמרת, אתה חייב להיות רגע היוזר בעצמך כדי להבין איך הדבר הזה עובד. אולי כאילו... תמיד אפשר להגיד את זה, אבל ללא שום ספק אם היינו עושים יותר ולידציה, בטח ובטח על האזורים האלה של הפוזישינים והפקג'ינג והאייג'נטים, זה צריך לדעת שזה נקודת תורפה, וצריך גם להבין שאין הרבה מקורות השראה. ממש. אין, כאילו אני ממש חיפשתי, קודם כל בסיקירותי כמעט לא היה לי על מה להסתכל, אז הסתכלנו במקומות אחרים. כל אחד עושה משהו אחר לגמרי, אז אני חושב שהיינו צריכים לשים שם יותר דגש, ולשים יותר דגש באמת על הוולידציה, בטח ובטח מול לקוחות. To get it right the first time, כי זה נקודת תורפה שאף אחד עדיין לא יודע איך עושים את זה, אז לקחת את זה בחשבון. אני חושב שזה מה שאני לוקח גם מהפרק הזה, זה קודם כל אנחנו תמיד רוצים לפתור את הבעיות של המשתמשים, אבל מה שאנחנו בעצם עושים זה אנחנו נותנים להם כלים לפתור את הבעיות של עצמם, ופה בחוויה אג'נטית אנחנו באמת פותרים להם את הבעיות, ואז התהליך של ולידציה משתנה כשאנחנו רוצים רגע לשקף. את ה-reasoning לאיך פתרנו את הבעיה ועל זה ולידציה ולא על זה שפתרנו את הבעיה. דווקא זה הנקודה שאני לוקח מאוד חזק לעולמות של Discovery. והדבר השני זה באמת ששינוי במוצר לא יכול לקרות בלי שינוי בחברה. אם אנחנו רוצים לעשות שינוי רדיקלי במוצר, אנחנו צריכים לעשות שינוי רדיקלי בחברה, אחרת באמת זה פשוט לעשות אוטומציה ולקרוא ל-AI וזה משהו שבעיניי הוא מאוד מאוד חזק. אז אמיר המון המון תודה. תודה רבה. ורגע לפני שנסיים אני אגיד שאם אתם רוצים לדעת בכל פעם שיוצא פרק חדש בתוכנית שלנו אתם מוזמנים לעקוב אחרינו בכל אחת מהאפליקציות. אז שוב תודה רבה אמיר. ממש תודה על ההזדמנות. ותודה רבה לכם שהאזנתם.