בפרק הזה של פיתוח בהפרעה חזרנו לאחד הנושאים האהובים עלינו - Platform Engineering, אבל הפעם מהכיוון המוצרי. מצטרפות לישי בארי, CTO ב LinearB, יפעת מתוף יעקב, מנהלת מוצר בכירה היום ב JFrog שמביאה הרבה שנות נסיון בניהול פלטפורמה, ו DevOps, ולינדה חביב Developer Advocate ב AWS בעולם ה Serverless שלפני כן הגיעה מ Fox News ויודעת איך זה נהיה להיות גם הצרכנית וגם המשווקת של טכנולוגיות לאנשי פלטפורמה ו DevOps. הצטרפו לשיחה מרתקת.
In this episode of Dev Interrupted we have returned to one of our favorite topics - Platform Engineering, but this time from a product perspective. Joining Yishai Beeri, CTO at LinearB are Yifat Matatof Yaacov, today Senior Product Manager at JFrog who brings many years of experience in platform engineering and DevOps, and Linda Haviv Developer Advocate at AWS from the serverless world who previously worked at Fox News and knows what it's like to be both a consumer and the "marketer" of technologies for Platform and DevOps engineers. Join a fascinating conversation.
בפרק הזה של פיתוח בהפרעה חזרנו לאחד הנושאים האהובים עלינו - Platform Engineering, אבל הפעם מהכיוון המוצרי. מצטרפות לישי בארי, CTO ב LinearB, יפעת מתוף יעקב, מנהלת מוצר בכירה היום ב JFrog שמביאה הרבה שנות נסיון בניהול פלטפורמה, ו DevOps, ולינדה חביב Developer Advocate ב AWS בעולם ה Serverless שלפני כן הגיעה מ Fox News ויודעת איך זה נהיה להיות גם הצרכנית וגם המשווקת של טכנולוגיות לאנשי פלטפורמה ו DevOps. הצטרפו לשיחה מרתקת.
In this episode of Dev Interrupted we have returned to one of our favorite topics - Platform Engineering, but this time from a product perspective. Joining Yishai Beeri, CTO at LinearB are Yifat Matatof Yaacov, today Senior Product Manager at JFrog who brings many years of experience in platform engineering and DevOps, and Linda Haviv Developer Advocate at AWS from the serverless world who previously worked at Fox News and knows what it's like to be both a consumer and the "marketer" of technologies for Platform and DevOps engineers. Join a fascinating conversation.
Episode Transcript תמליל הפרק
Hebrew, then English* בעברית ואז אנגלית:
(*Translated with Google Translate - so there may be some errors.
Please also bear in mind that Hebrew is a gendered language and therefore anything that is noted in a specific gender is intended as neutral and not gender-specific.)
(מוסיקת פתיח)
ברוכים הבאים לעונה השנייה של פיתוח בהפרעה, הגרסה העברית ל Dev Interrupted הפודקאסט המצליח של LinearB למנהלי ומנהלות פיתוח. נארח פה מובילים ומובילות בתעשייה ונדבר איתם על כל מה שמעניין מנהלי פיתוח, מי שעובד איתם ומי שרוצה יום אחד לנהל ארגון פיתוח. בעונה הזו נשים דגש מיוחד על חווית המפתח, developer experience. אני ישי בארי, CTO ב- LinearB, כבר מתחילים.
(מוסיקת פתיח)
ישי: בפרק הזה אני שמח לארח את יפעת מתתוף יעקב, Senior Product Manager ב-JFrog ואת לינדה חביב, developer advocate ב-AWS, איזה כיף שבאתן.
יפעת:כיף להיות פה.
לינדה:כיף להיות פה, תודה.
ישי:מעולה, אנחנו נדבר היום על platform engineering as a product או platform as a product, אבל כמו תמיד אני רוצה לשמוע על המסע של כל אחת מכן, איפה התחלתן ואיך הגעתן לאן שהגעתן, אז יפעת, בואי נתחיל איתך.
יפעת:אוקיי, אז היום אני באמת senior product manager בחברת JFrog ואני מתעסקת בעולמות ה-dev ops ו-cloud engineering, platform engineering, כל שם שנבחר לתחום. לפני כן ניהלתי צוותי DevOps פיתוח ו-QA ולאורך הדרך גם עשיתי תפקידים שהם רוחביים, הייתי release manager, technical customer success והתחלתי בתור QA engineer. באמת יצא לי מהניסיון שלי לעבוד בהרבה מאוד פוזיציות בתוך ארגון הפיתוח, וזה בעצם המסע שלי, זאת אומרת שהוא קצת שונה אני חושבת.
ישי:לא התחלת בתור product,
יפעת:לא, לא התחלתי ב-product,
ישי:התעסקת הרבה ב-delivery.
יפעת:נכון, ואני חושבת שדווקא זה שיש לי ניסיון והרבה מאוד נקרא לזה פרסונות שונות בתוך ארגוני הפיתוח, אז בתור product זה ממש מאפשר לי להבין אוקיי, מה הכאבים שלהם, מה בעיות שלהם, מה האתגרים שלהם, וזה ככה במיוחד ש-product manager בתחום ה-platform engineering זה product manager שהלקוחות הם פנימיים, וזה שונה.
ישי:אז את עכשיו מנהלת מוצר בעצם לאנשים כמוך בתפקידים קודמים,
יפעת:נכון.
ישי:אנחנו עוד נצלול לתוך זה, אבל באמת נגעת בהרבה אזורים שונים של ארגון הפיתוח.
יפעת:נכון.
ישי:אנחנו עוד נחזור למעבר הזה ל-product. לינדה, ה-journey שלך.
לינדה: ה-journey שלי. גם לא traditional at all, אני האמת חשבתי שאני הולכת להיות עורכת דין ובאוניברסיטה, I was a philosophy major, אני רק אגיד לכם שאני קצת שמה אנגלית בתוך הפודקאסט הזה כי אני מניו יורק ועברית זה כן השפה הראשונה שלי אבל גדלתי בניו יורק וגדלתי שם אז אני, יש מילים שאני לא (צוחקת) לא יודעת אבל נעשה כזה "היבריש". אבל, אז בעיקרון אני הלכתי ל"קולינג בוטקמפ", עבדתי בחדשות אחרי אוניברסיטה, חשבתי שאני אלך לעריכת דין, בארה"ב עריכת דין זה 3 שנים אחרי ה-4 שנים של אוניברסיטה אז יש זמן בין לבין. ובזמן הזה התחלתי להיכנס להנדסת מחשבים, לא לקחתי שום כיתת קודינג או משהו באוניברסיטה אז כזה בפוקס כזה נכנסתי לזה, התאהבתי בזה, עזבתי את העבודה שלי בחדשות ונכנסתי ל"בוט קמפ" של 3 חודשים. ובזמנו נכנס לי, העבודה הראשונה שלי הייתה ב-web development וזה היה יותרת ב-java script, דברים כאלה, more frontend ועם הזמן עשיתי יותר frameworks של NodeJS וכל מיני דברים כאלה ונכנסתי יותר ל-API work backend ועבדתי בחברה שמעניין כי עבדתי פעם בחדשות ואחרי זה עבדתי בחלק של טכנולוגיה של חדשות אז הייתי בצד השני והבנתי את ה-product אז תמיד, אני תמיד כאילו המוטיבציה שלי הייתה תמיד גם בשביל ה-product ובשביל האנשים ובשביל איך שהם they experience the platform. ובזמנו גם היה migration ל-cloud, הרבה, והתחלתי להיכנס ל-cloud, התחלתי להתעניין ו-over time עברתי ל-SRE, ל-infrastruction engineering ועכשיו אני עובדת כ-developer advocat ב-AWS. היו שם הרבה כל מיני סיפורים בדרך אבל,
ישי:אז גם עולם המדיה, גם עולם הבידור וגם עולם המשפטים הפסידו טאלנט (צוחקים) ואת בעצם עם המעבר ל-developer advocacy עברת לאזור שהוא קצת, אם יפעת עברה ל-product, את קצת עברת לסוג של marketing, לעולם של developer experience.
לינדה: כן, לסוג של זה, וגם זה מאוד מעניין כי כל מיני חברות, כל אחד אומר או זה יותר marketing או זה יותר product, זה מאוד מעניין כי זה סוג של קומבינציה וכל דבר הוא קומבינציה בעצם.
יפעת: אבל אני חושבת שזה באמת שני עולמות שמאוד מתחברים גם.
לינדה: כן.
ישי:אז אנחנו נצלול היום באמת לצדדים השונים האלה של platform engineering מעבר ל-practice הרגיל של platform בתוך ארגון פיתוח, על המעבר שלך יפעת ל-product ושלך לינדה לצד ה-marketing וה-advocacy, זה האזורים שאני רוצה לצלול אליהם. אז אולי נתחיל בלדבר על איפה platform מתנהג כמו product או אפילו בתוך ארגון? יש לנו לרוב קבוצה או צוות או התחלה של משהו שעושים platform פנימי, איפה זה מתנהג כמו product, כמו מוצר, איפה זה מתנהג כמו משהו אחר? איפה זה צריך להיות, להתנהג יותר או פחות כמו מוצר? ממה שראיתם?
יפעת: אז אני חושבת שבארגונים גדולים יותר, שיש שם עשרות, מאות מפתחים, אז יש באמת צורך בלבוא ולבנות מזה סוג של product. כי אנחנו רואים שיש הרבה מאוד צוותי פיתוח שיכולים לעבוד בצורות שונות, בסטנדרטים אחרים, עם פתרונות אחרים ובעצם הפרודקטיביות וה-efficiency של המפתחים, של אנשי ה-devops, של אנשי האופרציה, בעצם הם מאוד מתקשים עם זה. ואני חושבת שברגע שמסתכלים על התשתיות, על ה-infrastructure, על כל היכולות שצוותי ה-infrastructure מספקים לקבוצות הפיתוח והאופרציה בתור product, אז אפשר להנדס את זה בצורה הרבה יותר יעילה לארגון, בסופו של דבר זה המטרה, איך אנחנו מספקים צורת עבודה טובה יותר לצוותי הפיתוח וה-devops באופרציה כדי שהם יוכלו לפתח מוצרים ל-end user בצורה שהיא יותר איכותית ומהירה. אז זה כל הסיפור.
ישי: ואם אני מנסה לפרק טיפה מה זה אומר להיות product, כי יש לנו אזורים אחרים, יש לנו, לא יודע, UI guild, שלאו דווקא מתייחס למה שהוא עושה כ-product. מה זה אומר להתייחס ל-platform כ-product? זה אומר לשים product manager בקבוצה?
יפעת: אז אני חושבת שבאמת יש איזה צורך בארגונים שהם יותר גדולים. וה-product בעצם, product גם אם המשתמשים הם פנימיים, זה אותו תהליכי עבודה כמו product שעובד עם end user paying customers. זאת אומרת צריך להבין מה הבעיות, מה האתגרים של כל אחד מהקבוצות שעובדות בתוך הארגון, איפה היום הם מבזבזים את רוב הזמן שלהם, איפה אפשר להכניס הרבה יותר אוטומציה, איפה אפשר לשפר את התהליכים, וזה גם, זה ראיונות, לשאול אותם, להבין, להביא פתרונות, לעשות איתם POC, design partners. זאת אומרת מבחינת מתודולוגיית עבודה של product manager, אני לא חושבת שיש הבדל בין אם הלקוחות הם פנימיים או אם הלקוחות הם חיצוניים.
ישי:אז זה כמעט אומר שצריך product manager בקבוצה, כי אנשים של platform באופן טיפוסי אין להם את ה-skills או את הניסיון הזה של איך אני מגייס design partners איך אני עובד איתם ומשייף את ה-requirements.
יפעת: נכון, הם בד"כ אנשים שהם יותר טכניים, יותר מסתכלים, למרות שהם בד"כ גם ב-infrastructure הם אנשים שהם מאוד שירותיים. כי הם צריכים לעבוד עם הרבה מאוד קבוצות בתוך הארגון ובהכרח הם צריכים להיות אנשים שהם, שיש להם איזושהי ראייה רוחבית. אבל זה נכון, זה skill set אחר, זה skill set שלא תמיד, שלפעמים צריך להביא אותו מבחוץ כדי באמת למקד את הארגון איפה צריך להשקיע, איפה צריך להשקיע את המאמצים בשביל באמת לספק תשתיות טובות יותר לקבוצות הפנימיות בתוך הארגון.
ישי:ואיפה לדעתכן בכל זאת יש הבדל? איפה הקבוצות platform בתוך ארגונים מתרחקות או צריכות להיות קצת שונות מעבודה רגילה על product שהוא outbound?
לינדה:אני מאוד מזדהה עם מה שהיא אמרה על חברות גדולות כי אני חושבת במיוחד צריך להבין את ה-product ש-, איך אתה כאילו נכנס בתוך התמונה של ה-product הפנימי. אני אתן דוגמה. אז אני עבדתי בחדשות והחלק של ה-devops ו-platform שאני עבדתי עליו יותר הוא ה-CMS של אנשים שכותבים בכל שעה ביום כתבות של breaking news. ודברים שגם אנחנו צריכים כדי להראות תוצאות של elections, אוקיי? דברים כאלה. ולהבין את ה-inner workings, איך הקבוצה עובדת. זה product אבל זה באמת your customer is מאוד שונה, כי הוא באמת האנשים הם פנימיים אז יש פה עניין גם של ממש להבין את הדינמיקה הפנימית של החברה, שזה, אני לא יודעת אם זה קצת סוג אחר של audience, you know? your audience is technical (צוחקת)
יפעת: כן, לגמרי ה- manager product חייב להבין את ה-, מה הלקוחות עושים, זאת אומרת חייב לבוא מהעולמות של התשתיות ולהבין באמת את ה-day to day. ולכן אין ספק ש-product manager בכלל באופן כללי נורא חשוב שהוא יבין כאילו מה הלקוחות עושים כדי שהוא יכיר את המוצר אבל בטח ובטח שמדובר על מוצר שהוא בעצם תשתיות, אז צריך להבין את המטריה.
(מוסיקת מעבר)
ישי: אז דיברנו על ה-product skills ועל ה-product ceremonies או cycles שצריך לעשות, גם בארגון פנימי,
יפעת: כן.
ישי: אם אני מסתכל על הצד של ה-product marketing, ו evangelism איך זה קורה, שוב, בארגון platform, נניח בתוך ארגון engineering גדול?
לינדה: מה שמאוד מעניין זה שהרבה מה-tools גם שאנשים, ש-developers use, זה הרבה from the individual, לפעמים זה לא ה-CTO שמחליט על ה-tools, זה הרבה individual ופה יש,
ישי: אני עובד עם VI, ברור.
לינדה: כן (צוחקת) כן, אבל שם ה-advocacy, יש advocacy אחר שכאילו what tools do you wanna use that you're the, אתה כאילו משתמש כ-developer בצד השני. נגיד אני עבדתי כ-web developer והייתי מתעסקת יותר עם כאילו, הכול היה נראה כמו magic, שלא הייתי ב-devops, וכאילו ה-servers, מיליוני אנשים באים לראות את התוצאות של elections והכל כאילו עובד, כן? והחלק הזה נורא עניין אותי וה-tools שאני גם צריכה לעשות את העבודה שלי אפילו כ-, אם אני עובדת בהנדסה או מחשבים בצד השני, שאני עושה רק את החלק של ה-javascript והיותר ה-logic של ה-UI, זה אחר מאשר לעבוד ב-to support the underpinning, גם לא תמיד מקבלים את הקרדיט (צוחקת). של ההצלחה, ויש שם advocacy מסוים, רק הם באמת צריכים להבין גם את ה-tools וגם כאילו את ה-ease של לעבוד בסטרס, במיוחד במקום כמו חדשות, ואני רואה בזה סוג של advocacy מסוים to get buy in וכדי לעשות את ה-, יש פה relationship מאוד חזק של customer מסוים שהוא אולי ה-developer אז יש פה סוג של advocacy כמו product developer.
ישי: כן. יצא לי לראות לא מעט צוותי devops ו-platform שעובדים על דברים מגניבים ואף אחד לא משתמש.
יפעת: זה נכון, בדיוק אני רציתי להגיד שזה נורא חשוב ה-PR או ה-marketing למה שעושים בתוך הקבוצות devops. כי באמת לא כולם מכירים את זה. אבל אני חושבת שזה נורא דומה גם, אנחנו הולכים לפתח פונקציונליות במוצרים והלקוחות לא באמת יכירו שזה קיים, בין אם זה paying customer . ואני באמת חושבת שהשילוב הזה של לפתח וגם לדעת איך לעשות טוב את ה-marketing ואת ה-PR הוא מאוד קריטי כדי שיהיה adoption, כי בסופו של דבר אנחנו יכולים לפתח אבל באמת לא ישתמשו בזה וה-adoption יהיה מאוד נמוך אז למה אנחנו משקיעים פה את המאמץ?
לינדה: היו פעמים שבאמת היה אינטגרציות של כל מיני tools ובסוף הקבוצות לא השתמשו בזה, זה ממש buy in factor.
ישי: אז אני מאוד אוהב סיפורים, יש לך סיפור ספציפי על נגיד עבודת platform שהצליחה במיוחד או לא הצליחה בגלל עניינים פרודקטיים?
יפעת: כן. אז אני יכולה להגיד לך בכובע הקודם, כשניהלתי אחד מהצוותי פיתוח, אז באמת פיתחנו, זה היה גם, פיתחנו מוצרים למפתחים בתוך הארגון. ופיתחנו אז יכולות שלא עשינו מספיק מחקר או לא, יותר נכון לא עשינו מספיק שיתופי פעולה עם צוותים פיתחנו יכולות והמפתחים לא ידעו שהן קיימות. אז הם היו פונים אלינו, היינו גם צוות פיתוח, אומרים לנו אנחנו צריכים יכולות כאלה ואמרנו אבל רגע, כבר פיתחנו אותן. ובסופו של דבר הבנו שלא עשינו באמת מספיק PR למה שפיתחנו, וזה משהו שככה לקחתי את זה הלאה. אז כן, זה קיים, זאת אומרת צריך להתייחס לזה ולדעת איך, כמובן במינון, כן? אבל איך לספר את מה שאנחנו מפתחים.
ישי: יצא לך לראות או לעבוד בסיטואציה שצוותי platform מודדים את עצמם על adoption? מודדים את עצמם על הדברים האלה?
יפעת: אני חושבת שזה השאיפה של כולם. השאיפה של כולם זה באמת להראות adoption של מה שאנחנו מפתחים בתוך באמת משתמשים בו. אני חושבת שזה קשה, ובאמת זה הכיוון ללכת לשם, זה לא קל וצריך באמת גם פוקוס על זה. אם עולמות DORA Metrics או עוד כלים ומוצרים, אז זה לגמרי הכיוון, צריך אבל להשקיע שם את המאמצים.
ישי: ודיברת על זה שאת רואה את זה קורה יותר ויותר או מתפתח בארגונים גדולים. מה קורה בארגונים קטנים?
יפעת: זה נורא תלוי כי אם זה ארגונים של אני לא יודעת מה, 10 מפתחים, 15 מפתחים, אתה יודע, הם עדיין בסקייל שהם יכולים, שזה מתחיל להיות מאתגר אבל אני לא בטוחה שצריך שם למשל פונקציה שהיא dedicated product manager. אפשר אולי באמת שזה יהיה יותר משהו שראשי צוותים אולי יעשו. ה complexity עולה ועולה ככל שיש הרבה יותר מפתחים שגם נמצאים בלוקיישנים שונים ובארץ, בארה"ב או באירופה וזה פשוט מוסיף את ה complexity ושם האתגרים.
ישי: חוזר לשאלות של שיווק ו-awareness, וגם איך אני מדבר עם ה-user base שלי.
יפעת: נכון, כי הם לא נמצאים לידך תמיד וגם באמת המורכבות ככל שהיא עולה אז צריך באמת לבוא ולתת סטנדרטים אחידים לצוותי פיתוח.
״המורכבות ככל שהיא עולה אז צריך באמת לבוא ולתת סטנדרטים אחידים לצוותי פיתוח.״
ישי: אז לינדה, בעולם הזה של developer advocacy, ואני רוצה להתחיל ב internal ואח"כ לעבור לחשוב קצת על ה external. מה מיוחד ב-developers שצריך לדבר איתם בצורה כזאת שונה ולא יודע, אי אפשר למכור להם כמו שמוכרים אבקת כביסה או,
לינדה: כן, זה עניין של trust. בנאדם שיכול לדבר על הבעיות שהוא עבר גם כי הוא גם היה developer, זה אחרת שהוא מדבר עם developer, לעומת מישהו שבא ומוכר לך משהו והוא לא עבר את הסוג של בעיות או accomplishments גם של כל העניין של לבנות משהו טכנולוגי. זה עניין של trust, זה עניין של להבין את ה-audience שלך ולעזור להם גם. היופי שהמילה developer advocate פעם היו קוראים לזה enthusiast, אחרי זה advocate,
"זה עניין של trust, זה עניין של להבין את ה-audience שלך ולעזור להם" גם."
ישי: evangelist, יש הרבה מונחים.
לינדה: כן, כל מיני, לא יודעת אם עוד מצאנו את המילה הנכונה אבל מה שאני כן אוהבת ממה שהיה עד עכשיו, אני כן אוהבת את ה-developer advocate יותר כי you really advocating on behalf of developers, זה כמו checks and balances, איך אומרים בעברית?
ישי: איזונים ובלמים.
לינדה: כן, בדיוק. כי אתה לא יושב,
ישי: בפודקאסט זה עוד קיים המילה הזאת.
לינדה: (צוחקת) כן, זהו, אם יש מילה שזה, נעשה כזה,
ישי: ביפ.
לינדה: בדיוק, בדיוק, נכניס את זה, אני אשלח לך voice over (צוחקת). אבל מה שהיופי זה שיש אנשים ש-, שכחתי מה שרציתי להגיד,
ישי: דיברת על למה את אוהבת את ה-term developer advocacy.
לינדה: אז אתה לא יושב בתוך product, נכון? אני עובדת ב-AWS, יש לנו מעל 200 services, אני עובדת כ-generalist. אז העבודה שלי היא to advocate on behalf of developers, אני לא, כאילו אני רוצה את ההצלחה של services, אני רצה גם שזה יהיה experience טוב ל-developers. לי חשוב ה-experience של ה-developers וזה סוג של checks and balances שאני בפנים נותנת פידבק. אני בוחנת דברים שעוד לא יצאו, אני מסתכלת על דברים מנקודת עין שאנחנו יכולים גם לראות מה יכול לקרות כי אני בקשר הרבה עם ה-community, ב-social media, ב-meetups, בכל מיני mediums.
ישי: אבל תנסי לעזור לי להבין למה developers הם כל כך mistrusting,
יפעת: הם אנשים קשים (צוחקת)
ישי: כאילו למה הם צריכים את ה-middleman הזה או למה צריך לדבר אליהם בצורה כל כך שונה מאשר לכל הקהלים האחרים?
לינדה: אני אגיד לך שגם היופי בטכנולוגיה, יש לך כל כך הרבה אופציות וכל כל הרבה pathways. והעולם של ה-developers זה פחות, גם הצורה שהם מגיעים להיות developer, זה לא one path, והכמות של אופציות שיש לך עם השנים זה מאוד over whelming וכל אחד, והם אנשים מאוד opinionated בצורה טובה גם, כאילו זה היופי, הם בונים דברים, אנשים ש-by nature הם innovated ולפעמים גם cut the rules. וזה דבר טוב, אבל עם זה בא החלק של איך אתה נותן לזה סוג של דמוקרטיה לבחור tools, ה-developers בד"כ אוהבים לבחור ואם הם משתמשים בדברים שהם לא אוהבים, אנחנו רואים בחברות שמשנים את ה-tools, based on the developers, not the CTOs, נכון? ויש סיבה לזה, כי יש לך הרבה אנשים ב-upper management שלא תמיד מבינים את הדבר הזה. במיוחד באנטרפרייז, נגיד אתה הולך כאילו יותר גדול אתה מרגיש את זה יותר ויש סוג של אי הבנה של הידע לפעמים בין קבוצות, נכון? a lot of miscommunications ו-,
ישי: שזה אזור שה-developers הם לא תמיד הכי טובים.
לינדה: yea, your tools, ו-developers הם יודעים לבנות ולא תמיד to communicate. אז יש חלק שצריכים גם לעזור ל-developers להבין מה האופציות כי זה באמת overwhelming. ואין זמן ללמוד על כל דבר הכול וחברות כמו AWS צריכות כאילו to un-fragment.
יפעת: כן, אני יכולה גם להוסיף ש-developer זה כמו כל לקוח, הוא לא תמיד יודע מה הוא רוצה או מה הוא צריך.
ישי: די, באמת? (צוחקים)
יפעת: כן. יש לו איזה הבנה של מה הבעיה שיש לו אבל הוא לא תמיד יודע את הפתרון. ובאמת ברגע שעושים PR, dev relationship, ומספרים להם שזה קיים אז זה גם פותח בפניהם את האופציות שפשוט מקודם לא הכירו אותם. וכן, developers יכולים להיות באמת כמו שאמרת opinionated, שזה בסדר גמור. והם כן אני חושבת איזשהו סוג שונה של לקוחות מאשר למכור להם איזשהו מוצר כי פה באמת, אם אתה תבוא ותנסה לשווק להם איזשהו service ש-AWS עשתה ובאמת אין לך את ההיסטוריה הטכנית, הם פחות,
ישי: הם לא יאמינו לך.
יפעת: הם לא יאמינו לזה. הם לא יבינו, הם יחשבו אוקיי, אבל הוא או היא לא באמת התנסה בזה אז איך הם יודעים שבאמת זה יפתור לי את הבעיה? אז כן, צריך, ובניגוד לעומת לא יודעת מה, אם אתה הולך ומוכר מכונית אתה לא צריך לדעת איך לתפעל את המכונית. מספיק שאתה מוכר את המכונית כמו שהיא, את המוצא המוגמר, וזה כן שונה, זה שונה.
לינדה: וגם, the innovation שקורה, אתה גם רוצה לדעת מה הבעיות שה-developers עוברים, אפילו אם אין את ה-solution. כי מקומות כמו AWS הם עוד, they iterate based on the feedback ולפעמים אתה רק מסתכל על פידבק בביזנס ו C-Suite, אתה לא מקבל את הפידבק האחר, שהוא מהעם.
ישי: אז את צריכה להיות במקום שהוא, יש לך מספיק trust שהם יוכלו לדבר איתך ולהגיד זה לא עובד לי, פה חסר לי איזושהי גמישות ב-API.
לינדה: בעיקרון נגיד אנחנו יותר in tune עם ה-community ואנחנו באים ואחרי כותבים אולי 6 page paper באמאזון על דברים שאנחנו שומעים to advocate on behalf of developers ו-to build it into our product ובוא זמנית גם מביאים awareness על מה available ואופציות של to solve different problems.
(מוסיקת מעבר)
ישי: אז שתיכן עשיתן שינוי מעבודה של לכתוב או לפתח מערכות ו-platforms ו-devops בתוך ארגונים, למשהו שהוא פונה החוצה, כלומר אצלך, לינדה, שאת פונה ליוזרים של AWS, או אצלך יפעת שאת בעצם עושה פרודקט פנימי אבל ממש בתפקיד רשמי של product manager ולא builder.
יפעת: נכון.
ישי: תספרו לי קצת על השיפט הזה, על המעבר הזה.
יפעת: לי הוא מאוד טבעי, כי באמת ברקע שלי עברתי גם תפקידים שהם רוחביים וגם תפקידי ניהול. שב-7 שנים האחרונות יותר התעסקתי יותר ב-hands on ואני חושבת שעדיין תמיד היה לי את הפרספקטיבה של מי זה הלקוח שלי ומה אני צריכה לדלוור לו. ועם הזמן אז בעצם גם רכשתי כלים שהם יותר טכניים, אבל תמיד היה באמת את הפרספקטיבה של הרוחבי, של הלקוחות. אז לי, בתחושה שלי המעבר ל-product manager הוא מאוד טבעי, בטח product manager שהוא מתעסק בטכנולוגיה ובעולמות ה-devops אז זה,
ישי: את נכנסת לארגון שכבר היה בו פרודקט ל internal פלטפורם?
יפעת: לא, זה התפקיד הראשון.
ישי: אז זה חידוש. אז איך נכנסים לארגון שלא היה רגיל שיש ממש product manager בתפקיד כזה? ומכניסים איזשהו skill set וגישה אחרת?
יפעת: אז צריך לבנות את זה. קודם כל צריך להבין איפה המקומות שחשוב שאני אתרכז בהם, איפה היום הארגון צריך יותר את העזרה. וגם להסתכל קדימה, אוקיי, אז עכשיו אנחנו בעצם נטפל בבעיה הזו, בוא נסתכל איזה עוד בעיות צריך לטפל בהן בהמשך הדרך. וזה לא פעם ראשונה שאני יוצא לי לבנות תפקיד, זאת אומרת גם מקומות עבודה הקודמים אז הקמתי צוות, גייסתי אנשים, הקמתי בעצם צוות from scratch. אז החוויה הזאתי של לבוא ולייצר משהו מאין, אז היא לא חדשה לי. זה מאתגר, זה הכיף אבל, הכיף הוא לבוא ולמצוא את מה שחדש ולבוא עם ניסיון וגם תוך כדי גם ללמוד הרבה מאוד.
ישי: וארגונית את שייכת לארגון product? ל-engineering? איך זה בנוי?
יפעת: ספציפית לא, אני שייכת לארגון ה-engineering.
ישי: אז זה לא בחלוקה הרגילה.
יפעת: נכון.
ישי: ואיך זה תופס? זה עוזר לך שאת בתוך engineering? זה מוזר כי את לא חלק מ-product?
יפעת: אתה יודע, זה תמיד, תמיד הייתי בעולם ה-engineering אז זה נורא טבעי לי להישאר שם. וכן יש שיתופי פעולה עם פרודקטים מתוך הגילדות בוא נאמר של הפרודקט. ואני חושבת שכל product manager הוא בעצם בונה לעצמו את צורת ה-, את היחסים עם הפרודקט של הקבוצות האחרות ועם הקבוצות הנוספות כמובן. אז הקונסטלציה הזאתי להיות פרודקט כחלק מקבוצת engineering ועדיין לעבוד עם product manager אחרים, בתחושה שלי זה מאוד הגיוני ונכון.
ישי: אבל הם חיים את הלקוח, הם חושבים על איך אנחנו בונים את הפיצ'רים ללקוחות של JFrog ואת מתמודדת עם לקוחות לגמרי שונים, עם internal engineering groups.
יפעת: כן, אבל התשתיות שאנחנו מספקים גם הרבה פעמים הם תשתיות שבחברה של JFrog זה משהו מאוד טכני ומאוד, העולמות שלו זה עולמות ה-devops, אז האינטראקציה היא עם הקבוצות השונות הוא חלק מזה באמת היכולות שאנחנו מספקים כי זה תורם מאוד למוצרים. אז יש פה איזשהו שילוב,
ישי: יש דברים שאת כאילו מנהלת כ-product manager שמגיעים בסוף למוצר עצמו.
יפעת: כן.
ישי: אוקיי, אז יש פה איזשהו גם הסתכלות על הלקוחות בחוץ.
יפעת: נכון, יש פה גם את הצד הזה.
ישי: הבנתי. ולינדה, תספרי לי קצת על המעבר שלך ל-outbound
לינדה: לי זה גם היה מאוד טבעי, האמת כשעבדתי, עשיתי מעברים של כמה, עברתי ל-devops באותה חברה, גם במדיה. תמיד הבנתי את ה-product והייתי מאוד בתוך ה-AWS Community. היופי בטכנולוגיה, יש הרבה communities ומאוד, בגלל ש-innovation by nature זה משהו שאתה בונה על רעיונות של גם אחד לשני, יש עולם של open source, יש עולם של share information והקטע הזה בטכנולוגיה אני חושבת מאוד מיוחד. ובקטע של advocacy זה היה מאוד טבעי לי כי אני הייתי תמיד מאוד בתוך community. אז ספציפית AWS הייתי עושה קורסים של סרטיפיקציות בתוך החברה שעבדתי בשבילם לפני שעבדתי בשביל AWS, פשוט הייתי עושה lunch and learns, הייתי מריצה כל מיני דברים בתוך החברה, Internal, ל-developers שעבדו בחברה שעבדתי בה במדיה והעבודה שלי הייתה לגמרי טכנית ומאחורי הקלעים. ההבדל היום הוא שאני בונה ל-education ולא ל-prod. היום אני בונה יותר ל-education ואז בניתי ל-prod.
ישי: את בנית דברים לפרודקשן וחוץ מזה עשית קורסים פנימיים.
לינדה: ועשיתי קורסים פנימיים בצד, וגם,
ישי: כי מה? כי זה עניין אותך?
לינדה: זה עניין אותי, הייתי גם עושה הרבה וידאו ב-social media. הצורה שבכלל נכנסתי ל-advocacy זה מצאו אותי ב-social media, אבל מה שמצחיק זה שתמיד ידעתי שאני, שעשיתי את המעבר לטכנולוגיה תמיד ידעתי שבסוף אני כן אהיה באיזה סוג של קומבינציה. לא ידעתי אם זה יהיה, משהו עם אנשים, כאילו לא ידעתי אם זה יהיה sales, לא ידעתי אם זה יהיה advocacy, אבל ידעתי שאני רוצה להיות מאחורי הקלעים רק כאילו לבנות להרבה שנים ואז כאילו ברגע שאני מרגישה שאני יותר שוחה בדברים ועברתי כמה roles. אני יכולה גם לתת יותר. אבל כל הזמן הזה אני הייתי עושה הרבה social media, בטיקטוק ואינסטגרם about tech והייתי גם בתוך פרוגרם שקוראים לו AWS Community Builder program. אז אפשר to apply to it וזה מדהים, פוגשים אנשים מכל העולם שגם, מכל מיני חברות ובונים ביחד וגם זה אנשים שאוהבים ללמד וללמוד ביחד. ובשבילי זה היה נורא טבעי כאילו לעבור לתוך ה-role הזה, בשבילי זה די היה חלום כי אני הרגשתי שאני גם יכולה להיות טכנית. גם אני יכולה להיות עם אנשים ולהקשיב לאנשים ולעזור לאנשים, ואני בתחום שאני מאוד אוהבת שזה cloud, אבל זה מצחיק איך שלפעמים כאילו בטכנולוגיה אתה יכול להתחיל באיזשהו מקום ואתה יכול לעבור לכל כך הרבה roles, ואני אומרת שהחיים הם different phases in life, אני לא הייתי רוצה את העבודה הזאת לפני כמה שנים. אני חושבת שזה היה חשוב לי להיות כאילו ממש פוקוס, הייתי עושה את זה בצד אבל זה היה חשוב לי לבנות את ה-experience שלי במובן מסוים כי עבודה כזאת ה-challenge הוא, you don't get to build what you not used to build ואתה צריך כאילו to build over your experience.
יפעת: לגמרי, צריך לבוא עם הניסיון בשביל באמת להיות מסוגלת לעשות תפקיד כזה בצורה שהיא משמעותית. וחייבים את הניסיון הטכנולוגי, צריך את הניסיון של עבודה עם צוותים שונים, אני חושבת שגם בתפקידים שאני עשיתי בעבר אז גם לא היה לי תמיד פרודקט שעבדתי איתו או עבדתי איתה,
ישי: אז הייתי צריכה לעשות את זה בעצמך.
יפעת: אז הרבה פעמים עשיתי גם את התפקיד של הפרודקט פשוט בלי הטייטל של הפרודקט, והיום זה פשוט עם הטייטל של הפרודקט וזה ההבדל.
ישי: תגידי, ואיך את מסתדרת עם זה שמישהו אחר צריך לכתוב את הקוד?
יפעת: לא, זה בסדר גמור.
ישי: לא מדגדג לך ל-, אני אעשה את זה יותר טוב, אני יכולה ל-,
יפעת: לא, כרגע זה לא. גם עברתי מתפקידי ניהול לתפקיד עכשיו שהוא רוחבי שוב וכרגע זה לא מפריע לי. זאת אומרת אני לגמרי שלמה עם זה מלעבור לתפקיד שהוא ניהולי לתפקיד שהוא רוחבי. כי שוב, כי זה מרגיש לי טבעי, שזה מרגיש לך שזה טבעי, אז אין לך איזושהי תחושה של החמצה או תחושה של, אלא להרגיש את זה במקום הנכון.
(מוסיקת מעבר)
ישי: אני רוצה לדבר איתכן על הקשר ומערכת היחסים בין, שוב, תחת העולם הזה של פלטפורם, בין הפרודקט לבין המרקטינג וה-PR. דיברנו על החשיבות של כל אחד מהחלקים האלה, קצת על השיתוף פעולה ביניהם. איפה זה מצליח, איפה זה קשה.
יפעת: אז אני חושבת שבאמת חשוב לעשות את עבודת ה-PR הזו. זה צריך להיות אם זה בסקרים שמשחררים למפתחים ול-internal customer בשביל להבין מה הכאבים או מה האתגרים שבהם הם עובדים איתם ביום יום. וגם באמת בהיבט של ה-PR איך אני מפרסמת את מה שפיתחנו, אז אם זה ב-newsletter או בלוגים או כל מיני פוסטים.
ישי: או שהבילד פשוט לא עובד יותר וכותב או צריך לעשות משהו אחר (צוחקים)
יפעת: לא, אבל נגיד עכשיו פיתחנו נגיד, אתה מפתח יכולת תשתית חדשה, אוקיי? אתה רוצה לבוא ולפבלש אותה, שהמפתחים יכירו את זה, שהצוותי פיתוח יכירו, אז איך עושים את זה, אז אם זה בכל מיני פוסטים או כל מיני הודעות בסלאק או, אני לא יודעת אם היום כבר עושים newsletter, זה נראה לי קצת old fashioned כזה,
ישי: זה internal, כן. נגיד יש לך היום ב-JFrog שותף שיודע, שעוזר לך בצד הזה של ה-product marketing לעבודה שלך? או שזה עלייך? את צריכה עכשיו לספר לאלף איש שיש משהו חדש בפלטפורם?
יפעת: אני חושבת שזה יותר בעולם של הפרודקט. יכול להיות שבהמשך זה ישתנה, כן? אבל כרגע זה יותר כאילו בדומיין של הפרודקט. בהיבט של הפרודקט של ה-internal users, כן? אני בטוחה שזה גם אולי קצת שונה בפרודקט שבאמת יש להם outbound customers.
ישי: זאת אומרת פה יש איזה הבדל, נגיד במוצר החוצה יש enablement ויש training לשטח ו-product marketing ו-,
יפעת: כן, ודאי, יש לך, למרות שגם בתוך ה-internal הזה גם יש training ובאמת, כי גם חשוב לעשות training ללקוחות, אז גם בהיבט הזה יש, אין הרבה שוני משמעותי,
ישי: רק זה נופל על אותם אנשים במקום להתפצל ל-skills.
יפעת: זה גם יכול להיות אחריות של הראשי צוותים, של המנהלים, זה לאו דווקא שיש רק פונקציה אחת שדואגת לזה, לא, זה גם למנהלים יש הרבה מאוד ידע וניסיון והם לוקחים בזה חלק.
ישי: ולינדה, איפה את רואה את השיתוף, איך נראה שיתוף פעולה עם ה-product side?
לינדה: אני רואה את פרודקט ומרקטינג כמשהו שהולך hand in hand, יד ביד, buy in זה דבר מאוד חשוב, internally, אפילו שעבדתי בחדשות היו לנו אנשים שעבדו בפרודקט והיו לנו אנשים, כי זו הייתה חברה גדולה, שרק הלכו ו-trained enablement to get that marketing angle. והעבודה שלהם זה היה, עבדנו בפרודקט של CMS to enable חדשות, אז היה כאילו, היו לנו אנשים שהכול היה מאוד לחוץ, זה עולם מאוד לחוץ, אז אם משהו לא עובד, צריך שמישהו יגיע מלמטה כדי לעזור להם. אנחנו בונים להם tools שהם צריכים לעשות את העבודה שלהם. עכשיו ה-customers גם לפעמים הם אנשים שלא טכניים, הם editors, הם אנשים ש-authoring in journalists, אז זה סוג אחר, כאילו היה לנו קבוצה שבאמת רק ישבה על, לא רק, הם לא היו פרודקט, אלה שקבעו את הפרודקט עצמו, הם באמת היו אלה שהנהיגו, הם קראו לזה community managers. אבל הכול internal, ובזה, אני לא יודעת, תקראו לזה, לא משנה מה קוראים לזה כאילו בשבילי זה באמת כאילו החלק של ה-buying הוא כן סוג של מרקטינג that's ingrained in product.
ישי: ואז אנשי הפרודקט והאנשים של ה-enablement עבדו ביחד בשביל להוריד את הגוספל בסופו של דבר לשטח?
לינדה: כן, ו-to build that system out, וזה מאוד מעניין כי אני מסתכלת על זה בזווית העין נכון של אנטרפרייז, זה בטח אחר בקבוצה קטנה. אבל אפילו אני רואה את זה עכשיו בחברה כמו אמאזון, אתה יכול לבנות פרודקט, החלק שאתה רק to get the buy in של organic marketing vs. traditional marketing, זה גם חלק גדול, יש את ה-unsaid marketing. כשיש לך internal advocates and natural advocates שאתה לא משלם להם לעשות את זה, שהם עושים את זה, אתה רוצה כאילו, זה סוג של, זה מרקטינג שבסוג אחר.
ישי: Community.
לינדה: community, right, you can call it community, אבל it does go hand in hand.
ישי: אבל איך נראה הקשר הזה היום בין אנשי הפרודקט, אוקיי, בנינו מוצר, Kafka חדש, איזשהו service, לבין עכשיו יש ה-PR של זה ומצד השני גם, לא יודע, advocacy שמביא לי פידבק מהשטח, איך זה קורה ביום יום? יש סינקים קבועים? יש פידבק אורגני שאת מציפה ומקווה שמישהו יקשיב?
לינדה: כן. אז יש הבדל בין נגיד חברה כמו אמאזון היא ענקית אז יש לך פרודקט מרקטינג כאילו רק לזה. יש לך פרודקט שרק בונה את ה-service ויש לך advocacy שזה בכלל נפרד, שעובד עם מרקטינג ועם אינג'נירינג ועם קומיוניטי והוא עובד עם כל מיני קבוצות. לפעמים advocacy יושב במרקטינג, לפעמים advocacy יושב בפרודקט, לפעמים advocacy יושב ב engineering, כי זה מאוד, זה כאילו סוג של קומבינציה שחברות כל פעם, יש לנו גם advocate בתוך אמאזון שבכל מיני קבוצות, והעבודה שלהם אותו דבר אבל זה מעניין, זה כאילו לא בדיוק יושב על אחד מהם אז תמיד אתה,
ישי: אז יש להם reference points אחרים לעבוד איתם.
לינדה: כן, רפרנס פויינטס אחרים והם תמיד צריכים, יש סוג שצריך הסברה וצריך שהאנשים שאפילו head marketing או head product יבינו מה זה advocacy, שזה די שונה מה-traditional marketing או traditional .product כי העבודה שלי היא נגיד לא בשביל לקחת פרודקט ולהגיד אני נתתי לכם 500 אנשים שבאו מהפרודקט. העבודה שלי היא באמת קשה to measure כי אני צריכה, אני לא צריכה להיות תלויה בפרודקט, אני רוצה שהפרודקט יהיה טוב, אני רוצה להיות תלויה ב-success של ה-customer. להבין את מה שהוא צריך ולפתור את הבעיה שלו ולהעביר מסר גם חזרה לעזור לפרודקט להיות יותר טוב. אז זה כזה hand in hand. Feedback loop.
ישי: אז את צינור דו כיווני.
לינדה: yea.
ישי: יפעת, מעניין אותי בארגונים קצת יותר גדולים, ממה שראית, הדינמיקה של פידבק רשמי, או שאת אוספת פידבק על לא יודע. עשינו שינוי פלטפורם, הוצאנו משהו חדש, יש ערוצים רשמיים של פידבק, של ראשי צוותים ושואלים את ה-developers ומקבלים תשובות, ויש את השיחות מסדרון והקיטורים ליד הקולר (צוחקים). תספרי לי קצת על איפה ראית הבדלים או איך מגיעים לפידבק הלא רשמי שלפעמים יותר אמין.
יפעת: אז אני חושבת שזה קשור גם ל-trust. זאת אומרת מה שמקודם לינדה אמרה, אני חושבת שאם המשתמשים הם רואים במנהלים או בפרודקט באמת איזושהי פונקציה שאפשר לבוא ולהגיד אוקיי, זה הפידבק שתכלס על מה שדילוורתם. אני חושבת שזה מספיק טוב או לא מספיק טוב, אז זה דבר אחד, שהם ירגישו בנוח לבוא ולהגיד גם אם הדברים לא מספיק עובדים טוב. ודבר שני זה באמת שהרבה רעיונות טובים צצים מהשיחות מסדרון האלה. באמת פתאום אה, אוקיי, רגע, לא חשבנו על זה, אולי באמת שווה להכניס את הפונקציונליות הזו, אולי צריך לשנות את הפונקציונליות ממה שחשבנו בהתחלה? אפילו אם כבר מימשנו את זה. ואני חושבת שלזה יש מקום משמעותי וגם לזה יש מקום חשוב. פשוט שזה שיחות מסדרון אז אתה יודע, האנשים שאיתם אתה מדבר זה ה-, זה מדגמי, זה הרבה יותר קטן, ולעומת זאת כשאתה שולח סקר אז יש לך יכולת להגיע ליותר אנשים. אבל הפידבק הוא חשוב לשני הכיוונים.
ישי: ובארגון גדול איך מגיעים לחלק הלא פורמלי הזה? בסוף יש מעט אנשים בפלטפורם ועוד פחות מהם שיודעים לעשות, לא יודע, להקשיב לפידבק, שהם פרודקט ב-state of mind שלהם, שהם יכולים להסתובב רק בשני מסדרונות ולא בכל החברה.
יפעת: נכון, אז אני חושבת שברגע שעושים גם כל מיני סשן של טריינינג, כמו שלינדה הזכירה, עושים גם טרייניג פנימי, ואז בעצם יש לך עדיין מקבץ גדול יותר של אנשים.
ישי: הפסקת קפה ואפשר לשמוע באמת מה קורה.
יפעת: כן, וגם במהלך הסשנים הם יכולים להעלות פידבקים או שאלות, תוך כדי השאלות אתה יכול להבין כאילו האם הם, מה הבעיות שאולי עוד לא פתרנו, אז אני חושבת שיש כל מיני ערוצים שבהם אפשר לקבל פידבקים פורמליים ולא פורמליים.
לינדה: וגם הלא פורמלי ב-outbound עכשיו יש את social media וזה חלק גדול שהיום יש לך הרבה cooler conversations שם. שזה קצת שונה off course שאת מתעסקת עם אינטרנל, כי זה you can't really get it from social media. בעולם שלי אני יכולה הרבה גם לראות ב-social media מה קורה, מבחינת, באינסטגרם, בטיקטוק, I meet people where they are, אני פוגשת אותם. איפה שהם, אז זה מאוד מעניין כי אם אני מתחילה שיחה על משהו או עושה וידאו על משהו, אנ גם רואה חזרה גם את הדברים הטובים וגם את הדברים הלא טובים ויכולה לפעמים גם לדבר איתם ולראות איפה הזה או מה הם מחפשים לראות עוד או מה הטרנדינג שקורה עכשיו. off course subjective, יש לנו הרבה different communities and sub-communities.
ישי: את שומעת את מי שאוהב לדבר.
לינדה: כן, זהו, אז חשוב גם להסתכל על מקומות שהם לא מדברים אליי אבל מדברים about things.
ישי: יש לך קצת פילרז בחוץ לסנטימנט ולמצוא, וואלה, פה יש thread מעניין שמדברים על נושא שאני מתעניינת בו אז,
לינדה: אז יש, לי ספציפית אין. יש כאילו כל מיני גם פרודקטים שהם שומרים על סנטימנט מסוים גם, כי מאוד חשוב פידבק לכל ה-, כאילו customer obsession זה דבר מאוד מאוד מושרש באמאזון נגיד אז יש תמיד את הסנטימנט אנאליסיז הזה שמושרש. לי ספציפית אני מתעסקת הרבה בווידאו, זה היה מעניין כי בד"כ advocacy בעבר, במיוחד לפני קורונה, הרבה advocates, they got hired לעשות יותר public speaking, I got hired for video, והסיבה היא לא בשביל רק להוציא אינפורמציה. הסיבה היא לתקשר עם אנשים בעולם הווידאו כי אנשים שהם אולי פותחים אינסטגרם הם לא יבואו כל יום לאיזה משהו ששייך למשהו טכנולוגי, הם רוצים לשתות את הקפה שלהם ולראות משהוץ אה, פתאום צץ להם משהו שהם בכלל לא חיפשו, הם למדו על איזה workshop על generativeAI אבל זה לא פוגע בדבר שהם רוצים, הם רוצים משהו שיעזור להם לבנות משהו ספציפי, האם יש משהו כזה.
(מוסיקת מעבר)
ישי: לסיום אני רוצה לשמוע אולי מכל אחת מכן סיפור על מקרה אחד, משהו אחד שהפתיע אתכן, פידבק שקיבלתם על עבודה שקשורה באמת לפלטפורם שהיה הפתעה, שהיה כאילו, שינה איזה, כאילו לא ציפינו לקבל כזה דבר וזה שינה קצת איך שחשבנו על בעיה או על פתרון שאנחנו,
יפעת: אז בתפקיד, אחד התפקידים הקודמים, שבאמת פיתחנו יכולות שמפתחים, שעזרה להם מאוד לצמצם את ה release cycle time. פיתחנו להם כל מיני יכולות שעד כה הם היו צריכים לעשות חלק מהעבודה בצורה ידנית. וכשהשלמנו את המערכת, כשסיימנו וגם, אתה יודע, זה לקח גם כמה חודשים טובים ותוך כדי בדרך אז באמת התחלנו לקבל פידבקים על איך הם משתמשים במערכת. וזה היה מאוד יפה לראות את זה שבאמת מה שרצינו לפתור באמת הצלחנו לפתור. כמובן ששום דבר הוא לא באמת מושלם ויש מה לשפר אבל עצם זה שהצלחנו להגיע למטרה זו הייתה חוויה מאוד מאוד טובה. כי זה בסופו של דבר מה שאנחנו ניסינו לעשות. אז נגיד שאולי זאת לא הייתה הפתעה כי זה מה שרצינו לראות,
ישי: הפתעה חיובית.
יפעת: זאת הייתה הפתעה חיובית, כן. אז כן.
ישי: והרגשתם שחוץ מההצלחה כאילו האובייקטיבית זה הביא את המטרה גם. היה את החלק הסובייקטיבי של וואלה המפתחים מרגישים את ה-value, אוהבים את זה, זה כאילו הם, התחושות החיוביות שזה נותן להם? כי לפעמים זה יכול להיות וואלה, על הנייר זה עובד אבל התגובות הן בסדר, יופי.
יפעת: לא, אז ראינו באמת שזה גם בפועל זה עוזר, זה חוסך עבודה ידנית שבעבר הם היו צריכים לעשות ובעצם עכשיו זה חסך להם את כל התהליך הזה. זה עזר גם ל management לבוא ולהבין מה הסטטוס של הריליס. כי עד כה היה כמו איזה חור שחור עבורם, הם לא באמת ידעו אוקיי, מה השלב של כל גרסה,
ישי: זה job security של כמה אנשים.
יפעת: כן, אז בעצם הנגשנו להם את המידע ושיקפנו להם את כל הסטטוס של הריליס, אז מצד אחד זה ענה על הצרכים גם של המפתחים אבל גם על הצרכים של המנהלים ומנהלות, אז זה היה באמת איזהו סיפור הצלחה.
ישי: לינדה, איזה הפתעה שאת ככה,
לינדה: היו הרבה, יש אחת ש-, curveball, אחד שמעניין שהוא כאילו סוג של חלק מה-journey. אנחנו, כשעבדתי יותר ב-devops end בנינו CMS ועבדתי ב-Fox אז איך שזה עובד יש CMS ויש לנו sites, Fox Sports, Fox news, Fox Business, כל אחד מהם שונה, כל אחד קבוצה אחרת ומשתמשים ב-CMS שאנחנו מנסים לבנות אותו אחד. עכשיו מה שלא שמנו לב זה שגם ה-infrastructure as code מבחינת הקבוצות ואיך שהן השתמשו בזה, אחד would use cloud formation, השני Terraform. כל אחד כאילו עם משהו אחר והיו כל מיני דברים שבדיעבד היינו צריכים כזה קצת לעשות research על ה-tools שב-west coast vs. east coast, זה דבים שכאילו אחרי זה מבחינת פריוריטיז לא שמנו אותם בפריוריטי הנכון to address,
ישי: אז עשיתם כל מיני הנחות יסוד שלא התקיימו.
לינדה: והיו הרבה הנחות כאילו לחבר, כי מה קרה. זה היה סוג של, כל אחד היה siloed, זה היה פעם הכול בנוי בנפרד, sports בנה את שלו, ביזנס בנה את שלו, news בנה את שלו ואנחנו באנו לחבר את ה-CMS ולבנות משהו חדש, עם Wordpress, custom… the whole thing, וגם לבנות את ה-CICD לכל אחד. עכשיו their working versions, their working patterns are very different, זה חברה גדולה, יש לך קבוצה ב-west coast, קבוצה ב-east coast, קבוצה בסינסנטי וכל אחד שם גם משתמש ב-tools אחרים מבחינת החלק השני ואנחנו צריכים לחבר את אותו דבר אז כאילו זה, אנחנו הלכנו על פריוריטי של שתי קבוצות מהשלוש ואז ישבנו והיה לנו בעיקרון כמה אנשים שהיו צריכים כל יום לעבוד עם Sports בגלל שלא יכולנו, לא בנינו להם את הדברים של הפריוריטי ב-shared usability's אז זה דברים שכאילו לא, we didn't account for from the capacity stand point גם, כדי לעזור להם ב-manual way עד שאנחנו נבנה את הדברים שהם צריכים. אז זה דברים כאלה, אתה יודע (צוחקת).
ישי: אוקיי, ולסיום, עצה אחת למישהו, מישהי שרוצה ככה להיכנס לעולם הזה של פרודקט בשביל פלטפורם או devrel או מרקטינג באזורים האלה של פלטפורם, בין אם זה internal בין אם זה outbound ללקוחות, משהו אחד לחשוב עליו, איזשהו טיפ למי שנכנס לעולם הזה.
יפעת: אני חושבת שאם זה אנשים שמגיעים מהרקע הטכני, אז באמת יש הרבה מאוד מקורות שאפשר לקרוא, יש ספרים, יש פודקסאטים, יש אתרים שבאמת מלמדים איך להיכנס לעולמות של פרודקט ספציפית בעולמות הפלטפורם אינג'נירינג. אז זה שווה מאוד וחשוב מאוד באמת לבוא וללמוד, כל הזמן צריך ללמוד, כן? ולא משנה באיזה תפקיד אתה בעולמות הפיתוח תמיד לומדים. אז קודם כל באמת לבוא ולעשות מחקר ולהבין מה, במה צריך להתמקד כל פעם בשלב הלמידה. ואם זה אנשים שהם לא באים מרקע טכני והם יותר באים מרקע הפרודקט מנג'רז אבל הם רוצים להיכנס יותר לעולמות התשתיות, אז גם שם פשוט להתחיל ללמוד איפה ה gaps הטכנולוגיים, מה אני צריכה לבוא ולהתמקד בשלב הנוכחי ופשוט לבנות איזושהי תכנית עבודה, זאת אומרת לזהות את ה gaps ולבנות תכנית עבודה וכל פעם לבוא ולנעוץ עוד שלב.
לינדה: מהצד שלי מבחינת developer advocacy, זה עבודה שמאוד, כל האנשים שאני מכירה ב-developer advocacy התחילו את זה בלהיות involved in community ולתת ל-community. זה לא משנה אם אתה בעבודה טכנית או את בעבודה טכנית, אם אתה לומד משהו, את לומדת משהו, לכתוב על זה, to share ב-mediums שמתאים לכם ו-to interact to the community. היופי זה שלא חייבים להיות, לא כולם גרים ליד meetups או דברים כאלה אבל אפשר, יש גם digital worlds והיום יש accessibility לדברים האלה ואפשר to get involved גם בכל מקום. ואני חושבת שה-developer advocacy זה משהו שבאמת רוב האנשים שאני רואה בתוך זה זה אנשים שכאילו בכל מקרה היו כאילו מאוד into community,. אז כזה, וזה לא חייב להיות תמיד בצורה ש-, אם בנאדם לא אוהב לדבר זה יכול להיות ב-Reddit threads, זה יכול להיות בצורה, בלבנות משהו עם עוד אנשים, יש כל מיני, there's no one way אבל אני חושבת זה ובאמת העבודה היא כמו professional student בעיקרון, אנחנו לומדים כל הזמן ו-to lead with curiosity ודברים כזה נופלים בעיקרון when you wanna go into things that are community focused, זה גם לפעמים פאזה בחיים, הרבה פעמים אתה יכול כאילו להיות במקום מסוים בחיים שאתה יותר בונה, יותר זה, במיוחד אם מישהו עובד בסטארטאפ או משהו כזה, וזה לא אומר שכאילו אח"כ זה לא יכול להפוך ל-advocacy. אני חושבת שזה, יש זמנים גם לסוגי עבודה בחיים.
ישי: אתן מסכימות איתי ש-, יתרון מכריע למי שנכנס לתחום הזה זה מישהו שמתעסק ובנה עם הידיים פתרונות בעולמות האלה? מי שהתעסק בדליברי של devops ופלטפורם כ-engineer יש לו יתרון גם בצד של הפרודקט וגם בצד של devrel?
יפעת: כן, כן, אני חושבת שזה,
ישי: אולי יותר אפילו מסוגים אחרים של מוצרים של פרודקט מנג'ר כללי או devrel כללי?
יפעת: כן, אני חושבת שזה מאוד יעזור, זה כמובן לא צריך להיות הדבר היחידי כי אם יש לך, אם הבנאדם מאוד מאוד טכני אבל אין לו ראייה רוחבית ואין לו ראייה של לקוחות אז זה לא באמת יעזור שהוא מאוד טכני, כן? צריך להיות השילוב הזה. אבל איל אין ספק שה-,
ישי: הבסיס חשוב.
יפעת: כן, אבל הבסיס הוא לגמרי משמעותי.
לינדה: עד כדי כך שכאילו יש חברות, אמאזון נגיד, הן לא לוקחות אנשים בלי,
ישי: בלי רקע מעשי.
לינדה: בלי רקע מעשי, זה תלוי גם על of course סוג של פרודקט, ואני חושבת שזה מאוד חשוב to earn trust.
(מוסיקת רקע)
ישי: מעולה. יפעת, לינדה, תודה רבה שבאתן.
יפעת: תודה רבה.
לינדה: תודה לך.
ישי: היה כיף.
יפעת: היה מאוד כיף.
(מוסיקת מעבר)
** לינקים לקהילות שהוזכרו בפרק - כאן.**
Yishai: In this episode I am happy to host Yifat Matatof Yaacov, Senior Product Manager at JFrog and Linda Haviv, Developer Advocate at AWS, what a pleasure you came.
Yifat: It's fun to be here.
Linda: Nice to be here, thanks.
Yishai: Excellent, today we will talk about platform engineering as a product or platform as a product, but as always I want to hear about each one's journey, where did you start and how did you get to where you are, so Yifat, let's start with you.
Yifat: Okay, so today I'm really a senior product manager at JFrog and I'm involved in the worlds of dev ops and cloud engineering, platform engineering, whatever name is chosen for the field. Before that I managed DevOps development and QA teams and along the way I also did positions that are horizontal, I was a release manager, technical customer success and I started as a QA engineer. I really gained from my experience working in many positions within the development organization, and this is actually my journey, I mean it's a little different I think.
Yishai: You didn't start as a product,
Yifat: No, I didn't start with the product.
Yishai: You dealt a lot with delivery.
Yifat: That's right, and I think it's precisely because I have experience and a lot of, let's call it, different personas within the development organizations, so as a product, it really allows me to understand, okay, what their pains are, what their problems are, what their challenges are, and it's especially so that a product manager In the field of platform engineering, it is a product manager whose customers are internal, and this is different.
Yishai: So now you are actually managing a product for people like you in previous positions,
Yifat: That's right.
Yishai: We'll dive into that, but you really touched on a lot of different areas of the development organization.
Yifat: That's right.
Yishai: We will come back to this transition to product. Linda, your journey.
Linda: my journey Not traditional at all either, I actually thought I was going to be a lawyer and at university, I was a philosophy major, I'll just tell you that I put some English in this podcast because I'm from New York and Hebrew is my first language, but I grew up in New York and I grew up there then Me, there are words I don't (laughs) know, but we'll do something "hybrish". But, basically, I went to the "Cooling Bootcamp", I worked in the news after university, I thought I would go to law, in the US law is 3 years after the 4 years of university, so there is time in between. And during this time I started to get into computer engineering , I didn't take any coding class or anything at the university, so I got into it, I fell in love with it, I left my job in the news and entered a 3-month "boot camp". And at the time I entered, my first job was in web development and it was extra -java script, things like that, more frontend and over time I did more NodeJS frameworks and all kinds of things like that and I got more into API work backend and I worked at a company that is interesting because I once worked in the news and after that I worked in the technology part of news so I was on the other side and understood the product So always, I'm always as if my motivation was always for the product and for the people and for the way they experience the platform. And at the time there was also a migration to the cloud, a lot, and I started getting into the cloud, I became interested and over time I moved to - SRE, for infrastructure engineering and now I work as a developer advocate at AWS. There were many different stories along the way but,
Yishai: So Both the world of media, both the world of entertainment and the world of law lost talent (laughing) and actually with the transition to developer advocacy you moved to an area that is a bit, if Yifaat moved to product, you moved a bit to a type of marketing, to the world of developer experience.
Linda: Yes, for that kind of thing, and it's also very interesting because all kinds of companies, everyone says either it's more marketing or it's more product, it's very interesting because it's a kind of combination and everything is actually a combination.
Yifat: But I think it's really two worlds that really connect as well.
Linda: Yes.
Yishai: So Today we will really dive into these different sides of platform engineering beyond the normal practice of a platform within a development organization, about your transition to product and your Linda to marketing and advocacy, these are the areas I want to dive into. So maybe we'll start by talking about where a platform behaves like a product or even within an organization? We usually have a group or a team or the beginning of something that makes an internal platform, where does it behave like a product, like a product, where does it behave like something else? Where should it be, behave more or less like a product? What did you see?
Yifat: So I think that in larger organizations, where there are tens, hundreds of developers, then there is really a need to come and build some kind of product out of it. Because we see that there are a lot of development teams that can work in different ways, with other standards, with other solutions, and actually the productivity and efficiency of the developers, of the devops people, of the operations people, they actually have a lot of difficulty with it. And I think that once you look at the infrastructure, at the infrastructure, at all the capabilities that the infrastructure teams provide to the development and operation groups as a product, then it is possible to engineer it in a much more efficient way for the organization, in the end this is the goal, how do we provide a better way of working For the development and devops teams in the operation so that they can develop products for the end user in a way that is of higher quality and faster. So that's the whole story.
Yishai: And if I try to break down a bit what it means to be a product, because we have other areas, we have, I don't know, UI guild, which doesn't necessarily refer to what it does as a product. What does it mean to treat a platform as a product? Does this mean putting a product manager in the group?
Yifat: So I think there is really a need for larger organizations. And the product actually, product even if the users are internal, it's the same work processes as a product that works with end user paying customers. I mean, you need to understand what the problems are, what the challenges are for each of the groups that work within the organization, where today they spend most of their time, where you can introduce much more automation, where you can improve the processes, and that's also, it's interviews, ask them, understand, To bring solutions, do a POC with them, design partners. I mean, in terms of a product manager's work methodology, I don't think there is a difference between whether the customers are internal or whether the customers are external.
Yishai: So this almost means that a product manager is needed in the group, because platform people typically do not have the skills or this experience of how I recruit design partners, how I work with them and refine the requirements.
Yifat: True, they are usually people who are more technical, more observant, although they are usually also in infrastructure, they are people who are very helpful. Because they have to work with a great many groups within the organization and necessarily they have to be people who are, who have some kind of horizontal vision. But it's true, it's a different skill set, it's not always a skill set, which sometimes needs to be brought in from the outside in order to really focus the organization on where to invest, where to invest the efforts in order to really provide better infrastructure to the internal groups within the organization.
Yishai: And where do you think there is a difference anyway? Where do the platform groups within organizations distance themselves or should they be a little different from normal work on a product that is outbound?
Linda: I really sympathize with what she said about big companies because I think you especially need to understand the product, how do you fit into the image of the internal product. I will give an example. So I worked in the news and the part of the devops and platform that I worked on more is the CMS of people who write breaking news articles every hour of the day. And things we also need to show election results, okay? Stuff like that. and understand the inner workings, how the group works. It's a product, but it's really your customer is very different, because it's really the people who are internal, so there's also a real interest in understanding the internal dynamics of the company, which, I don't know if it's a bit of a different type of audience, you know? your audience is technical (laughing)
Yifat: Yes, absolutely the product manager must understand what the customers are doing, that is to say must come from the worlds of the infrastructures and really understand the day to day. And so there is no doubt that it is very important for a product manager in general to understand what the customers are doing so that he can get to know the product, but of course it is a product that is actually infrastructure, so you have to understand the umbrella.
(transitional music)
Yishai: So we talked about the product skills and the product ceremonies or cycles that need to be done, also in an internal organization,
Yifat: Yes.
Yishai: If I look at the side of product marketing, and evangelism, how does this happen, again, in a platform organization, let's say within a large engineering organization?
Linda: What is very interesting is that many of the tools also that people, developers use, are a lot from the individual, sometimes it is not the CTO who decides on the tools, it is a lot individual and here there is,
Yishai: I work with VI, obviously.
Linda: Yes (laughing) Yes, but in the name of advocacy, there is another advocacy such as what tools do you wanna use that you're the, you seem to use as a developer on the other side. Let's say I worked as a web developer and I used to deal more with like, everything would seem like magic, if I wasn't in devops, and like the servers, millions of people come to see the results of elections and everything seems to work, yes? And this part really interested me and the tools that I also need to do my work even as, if I work in engineering or computers on the other side, that I only do the javascript part and the more logic of the UI, it's different than working To support the underpinning, you don't always get the credit either (laughs). of success, and there is a certain advocacy there, only they really need to understand both the tools and, as it were, the ease of working under stress, especially in a place like news, and I see it as a certain kind of advocacy to get buy in and to do the There is a very strong relationship with a certain customer who is perhaps the developer, so there is a type of advocacy here like a product developer.
Yishai: Yes. I got to see quite a few devops and platform teams working on cool stuff and no one uses it.
Yifat: It's true, I just wanted to say that PR or marketing is very important for what is done within the devops groups. Because really not everyone knows it. But I think it's also terribly similar, we're going to develop functionality in the products and the customers won't really recognize that it exists, whether it's a paying customer. And I really think that this combination of developing and also knowing how to do marketing and PR well is very critical in order to have adoption, because in the end we can develop but it really won't be used and the adoption will be very low so why are we investing here the effort?
Linda: There were times when there were really integrations of all kinds of tools and in the end the groups didn't use it, it really is a buy in factor.
Yishai: So I really like stories, do you have a specific story about, say, a platform work that was particularly successful or not successful because of production issues?
Yifat: Yes. So I can tell you in the previous hat, when I managed one of the development teams, then we really developed, it was also, we developed products for developers within the organization. And then we developed capabilities that we didn't do enough research or not, rather we didn't do enough collaborations with teams, we developed capabilities and the developers didn't know they existed. So they would turn to us, we were also a development team, tell us we need such capabilities and we said but wait, we have already developed them. And in the end we realized that we didn't really do enough PR for what we developed, and that's something that I took it further. So yes, it exists, I mean you have to treat it and know how, of course in dosage, yes? But how to tell what we develop.
Yishai: Have you seen or worked in a situation where platform teams measure themselves on adoption? measure themselves on these things?
Yifat: I think that's everyone's dream. Everyone's ambition is to really show adoption of what we develop and actually use it. I think it's difficult, and really this is the direction to go there, it's not easy and you really need to focus on it. If the worlds of DORA Metrics or other tools and products, then that is completely the direction, but you have to invest the efforts there.
Yishai: And you talked about the fact that you see this happening more and more or developing in large organizations. What happens in small organizations?
Yifat: It really depends because if it's organizations of I don't know what, 10 developers, 15 developers, you know, they're still at the scale they can, which is starting to be challenging, but I'm not sure that there should be, for example, a dedicated product manager function. It might really be possible that it would be more something that team leaders might do. The complexity increases and increases as there are many more developers who are also in different locations and in Israel, the US or Europe and this simply adds to the complexity and the challenges.
Yishai: Returning to the questions of marketing and awareness, and also how I talk to my user base.
Yifat: True, because they are not with you always and really, as the complexity increases, we really need to come and provide uniform standards to development teams.
"As the complexity increases, we really need to come and provide uniform standards to development teams."
Yishai: So Linda, in this world of developer advocacy, I want to start with the internal and then move on to think a little about the external. What is special about developers that you have to talk to them in such a different way and I don't know, you can't sell to them like you sell washing powder or,
Linda: Yes, it's a matter of trust. A man who can talk about the problems he went through because he was also a developer, it's different that he talks to a developer, compared to someone who comes and sells you something and he hasn't gone through the kind of problems or accomplishments also of the whole thing of building something technological. It's a matter of trust, it's a matter of understanding your audience and helping them too.The beauty is that the word developer advocate used to be called enthusiast, after that advocate,
"It's a matter of trust, it's a matter of understanding your audience and helping them too."
Yishai: evangelist, there are many terms.
Linda: Yes, all sorts, I don't know if we have found the right word yet, but what I do like from what has been up until now, I do like the developer advocate more because you really advocate on behalf of developers, it's like checks and balances, as they say in Hebrew ?
Yishai: checks and balances.
Linda: Yes exactly. because you are not sitting,
Yishai: In this podcast this word still exists.
Linda: (laughing) Yes, that's it, if there's a word that's that, let's do it like that,
Yishai: Beep.
Linda: Exactly, exactly, we'll put it in, I'll send you a voice over (laughing). But the beauty is that there are people who-, I forgot what I wanted to say,
Yishai: You talked about why you like the term developer advocacy.
Linda: So you're not sitting inside a product, right? I work at AWS, we have over 200 services, I work as a generalist. So my job is to advocate on behalf of developers, I don't, as if I want the success of services, I also want it to be a good experience for developers. The experience of the developers is important to me, and it's a kind of checks and balances that I internally give feedback to. I look at things that haven't come out yet, I look at things from a point of view that we can also see what can happen because I'm in contact a lot with the community, on social media, in meetups, in all kinds of mediums.
Yishai: But try to help me understand why developers are so mistrusting,
Yifat: they are difficult people (laughing)
Yishai: Like why do they need this middleman or why do they need to be spoken to so differently than all the other audiences?
Linda: I will tell you that the beauty of technology is that you have so many options and so many pathways. And the world of developers is less, also the way they become a developer, it's not one path, and the amount of options you have over the years is very overwhelming and everyone, and they are very opinionated people in a good way too, as if that's the beauty, they build things, People who by nature innovate and sometimes also cut the rules. And that's a good thing, but with that comes the part of how you give it a kind of democracy to choose tools, the developers usually like to choose and if they use things they don't like, we see companies changing the tools, based on the developers, not the CTOs, right? And there's a reason for that, because you have a lot of people in upper management who don't always understand this thing. Especially in an enterprise, let's say you go as if the bigger you are you feel it more and there's a kind of misunderstanding of the knowledge sometimes between groups , right? a lot of miscommunications and,
Yishai: which is an area where the developers are not always the best.
Linda: yea, your tools, and developers know how to build and not always how to communicate. So there is a part that also needs to help the developers understand what the options are because it is really overwhelming. And there is no time to learn everything and companies like AWS need to un-fragment.
Yifat: Yes, I can also add that a developer is like any customer, he doesn't always know what he wants or what he needs.
Yishai: Enough, really? (laughing)
Yifat: Yes. He has some understanding of what the problem is but he doesn't always know the solution. And really, as soon as you do a PR, dev relationship, and tell them that it exists, then it also opens up options for them that they simply didn't know about before. And yes, developers can really be, as you said, opinionated, which is perfectly fine. And they are, I think some kind of different kind of customers than selling them some kind of product because here really, if you come and try to market them some kind of service that AWS has done and you really don't have the technical history, they are less,
Yishai: They won't believe you.
Yifat: They won't believe it. They won't understand, they'll think ok, but he or she hasn't really tried it so how do they know it will really solve my problem? So yes, you should, and in contrast to don't know what, if you go and sell a car you don't need to know how to operate the car. It is enough that you sell the car as it is, the finished product, and it is different, it is different.
Linda: And, the innovation that happens, you also want to know what problems the developers are going through, even if there is no solution. Because places like AWS are more, they iterate based on the feedback and sometimes you only look at feedback in business and C-Suite, you don't get the other feedback, which is from the people.
Yishai: So you have to be where it is, you have enough trust that they can talk to you and say it doesn't work for me, here I lack some kind of flexibility in the API.
Linda: Basically let's say we are more in tune with the community and we come and write maybe a 6 page paper on Amazon about things we hear to advocate on behalf of developers and to build it into our product and temporarily also bring awareness to what is available and options to solve different problems.
(transitional music)
Yishai: So both of you have made a change from the work of writing or developing systems and platforms and devops within organizations, to something that is directed externally, that is, for you, Linda, you are directed to AWS users, or for you, Yifat, that you are actually doing an internal product but in an official position of product manager and not a builder.
Yifat: Right.
Yishai: Tell me a little about this shift, this transition.
Yifat: It's very natural for me, because really in my background I've had both horizontal positions and management positions. that in the last 7 years I have been more involved in hands on and I think I still always had the perspective of who my client is and what I need to deliver to him. And over time then I actually also acquired tools that are more technical, but there was always really the perspective of the horizontal, of the customers. So for me, in my feeling, the transition to product manager is very natural, of course a product manager who deals with technology and the worlds of devops, so this,
Yishai: Are you joining an organization that already had an internal platform product?
Yifat: No, this is the first job.
Yishai: So it's a novelty. So how do you enter an organization that was not used to having a product manager in such a position? And put in some kind of skill set and a different approach?
Yifat: So you have to build it. First of all, I need to understand where the important places are for me to focus on, where today the organization needs more help. And also looking ahead, okay, so now we'll actually take care of this problem, let's look at what other problems need to be taken care of down the road. And it's not the first time I've had to build a position, I mean the previous jobs too so I formed a team, I recruited people, I basically formed a team from scratch. So this experience of coming and creating something from nothing, so it is not new to me. It's challenging, it's fun, but the fun is to come and find what's new and come with experience and while also learning a lot.
Yishai: And organizationally, do you belong to the product organization? for engineering? How is it built?
Yifat: Not specifically, I belong to the engineering organization.
Yishai: So it's not in the usual distribution.
Yifat: Right.
Yishai: And how does it catch? Does it help you that you are in engineering? It's strange because you're not part of product?
Yifat: You know, it's always, I've always been in the world of engineering so it's very natural for me to stay there. And there are collaborations with products from the guilds let's say of the product. And I think that every product manager actually builds for himself the form of the, the relations with the product of the other groups and with the additional groups of course. So this constellation of being a product as part of an engineering group and still working with other product managers, in my opinion is very logical and correct.
Yishai: But they live the customer, they think about how we build the features for JFrog's customers and you deal with completely different customers, with internal engineering groups.
Yifat: Yes, but the infrastructures that we provide are also often infrastructures that in JFrog's company is something very technical and very, his worlds are the devops worlds, so the interaction is with the different groups is really part of the capabilities that we provide because it contributes a lot to the products. So there is some combination here,
Yishai: There are things that you manage as a product manager that end up in the product itself.
Yifat: Yes.
Yishai: Okay, so there is also some kind of looking at the customers outside.
Yifat: True, there is also this side here.
Yishai: I realized. And Linda, tell me a little about your transition to outbound
Linda: It was also very natural for me, the truth is when I was working, I made several transitions, I moved to devops in the same company, also in media. I always understood the product and was very much in the AWS Community. The beauty of technology, there are many communities and very much, because innovation by nature is something you build on each other's ideas, there is a world of open source, there is a world of shared information and I think this part of technology is very special. And in the advocacy section it was very natural for me because I was always very much in the community. So AWS specifically, I would do certification courses within the company I worked for before I worked for AWS, I would simply do lunch and learns, I would run all kinds of things within the company, Internal, for developers who worked at the company I worked for in the media and my work was completely technical and behind the scenes. The difference today is that I build for education and not for prod. Today I build more for education then I built for prod.
Yishai: You built things for production and besides that you did internal courses.
Linda: And I did internal courses on the side, and also,
Yishai: because what? Because it interested you?
Linda: It interested me, I would also make a lot of videos on social media. The way I even got into advocacy is that they found me on social media, but what's funny is that I always knew that I, who made the transition to technology, always knew that in the end I would be in some kind of combination. I didn't know if it would be, something with people, like I didn't know if it would be sales, I didn't know if it would be advocacy, but I knew that I wanted to be behind the scenes only as if to build for many years and then as soon as I feel that I am more comfortable with things and have gone through several roles. I can also give more. But all this time I would do a lot of social media, on TikTok and Instagram about tech and I was also in a program called the AWS Community Builder program. So you can apply to it and it's amazing, you meet people from all over the world, from all kinds of companies and build together and this is also people who like to teach and learn together. And for me it was very natural as if to move into this role, for me it was quite a dream because I felt that I could also be technical. I can also be with people and listen to people and help people, and I'm in a field that I really like, which is the cloud, but it's funny how sometimes, as if in technology, you can start somewhere and you can move to so many roles, and I say that life is different phases in life, I don't I would have wanted this job a few years ago. I think it was important for me to be really focused, I would do it on the side, but it was important for me to build my experience in a certain way, because with work like this, the challenge is, you don't get to build what you didn't use to build And you need to build over your experience.
Yifat: Absolutely, you have to come with the experience to really be able to do such a role in a meaningful way. And we need the technological experience, we need the experience of working with different teams, I think that even in the positions I did in the past, I didn't always have a product that I worked with or worked with,
Yishai: So I had to do it myself.
Yifat: So many times I also did the role of the product simply without the title of the product, and today it is simply with the title of the product and that is the difference.
Yishai: Tell me, and how do you deal with the fact that someone else has to write the code?
Yifat: No, it's perfectly fine.
Yishai: I don't tickle you to, I'll do it better, I can to,
Yifat: No, it's not right now. I also moved from management positions to a position now that is horizontal again and at the moment it doesn't bother me. I mean, I'm completely fine with moving from a managerial position to a horizontal position. Because again, because it feels natural to me, it feels natural to you, so you don't have any feeling of missing out or a feeling of, but feeling it in the right place.
(transitional music)
Yishai: I want to talk to you about the connection and the relationship between, again, under this platform world, between the product and the marketing and the PR. We talked about the importance of each of these parts, a little about the cooperation between them. Where it succeeds, where it is difficult.
Yifat: So I think it's really important to do this PR work. It should be whether it's in surveys that are released to developers and internal customers in order to understand what the pains are or what the challenges are that they work with on a daily basis. And really in the PR aspect, how do I publish what we have developed, so whether it is in a newsletter or blogs or all kinds of posts.
Yishai: Or the child just doesn't work anymore and writes or needs to do something else (laughing)
Yifat: No, but let's say now we've developed, let's say, you're developing a new infrastructure capability, okay? You want to come and patch it up, for the developers to know about it, for the development teams to know about it, so how do you do it, so if it's in all kinds of posts or all kinds of messages in Slack or, I don't know if today they already do a newsletter, it seems a bit old fashioned to me ,
Yishai: It's internal, yes. Let's say you have a knowledgeable partner at JFrog today, who helps you with this side of product marketing for your work? Or is it up to you? Do you now need to tell a thousand people that there is something new on the platform?
Yifat: I think it's more in the world of the product. Maybe later it will change, yes? But right now it's more like in the domain of the product. In terms of the internal users' product, yes? I'm sure it's also maybe a little different in the product that they really have outbound customers.
Yishai: I mean, there is some difference here, let's say in the outbound product there is enablement and there is field training and product marketing and
Yifat: Yes, of course, you have, although even within this internal there is also training and really, because it is also important to train customers, so in this aspect too there is, there is not much significant difference,
Yishai: Only it falls on the same people instead of splitting into skills.
Yifat: It can also be the responsibility of the head of teams, of the managers, it's not necessarily that there is only one function that takes care of it, no, it's also that the managers have a lot of knowledge and experience and they take part in it.
Yishai: And Linda, where do you see the collaboration, what does collaboration with the product side look like?
Linda: I see product and marketing as something that goes hand in hand, hand in hand, buy in is a very important thing, internally, even when I worked in the news we had people who worked in product and we had people, because it was a large company, who just went and trained enablement to get that marketing angle. And their job was, we worked on a CMS product to enable news, so it was like, we had people who were all very stressed, it's a very stressed world, so if something doesn't work, someone needs to come from below to help them. We build them tools that they need to do their work. Now the customers are also sometimes non-technical people, they are editors, they are people who author in journalists, so it is a different type, as if we had a group that really just sat on, not only that, they were not a product, the ones who determined the product itself, They were really the ones who led, they called it community managers. But everything is internal, and in this, I don't know, call it, it doesn't matter what you call it, as for me it really is as if the buying part is indeed a type of marketing that's ingrained in product.
Yishai: And then the people of the product and the people of the enablement worked together to get the gospel down in the end?
Linda: Yes, and to build that system out, which is very interesting because I look at it from the corner of the eye, right, of an enterprise, it must be different in a small group. But even I see it now in a company like Amazon, you can build a product, the part you just to get the buy in of organic marketing vs. traditional marketing, this is also a big part, there is the unsaid marketing. When you have internal advocates and natural advocates that you don't pay them to do it, that they do it, you want like, it's a kind of, it's a different kind of marketing.
Yishai: Community.
Linda: community, right, you can call it community, אבל it does go hand in hand.
Yishai: But what does this relationship look like today between the product people, okay, we built a product, a new Kafka, some kind of service, and now there is the PR of this and on the other hand also, I don't know, advocacy that brings me feedback from the field, how does this happen on a daily basis? Are there regular sinks? Is there organic feedback that you expect and hope someone will listen to?
Linda: Yes. So there is a difference between say a company like Amazon is huge so you have a marketing product as if just for that. You have a product that only builds the service and you have advocacy which is completely separate, which works with marketing and with engineering and with the community and it works with all kinds of groups. Sometimes advocacy sits in marketing, sometimes advocacy sits in product, sometimes advocacy sits in engineering, because it's very, it's like a kind of combination that you have every time, we also have advocates within Amazon in all kinds of groups, and their work is the same but it's interesting, it's like not just sitting on one of them so always you,
Yishai: So they have other reference points to work with.
Linda: Yes, other reference points and they are always needed, there is a type that needs explanation and the people who are even head marketing or head product need to understand what advocacy is, which is quite different from traditional marketing or traditional product. Because my job is, let's say, not to take a product and say I gave you 500 people came from the product. My work is really hard to measure because I need, I don't need to depend on the product, I want the product to be good, I want to depend on the customer's success. Understand what he needs and solve his problem and convey a message also back to help the product be better. So it's kind of hand in hand. Feedback loop.
Yishai: So you are a two-way pipe.
Linda: yea.
Yishai: Yifat, I'm interested in slightly larger organizations, from what you saw, the dynamics of official feedback, or you collect feedback on I don't know. We made a platform change, we released something new, there are official channels for feedback, for team leaders who ask the developers and get answers, and there are the conversations in the corridor and the steamers by the collar (laughing). Tell me a little about where you saw differences or how you get to the unofficial feedback that is sometimes more reliable.
Yifat: So I think it's also related to the trust. I mean what Linda said earlier, I think that if the users see the managers or the product as really some kind of function that you can come and say okay, that's the feedback that will be on what we delivered. I think it's good enough or not good enough, so that's one thing, that they'll feel comfortable coming and saying even if things aren't working well enough. And the second thing is that really a lot of good ideas emerge from these corridor conversations. Really suddenly oh, okay, wait, we didn't think about it, maybe it's really worth introducing this functionality, maybe we should change the functionality from what we thought at first? Even if we have already implemented it. And I think it has a significant place and it also has an important place. It's just that it's corridor conversations so you know, the people you're talking to are the, it's samples, it's much smaller, and in contrast when you send a survey then you have the ability to reach more people. But feedback is important both ways.
Yishai: And in a large organization how do you get to this informal part? In the end there are few people on the platform and even fewer of them who know how to do, I don't know, listen to feedback, that they are a product in their state of mind, that they can only move around in two corridors and not in the whole company.
Yifat: Right, so I think that once you also do all kinds of training sessions, as Linda mentioned, you also do internal training, and then you actually still have a larger group of people.
Yishai: A coffee break and you can really hear what's going on.
Yifat: Yes, and also during the sessions they can raise feedback or questions, while asking questions you can understand, for example, whether they are, what are the problems that we may not have solved yet, so I think there are all kinds of channels where you can get formal and informal feedback.
Linda: And also the informal in outbound now has social media and it is a big part that today you have a lot of cooler conversations there. which is a little different off course that you are dealing with an internet, because you can't really get it from social media. In my world, I can also see a lot on social media what is happening, in terms of Instagram, TikTok, I meet people where they are, I meet them. Where they are, so it's very interesting because if I start a conversation about something or make a video about something, I also see back both the good things and the bad things and can sometimes also talk to them and see where this is or what they're looking to see more or what's trending happening now off course subjective, we have many different communities and sub-communities.
Yishai: You hear those who like to talk.
Linda: Yes, that's it, so it's also important to look at places that don't talk to me but talk about things.
Yishai: You have some Philraz out there for sentiment and to find, voila, here is an interesting thread talking about a topic I'm interested in then,
Linda: So there is, I specifically don't have. There are also all kinds of products that maintain a certain sentiment as well, because feedback is very important to all, as if customer obsession is something very, very rooted in Amazon, let's say, so there is always this sentiment analysis that is rooted. I specifically deal with video a lot, it was interesting because usually advocacy in the past, especially before Corona, a lot of advocates, they got hired to do more public speaking, I got hired for video, and the reason is not just to get information out. The reason is to communicate with People in the video world, because people who maybe start Instagram, they won't come every day to something that belongs to something technological, they want to drink their coffee and see what's going on, oh, suddenly something pops up that they weren't looking for at all, they learned about some workshop on generativeAI, but it doesn't hurt In terms of what they want, they want something that will help them build something specific, is there such a thing.
(transitional music)
Yishai: In conclusion, I would like to hear perhaps from each of you a story about one case, one thing that surprised you, feedback you received about work that was really related to the platform that was a surprise, that was like, changed something, like we didn't expect to receive something like this and it changed a little how we thought about a problem or a solution We,
Yifat: So in the position, one of the previous positions, we really developed capabilities that we are developing, which helped them a lot to reduce the release cycle time. We have developed all kinds of abilities for them that until now they had to do part of the work manually. And when we completed the system, when we finished and also, you know, it also took a good few months and along the way then we really started getting feedback on how they use the system. And it was very beautiful to see that what we really wanted to solve we really managed to solve. Of course, nothing is really perfect and there is something to improve, but the fact that we managed to reach this goal was a very, very good experience. Because that's ultimately what we were trying to do. So let's say maybe it wasn't a surprise because that's what we wanted to see,
Yishai: A positive surprise.
Yifat: It was a positive surprise, yes. so yes.
Yishai: And you felt that apart from the seemingly objective success, it also brought the goal. There was the subjective part of Walla. The developers feel the value, like it, it's like them, the positive feelings it gives them? Because sometimes it can be great, on paper it works but the reactions are fine, great.
Yifat: No, so we really saw that it also helps in practice, it saves manual work that they had to do in the past and actually now it saved them this whole process. It also helped the management to come and understand the status of the releases. Because until now it was like some kind of black hole for them, they didn't really know okay, what's the stage of each version,
Yishai: It's job security for some people.
Yifat: Yes, so we actually made the information available to them and showed them the entire status of the releases, so on the one hand it met the needs of the developers but also the needs of the managers, so it was really a success story.
Yishai: Linda, what a surprise you are like this,
Linda: There were many, there is one that, a curveball, one that is interesting that is like a kind of part of the journey. We, when I worked more at the devops end, built a CMS and I worked at Fox, so the way it works is there is a CMS and we have sites, Fox Sports, Fox news, Fox Business, each of them is different, each a different group and uses the CMS that we are trying to build one. Now what we didn't notice is that the infrastructure as code in terms of the groups and how they used it, one would use cloud formation, the other Terraform. Each as if with something different and there were all kinds of things that in retrospect we had to do a little research on the tools on the west coast vs. east coast, it's Debim, as if after that, in terms of priorities, we didn't put them in the correct priority to address,
Yishai: So you made all kinds of assumptions that didn't exist.
Linda: And there were many discounts as if to a friend, because what happened. It was kind of, everyone was siloed, it used to be that everything was built separately, sports built its own, business built its own, news built its own and we came to connect the CMS and build something new, with Wordpress, custom... the whole thing , and also build the CICD for each. Now their working versions, their working patterns are very different, it's a big company, you have a group on the west coast, a group on the east coast, a group in Cincinnati and everyone there also uses other tools in terms of the other part and we have to connect the same thing So it's like this, we went for a priority of two groups out of the three and then we sat down and we basically had several people who had to work with Sports every day because we couldn't, we didn't build them the things of the priority in shared usability's, so it's things like no, we didn't t account for from the capacity stand point also, to help them in a manual way until we build the things they need. So it's things like that, you know (laughs).
Yishai: Okay, and finally, one piece of advice for someone, someone who wants to enter this world of a product for a platform or devrel or marketing in these areas of a platform, whether it's internal or outbound to customers, one thing to think about, some kind of tip for those who enter this world.
Yifat: I think that if it's people who come from a technical background, then there are really a lot of sources that you can read, there are books, there are podcasts, there are websites that really teach how to enter the worlds of a product specifically in the worlds of platform engineering. So it is very worthwhile and very important to really come and study, you always have to study, yes? And no matter what role you play in the worlds of development, you are always learning. So first of all really come and do research and understand what, what should be focused on each time in the learning phase. And if it's people who don't come from a technical background, and they come more from a product manager background, but they want to enter more into the worlds of infrastructure, then also there just start learning where the technological gaps are, what I need to come and focus on the current stage and just build some kind of work plan, I mean Identify the gaps and build a work plan and each time come and nail another step.
Linda: From my side in terms of developer advocacy, it's a job that is very important, all the people I know in developer advocacy started it by being involved in the community and giving to the community. It doesn't matter if you are in a technical job or you are in a technical job, if you learn something, you learn something, write about it, share it in mediums that suit you and interact with the community. The beauty is that you don't have to be, not everyone lives near meetups or things like that but it is possible, there are also digital worlds and today there is accessibility to these things and it is possible to get involved anywhere. And I think that the developer advocacy is something that really most of the people I see in it are people who were like in any case very much into the community. So like that, and it doesn't always have to be in a way that, if a person doesn't like to talk, it can be in Reddit threads, it can be in the form of building something with other people, there are all kinds, there's no one way, but I think this and really the work She is like a professional student basically, we study all the time and to lead with curiosity and things like this basically fall when you wanna go into things that are community focused, it is also sometimes a phase in life, many times you can seem to be in a certain place in life where you are more constructive, It's more, especially if someone works in a startup or something like that, and that doesn't mean that it can't become advocacy later on. I think it is, there are times for types of work in life as well.
Yishai: Do you agree with me that, a decisive advantage for those who enter this field is someone who deals and builds solutions in these worlds with their hands? Does someone who has dealt with devops and platform delivery as an engineer have an advantage both on the product side and on the devrel side?
Yifat: Yes, yes, I think it is,
Yishai: Maybe even more than other types of general product manager or general devrel products?
Yifat: Yes, I think it will be very helpful, of course it shouldn't be the only thing because if you have, if the person is very, very technical but he doesn't have a horizontal view and he doesn't have a customer view then it won't really help that he is very technical, yes? Should be this combination. But there is no doubt that the
Yishai: The foundation is important.
Yifat: Yes, but the base is completely significant.
Linda: So much so that some companies, Amazon for example, do not take people without,
Yishai: without a practical background.
Linda: Without a practical background, of course it also depends on the type of product, and I think it is very important to earn trust.
(Background Music)
Yishai: Excellent. Yifat, Linda, thank you very much for coming.
Yifat: Thank you.
Linda: Thank you.
Yishai: It was fun.
Yifat: it was very fun.
(transitional music)
Go to devinterrupted.com where you will find both our episodes in English and our discord server, and I would like to introduce you to Gitstream, our smart engine for continuous merge, only 2 minutes of installation and of course it is free. Go to gitsream.com I'm Yishai Beeri, we'll hear from you in the next episode.
Links to the nifty tools and resources mentioned in the episode: