בפרק הראשון בעונה השניה של פיתוח בהפרעה, ישי בארי, CTO ב LinearB מארח שתי אורחות מ Gloat, יוליה טרכטנברג ה VP R&D וויקטוריה קלמנוביץ מנהלת פיתוח לבקאנד ודאטה. איתו הן סוקרות את כל העולם של מוצרי דאטה, האתגרים הייחודיים בפיתוח טכנולוגיה עם דגש על אספקטים של דאטה, ואיפה זה פוגש את ניהול הפיתוח וחוויית מפתח כמובן - הנושאים האהובים עלינו.
In our first episode in Season 2 of Dev Interrupted - the Hebrew Edition, Yishai Beeri, CTO at LinearB, hosts two guests from Gloat - Yulia Trakhtenberg VP R&D, and Victoria Kalmanovich, Backend & Data Engineering Manager (as well as DevOpsDays Tel Aviv musical performer). In this episode they chat about the unique challenges of building data products, software engineering with a focus on data aspects, and of course how this impacts engineering management and developer experience...our favorite topics.
Tune in!
בפרק הראשון בעונה השניה של פיתוח בהפרעה, ישי בארי, CTO ב LinearB מארח שתי אורחות מ Gloat, יוליה טרכטנברג ה VP R&D וויקטוריה קלמנוביץ מנהלת פיתוח לבקאנד ודאטה. איתו הן סוקרות את כל העולם של מוצרי דאטה, האתגרים הייחודיים בפיתוח טכנולוגיה עם דגש על אספקטים של דאטה, ואיפה זה פוגש את ניהול הפיתוח וחוויית מפתח כמובן - הנושאים האהובים עלינו.
In our first episode in Season 2 of Dev Interrupted - the Hebrew Edition, Yishai Beeri, CTO at LinearB, hosts two guests from Gloat - Yulia Trakhtenberg VP R&D, and Victoria Kalmanovich, Backend & Data Engineering Manager (as well as DevOpsDays Tel Aviv musical performer). In this episode they chat about the unique challenges of building data products, software engineering with a focus on data aspects, and of course how this impacts engineering management and developer experience...our favorite topics.
Tune in!
Episode Transcript תמליל הפרק
Hebrew, then English*
בעברית ואז אנגלית:
(*Translated with Google Translate - so there may be some errors)
(מוסיקת פתיח)
ישי: ברוכים הבאים לעונה השניה של פיתוח בהפרעה, הגרסה העברית ל dev interrupted, הפודקאסט המצליח של LinearB למנהלי ומנהלות פיתוח. נארח פה מובילים ומובילות מהתעשיה ונדבר איתם על כל מה שמעניין מנהלי פיתוח, מי שעובד איתם, ומי שרוצה יום אחד לנהל ארגון פיתוח. בעונה הזו נשים דגש מיוחד על חוויית המפתח - Developer Experience. אני ישי בארי, CTO ב LinearB. כבר מתחילים.
ישי: בפרק הזה אני שמח לארח את יוליה טרכטנברג, VP R&D ב Gloat, ואת ויקי קלמנוביץ', מנהלת פיתוח ב Gloat, אהלן, איזה כיף שבאתן.
יוליה וויקי: איזה כיף להיות פה.
ישי: כמו תמיד, אנחנו מתחילים ממש בכמה מילים, נשמח לשמוע מכל אחת מכן איך הקריירה שלך התפתחה ואיך הגעת עד הלום, אז יוליה, בואי תתחילי את.
יוליה: אני מתחילה, סבבה. אז אני בהייטק אני חושבת למעלה מ-20 שנה, עשיתי תואר במדעי המחשב, כמו כולם, התחלתי בזמני המשבר הראשון, 2001, בחברת טלפוניה, שמה למדתי טוב-טוב את ה-C++, את העומק של ה- threading וכל ה-bits & bytes של הפיתוח. משם התפתחתי לניהול, התחלתי כראש צוות, ראש קבוצה, והבנתי שעולם הסטארטאפים יותר מעניין אותי ועברתי לעבוד בסטארטאפים. אז בשנתיים האחרונות אני ב Gloat, מנהלת פיתוח. בשנתיים האחרונות אנחנו גדלנו בצורה משמעותית, גם כחברה וגם כפיתוח, פיתחנו מוצרים חדשים, שינינו את הכיוון לחלוטין, הבאנו לקוחות אנטרפרייז מאוד משמעותיים, ככה שאני חושבת שהדרך שעשינו כחברה היא מאוד מעניינת ונדבר על זה קצת.
ישי: בהחלט. אז היום את VP R&D ב Gloat, כמה אנשים בארגון הפיתוח פחות או יותר?
יוליה: 70 אנשים.
ישי: 70, מעולה, אז אנחנו תכף נצלול גם על קצת לשמוע על מה Gloat עושה, אבל ויקי בואי ספרי לי את על המסלול שלך.
ויקי: אז אני ב Gloat חודש וחצי (צוחקת), שזה מאוד מרגש.
ישי: זהו, נגמר ה"גרייס" עכשיו.
ויקי: כן (צוחקת) בסטארטאפים הוא נגמר מאוד מוקדם, אתה יודע את זה. אז לפני זה הייתי בחברה בשם אספקטיבה, שנרכשנו ע"י Walmart, עשינו שם כל מיני גם מוצרי דאטה מבוססים על NLP, ולפני זה הייתי בערך 10 שנים בתפקידים טכנולוגיים בצבא, אז ככה שאני מנהלת כמעט 7 שנים, וזהו.
ישי: מעולה. אז תספרו לי בכמה מילים מה Gloat עושה, רק שיהיה לנו קונטקסט.
יוליה: Gloat מפתחת מוצרים לאנטרפרייזים בעולם ה-HR Tech, בעצם ארגונים היום רוצים מאוד מאוד לדעת איזה skill sets יש ל-workforce שלהם, לארגון שלהם, לעובדים, ולתכנן אותו קדימה. מה יהיה חסר בעוד שנה? בעוד 3 שנים, בעוד 5 שנים? ובעצם אנחנו מפתחים כמה מוצרים שנותנים אחד, את היכולת להבין איפה הארגון עומד עכשיו לעומת השוק, לעומת הורטיקל שלו ולאן רוצים לקחת את הארגון, וזה מתחבר למוצר השני שמאפשר לעובדים בתוך הארגון להתפתח. אז בעצם יש פה שני צדדים, אחד, איך העובדים מתפתחים, איזה opportunities הם יכולים לקחת ולפתח את הקריירה שלהם בתוך הארגון, ושתיים, איך הארגון גם יכול לכוון אותם למשהו שיהיה מאוד רלוונטי עבור הארגון בעוד 3 ו-5 שנים.
ישי: הבנתי, אז זה מתחבר למערכות, נגיד כמו workday וכאלה של יותר ניהול HR, ומצד שני ל-learning ו-development?
יוליה: אז אנחנו עומדים באמצע בעצם, אנחנו מתחברים למערכות כמו workday, HCMs למיניהן כדי לקבל את הדאטה עבור ה-employees, כדי לדעת מה הם יודעים לעשות, איזה skill set יש להם נכון לעכשיו. כמובן שהם יכולים להעשיר אותו בתוך הפלטפורמה שלנו, ומתחברים למערכות כמו learning ונוספות, שמאפשרות להביא ל-talent marketplace, שזה בעצם המוצר השני שאמרתי שבו העובדים מתפתחים, הרבה מאוד opportunities, ושם העובד יכול להגיד אני היום ג'וניור frontend developer, אני רואה את עצמי בעוד 5-6 שנים senior architect. איך אני עושה את זה בתוך הארגון שלי? ואנחנו בעזרת כל ה-opportunities, מנטורים, קורסים, פרויקטים, משרות באמצע, בונים לו קריירה ועוזרים לו לקח כל צעד בקריירה ולהסביר לו מה הוא צריך לעשות.
ישי: הבנתי, אז זה גם מתחבר לעולם של hiring וגם של promotions או skilling up, בסוף הצלחתי להתקדם ב-skills שלי, אולי אני יכול לקבל promotion ולהתקדם.
יוליה: לגמרי.
ישי: מעולה. אנחנו נדבר היום על מוצרי דאטה, איזשהו עולם של מוצרים שבסוף משתמש בדאטה ומנגיש דאטה ללקוחות כדי לתת להם value, ו Gloat נשמע כמו מוצר דאטה. ואני רוצה לגעת איתכן על, כאילו להבין איפה זה שונה, איפה זה דומה, איזה אתגרים זה מעמיד בפני מנהל פיתוח או ראש צוות או מי שבסוף עוסק בלדלבר את זה. אז ויקי, אולי נתחיל איתך, מה לדעתך, איפה הנקודות העיקריות שמוצרי דאטה מתנהגים שונה.
ויקי: אני, האמת אני אתחיל אולי טיפה להתחבר למה שיוליה אמרה קודם לגבי המוצר. בגדול, הרבה מאוד מהדברים שאנחנו עושים היום, הם אמורים לעזור להרבה מאוד אנשים בתוך חברות מאוד מאוד גדולות, שזה מאוד קשה להגיע להזדמנויות הנכונות עבור כל בן אדם בצורה פרטנית בלי להסתכל על הדברים בצורה מאוד כוללת כאילו, ולהיעזר בדאטה. יש חברות שהן כאילו 100 אלף עובדים ויותר, וזה מאוד מאוד קשה, אני חושבת, לארגוני HR בתוך החברות האלה, להגיע לכל עובד ולעזור לכל עובד בנפרד. ולכן כאן דאטה זה פשוט, אנחנו חייבים להיות ארגון data driven, כאילו אין מה לעשות. פשוט אתה לעולם לא תצליח להגיע לאנשים שלך ואם זה משהו שחשוב לך אז אתה חייב ללמוד איך להבין את העובד של, איך לקבל עליו את כל הדאטה שצריך ואיך להשתמש בדאטה הזה אחר כך בשביל לתת לו את ההזדמנויות הכי מתאימות בשבילו. ואיך שזה שונה מארגונים אחרים? זה פשוט בהיבט הזה של מה אתה עושה עם הדאטה הזה, כאילו איך אתה אוסף את הדאטה, מה אתה עושה איתו, איך אתה נותן את האינסייטים בחזרה.
ישי: כן, אז אם אני מסתכל על מוצרים, בעולם של SaaS, או בעולם של מוצרי תוכנה בכלל, יש הרבה דברים שקשורים ל-flow, איך אני עושה איזה task, איך אני משיג מטרה, ואם אני מסתכל על מוצרי דאטה אז שמה אולי הדאטה הוא המלך ולא ה-flow. זה לא משנה או, זה וודאי חשוב שה-UX יהיה טוב ושאני אוכל לעשות משהו עם הדאטה, אבל יש קודם כל value בעובדה שהדאטה הזה מוצג, יש שם אינסייטיס וכו'. ומעניין אותי להבין, כשאני מפתח מוצר דאטה כזה, שבו הדגש הוא לא תמיד על ה-usability או על להביא אותי ממקום איקס, אני לא יודע, לקחתי "ליים" בדרך לכאן. יש שם מלא דאטה אבל הוא לא משרת אותי כיוזר, אני צריך בסוף למצוא את הקורקינט, להפעיל אותו, להגיע לפה, לסגור את הנסיעה ולשלם. אז לי זה לא מוצר דאטה, יש יוזרים אחרים,
ויקי: לך לא, אבל גם ב"ליים" יש הרבה מאוד דאטה כדי לדעת, להביא את הקורקינטים למקומות שהכי הרבה ידרשו אותם. אז אני חושבת שהיום כשאנחנו חיים בעולם המוצרים עם הרבה מאוד משתמשים, כמעט כל מוצר יש בו איזשהו מרכיב של דאטה וכנראה הביג דאטה, כן? כדי להביא את האינסייט וכדי להביא את המוצר, זה סגנון אחד של המוצרים. והסגנון השני, אני חושבת שהיום עולם ה-go to market הוא הרבה פעמים מתבסס על הדאטה, כשאתה רוצה למכור, כשאתה רוצה להחליט על איזה מוצר אתה הולך, על איזה כיוון, הרי יש לנו אינסוף אפשרויות ויש לנו שמיכה קצרה של הריסורסים. אנחנו תמיד רוצים לדעת איך לעשות פריוריטיזציה וכל ה-, פעם העולמות האלה של risk ו effort וכל העולמות האלה של פרודקט להחליט הם נחמדים, אבל היום יש עוד מרכיב של דאטה analysis שאתה יכול לעשות, להגיד מראש האם המוצר הולך להצליח לך או לא, לפי הדאטה שאתה אוסף מהשטח לפני שאתה מממש את המוצר.
ישי: כן, אז יש פה עולם של דאטה לשימוש פנימי, דאטה ל-BI, דאטה לפרודקט אנליטיקס, להוריד פריקשן בפרודקט, להבין איזה יוזרים, במה הם נתקעים וכן הלאה. ויש את הדאטה פרודקטס שממש שמים את הדאטה בעיקר לפלואים וליוזרים שבסופו של דבר משתמשים בזה.
ויקי: כשאתה לוקח דאטה analysis כאילו, אני אתחבר רגע למה שאמרת, אם אנחנו רוצים לעשות, אמרת קודם שיש נגיד טאסקים בעולם הקלאסי בלי דאטה involved. אבל אם אנחנו רוצים לדעת איזה בעצם value אנחנו רוצים לתת ליוזרים, ויש לנו הרבה דאטה ואנחנו רק צריכים לחשוב מה האגרגציה הנכונה או מה הלא יודעת, מה הפרוססינג הנכון שאני צריכה לעשות לדאטה, אז אני יכולה לעשות את זה כבר מראש. יש לי את כל הדאטה, אני יכולה לעשות עליו אנליסיס, אני יכולה לבדוק איזה פיצ'רים אני יכולה לספק שיתנו איזה סוג של value ואז לפי העיבוד שלי של הדאטה אני יכולה להבין איפה היוזרים שלי יקבלו את המקסימום value שלהם.
ישי: כן, שזה שימוש פנימי בעצם.
ויקי: גם שימוש פנימי וגם שימוש חיצוני. מה הכוונה שימוש פנימי?
ישי: אם אני צריך להחליט איך לפתח פיצ'ר או אפילו איזה UX מתאים, אני משתמש בדאטה שאני אגרתי כדי לפתח מוצר יותר טוב. גם האינטרפייס שאני עבדתי איתו שלקחתי את הקורקינט לפה נשען על דאטה מאחורי הקלעים, מישהו אמר וואלה, אם הכפתור בצד ימין למעלה, היוזרים פחות מתבלבלים.
ויקי: אז הכוונה שלי יותר למשל אם החברה כחברת דאטה פרודקטס רוצה לתת איזשהו מוצר ליוזר, והיא לא יודעת אם המוצר הזה יהיה valuable על סמך הדאטה שיש לה, אז אפשר לעשות את זה בכלים שיש לנו/ כאילו אנחנו יכולים לעשות analysis על הדאטה שיש לנו, להבין איך אנחנו עושים את הפרוססינג הזה וזה לא לשימוש פנימי, זה יותר להבין מה צורך של הלקוחות ואיך אנחנו עונים עליו.
ישי: אוקיי, אז כשאני בונה מוצר ששוב, הדאטה הוא הלב שלו וגם זה עיקר ה-value שהלקוחות מקבלים ממנו, איפה כאן תהליך הפיתוח או תהליך העבודה בבניה של המוצר הזה? איפה זה שונה או דומה לתהליך שאני בונה מוצר מסוג אחר, שהוא לא דווקא דאטה אוריינטד או שהדאטה הוא לא העיקר שלו, איפה זה פוגש אותי בתהליכי סייקלים מול פרודקט או בלמידה מול מה עובד ללקוחות ומה לא.
יוליה: אני?
ישי: לכי על זה.
יוליה: אז אני חושבת שאם אנחנו מתחילים לדבר על פיתוח מוצר, אני חושבת שהרבה פעמים כל מנהל מוצר, כל חברה, תעדיף לפתח מוצר שיש לה איזשהו use case אמיתי ואפילו partnership, design partner כזה, שאיתו אפשר לפתח את המוצר. וזה מתאים גם למוצרים שהם דאטה אוריינטד ומוצרים אחרים. במוצרים שהם דאטה אוריינטד אני חושבת שכשיש לך design partner שיכול להסתכל על דאטה ולהגיד כמה הוא איכותני, כמה הוא מביא לו את הערך, הרי בסופו של דבר מה מוצרים, מה כל, אנחנו מכניסים אולי איזשהו innovation ודברים כאלה ואנחנו גם מורידים את כמות העבודה הידנית ומייגעת אולי של לבנות דברים, אולי אנחנו פותרים בעיה שאי אפשר לפתור, כמו שויקי אמרה היום בעולם ה-, בחברות הגדולות, אי אפשר להגיע לכל עובד ועובד ולהציע לו דברים. אז במקרים האלה האם אנחנו מציעים הצעות רלוונטיות, האם אנחנו מציעים מסלולים רלוונטיים לעובדים, אני חושבת שבלי design partner לא היינו יכולים לדעת האם ה-flow, האם המוצר שלנו טוב, כי ה-flow אולי בסדר, כן? אנחנו מציעים career path לעובד, אבל האם ה-career path הזה מעניין? האם העובדים יעשו עליו לייק או דיסלייק? זה משהו שאנחנו חייבים פה design partner לעזור, וזה בד"כ מאפיין מוצרי דאטה, שאתה מסתכל,
ישי: זאת אומרת ההישענות שלהם על design partner היא יותר מהותית ויותר קשה להתקדם בלי design partner אמיתיים, בניגוד אולי למוצרים אחרים שאני יכול לעשות קצת יותר התקדמות, גם אם עוד אין לי בדיוק את ה-design partner שנותן לי פידבק בכל רגע.
יוליה: אלא אם כן אתה יודע מה ה-end game, כן? מה המוצר הסופי שאתה, מה האימפקט הסופי שאתה רוצה להגיע אליו, כן? במקרים שלנו, בגלל שזה איטרציות, בגלל שזה עבודה עם אנשים, קשה מאוד לדעת מה אנשים יאהבו ומה אנשים יעדיפו.
ישי: גם הדאטה יכול להפתיע.
יוליה: גם הדאטה יכול להפתיע, כל ארגון הוא שונה במבנה שלו וביכולת התקדמות של העובד בתוך הארגון, ולכן זה נורא מעניין לעבוד כן עם ה-design partners הגדולים והמגדירים את התחום הזה. בעצם כל העולם של פיתוח עובדים הוא יחסית חדש.
ישי: כן, אז גם לא תמיד היוזרים יודעים מה הם צריכים ורוצים. זה אומר שכשאני עובד עם design partners אני, שוב, על מוצרי דאטה, אני צריך לדרוש מהם יותר? יש skills נוספים שהם צריכים להיות מסוגלים להסתכל על דאטה שהוא עוד לא לגמרי לעוס ולהגיד יש פה משהו. זאת אומרת אולי הם צריכים להיות power users יותר מאשר יוזרים רגילים, כשאני עושה design partnership על מוצר שהוא בעיקרו flow?
יוליה: כמו ב adoption של כל מוצר, יש לך את ה-early adopters האלה המשוגעים שילכו איתך גם כשיש במוצר שלך אלף באגים, וכן יראו לך מה טוב ומה לא טוב, אני חושבת שככה אתה צריך לבחור גם את ה-design partner. כנראה שלא תביא מישהו שהכל אצלו צריך להיות מדויק ומסודר, כנראה שפה אתה, אתה כנראה תיכשל, אם אתה בונה design partnership על בסיס בנאדם כזה או לקוח כזה. אבל אם אתה לוקח את הדרימר (dreamer), ואיתו אתה הולך, אז הוא יכול לחלום יחד איתך ולהגיד או, פה אני רואה את הערך שלי, בואו נתחיל לחפור פה, באזור הזה.
"כמו ב adoption של כל מוצר, יש לך את ה-early adopters האלה המשוגעים שילכו איתך גם כשיש במוצר שלך אלף באגים, וכן יראו לך מה טוב ומה לא טוב, אני חושבת שככה אתה צריך לבחור גם את ה-design partner."
ישי: אוקיי. מה לגבי delivery של value מחוץ למוצר, בתור כלי ללמידה? אני יכול לדמיין, אם אני חושב על העולם שלכן, בוא נוציא לך גוגל שיט או איזשהו אקסל עם דאטה שהוא כבר אקשנבל (actionable), אבל הוא לא תפור לפלואים, הוא לא במוצר, נקבל על זה פידבק, נראה שאתה מצליח לעשות, נגיד אם אני מדבר על career path, מישהו יכול להסתכל על האאוטפוט הזה בעיניים ולהגיד וואלה, נראה הגיוני, וואלה אני ידנית אתפוס 10 עובדים וננסה לראות את הפידבק שלהם על הדאטה שהוצאתי. לגמרי מחוץ למוצר או לגמרי, כאילו הרבה פחות engineering, לקבל את הפידבק ואז להמשיך, להקדים כאילו את הפידבק מהשטח, לעבודת פיתוח אמיתית או סגירה של פלואס (flows) ו-UX וכו'. זה דבר שיוצא לכם ל-,
ויקי: השאלה מה אתה רוצה להשיג בדבר הזה, כאילו אתה רוצה למתג את עצמך בתור חברה שהיא מספקת APIs של data raw ולך תעשה איזה אנליזה שמתאימה לך כחברה? שזה גם בסדר, יש חברות שעושות את זה, או אתה רוצה למתג את עצמך ולתת הרבה מאוד כלים כמו שאנחנו עושים, שזה פשוט פלטפורמה שלמה של הכל מהכל, ואז לתת עוד איזה משהו raw data שתעשה לו אנליסיס בעצמך, זה לא נותן את האימפקט המלא כמו לקבל את כל מה שאתה מקבל בתוך כל הפלטפורמה.
ישי: כן, אז אני חושב על הפרדה כאן בין, אם אני מדבר על, שוב, איזושהי סיפור של הצעות של career path, אז יש לי את ה-, אוקיי, בסוף עובד צריך לקבל הצעות, מותאמות אישית, ולהגיב אליהן, לבחור אותן ולהשתמש במערכת הזאת. אז המערכת נמדדת על זה שזה קל למצוא וקל לי לתת פידבק ולהבין מה אני רואה וכו', אבל יש בו גם איזה core שאומר בכלל הבאתי לך career path טובים או לא, אני יכול לנתק את השאלות ולהגיד, אני אשים לך רגע את זה ב-document, תגיד לי כן או לא, ואני לא עדיין שואל את עצמי האם ה-flow אינטואיטיבי, האם קל למצוא את הכפתור, איך עושים search. כאילו אני מפריד שאלות usability משאלות על דאטה, אולי הדאטה שלנו לא יודע להציף career path טובים ואז אין לי מה לבנות UI ומרקט פלייס ופלואים אם הדאטה לא עובד.
יוליה: אני מאוד מתחברת לגישה הזאת, אני חושבת שלפני שמתחילים להשקיע הרבה, צריך להבין שהבסיס הוא טוב, והבסיס פה הוא דאטה ואלגוריתם מבוסס AI שיכול להביא לך את הדאטה טוב. יותר מזה, אתה כנראה תמשיך לשפר את האלגוריתם שלך כל הזמן וזאת תהיה הדרך שלך לבדוק, לא תחבר את זה ישר לפרודקשן ול-UI כדי לדעת אם הלינים שלך טובים, כן? אז אני מאוד מתחברת לגישה הזאת, אני חושבת, אני יכולה להגיד שאפילו באיד הארגונים שעבדתי בהם לפני זה, לפני Gloat. היה לנו שנה שלמה מוצר שהוא התנהל באקסלים עם design partners, בלי UI, בלי שום דבר, כדי להוכיח שיש בכלל היתכנות למוצר הזה, לפני שהבאנו value לכמה לקוחות שעבדו עם אקסלים, לא בנינו שורת קוד לא בב-backend ולא ב-frontend, רק בדאטה. כל מה שעשינו זה היה רק בדאטה, רק לראות שהמוצר הזה יביא ערך.
״אני חושבת שלפני שמתחילים להשקיע הרבה, צריך להבין שהבסיס הוא טוב, והבסיס פה הוא דאטה ואלגוריתם מבוסס AI."
ישי: מה זה עושה לאיש פרודקט? שעושים כזה תהליך שהוא או קיצוני לגמרי מחוץ למוצר בלי קוד, או שהשאלות העיקריות הן האם הדאטה טוב, האם הצלחנו להביא אינסייטס (insights) איך הקשר בין הפרודקט ל-engineering משתנה או נראה אחרת כשזה הפוקוס.
ויקי: אני חושבת שבחברה הקודמת שלי שגם עשינו דאטה פרודקטס ובעצם הפרודקטית שעבדתי איתה שם היא הייתה מאוד חזקה במטריקות והיא מאוד ניסתה להבין את הלקוחות ומה הם צריכים ואיך אנחנו מייצרים כאילו את ה-most valuable data features, כאילו אז היא הייתה מאוד מאוד מחוברת להיבטים של הדאטה אנליסיס, להיבטים של כאילו המטריקות שאנחנו רוצים למצוא, וגם כאילו איזה AB testing כדאי שנעשה ובהיבטים של הדאטה. אז ככל שהפרודקט באמת הייתה שם יותר מחוברת לדאטה עצמו ולנסות לחלוב מהיוזרים כאילו מה הצורך שלהם, זה יכול להיות מאוד מאוד מוצלח.
ישי: ומצד שני קבוצת ה-engineering שבונה את זה או שעושה אטרציות על הדאטה, אז לפעמים גם engineering ו-data scientists או אנליסטים, יש להם משקל יותר גדול בלהחליט מה אפשר, מה כדאי לבנות, מה נכון, שוב, מול פרודקט ובהשוואה למוצרים שהם לאו דווקא דאטה אוריינטד (data-oriented).
יוליה: אני חושבת שהגבולות פה קצת מטשטשים בין אנשי פרודקט, אנשי פיתוח ומי שבודק בסוף את הדאטה, כן? כי המוצר הוא נמדד לא רק על הפלואים שלו, אלא גם על האיכות של הדאטה שאתה מביא. פלואים בהתחלה אפילו חסרים בתוך ה-, בהתחלה של המוצר, נכון? לא יהיו פלואים. אז כל מה שיש לנו זה דאטה, ודאטה, צריכות להיות שם איטרציות מאוד מאוד זריזות של להעריך את איכות הדאטה, להבין עד כמה אנחנו רחוקים מהכיוון, אולי אפשר לעשות פה איזה tweak ועוד קצת לשנות את האלגוריתם ולהביא משהו הרבה יותר טוב. אז אם אנחנו מדברים על ארגונים, ארגוני HR הם מאוד version oriented, יש שם בדיקות ודברים כאלה. במוצרי דאטה זה לא יעבוד, כנראה שמוצרי דאטה בהתחלה שלהם, בבנייה שלהם, נצטרך לעשות איזשהו, כמה שינויים ביום, ולדבר 5 פעמים ביום בזום עם הלקוח כדי לדעת איך הוא חווה את השינוי בדאטה שעשינו מבחינת האיכות של התוצאות.
ויקי: אני פשוט רוצה רגע לתת דוגמה מהדאטה פיצ'ר הראשון שהעלנו ל Walmart. אני זוכרת שזאת הייתה עבודה מאוד מאוד מאומצת גם של ה-engineering, גם של ה-data scientists וגם של הפרודקט ביחד, ואז כשהגדרנו כאילו, מהצד של ה-data scientists הם נורא נורא ניסו להגיע ל precision וריקול שיהיו מתאימים למה שרצינו בשביל להגדיר שהדאטה איכותי, ובסוף כן היה איזשהו good enough, כאילו אוקיי, לא הגענו לפרסיז'ן ולריקול המקסימלי. זאת תהיה האיטרציה הראשונה, וה-engineering מהצד שלנו לקחנו וניסינו להבין מבחינת איך שהדאטה, לא יודעת, אם יש fields שנראים מוזר או יש null-ים או כל מיני דברים כאלה נורא נורא בסיסיים, כדי להבין האם הדאטה שאנחנו מספקים עכשיו לדאטה פיצ'ר הזה הוא באמת הכי טוב שיכול להיות והכי מלא שיכול להיות. ומהצד של הפרודקט גם, מבחינת להביא את ה-value כמו שצריך, אז זאת הייתה עבודה מאוד מאוד מאומצת לנסות להבין מה האיכות של הדאטה פיצ'ר הראשון שאנחנו מביאים, וגם כבר לתכנן מה האיטרציה הבאה.
ישי: כן, אני חושב שאם נסתכל על כאילו מן הגדרה קלאסית, אנשי פרודקט כותבים user stories, ומדברים על האם היוזר מצליח לבצע את המשימה, וברוב המקרים, שוב, של מוצרים קלאסיים, זה תלוי בפלואו, האם הפלואו מאפשר לבצע את המשימה בצורה שהיוזר מקבל את מה שהוא רצה. כשאתה מכניס דאטה לתמונה אז השאלה הופכת להיות אוקיי, אני יכול לבצע את המשימה, אבל השאלה אם הדאטה היה מספיק טוב כדי לעשות את זה בביטחון או כדי לקבל החלטה, ואז זה כבר נהיה משהו מאוד פלואידי (fluid), מי אמר שהדאטה מספיק טוב, כאילו איך אני יודע שהיוזר הצליח? הוא הצליח לעשות, להזיז את הכפתור מ-A ל-B, הוא יכול טכנית לבחור או to act on the data, אבל השאלה האם הדאטה מספיק טוב כדי שהוא באמת ירגיש בנוח לבחור, וזה כבר הופך להיות משהו שהוא פאזי (fuzzy).
יוליה: נכון, יותר מזה, גם זה שהוא לא לחץ, זה שהוא לא בחר נגיד את הליין הספציפי, זה בגלל שהיוזר אינטרפייס היה לא נוח והוא לא מצא כפתור? או בגלל שהליין היה לא טוב והוא לא רצה אותו? אוקיי? זה משהו שאנחנו בכלל לא יכולים להעריך בכלים של פרודקט אנליטיקס הרגילים הסטנדרטיים, נכון?
ישי: נכון, או שאני תופר UI שמאפשר לתת לי פידבק, אבל אם אני חוזר לסטורי, הסטורי אומר תאפשר לו לבחור ליין, סבבה, ה-UI מאפשר לבחור ליין. ואין פה אף מילה, או לפחות קשה להכניס דיבור של רגע, שגם ההצעות יהיו טובות. ומה זה אומר טובות. זה מן ייצור חדש בסטוריז, בהשוואה למוצרים אחרים.
יוליה: כן, אנחנו שוברים פה את העולם של פנקשן או פנקשנל, נכון, איפה איכות הדאטה? לא פה ולא פה.
ישי: אוקיי.
יוליה: אפשר להגיד, נכון?
ישי: יש איזה, נכון.
יוליה: שפתאום עולם הפרודקט מכניס איזשהו עולם שלישי, מימד שלישי לעולם הדרישות.
ישי: כן, אם העלינו את האיכות מ-82% ל-84%, זה פנקשנל או שזה נון-פנקשנל, איך אני מודד.
ויקי: גם איך הגדרת את -82% (צוחקים) על סמך מה?
ישי: זאת שאלה עמוקה, אבל נגיד שיש לי מספר או נגיד שאפילו כל אחד מהיוזרים מסמן, אבל זה אלף הופך להיות רצף, אז מה האקספטנס של סטורי, מי מחליט שזה מספיק טוב, וגם רגע, זה שינוי פנקשנל או נון-פנקשנל? היוזר סטורי לא השתנה, פשוט נתתי עוד קצת value.
ויקי: בשביל זה יש לך כל מיני כלים כמו AB Test. לא יודעת, אתה רוצה לדעת איך היוזר שלך חווה את הדבר הזה? בוא נעשה AB Test, בוא נראה, 50% כאלה, 50% כאלה ובוא נראה איך יוזרים חווים.
ישי: אז זה כלי שעוזר לי לבחור בין שתי ורסיות, אבל האם הסטורי קומפליטד?
ויקי: אז בוא נגיד שנגיד, אני אחזור רגע לדוגמה שהבאתי, בדקנו את איכות הדאטה, הגענו לפרסיז'ן ריקול מספיק טוב, הגענו לזה שאין לנו nulls נגיד בשום שדה, הכל טוב, והמספרים נראים בסדר מבחינת כמויות נגיד. ואז אנחנו אומרים אוקיי, איכות הדאטה מספיק טוב בשבילנו, בשביל להוציא את זה רגע לשוק ונקבל איזושהי חוות דעת של יוזרים. ואז אתה יכול לעשות נגיד או AB Testing או כל מיני כלים אחרים של פרודקט שאני לא כל כך מכירה. אבל נגיד אתה יכול לקבל את זה בשביל לקבל איזושהי חוות דעת ואז לראות אולי אתה צריך איטרציה נוספת, אולי אתה צריך להוריד את הפיצ'ר הזה, אולי הפיצ'ר הזה לא valuable, לא יודעת.
ישי: ומה שמזיז קדימה את השאלות האלה של בוא נעשה AB Testing או בוא נעשה, לא יודע. ה-quality לא מספיק טוב, בוא נתקדם, זה אחריות של פרודקטס? בסוף? או אחריות של קבוצה שמפתחת את זה?
ויקי: תכלס, כולנו צריכים להיות owner-ים של הדאטה הזה וכאילו לדחוף קדימה, אם אני רואה שהדאטה לא איכותי ואני ב-engineering אני צריכה להרגיש מספיק בנוח בשביל להגיד הדאטה לא איכותי, בוא נעשה הכל כדי להגדיל את האיכות של הדאטה.
ישי: אז יש פה איזה קצת בוא נגיד טשטוש יותר מהרגיל בין פרודקט ל-engineering, מבחינת מי מחליט שזה good enough, מי הדרייבר של לעשות שיפור, כי מקובל לחשוב ש-engineering רוצים לקדם את הנון-פנקשנל, רוצים שיהיה להם קוד שיאפשר להם לעבוד בקלות גם על הפיצ'ר הבא, אבל שפרודקט הם אלה שבסוף מחליטים או קובעים, זה המעטפת של הסטורי, זה הפלואו שצריך לקרות. ובדאטה אני שומע שיש פה קצת יותר מערבוב בין מה שפרודקט ו-engineering צריכים לתת עליו את הדעת של האם זה good enough, האם זה עובר איזה רף של אקספטנס.
יוליה: כן, שיש פה תפקיד חדש שפתאום צץ, נכון? בתוך ה- R&D, הוא תמיד היה קיים, אבל לא בתוך R&D, פתאום יש לנו דאטה אנליסט שצריך, שאולי הוא זה שחותם על האיכות של הדאטה, על הקומפליטנס (completeness) של הסטורי, זה משהו שלא היה קיים לפני שהתחילו לעבוד עם מוצרי דאטה.
ישי: אז בואו נדבר באמת על האנליסט, קודם כל איפה הוא יושב לרוב? זה חלק מארגון ה-engineering? זה חלק מארגון הפרודקט? זה ארגון שלישי?
ויקי: בחברה הקודמת שלי (צוחקת) הדאטה אנליסט ישבה בתוך הצוות של ה-NLP ועבדה ביחד איתם וזה עבד בצורה מדהימה. כי היא ידעה בדיוק מה היה בתוך הדאטה, היא ידעה בדיוק מה עובד, מה לא עובד, איפה יש דברים שצריך לעשות אותם, והיא גם הייתה מאוד ורבאלית בצורה שהיא אומרת איפה הכאבים.
ישי: חוקרת NLP...
ויקי: (צוחקת) כן, היא גם הייתה בלשנית, נכון. אז היא באמת ידעה להגיד איפה הכאבים בצורה מאוד מאוד ברורה, ואני חושבת שזה ערך מאוד מאוד גדול לארגון, שיש data scientists שהם מתעסקים בדברים שהם יותר ארוכי טווח ואז הדאטה אנליסט יכול לבוא ולהסתכל רגע על הדאטה ולתת איזושהי תמונת מצב.
ישי: אז את אומרת דווקא זה עבד טוב כשהאנליסט היה חלק מהפיתוח, ולא מהפרודקט, שאולי זה היה, אם הייתי צריך לשלוף הייתי אומר זה יותר קרוב לפרודקט, כי צריך להגיד מה good enough מה לא good enough, יותר על ה-what ופחות על ה-how.
ויקי: כי זה תלוי מה המטרה. שם המטרה הייתה באמת להעלות דברים כמו איכות הדאטה.
ישי: אוקיי.
יוליה: אני חושבת שיש פה כמה שכבות, כן? יש פה איזושהי שכבה של data scientists שעובדים עם המודלים שלהם ומתי הם אומרים המודל good enough כדי להתחיל להכניס אותו לפיתוח. פה צריך אנליסט שיישב בתוך הארגון של דאטה סיינטיסטס, כמו שויקי אמרה. ויש את איך הדאטה הזה כבר מתחבר למוצר, ופה אני כן חושבת שזה יושב איפשהו במוצר, בין מוצר לפיתוח, כן? אבל כבר בפיתוח, לא בדאטה סיינטיסטס, לצוות של סיינטיסטס, אצלנו זה יחסית מופרד ומחובר. אי אפשר לדעת, זה די פלואידי (fluid), איך דאטה סיינס מתחבר לפיתוח, אבל אני חושבת שזה שתי שכבות לגמרי שונות של אנליזה שאתה צריך לעשות.
ישי: אוקיי, אז יש לנו, דאטה סיינטיסט זה משהו שהוא קצת יותר מחקרי, הוא קצת יותר אופן-אנדד (open-ended), גם בסוף עובדים על משימות מוצריות, אבל אולי הם קצת יותר עושים אקספלוריישן (exploration), לא בטוח שהכיוון שהם הולכים עליו יצליח. אבל אז את אומרת את צריכה דאטה אנליסט כחלק מצוות הפיתוח, חי באיטרציות, חי ממש בדליברי, ושמה זה כבר לא אקפלוריישן, זה בנייה של ה-value או מדידה של זה good enough, ופה זה לא אופן-אנדד. ואז החיסרון הוא מה, שדאטה אנליסט הוא צבוע לצוות מסוים שעושה מוצר מסוים והוא לא יכול לשרת גם אלף ואחד דברים אחרים? שזה לפעמים הסיבה לשים אנליסטים בחוץ? שהם יהיו גם זה וגם זה וגם זה וגם BI וגם,
יוליה: זה תלוי בגודל הארגון, כן? אני חושבת שככה הארגון מתפתח. בהתחלה לכולנו יש כמה כובעים, כן? כל אחד מאיתנו עושה כמה דברים. אז בשליש משרה עושים את זה ובשליש פה וסוף זה מסתכם לקצת יותר מ-100%, נכון? (צוחקים) אבל ככל שהארגון מתפתח אתה מרגיש יותר ויותר צורך, ככה ראיתי את זה בארגונים הקודמים שהתפתחו, יש יותר ויותר צורך שיהיו אנשים דדיקייטד (dedicated) לביזנס הספציפי, לביזנס ליין הספציפי של המוצרים שלך. כי אתה מכיר אותם, אתה מבין אותם, אתה גם יודע מה המטרות שלהם וכבר אי אפשר להתפקס על שמונה מוצרים אלא צריך אולי שמונה אנשים בתוך מוצר אחד, כדי לתת את ה-value האמיתי, כן, זה הכל תלוי בסקייל (scale).
ישי: אז אם יש לי דאטה אנליסט בצוות הפיתוח, איך מתנהל היום יום? כאילו מפתחים לוקחים טאסקים מהבק-לוג (backlog) או מהספרינט או whatever ועובדים ויוצרים קוד, האנליסט גם עובד על סטוריז? לוקח סטוריז הוא owner שלהם? או שהוא עוזר או עוזרת, חוברת לאנג'ינירז לטאסקים שלהם?
ויקי: אני חושבת שזה באמת כאילו פר ארגון, בארגון הקודם שהייתי בו, שהיינו, זה באמת היה צוות אחד של דאטה סיינטיסטים, הארגון היה מאוד קטן, היו פחות מ-30 איש בתקופה ההיא. והיא הייתה חלק מהספרינטים והיה לה את המשימות שלה והיא הייתה צריכה, כמו שדאטה סיינטיסטים עכשיו בוחנים איזשהו כיוון האם הוא טוב או לא טוב, גם היא בוחנת כיוונים האם הם טובים או לא טובים. אם עכשיו יש לנו איזשהו פיצ'ר שרצינו להריץ, איזה מערכת רקומנדיישן (recommendation) מבוססת על דאטה מסוים, אז היא עוברת על הדאטה הזה, אז היא עושה עליו כל מיני שאילתות, אז היא בודקת האם באמת המערכת רקומנדיישן תיתן את הדאטה אינסייטס שאנחנו רוצים שהיא תיתן?
ישי: היא עובדת על דברים שהם כאילו ספירנט אחד קדימה או אחורה לפני הפיתוח עצמו?
ויקי: בעולם מושלם כן (צוחקת) אבל בתכלס זה הכל קורה כזה כנראה לפעמים ביחד.
ישי: אוקיי, מצאתי משהו good enough, בוא נכניס טאסק של לפתח או לעשות אותו מסודר מבחינת אינג'נירינג (engineering) ונתקדם?
יוליה: אולי ניתן דוגמה, אמיתית. אנחנו עכשיו מוציאים את career path version 2, אוקיי? שהוא מבוסס על אלגוריתם דאטה סיינס אחר לחלוטין, אוקיי? אז בעצם הייתה שם איטרציה בין אינג'נירינג וסיינס, כדי להביא את כל הליינים בלי, כמו שאמרת, באקסלים. ועברנו באקסלים ועשינו שיפור של המודל ואיך הוא מתחבר לאינג'נירינג ואיך לוקחים את הדברים והגרף שנבנה ואיפה הלימיט (limit), איפה חותכים את המקדמים, כן? ב-0.6 או ב-0.8? אוקיי? פה אנחנו לגמרי היינו מנותקים מהלקוחות, היינו מנותקים מבחוץ, אלא עשינו על הדאטה שאספנו מלקוחות וניסינו לראות אם בכלל הכיוון שלנו נכון, אם המודל הזה הולך להצליח.
ישי: כן.
יוליה: היום אנחנו בשלב שאנחנו לקחנו כבר שני לקוחות ומתחילים להטמיע את הפיצ'ר הזה אצל שני לקוחות, זה עוד לא הולך לצאת לכולם. כי אנחנו מרגישים שגם שם יש טיונינג (tuning) על הדאטה, אוקיי? אז אולי חשבנו שבעולם האידאלי זה הולך להיות ככה, אבל הינה אצל הלקוח הזה זה עובד ככה ואצל הלקוח אחר זה עובד ככה, אז אולי אנחנו צריכים לעשות משהו איטרטיבי לפני שהלקוח ישחרר את הפיצ'ר הזה הוא יחליט איפה הוא חותך לפי איזשהו סמפל (sample) או משהו כזה, והנה זה משפיע עכשיו על הפיצ'ר. אז גם פה יש אנליסט שיושב ומשפיע, ופה אמרתי, בדיוק זה ההבדל בין אנליסט שהוא בודק את המודל, את הדאטה נקי. לבין איך זה מתחבר בסוף למוצר ולדאטה של הלקוח הספיציפי או כמה לקוחות כדי להבין איך בכלל המודל הזה יחיה בתוך מוצר.
(מוסיקת מעבר)
ישי: אוקיי, אז דיברנו על בעלי תפקידים ועל החשיבות של יכולת של דאטה אנליסט ובתוך צוות הפיתוח, בוא נדבר באמת טיפה על הסקילס או על איך אני בונה צוות שיודע לתת דאטה פרודקטס. בצד של היירינג (hiring), בצד של סקילינג אפ (skilling up), איך זה שונה או, ויקי, מה את ככה מרגישה, על מה קריטי לשים את האצבע כדי לוודא שיש את האנשים הנכונים למשימה הזאת?
ויקי: אני חושבת שהרבה ארגונים בשנים האחרונות עברו את השיפט הזה ממערכות שהן בק-אנד למערכות שהן צריכות עכשיו לתמוך בהרבה דאטה, וזה stack שונה לחלוטין וזה סקילס שונים לחלוטין גם. כאילו אם אני עכשיו שומרת דאטה בצורה מסוימת במערכת שהיא בק-אנדית ואני רק צריכה, לא יודעת, להעביר, לא משנה, אני לא אתן איזה דוגמה. אבל אם אני עכשיו רוצה לעבור למערכת שנותנת לי דאטה אינסייטס, אז אני צריכה ללמוד איך לייצר data pipelines, אני צריכה ללמוד איך לעבוד עם scheduling של טאסקים מסוימים, אני צריכה לעבוד עם אוונטים. אני צריכה כאילו להעביר את כל המערכת שלי לצורה אחרת, שמערכות בק-אנד לא עבדו בצורה הזאתי. והרבה מאוד ארגונים ממה שאני מרגישה כזה, משיחות ומחברים שאנחנו מדברים על הדברים האלה זה מאוד, זה מעבר לא פשוט ולא אינטואיטיבי.
ישי: וזה קורה, ממה שאת רואה, בצורה ככה מרוכזת? יש איזה צוות, תשתיות, שבונה את הפייפליינס ובונה איזה תשתית שאח"כ צוותי מוצר יוכלו לנצל? או שכל אחד עושה לעצמו?
ויקי: ממה שאספתי קצת מידע (צוחקת)
ישי: מי מכניס את ה Kafka?
ויקי: (צוחקת) אז ממה שאספתי קצת זה שבד"כ זה מתחיל ככאב לארגון, ואז הארגון נותן לזה צוות לעשות איזה משהו קטן ואז מרגישים שצריך את זה בכל הארגון ואז מייצרים לזה איזה דאטה פלטפורם או איזה משהו כאילו שהוא טיפה יותר כולל, כי הארגון מבין שהוא עבר להיות דאטה אורגניזיישן (data organization). אבל בשביל להיות דאטה אורגניזיישן אתה צריך להתחיל לאסוף את האנשים, כאילו להתחיל להביא דאטה אינג'נירז שמבינים איך לעבוד עם דאטה, כאילו להכניס Kafka כשאתה בק-אנד אינג'ניר ואתה לא יכול לצפות דברים כמו דברים שקרו לנו, כאילו ריבלנסינג פתאום בפרודקשן כשיש לך כמויות פסיכיות של דאטה, מאיפה אנחנו יודעים את הדברים האלה? לא עבדנו עם כאלה כמויות של סקייל בעבר, אז את הדברים האלה כאילו כדאי שיהיה את הסט אוף סקילס הנכון בשביל עבודה עם דאטה, זה מקצוע שהוא יחסית חדש, אז כאילו אין כזה הרבה אנשים שחוו את הדברים האלה, בסקייל מאוד מאוד גבוה.
ישי: אז אם אני ארגון או חושב על עצמי בתור ארגון או צוות או מוצר שהוא דאטה אוריינטד, אז מודל בשל זה כבר כשיש פלטפורם טים שמרים משהו מרכזי לכולם ומודל ראשוני שלרוב שמה מתחילים זה שאחד הצוותים שנתקל בצורך ראשון, מתחיל להקים משהו.
ויקי: תעשה POC, POC זה תמיד טוב, להתחיל מ-POC (צוחקת).
ישי: אוקיי, אבל אז יש את הטרנזישן (transition) שהם אומרים אוקיי, זה not good enough שזה משהו אד הוק, אני צריך להקדיש לזה צוות, שזה יהיה ה-day in day out שלו, זה צוות שהוא בעצם לא בונה מוצרים, הוא בונה תשתיות. אז זה קצת, איך המעבר הזה מ-, מעניין אותי הדינמיקה שבמעבר, מתי מחליטים שאוקיי, הגיע הזמן להקים צוות תשתיות שיעשה את זה ולא יתעסק בדליברי של מוצר.
יוליה: אני חושבת שכשאתה פתאום מזהה שאתה משכפל דברים, כן? או שאתה פתאום משכפל איך אתה עובד עם קפקא הזכרת פה, או פתאום אתה משכפל את הדאטה, שזה מתחיל כבר לכאוב, כי יש לך דאטה דיסקריפנסי (discrepancy) וזה עולה לך יותר מידי. אז איך אתה בונה משהו אחד שישרת את שני הצדדים, ואיך אתה לא פוגע בפונקציונליות של כל אחד, כן? אז בעצם אם זה צוות אחד שהתחיל וממשיך לתחזק את זה, אז הוא זוכר את האינטרסים של עצמו ולפעמים שוכח את האינטרסים של הצוות השני ויכול לפגוע. ואם זה צוות פלטפורם אז בעצם יש לו שני לקוחות והוא צריך לשרת את שניהם, וזה המעבר אני חושבת שאתה כבר, כשזה מתחיל לכאוב כמו שויקי אמרה, והכאב יכול להיות שכפול, דיסקריפנסי, דברים כאלה ופחות אני חושבת של רצון לשים משהו במרכז כשעוד אין מספיק,
ישי: אפשר בכלל להתחיל עם משהו מרכזי? זה ריאלי? זה נכון? אני וואלה, כבר הייתי בכמה סטארטאפים, עברתי את הכאב, בוא נתחיל בפלטפורם טים שישים את זה במרכז. אי אפשר לדלג על השלב המלוכלך והראשוני הזה? או שזה, אני אעשה טעויות, זה פשוט לא נכון, עד שאתה לא תחווה את ה-pain ואז תזוז.
ויקי: תמיד תחווה את ה-pain ואז תזוז, תמיד, כאילו זה תמיד נכון, זה, אם אתה רוצה לעשות, זה כמו ש-, לא יודעת, אנחנו כולנו רוצים לעשות כמו נטפליקס וכמו טוויטר לפני עידן מה שקורה עכשיו, אבל אנחנו לא באותם צרכים, אנחנו לא באותם כאבים, אז כאילו בואו נבין מה הצרכים שלנו ומה הכאבים שלנו ואז נבנה מה שאנחנו צריכים.
ישי: אוקיי, אז אני חושב שזה מעניין בתור אפילו מישהו שהוא מתראיין בחברה או שמסתכל רגע על חברה מהצד, להבין איפה הוא נמצא ב-, איפה החברה הזאת בתהליך של פתרון אד הוק לבעיות דאטה או להקמה של צרכים של דאטה בשביל מוצר ספציפי, ועד המצב שיש לי איזשהו סרביס ו-bus ומשהו מרכזי שכל הדאטה פרודקטס ואולי גם לא הדאטה פרודקטס נשענים עליו. אחלה כאילו דיאגרמה לארכיטקטורה, אבל אי אפשר להגיע לשם ישר, צריך להתחיל בדברים לידו ולהתחבר. מה זה עושה לצוות שמפסיק לדלבר פרודקט או הוא מלדבר רק אינטרנל פלטפורם, כאילו בסוף יש לו, זה שיפט מאוד גדול באיך שהוא מתנהל בדיסקברי של value ופידבק על value, ובכלל לא מדלבר יוזר סטוריז. זה לא מתאים לכל אחד, אז איך נראה הטרנזישן בהנחה שאתה לא לגמרי מביא אנשים חדשים להקים את הפלטפורם טים שלך או את הדאטה טים. איך מוצאים מי מתאים לזה ואיך נראה השינוי הזה מבחינת החיים של, אפילו טים ליד שעד עכשיו דילבר מוצרים ועכשיו הוא דלבר פלטפורם.
ויקי: לא הייתי אומרת שאין לך שיפט פה באנשים, חייב להיות לך פה שיפט באנשים כי אם אני הראש צוות שכל כך אוהב לראות, לספור את ה-page views או דברים כאלה, אני לא, כנראה לא אמצא את עצמי בפלטפורם, כן? יותר מזה, זה כנראה עבודה של צוות בלי פרודקט מנג'ר, כי מה זה פרודקט יותר, כן? אין יותר הגדרות מוצר, אין קסטומר פייסינג, זה מתחיל להיות דרישות טכניות בלבד.
ישי: נכון.
ויקי: אז אני חושבת שכשעושים דבר כזה אתה טבעית, עם הגדילה של הצוות, אתה טבעית רואה מי האנשים שהם יותר נמשכים למוצר, למשהו אינטראקטיבי, מול עבודה מול לקוחות, עבודה מול דרישות של פלואוז, לבין משהו שהוא אולי קצת יותר ארוך בסייקל (cycle), קצת יותר נותן שירות לצוותים אחרים, כן? ופה אני חושבת שזה אנשים שונים בד"כ, זה לא אותו בנאדם שפתאום יכול לעשות סוויץ'. יש כאלה שכן אוהבים את זה, אבל לרוב ראיתי שזה מתחיל בתוך צוותים מוצריים, יש אנשים שהם יותר אוהבים את הקסטומר פייסינג, ויש יותר אנשים שאוהבים יותר את האינפרא (infra) בתוך הצוותים, וככל שהצוותים גדלים והארגון גדל ואתה מחליט כבר לעשות קבוצת פלטפורמה, אז אתה מזיז את האנשים האלה לכיוון הזה ומייצר פה קבוצה.
ישי: מה קורה כשאני עובד על מוצר שהוא מבוסס דאטה ואולי נשען על איזה פלטפורמה, ואני לא מקבל שירות מספיק מהיר או מספיק גמיש מהפלטפורם טים. אבל אני צריך לדלבר ואני רוצה, אני לא רוצה להיות תקוע, איך, כאילו,
ויקי: זה עברת לצעד הבא, אחרי שכבר עשינו את ה-, בנינו צוות פלטפורמה, עכשיו זה כשזה לא עובד טוב (צוחקת)
ישי: או כשהוא אחלה אבל אני יש לי משהו, אני יש לי צרכים שהם אולי לא בפריוריטי הכי גדולים בתוך הארגון.
ויקי: ואין פרודקט אתה אומר, אז אין מי שיתעדף?
ישי: ואני צריך את הדאטה ככה ולהם ייקח חצי שנה. מה, איך פותרים את זה? כאילו דרך אחת שאני מכיר זה סבבה, אני אפתור את זה לעצמי, נעשה את מה שצריך אד הוק, אבל יצרתי עכשיו pain חדש.
ויקי: אני חושבת שלפלטפורם צריך להיות אנאייבלמנט (enablement) ולא צוואר בקבוק, אבל זה כאילו כבר פילוסופיה (צוחקים)
ישי: השאלה אם בחיים האמיתיים זה, רואים את זה? זה קורה?
יוליה: אני מאמינה שאיך שהתחלת מהכאבים ואז הגעת לפלטפורמה, גם פה אתה, פה אתה באיטרציה. אז אתה יצרת pain חדש כשהוא מספיק יכאב לך תכניס אותו חזרה לפלטפורמה. תעשה משהו בעצמך, תרוץ עם זה, תוכיח שזה טוב, תוכיח שזה חשוב, כשיהיו עוד צוותים שישתמשו בזה וזה יהיה pain אמיתי.
ישי: אז תכריח את הפלטפורם לאכול את זה.
יוליה: בצורה הטבעית ייכנס לפלטפורמה, כל איטרציה.
ישי: אוקיי, אני בטוח שאנשי הפלטפורם טימז מאוד אוהבים את המשפט שעכשיו אמרת (כולם צוחקים) ואומרים כן, כולם קיבלו רשות לעשות, לעבוד מלוכלך, אבל אולי זה הדרך לדלבר.
(מוסיקת מעבר)
ישי: בואי נדבר על אתגרים ככה חיצוניים או מיוחדים סביב העולם של מוצרי דאטה. קודם כל מאיפה בכלל יש לי דאטה?
ויקי: אז חלק מזה זה באמת דאטה של הלקוחות שאתה אוסף. והאם מותר לך לערבב, האם מותר לך להשתמש בדאטה של לקוח אחד עבור האינסייטים ללקוח אחר, אז זה שאלה מעניינת ואני חושבת שכל ביזנס פותר את זה בצורה אחרת. הדרך השנייה היא לקנות דאטה ממקורות אחרים, לקנות או להשיג דאטה ממקורות אחרים. ופה כל העולמות של פבליק סורסס (public sources) וכמה הם מותרים וכל השאלות המוסריות שאנחנו יכולים להתחיל לשאול. ואני חושבת שאם אתה, אם כן מותר לך להשתמש בדאטה של לקוח אחד ללקוח אחר, איך לא מזהים ולא מתנגשים פה הלקוחות, כן? איך התחרותיות של הלקוחות אחד מול השני לא נפגעת, גם פה יש לך אחריות.
ישי: כן, וכמובן privacy.
ויקי: וכמובן privacy, כן.
ישי: אז זה מי ש-, נגיד זה אנשי פרודקט? התפקיד שלהם הוא לנווט את השאלות האלה של מה מותר לי, מה אסור לי, מאיפה יש לי דאטה, מה ההסכמים, מה לקוח מוכן לקבל, לא מוכן לקבל? זה נתון שפרודקט מנהלים אותו? או שיש לאינג'נירינג איזה סיי (say) כאן? איך נראה התהליך הזה של להבין מה בכלל, מה אפשרי, אנחנו צריכים לקנות דאטה כדי להשיג את המטרה שלנו אנחנו צריך לקנות דאטה כזה או להביא את הדאטה של כל הלקוחות כדי לעשות נגיד בנצ' מארק (benchmark) או משהו כזה.
ויקי: אחד הדברים שאני יכולה להוסיף כאילו מהעבר שלי זה שאנחנו הבאנו דאטה מכל מיני מקורות חיצוניים, אז הנגיעה של הפרודקט בדבר הזה הייתה בשביל להבין איזה סוג של פילדס (fields) אנחנו צריכים בשביל איזה יוז-קייסים (use cases), אז כאילו אז אנחנו היינו אלה שמביאים את כל הדאטה, ואז הם היו יותר מסתכלים על איך בונים מזה יוז-קייס, מהדאטה שיש לנו. אבל זה דרך אחת.
יוליה: אני חושבת ש-ownership על הדאטה עשה קצת שיפט לכיוון הפיתוח באמת, אז הקנייה היא כנראה או קנייה או העברה של דאטה, כמו שויקי אמרה, עברה קצת יותר לפיתוח. לפעמים פרודקט מנג'רס כן חולקים את המשימות האלה יחד עם הפיתוח, אבל אחד התפקידים החדשים שפתאום התחלתי לראות בארגון שפעם לא היה לי איתו שום אינטראקציה, זה תפקידים של ליגל וסיסו (CISO) ואיפה ה-privacy ואיפה הדאטה צריך להישמר ומה מותר לשמור ולכמה זמן ומה מותר לחלוק. זה דברים שלפעמים יש ארגונים שהפרודקט לוקח את זה ויש לפעמים ישר, ערוץ ישיר לתוך הפיתוח, כמו שאמרנו נון-פנקשנל, הם בד"כ נופלים בין הכיסאות, וזה מהסוג הזה.
ישי: אז כדי לעשות את זה יעיל או אפקטיבי, אנשי הקומפליינס (compliance) והליגל צריכים להגיע עד הטים ליד, כאילו קשה למישהו באינג'נירינג לרכז את זה מלמעלה ולהגיד אני וידע בדיוק איזה שימוש עושים בכל דאטה, איזה שדות נשמרים, מה הריטנשן (retention) פוליסי שלנו, איך מייצרים אינטרפייס (interface) הגיוני בין אנשי ליגל קומפליאנס סקיוריטי וכו', לבין האנשים שהטים ליד שעכשיו בונה את המוצר, בלי שכל אחד משגע את השני.
יוליה: אז אני חושבת שדיברנו קצת על צוות פלטפורמה, אז אנחנו כן מדברים על סוגים שונים איפה אנחנו שומרים את הדאטה, כן? יש, כנראה כשיש לך, אתה כבר מגיע לסקייל מספיק גדול שיש לך דאטה לייק (data lake), והוא באחריות של פלטפורמה, כנראה שהליגל יגיעו לצוות הזה ויתחילו לעבוד איתם, כן? איזה דאטה מגיע לי שם, לכמה הוא נשמר ומה אתה עושה עם זה. ופה זה תלוי עד כמה אתה, איזה כלים אתה מייצר בתוך הפלטפורמה. אם אתה מאפשר לעשות דאטה ownership לצוותים, אתה כנראה גם מייצר מספיק כלים כדי שהם יוכלו לדאוג לריטנשן ואיפה ה-PII וצביעה וזיהוי ה-PII בתוך הדאטה שלך. ואז כן, כמו שהדיסטריביוטד ארקיטקצ'ר (distributed architecture) הוא מסובך, פה זה דיסטריביוטד דאטה (distributed data), הוא מסובך. צריך פה הרבה מאוד ראשים בחדר אחד כדי להבין איפה הדאטה שלך נמצא ומה קורה עם אותו נתון שמטייל פתאום מסורס לסורס ונשמר במקומות שונים.
ישי: אז הפלטפורם נותן שירותים של נגיד ריטנשן או אוקיי, הלקוח ביקש למחוק אז אני מוחק מרכזית וכל הצוותים שיסתדרו?
ויקי: זה תלוי בבשלות של הפלטפורם, בעולם האידיאלי כנראה שמה שתרצה זה שלכל ריסורס של דאטה יהיו לך כלים של כמה אתה שומר, איך אתה מזהה את הנתון הספציפי שעכשיו אתה למשל צריך למחוק בגלל ש-GDPR או כל סיבה אחרת, ואיך אתה עושה את זה במקום מרכזי. אבל זה כמו שאמרנו, איטרציות.
ישי: זה אתגר.
יוליה: כן.
ישי: אז גם פה יש איזה וקטור של בשלות, שבהתחלה אנשי הקומפליינס צריכים לעבוד עם הצוותים שכנראה מחזיקים כל מיני איים של דאטה וכל מיני, או רפליקות או דאטה לעוס בצורה מסוימת כדי לשרת את ה use case. ועם הבשלות, עם הפלטפורם, אז גם השאלות האלה הופכות להיות מרכזיות ואז בא איש צוות שרוצה, שצריך את הדאטה, אני צריך אותו לעוד כמה ימים, בשביל ה use case, אז אני עוקף את ה-, מייצר את ה-pain החדש שדיברת עליו. בוא נדבר דקה על cost, העולם הזה של דאטה מביא איתו אתגרים של cost שאולי לא קיימים במוצרים רגילים או בפלואים רגילים, איך ההתייחסות למחיר של הדאטה, למחיר של להזיז אותו, של לתחזק אותו, של לתשאל אותו, איפה זה נכנס ליום יום של תהליך הפיתוח?
ויקי: בגדול אנחנו עכשיו האמת ממש בשבוע האחרון הייתה לנו שאלה כזאתי על, יש לנו איזה משהו, פיצ'ר שאנחנו צריכים לדלבר וניסינו לעבוד עם איזושהי פלטפורמה מסוימת שהיא טיפה יותר זולה מפלטפורמה אחרת, אבל היא לא הצליחה להביא לנו את התוצאות שרצינו. ואז אמרנו אוקיי, אנחנו מוכנים עכשיו לשלם אולי טיפה יותר, אבל בהמשך אנחנו נצטרך להבין איך אנחנו נותני פה פתרון בלונג-ראן שהוא גם מתחשב ב-cost, ככה שכאילו באינג'נירינג העניין של ה-cost הוא מאוד מדברים עליו, כאילו הוא בתוך השיח, אבל צריך להבין, אני חושבת שאת יכולה להסביר את זה יותר טוב, על איך דאטה משנה לחלוטין את התפיסה של ה-cost.
יוליה: כן, אז אולי קצת צריך לדבר על הפרדיקשן (prediction), כמה זה יכול לעלות. כי כשמדברים על תהליך פיתוח הרגיל, אפשר לדמיין באיזה סקייל אנחנו הולכים לרוץ, בעתיד, אם נמכור את ה-, אם יהיה לנו 100 אלף יוזרים ביום, אז ככה זה יעלה לנו. לעומת דאטה, אתה לא יכול לדעת, כי אתה לא יודע באיזה צורות תצטרך לשמור אותו, מה תהיה הכמות של הדאטה, והרבה פעמים היכולת שלך להבין, לצפות מראש כמה המוצר הזה הולך לעלות, יכולה מאוד מאוד להשתנות, נכון? לפי הפיצ'ר. ולכן אני חושבת שחשוב מאוד להכניס פה את תהליכי החשיבה וההערכה של כמה הולך לעלות לנו הפיצ'ר וכמה הוא הולך להיות לנו כדאי, ממש בתחילת ה-, בתכנון, בתחילת הפיצ'ר, כשמגיעים עם ה-requirements. למשל אם אני הולכת לעשות איזשהו חישוב פעם ביום, או פעם בשעה, זה הולך לשנות לחלוטין את כמה אנחנו הולכים לשלם. והרבה פעמים אנשי פרודקט נטו להתעלם מה-cost המוצרי, והיום זה שאלה שהיא עולה עוד ברמת ה-requirements לפני שכותבים שורת קוד ראשונה או מביאים כמויות דאטה ראשונות. מתחילים לדבר על כמה זה יעלה וה-cost מתחיל להשפיע לנו על פונקציונליות של המוצר הרבה פעמים.
ישי: אז זהו, זה כאילו משהו חדש, לרוב פרודקטס אומרים הנה הסטורי, אינג'נירינג הולכים לממש אותו ומגלים על הדרך שה-query שעשינו מצריך אותנו לשדרג את הדאטאבייס, נלחמים בזה או לא כחלק מהנון-פנקשנל סטאף (stuff), אבל אין מישהו שאומר שמע, אני מוכן להקצות לפיצ'ר הזה או לסטורי הזה 100 דולר בחודש, או אלף דולר בחודש across הקסטומר בייס (customer base) שלנו.
ויקי: וגם בשיחה יגידו לך אני חייב את זה בריל טיים, ריל טיים, מה זה אומר ריל טיים? כאילו אתה יודע כמה זה עולה להביא את זה בריל טיים? בכלל אתה צריך? אולי כדאי לעשות איזשהו אוף ליין פרוסס שיעלה לנו הרבה פחות?
ישי: אבל עצם השיחה על ה-cost, לפחות בארגונים שעוד לא התרגלו לעשות את זה, היא באה חודשיים אח"כ כשפתאום ה-cost טיפס אז אומרים רגע, יש לנו בעיה, בוא נכווץ. אבל איך מחליטים מה זה יקר מידי ומה זה זול מספיק? אלף דולר בחודש, זה טוב או לא טוב?
ויקי: תלוי.
ישי: השאלה הזאת כאילו היא חדשה לגמרי להרבה תהליכי פרודקט, מאיפה זה בא? כאילו איך קורה השיפט מבוא נגיב לבעיית cost בדיעבד, שזה מה שעד עכשיו עשינו. ה-CPU עלה בוא נגדיל את ה instance קודם כל, או בוא נגדיל את הדאטאבייס, אחרי זה מישהו יצעק על ה-cost, לאט לאט נוריד אותו. אבל הוא כבר לא קשור לפיצ'ר, הוא לא קשור לסטורי, הוא קשור לזה שהמערכת יקרה, בוא נמצא הזדמנות לשפר והאינג'ניר זוכר שכן, עשינו כאן שטות, בוא נסדר את זה. זה הפלואו הרגיל שכולנו מכירים. איך עוברים מזה למצב שבו יש תג מחיר לפיצ'ר?
יוליה: אז קודם כל זה שינוי תרבותי, כן? אתה לא יכול להכניס משהו כזה בארגון שלא מודע ל-cost, אין לו גישה ל-cost ואין לו ownership, כן? וההגדרה של ownership בארגונים כאלה שהם אוריינטד cost ויודעים להכניס את זה לתרבות, אז יש לך תיוגים ויש לך הגדרה כמה כל צוות מבזבז, בגירשיים, על הפרודקשן שלו, כן? על הפיצ'רים שלו, או יבזבז בעתיד אם הוא מתכנן משהו. ופה התקציבים באים גם מבחינת האסטרטגיה. כמה המוצר שלך הולך להיות אסטרטגי, כמה אתה חושב שאתה תרוויח עליו, כמה אתה חושב שאתה יכול לחלוק את העלות הזאת בין הלקוחות השונים ואולי להוריד ככל שהקסטומר בייס שלך יגדל, להוריד בעלות פר יוזר, פר לקוח. שבמוצרי דאטה זה מאוד משמעותי, הרבה פעמים אתה באמת שומר דאטה במקום אחד אבל משתמש בו להרבה מאוד לקוחות שונים באותו דבר, באותו בייס.
ישי: ואז מה, המפתחים מתחילים להיות מודעים ל-cost ואיך אני מעמיס cost על יוזרים ועל ארגונים שונים? זה חלק מהשיקולים שלהם? או שיש מישהו שסופר דולרים בצד ורק אומר ה-cost של התג הזה על מידי בוא נסדר.
יוליה: אז אני חושבת שצריך פה גם וגם, כן צריך להיות מישהו מרכזי שיושב ואומר פה זה יקר מידי, פה זה קפץ מידי, להיות על הדברים. אבל בתוך ה-, אצלנו בתוך הצוותים כל אחד יודע כמה מוצרים שלו עולים, אם הם קפצו או לא קפצו, יש להם אלרטים על זה, וגם יודעים לנהל את השיח, אני מכניס עכשיו את הפיצ'ר הזה או אני מכניס את הטכנולוגיה הזאת, אני משפר את הפרפורמנס (performance) ואני אוריד את ה-cost. אוקיי? זה חלק מהאינוביישן (innovation) הרבה פעמים שקורה לנו בתוך הצוותים.
ישי: שזה נון-פנקשנל פרוגרס שעושים, אני משפר טכנולוגיה, הוספתי אינדקס, whatever, ואני יודע להגיד כמה ה-cost ירד.
יוליה: או כשאתה הולך לממש משהו פנקשנל ואתה צריך להביא ארכיטקטורה, את הדיזיין שלך החדש, אתה הרבה פעמים נדרש בתוך הדיזיין ריביו, cost אסטימיישן.
ישי: יצא לכם לראות או להצליח בלקחת את זה לקצה של נגיד זה חלק מהטסטים? PR, כאילו כמו שלפעמים בודקים באנצ' מארק של ביצועים אומרים הקוד הזה לא ייכנס אם הוא דופק את הביצועים של משהו, של המערכת או של איזה view, הוא גם לא ייכנס אם הוא מקפיץ את ה-cost.
ויקי: וואו, איזה עולם יפה (צוחקת)
יוליה: יצא לי לעצור פרודקט ריקווירמנטס על זה, שזה פשוט ה-cost גבוה מידי, הוא לא ישתלם ואנחנו נעצור, לא נפתח את המוצר כי הוא לא ישתלם לנו.
ישי: אוקיי, ומי קובע מה זה משתלם? מה, זה שאלה של מרג'ין (margin)? אומרים אני צריך איקס, על כל X דולרים שאני מכניס מותר לי להוציא Y, או שאני עכשיו בשלב של growth ואני לא משחק על מרג'ין אלא רק על סניטי (sanity) של cost כללי?
יוליה: זה תלוי בשלב, כן? כמובן, אבל יצא לי לעבוד במוצר שכבר ידענו כמה, מה המרג'ינג שלו, ואז כל פיצ'ר הוא מאוד חשוב אם אתה עדיין עומד באחוזים של הרווח שאתה רוצה להביא, מתוך המוצר הזה. אז הרבה פעמים או שאתה עושה את הפיצ'ר ומתחיל לנהל משא ומתן עם הביזנס side כדי להרחיב ולמכור את זה כפאקג' נוסף, יכול להיות.
ישי: כלומר או שאתה מגדיל את הטופ ליין או שאתה מתעסק במרג'ין.
יוליה: כן.
ישי: שזה כנראה חברות יותר ותיקות, עם מוצרים אלף שהם מאוד מדידים, ובית שכבר המרג'ין הוא משחק תפקיד. לכאורה דיבור על cost הוא לא צריך להיות מוגבל רק לדאטה, כל פיצ'ר אני יכול למדוד כמה הוא עולה לי, ויכול להיות שהפיצ'ר הזה הורג אותי בגלל מימוש בלי קשר לזה שזה דאטה. אז מה הדאטה מכניס כאן מיוחד? פשוט סקייל אחר? או אימפקט הרבה יותר חזק על ה-cost?
יוליה: סקייל אחר ואני חושבת שהפרדיקטביליות (predictability) של ה-cost כשאנחנו מכניסים את הפרמטר של דאטה, יורדת, ופה אתה, בגלל זה אתה צריך להיות יותר על זה בהתחלה.
ישי: הפרדיקטביליתי (predictability), אוקיי. כי מה, יש שונות גדולה בין לקוחות או בין, איזה דאטה, כמות הדאטה שאני אוסף עבורם, כמות הדאטה שאני צריך לנהל?
יוליה: אני חושבת שהסקייל שלך עולה, נגיד אתה עולה מאלף יוזרים ביום למיליון יוזר ביום, כשמדובר רק על ארכיטקטורה שלא מערבת את הדאטה, יכולת הפרדיקטיביליות שלך היא מסוימת, אבל כשאתה מכניס את המימד של דאטה, אז יש לך פה כמויות דאטה שאתה יכול, זה לא תמיד לינארי, זה יכול לגדול הרבה יותר, וזה פשוט מכניס עוד פרמטר למשוואה, שהופך אותה להרבה מסובכת.
ישי: יותר קשה לי לחזות איך נראה גידול.
(מוסיקת מעבר)
ישי: לסיום, אני רוצה ככה לבקש מכל אחת מכן איזה מחשבה או שתיים על מי שמתחיל להתעסק עכשיו בדאטה פרודקטס או רוצה להתקדם לכיוון הזה של לעסוק בדליברי של דאטה פרודקטס, טיפ אחד או שניים שככה, על מה חשוב לשים לב, מה לא לעשות או כן לעשות כדי להצליח. ויקי, מה אתה לוקחת איתך למסע הזה?
ויקי: אני קודם כל מהרגע שהתחלתי לעבוד על דאטה פרודקטס, זה פשוט גיליתי כמה שאני אוהבת את זה וכמה שזה כיף. אז כל מי שעוד לא יצא לו לעבוד על דאטה פרודקטס תנסו, זה ממש ממש כיף, זה דבר ראשון. ודבר שני, אם כבר נכנסים לעבוד על דאטה פרודקטס, אני חושבת שהדבר הכי חשוב בהתחלה זה בכלל להבין איזה דאטה יש ומה אנחנו חושבים שאנחנו יכולים לעשות איתו ולאן הארגון רוצה לקחת את הדאטה הזה, כדי קצת להבין אולי מה הערך המוסף שאנחנו יכולים לתת למה אנחנו חושבים שאפשר לעשות עם הדאטה. כי יש מלא דברים שאפשר לעשות עם הדאטה, אבל כאילו בכלל שאלות של בני אדם כזה, מה זה יכול לתת לי, מה המידע הזה יכול לתת לי כבן אדם או כאילו לקחת את הדאטה ולמפות אותו בחזרה לשפה של אנשים.
ישי: ובין השורות אני שומע שכנראה צריך לאהוב את זה כדי להצליח, אז צריך למצוא, בוא תמצא את ההזדמנות להתנסות.
ויקי: כן.
ישי: לראות אם זה משהו שממש מדליק אותך, אז תעשה, זה כיוון טוב בשבילך.
ויקי: זה תמיד נכון, כן (צוחקת)
יוליה: כן, אני כמו ויקי גם מאוהבת במוצרי דאטה כבר הרבה מאוד שנים. אחד הדברים הראשונים שהבנתי שצריך לשבור לגמרי את צורת החשיבה שהייתה לי כמהנדסת רגילה, ארכיטקטורה ודברים כאלה, שהכל פה הולך להיות שונה, כמו שאמרת. פתאום הפלואו הם לא מרכזיים, אלא מה שמרכזי זה הדאטה והאיכות של הדאטה ומה אנחנו יכולים להביא, איך עושים MVP, הוא פתאום נורא שונה, אפשר להתחיל בכלל בלי מוצר, רק עם הדאטה. וזה כבר מוצר - יכול להיות. אז אני חושבת שגמישות מחשבתית ולנסות להשתחרר מהחשיבה הקודמת שהייתה במוצרי פלואו הרגילים שלא עירבו את הדאטה, להבין איך עושים את זה אחרת. הרבה פעמים מה שאני הבנתי כשעשיתי דאטה, לפעמים לעשות יותר זה יותר מהר מלעשות פחות, כי הרבה דברים אתה יכול לעשות במקביל ולראות פתאום דברים קורים, אז לפעמים אפילו בפרוססינג, אתה עושה יותר פרוססינג ומקבל תוצאה יותר מהר.
(מוסיקת מעבר)
ישי: מעולה, תודה רבה לכן שבאתן, הנושא הזה של דאטה פרודקטס ואיך הם שונים ודומים לעולם המוצרים הכללי שאנחנו מכירים, אותי לפחות הוא מרתק, אז שמחתי ללמוד מכן.
ויקי ויוליה: תודה, תודה רבה לך, איזה כיף.
ישי: תודה.
(מוסיקת מעבר)
** לינקים לקהילות שהוזכרו בפרק - כאן.**
Yishai: Welcome to Season 2 of Dev Interrupted - the Hebrew Edition, LinearB's podcast which discusses everything that interests the daily work of engineering managers. This season we will host industry leaders and talk with them about everything that interests engineering managers, those who work with them, and those who one day would like to manage an engineering organization. This season we will place special emphasis on Developer Experience. I'm Yishai Beeri, CTO at LinearB. Let's get started.
Yishai: In this episode, I am happy to host Yulia Trakhtenberg, VP R&D at Gloat, and Vicky Kalmanovich, engineering manager at Gloat. Hello, how nice of you to come.
Yulia & Vicki: What fun to be here.
Yishai: As always, we start with just a few words, we would love to hear from each of you how your career developed and how you got to this point, so Yulia, let's get started.
Yulia: I'm starting, okay. So I've been in high-tech I think for over 20 years, I did a degree in computer science, like everyone else, I started in the times of the first crisis, 2001, in telephony, where I learned very well C++, the depth of threading and all the bits & bytes of development. From there I evolved into management, I started as a team leader, a group leader, and I realized that the world of startups is more interesting to me and I moved to work in startups. So for the last two years I've been at Gloat, engineering manager. In the last two years we have grown significantly, both as a company and as a development, we have developed new products, we have changed the direction completely, we have brought in very significant enterprise customers, so I think the path we have taken as a company is very interesting and we will talk about it a bit.
Yishai: Definitely. So today you are VP R&D at Gloat, how many people in the development organization more or less?
Yulia: 70 people.
Yishai: 70, great, so we'll dive right in to hear a little bit about what Gloat is doing, but Vicky, come on, tell me about your track.
Vicki: So I've been at Gloat for a month and a half (laughs), which is very exciting.
Yishai: That's it, "Grace" is over now.
Vicki: Yes (laughing) in startups it ends very early, you know that. So before that I was at a company called Aspectiva, which was acquired by Walmart, we also made all kinds of data products based on NLP there, and before that I was about 10 years in technological positions in the army, so I've been managing for almost 7 years, and that's it.
Yishai: Excellent. So tell me in a few words what Gloat does, just so we have context.
Yulia: Gloat develops products for enterprises in the world of HR Tech, in fact organizations today really, really want to know what skill sets their workforce, their organization, their employees have, and plan it forward. What will be missing in a year? In 3 years, in 5 years? And actually we are developing several products that give one, the ability to understand where the organization stands now compared to the market, compared to its vertical and where we want to take the organization, and this connects to the other product that allows employees within the organization to develop. So basically there are two sides here, first, how the employees develop, what opportunities they can take and develop their career within the organization, and second, how the organization can also direct them to something that will be very relevant for the organization in 3 and 5 years.
Yishai: I understand, so it connects to systems, say like workday and those of more HR management, and on the other hand to learning and development?
Yulia: So we are actually standing in the middle, we connect to systems like workday, HCMs of all kinds to get the data for the employees, to know what they know how to do, what skill set they currently have. Of course, they can enrich it within our platform, and connect to systems like learning and others, which make it possible to bring to the talent marketplace, which is actually the second product I said where the employees develop, a lot of opportunities, and where the employee can say I am a junior frontend developer today, I see myself in 5-6 years senior architect. How do I do this within my organization? And with the help of all the opportunities, mentors, courses, projects, jobs in the middle, we build his career and help him take every step in his career and explain to him what he needs to do.
Yishai: I understand, so it also connects to the world of hiring and promotions or skilling up, in the end I was able to advance in my skills, maybe I can get a promotion and advance.
Yulia: Completely.
Yishai: Excellent. Today we will talk about data products, some kind of world of products that in the end uses data and makes data available to customers to give them value, and Gloat sounds like a data product. And I want to touch with you about, as if to understand where it is different, where it is similar, what challenges it poses to a development manager or a team leader or whoever is ultimately involved in creating it. So Vicki, maybe we'll start with you, what do you think, where are the main points that data products behave differently.
Vicki: Me, the truth is I'll maybe start a little to connect with what Yulia said before about the product. In general, many of the things we do today, they are supposed to help many people within very, very large companies, that it is very difficult to reach the right opportunities for each person in an individual way without looking at things in a very general way, as if, and using data. There are companies that have like 100 thousand employees or more, and it is very, very difficult, I think, for HR organizations within these companies to reach each employee and help each employee individually. And so here data is simple, we must be a data driven organization, there's nothing you can do. You will simply never be able to reach your people and if this is something that is important to you then you must learn how to understand the employee, how to get all the necessary data about them and how to use this data later to give them the most suitable opportunities for them. And how is it different from other organizations? It's simple in this aspect of what you do with this data, like how you collect the data, what you do with it, how you give the insights back.
Yishai: Yes, so if I look at products, in the world of SaaS, or in the world of software products in general, there are many things related to flow, how I do a task, how I achieve a goal, and if I look at data products, then perhaps the data is The king and not the flow. It doesn't matter either, it's certainly important that the UX is good and that I can do something with the data, but first of all there is value in the fact that this data is displayed, there are insights, etc. And I'm interested to understand, when I develop such a data product, where the emphasis is not always on the usability or on bringing me from place X, I don't know, I took "Lime" on the way here. There is a lot of data there, but it doesn't serve me as a user, I have to find the scooter in the end, turn it on, get here, close the trip and pay. So for me it's not a data product, there are other investors,
Vicki: You don't, but "Lime" also has a lot of data, for example to know, to bring the scooters to the places that will need them the most. So I think that today when we live in the world of products with a lot of users, almost every product has some kind of data component and probably big data, yes? To bring the insight and to bring the product, this is one style of the products. And the second style, I think that today the world of go to market is often based on the data, when you want to sell, when you want to decide which product you are going for, in which direction, we have endless options and we have a short blanket of resources. We always want to know how to prioritize and all the, once these worlds of risk and effort and all these worlds of deciding a product are nice, but today there is another component of data analysis that you can do, to say in advance whether the product is going to be successful for you or not, according to The data you collect from the field before you redeem the product.
Yishai: Yes, so there is a world of data for internal use, data for BI, data for product analytics, to reduce friction in the product, to understand which users, what they get stuck on and so on. And there are the data products that actually put the data mainly for the blokes and users who end up using it.
Vicki: When you take data analysis as if, I will connect for a moment to what you said, if we want to do, you said before that there are, say, tasks in the classical world without data involved. But if we want to know what value we actually want to give to the users, and we have a lot of data and we just have to think about the right aggregation or what not, what is the right processing I need to do to the data, then I can do it in advance. I have all the data, I can analyze it, I can check what features I can provide that will give what kind of value and then according to my processing of the data I can understand where my users will get their maximum value.
Yishai: Yes, which is actually internal use.
Vicki: Both internal and external use. What is meant by internal use?
Yishai: If I have to decide how to develop a feature or even what UX is appropriate, I use the data I've collected to develop a better product. The interface I was working with that I took the scooter to here relies on data behind the scenes, someone said voila, if the button is on the top right, the users are less confused.
Vicki: So my intention is more, for example, if the company as a data products company wants to give some kind of product to the user, and it does not know if this product will be valuable based on the data it has, then it can be done with the tools we have / like we can do analysis on the data we have, to understand How do we do this processing and it's not for internal use, it's more to understand what the customers need and how we answer it.
Yishai: Okay, so when I build a product that again, the data is its heart and it is also the main value that the customers get from it, where is the development process or the work process in building this product? Where is it different or similar to the process that I build a different type of product, which is not necessarily data oriented or where the data is not its main point, where does it meet me in cycle processes versus a product or in learning versus what works for customers and what doesn't.
Yulia: Me?
Yishai: Go for it.
Yulia: So I think that if we start talking about product development, I think that many times every product manager, every company, will prefer to develop a product that has some kind of real use case and even a partnership, a design partner, with which the product can be developed. And this also applies to products that are data oriented and other products. In products that are data oriented, I think that when you have a design partner who can look at the data and say how high-quality it is, how much it brings value to it, in the end what are the products, what is all, we introduce maybe some kind of innovation and things like that and we also reduce the amount of manual work And maybe it's tiring to build things, maybe we're solving a problem that can't be solved, as Vicki said today in the world of, in the big companies, you can't go to each and every employee and offer them things. So in these cases, do we offer relevant proposals, do we offer relevant routes to the employees, I think that without a design partner we would not be able to know if the flow, is our product good, because the flow might be fine, yes? We offer a career path to the employee, but is this career path interesting? Will the employees like or dislike him? This is something that we have here a design partner to help with, and this is usually a characteristic of data products, which you look at,
Yishai: This means that their reliance on a design partner is more fundamental and it is more difficult to progress without a real design partner, unlike perhaps other products where I can make a little more progress, even if I don't yet have the exact design partner who gives me feedback at every moment.
Yulia: Unless you know what the end game is, right? What is the final product you are, what is the final impact you want to achieve, yes? In our cases, because it's iterations, because it's working with people, it's very hard to know what people will like and what people will prefer.
Yishai: The data can also surprise us.
Yulia: The data can also surprise us. Every organization is different in its structure and the employee's ability to progress within the organization, so it is very interesting to work with the big design partners who define this field. Basically the whole world of employee development is relatively new.
Yishai: Yes, so the visitors don't always know what they need and want either. Does this mean that when I work with design partners I, again, on data products, I should demand more from them? There are additional skills that they need to be able to look at data that is not yet completely digested and say there is something here. I mean, maybe they should be power users more than regular users, when I do a design partnership on a product that is mainly flow?
Yulia: As with the adoption of any product, you have these crazy early adopters who will go with you even when your product has a thousand bugs, and will show you what's good and what's not good, I think that's how you should also choose the design partner. You probably won't bring someone for whom everything has to be precise and orderly, probably your language, you will probably fail, if you build a design partnership based on such a person or such a client. But if you take the dreamer, and you go with him, then he can dream along with you and say oh, here I see my value, let's start digging here, in this area.
Yishai: Okay. What about delivery of value outside the product, as a learning tool? I can imagine, if I think about your world, let's get you Google Sheet or some kind of Excel with data that is already actionable, but it's not sewn into the flow, it's not in the product, we'll get feedback on it, it seems you're able to do it, let's say if I'm talking about career path, someone can look at this output with their eyes and say voila, it seems logical, voila I'll manually grab 10 employees and try to see their feedback on the data I took out. Completely outside the product or completely, as if much less engineering, to receive the feedback and then continue, as if to advance the feedback from the field, to real development work or closure of flows and UX, etc. It's something you get to,
Vicki: The question is what do you want to achieve with this, as if you want to brand yourself as a company that provides raw data APIs and you do some analysis that suits you as a company? That's also fine, there are companies that do that, or you want to brand yourself and give a lot of tools like we do, which is simply a whole platform of everything from everything, and then give some other raw data that you can analyze yourself, it doesn't give the full impact Like getting everything you get within the entire platform.
Yishai: Yes, so I'm thinking of a separation here between, if I'm talking about, again, some kind of story of career path offers, then I have the, okay, at the end an employee has to receive offers, personalized, and respond to them, choose them and use the system this. So the system is measured by the fact that it's easy to find and it's easy for me to give feedback and understand what I'm seeing, etc., but it also has some core that says did I bring you a good career path or not, I can disconnect the questions and say, I'll put it in document, tell me yes or no, and I still don't ask myself whether the flow is intuitive, whether it's easy to find the button, how to search. As if I am separating usability questions from questions about data, maybe our data does not know how to flood good career paths and then I have nothing to build a UI and a market place and flows if the data does not work.
Yulia: I really connect with this approach, I think that before you start investing a lot, you need to understand that the basis is good, and the basis here is data and an AI-based algorithm that can bring you good data. More than that, you will probably keep improving your algorithm all the time and that will be your way of testing, you won't connect it directly to production and UI to know if your lanes are good, yes? So I really relate to this approach, I think, I can say that even in the organizations I worked in before this, before Gloat. We had a product for a whole year that was run in Excel with design partners, without a UI, without anything, to prove that this product was even feasible, before we brought value to several customers who worked with Excel, we did not build a line of code either in the backend or in the frontend, only in data. Everything we did was just in data, just to see that this product would bring value.
Yishai: What does that do to a product person? Doing such a process is either completely radical outside of the product without code, or the main questions are whether the data is good, whether we were able to bring insights into how the relationship between the product and engineering changes or looks different when that is the focus.
Vicki: I think in my previous company that we also did data products and in fact the product manager that I worked with there she was very strong in metrics and she really tried to understand the customers and what they need and how we produce as if the most valuable data features, as if then she was very, very connected to aspects of the data analysis, for aspects of the metrics we want to find, and also for what AB testing we should do and aspects of the data. So the more the product was really there and connected to the data itself and try to extract from the users what their needs are, it could be very, very successful.
Yishai: And on the other hand, the engineering group that builds it or makes iterations on the data, so sometimes also engineering and data scientists or analysts, they have a greater weight in deciding what is possible, what should be built, what is right, again, compared to a product and compared to products that are not Rather data-oriented.
Yulia: I think the boundaries here blur a bit between product people, development people and whoever checks the data at the end, yes? Because the product is measured not only on its features, but also on the quality of the data you bring. Flows at the beginning are even missing within the, at the beginning of the product, right? There will be no flows. So all we have is data, and data, there should be very, very quick iterations of evaluating the quality of the data, understanding how far we are from the direction, maybe we can make some tweak here and change the algorithm a little more and bring something much better. So if we talk about organizations, HR organizations are very version oriented, there are tests and things like that. In data products this won't work, probably for data products in their beginning, in their development, we will have to make some kind of, several changes a day, and talk 5 times a day in Zoom with the customer to know how he experiences the change in the data we made in terms of the quality of the results.
Vicki: I just want to take a moment to give an example from the first data feature we uploaded to Walmart. I remember that it was very, very hard work by both the engineering, the data scientists, and the product together, and then when we defined it as if, from the data scientists' side, they tried very hard to achieve precision and recall that would be suitable for what we wanted in order to define. That the data was high quality, and at the end there was some kind of "good enough", like okay, we didn't reach the maximum precision and recall. This will be the first iteration, and the engineering from our side we took and tried to understand in terms of how the data, does not know, if there are fields that look strange or there are nulls or all kinds of things like that very very basic, in order to understand whether the data we are providing now for a data feature This is really the best it can be and the most complete it can be. And from the side of the product as well, in terms of bringing the value properly, so it was very, very hard work to try to understand the quality of the first data feature we are bringing, and also to already plan what the next iteration will be.
Yishai: Yes, I think that if we look at, as if from a classic definition, product people write user stories, and talk about whether the user succeeds in performing the task, and in most cases, again, of classic products, it depends on the flow, whether the flow allows the task to be performed in such a way that the user receives the what he wanted When you put data into the picture then the question becomes okay, I can do the task, but the question is whether the data was good enough to do it with confidence or to make a decision, and then it becomes something very fluid, who said the data is good enough, Like how do I know the user was successful? He managed to move the button from A to B, he can technically choose to act on the data, but the question is whether the data is good enough for him to really feel comfortable choosing, and it is already becoming something that is fuzzy.
Yulia: Right, more than that, the fact that he didn't click, the fact that he didn't select, say, the specific line, is it because the user interface was uncomfortable and he couldn't find a button? Or because the line was bad and he didn't want it? Okay? That's something we can't even assess with the standard normal product analytics tools, right?
Yishai: Right, or I'm creating a UI that allows me to give feedback, but if I go back to the story, the story says let him choose a line, ok, the UI allows you to choose a line. And there is not a single word here, or at least it is difficult to insert a moment's speech, that the offers will also be good. And what does favor mean? This is from a new production in Stories, compared to other products.
Yulia: Yes, we are breaking the world of functional or functional here, right, where is the quality of the data? Neither here nor here.
Yishai: Okay.
Yulia: You can tell, right?
Yishai: There is some, right?
Yulia: that suddenly the world of the product introduces some kind of third world, a third dimension into the world of requirements.
Yishai: Yes, if we increased the quality from 82% to 84%, is it functional or is it non-functional, how do I measure.
Vicki: Also how did you define the 82% (laughing) based on what?
Yishai: This is a deep question, but let's say I have a number or let's say even each of the users marks, but it's a thousand becomes a sequence, so what's the extent of a story, who decides that it's good enough, and also wait, is it a functional or non-functional change? The user story didn't change, I just gave a little more value.
Vicki: For this you have all kinds of tools like AB Test. I don't know, do you want to know how your stranger experienced this thing? Let's do an AB Test, let's see, 50% like that, 50% like that and let's see how investors experience.
Yishai: So it's a tool that helps me choose between two versions, but is the story complete?
Vicki: So let's say let's say, I'll go back to the example I gave, we tested the quality of the data, we reached a sufficiently good precision recall, we reached the point where we don't have nulls in any field, everything is good, and the numbers look fine in terms of quantities, let's say. Then we say ok, the quality of the data is good enough for us, to put it on the market for a moment and we will get some kind of opinion from users. Then you can do, say, AB Testing or all kinds of other product tools that I'm not that familiar with. But let's say you can accept it to get some kind of opinion and then see if you need another iteration, maybe you need to download this feature, maybe this feature is not valuable, I don't know.
Yishai: And what moves forward these questions of let's do AB Testing or let's do, I don't know. The quality is not good enough, let's move on, is this a product warranty? at the end? Or responsibility of a group that develops it?
Vicki: After all, we should all be owners of this data and to forge ahead, if I see that the data is not of high enough quality and I am in engineering I should feel comfortable enough to say the data is not of high quality, let's do everything to increase the quality of the data.
"After all, we should all be owners of this data and ...if I see that the data is not of high enough quality, and I am in engineering, I should feel comfortable enough to say the data is not of high enough quality."
Yishai: So there is a bit, let's say, more blurring than usual between product and engineering, in terms of who decides that it is good enough, who is the driver to make an improvement, because it is common to think that engineering wants to promote the non-functional, they want to have code that will allow them to work easily Also about the next feature, but that the product is the ones who finally decide or determine, this is the shell of the story, this is the flow that needs to happen. And in the data, I hear that there is a little more mixing here between what product and engineering have to give an opinion on, whether it is good enough, whether it passes some level of experience.
Yulia: Yes, there's a new role here that suddenly popped up, right? Within R&D, it always existed, but not within R&D, suddenly we have a data analyst that is needed, who may be the one who signs off on the quality of the data, on the completeness of the story, this is something that did not exist before they started working with data products .
Yishai: So let's really talk about the analyst, first of all where does he usually sit? Is it part of the engineering organization? Is it part of the product organization? Is this a third party?
Vicki: In my previous company (laughs) the data analyst sat within the NLP team and worked together with them and it worked amazingly. Because she knew exactly what was in the data, she knew exactly what worked, what didn't work, where there were things that needed to be done, and she was also very verbal in the way she said where the pain was.
Yishai: An NLP investigator...
Vicki: (Laughs) Yes, she was also a linguist, right. So she really knew where the pain was in a very, very clear way, and I think it's a very, very great value for the organization, that there are data scientists who deal with things that are more long-term, and then the data analyst can come and look at the data for a moment and give some sort of situational picture.
Yishai: So you are actually saying that it worked well when the analyst was part of the development, and not of the product, which maybe it was, if I had to pull out I would say it is closer to the product, because you have to say what is good enough and what is not good enough, more about the what and less about the how.
Vicki: Because it depends on what the goal is. There the goal was really to raise things like data quality.
Yishai: Okay.
Yulia: I think there are several layers here, yes? There is some sort of layer of data scientists here who work with their models and when do they say the model is good enough to start putting it into development. Here we need an analyst who will sit within the organization of data scientists, as Vicki said. And there is how this data is already connected to the product, and here I do think it sits somewhere in the product, between product and development, yes? But already in development, not in data scientists, for a team of scientists, with us it is relatively separated and connected. It's impossible to know, it's quite fluid, how data science connects to development, but I think it's two completely different layers of analysis that you need to do.
Yishai: Okay, so we have, a data scientist is something that is a little more research, it is a little more open-ended, they also end up working on product tasks, but maybe they do a little more exploration, not sure the direction they are going He will succeed. But then you say you need a data analyst as part of the development team, living in iterations, living in delivery, and its name is no longer exploration, it's building the value or measuring it as good enough, and here it's not an endless process. And then the downside is what, that a data analyst is assigned to a certain team that makes a certain product and he can't also serve a thousand and one other things? Is that sometimes the reason to put analysts outside? Let them be both this and this and this and BI and,
Yulia: It depends on the size of the organization, yes? I think this is how the organization develops. In the beginning we all have several hats, yes? Each of us does several things. So in a third of a job we do it and in a third here and there it adds up to a little more than 100%, right? (laughing) But as the organization develops you feel more and more the need, this is how I saw it in the previous organizations that developed, there is more and more need to have people dedicated to the specific business, to the specific business line of your products. Because you know them, you understand them, you also know what their goals are and it's no longer possible to focus on eight products, but perhaps you need eight people within one product, to give the real value, yes, it all depends on the scale.
Yishai: So if I have a data analyst in the development team, how is the day to day going? As if developers take tasks from the backlog or from the sprint or whatever and work and create code, the analyst also works on stories? Taking stories is their owner? Or is he a helper or a helper, a companion to the engineers for their tasks?
Vicki: I think it's really like a per-organization, in the previous organization I was in, which we were, it was really one team of data scientists, the organization was very small, there were less than 30 people at that time. And she was part of the sprints and she had her tasks and she had to, just as data scientists now examine some direction to see if it is good or not good, she also examines directions to see if they are good or not good. If now we have some kind of feature that we wanted to run, some kind of recommendation system based on certain data, then it goes through this data, then it makes all kinds of queries on it, then it checks whether the recommendation system will really give the data insights we want will she give?
Yishai: She works on things that are like one spirant forward or backward before the development itself?
Vicki: In a perfect world yes (laughs) but in general it all happens like this probably sometimes together.
Yishai: Okay, I found something good enough, let's put in a task to develop or make it organized in terms of engineering and move forward?
Yulia: Maybe we can give a real example. We are now releasing career path version 2, okay? which is based on a completely different data science algorithm, okay? So basically there was an iteration between engineering and science, to bring all the lines without, as you said, in Excel. And we went through Excel and improved the model and how it connects to engineering, how do you take the things and the graph that was built and where is the limit, where do you cut the coefficients, yes? At 0.6 or at 0.8? Okay? Here we were completely cut off from the customers, we were cut off from the outside, but we used the data we collected from customers and tried to see if our direction was correct at all, if this model was going to be successful.
Yishai: Yes.
Yulia: Today we are at the stage where we have already taken on two clients and are starting to implement this feature in two clients, it is not yet going to be released to everyone. Because we feel that there is also tuning on the data, okay? So maybe we thought that in the ideal world it was going to be like this, but here it is with this client it works like this and with another client it works like this, so maybe we need to do something iterative before the client releases this feature he will decide where he cuts according to some sample ) or something like that, and now it affects the feature. So here too there is an analyst who sits and influences, and here I said, this is exactly the difference between an analyst who checks the model, the data is clean. And how it connects in the end to the product and the data of the specific customer or several customers in order to understand how this model will live within a product.
(transitional music)
Yishai: Okay, so we talked about job holders and the importance of the ability of a data analyst and within the development team, let's really talk a little bit about the skills or how I build a team that knows how to deliver data products. On the hiring side, on the skilling up side, how is it different or, Vicky, how do you feel, what is critical to put your finger on to make sure there are the right people for this task?
Vicki: I think that many organizations in recent years have gone through this shift from systems that are back-end to systems that now need to support a lot of data, and this is a completely different stack and it's also completely different skills. Like if I now save data in a certain way in a back-end system and I just need, I don't know, to transfer, it doesn't matter, I won't give an example. But if I now want to switch to a system that gives me data insights, then I need to learn how to create data pipelines, I need to learn how to work with scheduling certain tasks, I need to work with events. I seem to need to transfer my entire system to a different form, that back-end systems did not work in this way. And a lot of organizations from what I feel like this, from conversations and authors that we talk about these things is very, it's a difficult and non-intuitive transition.
Yishai: And it happens, from what you see, in such a concentrated way? Is there some infrastructure team that builds the pipelines and builds some infrastructure that later product teams can use? Or does everyone do it for themselves?
Vicki: From what I gathered some information (laughing)
Yishai: Who installs the Kafka?
Vicki: (Laughs) So from what I gathered a little bit is that it usually starts as a pain for the organization, then the organization gives it a team to do something small and then they feel that it is needed throughout the organization and then they create some kind of data platform or something for it as if it is a little more inclusive, because the organization understands that he moved to become a data organization. But in order to become a data organization you have to start gathering the people, like starting to bring in data engineers who understand how to work with data, like bringing in Kafka when you're a back-end engineer and you can't expect things Like things that happened to us, like suddenly rebalancing in production when you have insane amounts of data, how do we know these things? We haven't worked with such amounts of scale before, so these things like you should have the right set of skills to work with data, that A profession that is relatively new, so as if there aren't that many people who have experienced these things, on a very, very high scale.
Yishai: So if I am an organization or think of myself as an organization or a team or a product that is data oriented, then a model due to this is already when there is a platform and teams that maintain something central for everyone and an initial model that usually starts with one of the teams that encounters the first need, starts to establish something.
Vicki: Do POC, POC is always good, start from POC (laughing).
Yishai: Okay, but then there is the transition where they say okay, it's not good enough, it's something ad hoc, I need to dedicate a team to it, which will be its day in day out, it's a team that doesn't actually build products, it builds infrastructure . So it's a bit, how is this transition from, I'm interested in the dynamics of the transition, when do you decide that okay, it's time to establish an infrastructure team that will do this and not deal with the delivery of a product.
Yulia: I think when you suddenly recognize that you are duplicating things, yes? Either you suddenly duplicate how you work with Kafka, which you mentioned here, or you suddenly duplicate the data, which is already starting to hurt, because you have discrepancy data and it costs you too much. So how do you build one thing that serves both sides, and how do you not compromise the functionality of either, yes? So basically if it's one team that started and continues to maintain it, then it remembers its own interests and sometimes forgets the interests of the other team and can hurt. And if it's a platform team then it actually has two clients and has to serve both of them, and that's the transition I think you've already made, when it starts to hurt like Vicky said, and the pain can be duplication, discrimination, things like that and less I think of a desire to put something in the center when there's still not enough ,
Yishai: Can we even start with something central? Is it realistic? This is true? I'm fine, I've already been in several startups, I've been through the pain, let's start with the Tim platform that will put it in the center. Can't skip this dirty and initial step? Or that, I'll make mistakes, it's just not right, until you experience the pain and then move.
Vicki: Always experience the pain and then move, always, as if it's always true, this, if you want to do, it's like-, I don't know, we all want to do like Netflix and like Twitter before the era of what's happening now, but we're not in the same needs , we are not in the same pains, so as if let's understand what our needs are and what our pains are and then we will build what we need.
Yishai: Okay, so I think it's interesting as even someone who is being interviewed at a company or who looks at a company for a moment from the side, to understand where he is in, where this company is in the process of an ad hoc solution to data problems or the establishment of data needs for a specific product, and the situation that has I have some kind of service and bus and something central that all the data products and maybe not the data products rely on. Great, like a diagram for architecture, but you can't get there straight away, you have to start with things next to it and connect. What does it do to a team that stops devising a product or is only talking about an internal platform, as if it finally has one, this is a very big shift in how it is conducted in the discovery of value and feedback on value, and does not deliver user stories at all. It's not for everyone, so what does the transition look like assuming you're not completely bringing in new people to build your platform team or data team. How do you find who is suitable for this and what does this change look like in terms of the life of, even team lead who until now delivered products and now he is delivering a platform.
Vicki: I wouldn't say that you don't have a shift in people here, you must have a shift in people here because if I'm a team leader who likes to see so much, count the page views or things like that, I won't, I probably won't find myself on the platform, yes? More than that, it's probably a team job without a product manager, because what's a product anymore, right? There are no more product definitions, no customer facing, it starts to be only technical requirements.
Yishai: Right.
Vicki: So I think that when you do something like this you naturally, with the growth of the team, you naturally see which people are more attracted to the product, to something interactive, versus working with customers, working with the requirements of colleagues, and something that is perhaps a little longer in the cycle, A bit more of a service provider for other teams, yes? And here I think it's usually different people, it's not the same person who can suddenly make a switch. There are some who do like it, but mostly I've seen it start within product teams, some people like customer facing more, and there are more people who like it more the infra within the teams, and as the teams grow and the organization grows and you already decide to make a platform group, then you move these people in this direction and create a group here.
Yishai: What happens when I work on a product that is data-based and perhaps relies on some platform, and I don't get a fast enough or flexible enough service from the Tim platform. But I need to think and I want, I don't want to be stuck, how, like,
Vicki: You moved to the next step, after we already did the, we built a platform team, now this is when it doesn't work well (laughs)
Yishai: Or when it's great but I have something, I have needs that may not be the highest priority within the organization.
Vicki: And there is no product, you say, so there is no one to prioritize?
Yishai: And I need the data like this and it will take them six months. What, how do you solve this? As if one way I know is fine, I will solve it myself, we will do what is necessary ad hoc, but I have now created a new pain.
Vicki: I think the platform should have an enablement and not a bottleneck, but it's like a philosophy already (laughing)
Yishai: The question is if in real life, do you see it? It happens?
Yulia: I believe that the way you started from the pain and then reached you reached platform engineering, here you are too, here you are in the iteration. So you created a new pain, when it hurts enough, put it back into the platform. Do something yourself, run with it, prove that it's good, prove that it's important, when there will be other teams that will use it and it will be a real pain.
Yishai: Then force the platform to eat it.
Yulia: In the natural way it will enter the platform, each iteration.
Yishai: Okay, I'm sure the people of platform teams really like the sentence you just said (everyone laughs) and say yes, everyone was given permission to do darkOps, but maybe that's the way to deal.
(transitional music)
Yishai: Let's talk about such external or special challenges around the world of data products. First of all, where do I even have data from?
Yulia: So part of that is really customer data that you're collecting. And are you allowed to mix, are you allowed to use the data of one customer for the insights for another customer, so it's an interesting question and I think every business solves it in a different way. The second way is to buy data from other sources, buy or obtain data from other sources. And here are all the worlds of public sources and how much they are allowed and all the moral questions we can start asking. And I think that if you are, if you are allowed to use the data of one customer for another customer, how are the customers not identified and not conflicted here, yes? How the competitiveness of the customers against each other is not harmed, here too you have a responsibility.
Yishai: Yes, and of course privacy.
Yulia: And of course privacy, yes.
Yishai: So it's who, let's say it's product people? Their job is to navigate these questions of what I am allowed, what I am not allowed, where do I get data from, what are the agreements, what is a client willing to accept, not willing to accept? Is it a fact that a product is managed? Or does engineering have a say here? What does this process of understanding what is possible, what is possible, we need to buy data to achieve our goal, we need to buy such data or bring the data of all the customers to make, say, a benchmark or something like that.
Vicki: One of the things I can add, as if from my past, is that we brought data from all kinds of external sources, so the product's touch on this matter was to understand what kind of fields we need for which use cases, so as if then we were Those who bring all the data, then they would look more at how to build a use case from it, from the data we have. But that's one way.
Yulia: I think ownership of the data has made a bit of a shift towards development really, so buying is probably either buying or transferring data, as Vicki said, shifted a bit more to development. Sometimes product managers do share these tasks together with development, but one of the new roles that I suddenly started to see in an organization with which I used to have no interaction, is the roles of legal and CISO and where the privacy and where the data should be kept, what is allowed to be kept and how much Time and what is allowed to be shared. These are things that sometimes there are organizations that the product takes it and there are sometimes straight, a direct channel into the development, as we said non-functional, they usually fall through the cracks, and it is of this type.
Yishai: So in order to make it efficient or effective, the compliance and legal people have to reach the top team, as if it is difficult for someone in engineering to concentrate it from the top and say I and know exactly what use is made of each data, which fields are saved, what is the retention (retention) Our policy, how do you create a reasonable interface between the legal compliance security people, etc., and the people who are close by who are now building the product, without each driving the other crazy.
Yulia: So I think we talked a little bit about platform team, so we do talk about different types of where we store the data, yes? There is, probably when you have, you already reach a large enough scale that you have a data lake (data lake), and it is the responsibility of a platform, probably the legals will come to this team and start working with them, yes? What data do I deserve there, how long is it saved for and what do you do with it. And here it depends to what extent you are, what tools you produce within the platform. If you enable data ownership to teams, you probably also create enough tools for them to take care of retention and where the PII is and coloring and identifying the PII within your data. And yes, just as distributed architecture is complicated, here it is distributed data, it is complicated. It takes a lot of heads in one room to understand where your data is and what happens to that data that suddenly travels from one place to another and is stored in different places.
Yishai: So the platform provides services of, say, retention or okay, the client asked to delete, so I delete centrally and all the teams will manage?
Vicki: It depends on the maturity of the platform, in the ideal world, what you would probably want is for each data resource to have tools for how much you keep, how you identify the specific data that you now, for example, need to delete because of GDPR or any other reason, and how you do it instead central. But it's like we said, iterations.
Yishai: It's a challenge.
Yulia: Yes.
Yishai: So here too there is some vector of maturity, that initially the compliance people have to work with the teams that probably hold all kinds of islands of data and all kinds, or replicas or data to be chewed in a certain way to serve the use case. And with the maturity, with the platform, then these questions also become central and then a staff member comes who wants, needs the data, I need it for a few more days, for the use case, so I bypass the, generate the new pain you talked about . Let's talk for a minute about cost, this world of data brings with it challenges of cost that may not exist in normal products or normal flows, how is the reference to the price of the data, to the price of moving it, of maintaining it, of questioning it, where does it fit into the daily life of the process the development?
Vicki: By and large we are now the truth, just last week we had a question like this about, we have something, a feature that we need to devise and we tried to work with a certain platform that is a little cheaper than another platform, but it was not able to bring us the results we wanted. Then we said okay, we are now ready to pay maybe a little more, but later on we will have to figure out how to provide a long-run solution here that also takes into account the cost, so that as in engineering the matter of the cost is very much talked about, as if it is in The discourse, but you need to understand, I think you can explain it better, about how data completely changes the perception of cost.
Yulia: Yes, so maybe we should talk a little about the prediction, how much it could cost. Because when you talk about the normal development process, you can imagine on what scale we are going to run, in the future, if we sell the , if we have 100 thousand users a day, then this is how it will cost us. Compared to data, you can't know, because you don't know in what forms you'll have to save it, what the amount of data will be, and many times your ability to understand, to anticipate in advance how much this product is going to cost, can change very, very much, right? According to the feature. And so I think it is very important to include here the thought processes and assessment of how much the feature is going to cost us and how much it is going to be worthwhile for us, at the very beginning, in the planning, at the beginning of the feature, when we come up with the requirements. For example if I'm going to do some kind of calculation once a day, or once an hour, it's going to completely change how much we're going to pay. And many times product people tended to ignore the product cost, and today it's a question that comes up even more at the requirements level before writing the first line of code or bringing in the first amounts of data. We start talking about how much it will cost and the cost starts to affect the functionality of the product many times.
Yishai: So that's it, it's like something new, most products say here's the story, engineering is going to implement it and find out along the way that the query we made requires us to upgrade the database, we fight it or not as part of the non-functional staff (stuff), but there is no one who says Listen, I'm ready to allocate to this feature or this story 100 dollars a month, or a thousand dollars a month across our customer base.
Vicki: And in the conversation they will tell you I owe it to Real Time, Real Time, what does Real Time mean? Like do you know how much it costs to bring it to Brill Time? do you even need Maybe we should do some kind of off-line processing that will cost us much less?
Yishai: But the very conversation about the cost, at least in organizations that have not yet gotten used to doing it, it came two months later when the cost suddenly climbed, so they say wait, we have a problem, let's shrink. But how do you decide what is too expensive and what is cheap enough A thousand dollars a month, is it good or not good?
Vicki: Depends.
Yishai: This question seems to be completely new to many product processes, where does it come from? Like how it happens, the sentence Introduction We will respond to the cost problem in retrospect, which is what we have been doing until now. The CPU went up, let's increase the instance first, or let's increase the database, after that someone will shout about the cost, we will slowly lower it. But it is no longer related to the feature, it is not related to the story, it is related to the system being expensive, let's find an opportunity to improve and the engineer remembers that yes, we did something stupid here, let's fix it. It's the usual flow we all know. How do you go from that to a situation where there is a price tag for the feature?
Yulia: So first of all it's a cultural change, yes? You cannot introduce something like this in an organization that is not aware of the cost, has no access to the cost and has no ownership, yes? And the definition of ownership in such organizations that are cost oriented and know how to introduce it into the culture, so you have labels and you have a definition of how much each team spends, in years, on its production, yes? on his features, or will spend in the future if he plans something. And here the budgets also come in terms of strategy. How strategic is your product going to be, how much do you think you will earn on it, how much do you think you can share this cost between the different customers and maybe lower as your customer base grows, lower the cost per user, per customer. In data products this is very significant, many times you really save data in one place but use it for many different customers in the same thing, in the same base.
Yishai: And then what, the developers are starting to be aware of the cost and how do I burden the cost on users and different organizations? Is this part of their considerations? Or is there someone counting dollars on the side and just saying the cost of this tag is on my hands, let's sort it out.
Yulia: So I think that both are needed here, yes there needs to be someone central who sits and says here it is too expensive, here it has jumped too much, to be on top of things. But within the, within our teams, everyone knows how much their products cost, whether they jumped or not, they have alerts about it, and also know how to manage the conversation, I now introduce this feature or I introduce this technology, I improve the performance and I will lower the cost. Okay? This is part of the innovation many times that happens to us within the teams.
Yishai: that this is non-functional progress that is being made, I am improving technology, I added an index, whatever, and I know how much the cost has decreased.
Yulia: Or when you are going to implement something functional and you need to bring architecture, your new design, you are often required in the design review, cost estimation.
Yishai: Did you happen to see or succeed in taking it to the edge of say this is part of the tests? PR, as if sometimes checking performance benchmarks, they say this code will not enter if it knocks the performance of something, of the system or of some view, it also will not enter if it increases the cost.
Vicki: Wow, what a beautiful world (laughing)
Yulia: I had to stop Product Requirements for this, that the cost is simply too high, it won't pay off and we will stop, we won't open the product because it won't pay off for us.
Yishai: Okay, and who decides what is worthwhile? What, is this a margin question? They say I need X, for every X dollars I put in I'm allowed to take out Y, or am I now in the growth stage and I'm not playing for margin but only for the sanity of the general cost?
Yulia: It depends on the stage, yes? Of course, but I got to work in a product that we already knew how much, what its margining is, and then every feature is very important if you still meet the percentage of the profit you want to bring, from this product. So many times you either make the feature and start negotiating with the business side to expand and sell it as an additional package, maybe.
Yishai: That is, either you increase the top line or you mess with the margin.
Yulia: Yes.
Yishai: which is probably older companies, with thousand products that are very measurable, and a house where the margin already plays a role. Apparently talking about cost should not be limited to data, every feature I can measure how much it costs me, and it could be that this feature is killing me due to implementation regardless of the fact that it is data. So what makes the data special here? Just another scale? Or a much stronger impact on the cost?
Yulia: Another scale and I think that the predictability of the cost when we insert the data parameter decreases, and here you are, that's why you need to be more on top of it at the beginning.
Yishai: The predictability, okay. Because what, there is a big difference between clients or between, what data, the amount of data I collect for them, the amount of data I have to manage?
Yulia: I think your scale is increasing, let's say you increase from a thousand users a day to a million users a day, when it's only about an architecture that doesn't involve the data, your ability to predict is certain, but when you introduce the dimension of data, then you have here amounts of data that you can, it's not Always linear, it can grow much larger, and it just puts another parameter into the equation, which makes it much more complicated.
Yishai: It is more difficult for me to predict what growth will look like.
(transitional music)
Yishai: In conclusion, I would like to ask each of you for a thought or two for those who are now starting to deal with data products or who want to move in this direction of dealing with the delivery of data products, one or two tips like that, what is important to pay attention to, what not to do or what to do to succeed. Vicki, what are you taking with you on this trip?
Vicki: First of all, from the moment I started working on Data Products, I just discovered how much I love it and how much fun it is. So anyone who hasn't had the chance to work on data products yet, try it, it's really, really fun, it's the first thing. And secondly, if you are already starting to work on data products, I think the most important thing at the beginning is to understand what data there is and what we think we can do with it and where the organization wants to take this data, in order to perhaps understand a bit what the added value we can give to what we Think you can do with the data. Because there are a lot of things that can be done with the data, but as if questions of humans like this, what can it give me, what can this information give me as a human being or as if taking the data and mapping it back into the language of people.
Yishai: And between the lines I hear that you probably have to love it to be successful, so you have to find, let's find the opportunity to experiment.
Vicki: Yes.
Yishai: See if it's something that really turns you on, then do it, it's a good direction for you.
Vicki: It's always true, yeah (laughs)
Yulia: Yes, like Vicki, I have also been in love with data products for many, many years. One of the first things I realized was that it was necessary to completely break the way of thinking I had as an ordinary engineer, architecture and things like that, that everything here is going to be different, as you said. Suddenly the flow is not central, but what is central is the data and the quality of the data and what we can bring, how to make an MVP, is suddenly very different, you can start without a product at all, just with the data. And it is already a product - can be. So I think that mental flexibility and trying to break free from the previous thinking that was in the usual Fluo products that did not involve the data, to understand how to do it differently. Many times what I realized when I was doing data, sometimes doing more is faster than doing less, because you can do many things at the same time and suddenly see things happen, so sometimes even in processing, you do more processing and get a result faster.
(transitional music)
Yishai: Excellent, thank you very much for coming, this topic of data products and how they are different and similar to the general world of products that we know, at least to me is fascinating, so I was happy to learn about it.
Vicky and Yulia: Thank you, thank you very much, what fun.
Yishai: Thanks.
(transitional music)
Go to devinterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are in rapid growth and are recruiting for a variety of positions in all fields. Visit linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll hear from you in the next episode.
(Closing music)
Links to the nifty tools and resources mentioned in the episode: