Woof! The Art of Dogfooding! - Yaniv Shani, VP R&D Lightrun

בפרק הזה, ישי בארי, CTO ב LinearB מארח את יניב שני, VP R&D  ב Lightrun על כל נושא ה dogfooding בארגוני פיתוח, למי זה מתאים, איך עושים את זה נכון, ומה האתגרים בדרך להצלחה.

In this episode, Yishai Beeri, CTO at LinearB, Yaniv Shani, VP R&D at Lightrun, who unpacks the world of dogfooding in engineering organizations...the types of organizations this works for, how to get started, and the challenges you'll encounter on your way to success.

Transcript

Episode Transcript תמליל הפרק

Hebrew, then English בעברית ואז אנגלית:

(מוסיקת פתיח)

ישי: ברוכים הבאים לפיתוח בהפרעה, הגרסה העברית ל dev interrupted, הפודקאסט המצליח של LinearB...למנהלי ומנהלות פיתוח. פה נדבר על כל מה שמפריע למנהלי פיתוח. אני ישי בארי, CTO ב LinearB...אנחנו שמחים להביא אליכם את הפודקאסט בעברית, נארח אצלנו מובילים ומובילות בתעשייה כדי לדבר על כל מה שמעניין מנהלי פיתוח, מי שעובד איתם ומי שרוצה יום אחד לנהל ארגון פיתוח. 

ישי: בפרק הזה אני שמח לארח את יניב שני, VP R&D בלייטרן, אהלן יניב.

יניב: היי, מה העניינים?

ישי: איזה כיף שבאת בהתראה קצרה, שיחקת אותה.

יניב: בכיף, בכיף.

ישי: ואנחנו נדבר היום על  דוג פודינג. לפני כן אני רוצה שתספר לי קצת עליך, איך הגעת עד הלום, כמה מילים על הקריירה שלך so far ואז נצלול פנימה. 

יניב: בכיף, אני אספר על הקריירה וגם אני אכניס קצת, כטריגר לשיחה, כמה נקודות ממשק של  דוג פודינג תוך כדי התהליך. 

ישי: לך על זה.

יניב: אז בגדול אני 25 שנה בתעשייה, למדתי במחזור הראשון בפריקסטים (precasts) באוניברסיטת רייכמן, וכבר בהתחלה, בסוף השנה הראשונה ללימודים, התחלתי ככה לעבוד בתעשייה. התפקיד הראשון שלי היה בחברה בשם VCON, חברה שבעצם פיתחה מערכות "וידאו קונפרנסינג" סטייל פוליקום והמערכות הגדולות שהיינו רואים אותן בחדרי ישיבות, שהיום כבר הן לא קיימות, והתמקצעתי בתחום של voice over IP, הרבה תקשורת, הרבה עיבוד תמונה, ואני חושב ששמה בעצם, אם אני מסתכל על זה בקונטקסט של השיחה, פעם ראשונה בעצם חוויתי מוצר ואספקטים ראשונים של  דוג פודינג (dogfooding). אני מאוד האמנתי בתחום של וידאו קונפרנסינג, הייתי בטוח שזה הדבר הבא בתקשורת, ולימים, ואנחנו נחזור אולי על זה בהמשך, בתור משתמש, שהתחלתי להשתמש בזה לא רק כ-developer  רק שעושה בעצם בדיקות שהתקשורת עובדת ורואים וידאו, אלא באמת בתור משתמש אמיתי שמנסה לעשות שיחה, הבנתי שמשהו לא עובד.

ישי: לקח איזה 20 שנה...

יניב: כן, לקח איזה 20 שנה, אני חושב ששתי הבעיות המרכזיות שהרגשתי זה כבר שהשיחות הם set up, השיחות האלה דורשות מעורבות רגשית מאוד גבוהה, אתה לא יכול לדבר את זה על הא ועל דא, שיחות כבדות, וגם לא היה את ה-eye contact במכשירים האלה. אני חושב שתיקנו את זה עם הלפטופים, תיקנו את זה גם בהנגשה של הדברים וקלות ה-setting up, אבל לי זה בעצם ככה אנקדוטה ראשונה לגבי  דוג פודינג ואנחנו ניגע בזה בהמשך. אחרי 8 שנים ב VCON עשיתי שיפט לדומיין אחר, הצטרפתי למרכז הפיתוח של Sun Microsystems, חברה שהייתה מובילה בזמנו, היום היא כבר לצערי נבלעה ע"י Oracle לגוף ה Java. בעצם פה בארץ פיתחנו פתרונות של ה-virtual machine, ואני נכנסתי בעצם בתחום של ג'אווה למובייל, מה שבעבר היה נקרא J2ME, והובלתי פרויקטים של הטמעה של ה-virtual machine אל המכשירים של היצרנים. תפקיד שעשיתי במשך 8 שנים, חברה שעבדתי בה 8 שנים, ובסופו של דבר הובלתי את הפיתוח, גוף פיתוח גלובלי שהיה אחראי על בעצם פיתוח והטמעה של הג'אווה virtual machine למובייל. 

ישי: אז לפני שאנחנו צוללים פנימה, בוא נעזור להגדיר, למי שאולי לא מכיר, מה זה  דוג פודינג?

יניב: סבבה, אני לא...אין לי שום בעלות על ה-term, אבל בגדול  דוג פודינג, המשמעות של זה זה להשתמש במוצר שירות חדש שפותח ע"י החברה ולבדוק אותו לפני שהוא זמין לכלל הלקוחות.

ישי: ולמה אנחנו קוראים לזה  דוג פודינג, אוכל לכלבים, היסטורית זה בגלל סביב פרסומות לאוכל לכלבים שהכלבים של המפרסמים היו הראשונים לטעום אותם.

יניב: אם אני מסתכל פה ככה על כמה אנקדוטות של  דוג פודינג שכן זכורות לי מימי Sun. זה אחד, אנחנו מדברים פה על פיתוח של ה-virtual machine. והחלק שהקסים אותי בתהליך הפיתוח זה שהמפתחים כתבו את זה ככה שבעצם הקומפיילר היה בודק את עצמו, ה ahead of time compiler שהיה לנו בתוך ה hot spot implementation, כחלק מתהליך הבנייה, היה בעצם בונה את עצמו ועושה ahead of time compilation. וזה היה milestone מאוד מאוד חשוב, אחרי שעשו פיתוחים בתוך אותו קומפיילר, לראות שבעצם הכל עובד כמו שצריך, אז ככה חוויה ראשונה של דוג פודינג מסאן.

ישי: הקומפיילר מקמפל את עצמו לתוך ה-VM.

יניב: כן, עושה בעצם "אהד אוף טיים קומפיליישן".

(מוסיקת מעבר)

ישי: אז אולי נתחיל באיך אני כמנהל מזהה את ההזדמנויות, איך אני מוצא מתי כדאי ואיך נכון לעשות דוג פודינג למוצרים שאני בונה.

יניב: שאלה טובה. אלף אני אתחיל מהסוף, אני יודע שעבורי, כשאני הלקוח של המוצר שאני עובד, זה מבחינתי כאילו ה dream job, וזה משהו שלקח לי להגיע יחסית הרבה זמן. בואו באמת נסתכל על שתי דוגמאות אולי שלי שהיו מהעבר, את הדוגמה של סאן ואת הדוגמה של Lightrun ב Sun בעצם. אני חושב שהיה פה טעות, שניסו להכריח ולאנוס את כל הארגון, מדברים על ארגון של עשרות אלפי אנשים להשתמש במוצר שלא עובד, ואם אנחנו באמת לא ה-ICP שלו (ideal customer profile), וגם לא מנסים להקשיב לבעיות של השטח, אז בעצם יש פה lose-lose, כי זה פוגע בפרודקטיביות. ה perception הוא לא טוב, אז אני חושב שדוג פודינג הוא לא אמור להיות בכל מחיר. קודם כל צריך לראות באמת שהמוצר שאנחנו בעצם מפתחים, אנחנו כחברה באמת יכולים להיות ICP רלוונטי ולא לנסות לייצר פה מצב שאנחנו בעצם אונסים את עצמנו להשתמש במוצר רק כדי שזה טוב לנו מסיבות עסקיות או,

"אם אנחנו באמת לא ה-ICP שלו (ideal customer profile), וגם לא מנסים להקשיב לבעיות של השטח, אז בעצם יש פה lose-lose..."

ישי: להגיד שעשינו את זה.

יניב: כן, כחלק מהתהליך של הבדיקות. אז זה פן אחד, לראות שבאמת, לנסות לראות שאנחנו יכולים להיות ICP רלוונטי. 

ישי: הייתי אולי מוסיף לזה, דוג פודינג בעיני זה כשהארגון שמפתח את זה משתמש בזה.

יניב: נכון. 

ישי: לאו דווקא החברה העסקית ש-, בסוף אתם לא פיתחתם את "סטאר אופיס", ולא היה לכם שום השפעה עליו, 

יניב: נכון, נכון.

ישי: אז לפחות ה-core של דוג פודינג זה אומר שמי שמפתח את זה הוא ה-user.

יניב: נכון, באספקטים האלה זה בעצם הכי טוב, אבל קורה מצבים, גם ב JFrog, גם בסאן שמה לעשות, רוצים שתשתמש במוצרים פנימיים, ועשו את זה בצורה אחרת. בארגונים מסוימים ראיתי שעשו את זה בצורה אחרת, שגם אני לא הייתי מי שמפתח אבל היה לי יכולת להשפיע ולתת פידבק, והמטרה היא פה לעשות QA ולעזור לנו כחברה לבדוק את המוצרים יותר טוב, אבל בהחלט. הדוג פודינג האולטימטיבי, לדעתי גם הכי פשוט, זה בעצם שאתה משתמש במוצר שלך. אז זה משהו אחד שהיה חשוב לי להדגיש. דבר שני, דוג פודינג, מהניסיון שלי, יש פה מורכבויות טכנולוגיות, בוא ניקח לדוגמא את לייטרן, מוצר שלנו של לייטרן בעצם מאפשר לדבג אפליקציות חיות היישר מסביבת המפתח ולעדכן אותן עם additional insights, להוסיף לוגים, לקבל סנאפשוטים של מידע, מטריקות וכד'. לעשות עליו  דוג פודינג זה לא פשוט כי בעצם זה מוצר של מפתחים שהוא תוסף שנכנס לתוך ה-IDE ובעצם כדי לדבג את עצמו צריך בעצם לעשות פה איזה משהו טכני שלא יבלבל את המפתח. איך אתה בעצם יכול לדבג את הפלאגין ע"י זה שאתה מכיל עוד דוג פודינג של פלאגין נוסף. 

ישי: אתה מדבג את הפלאגין, תוך כדי שהלקוח שלך מדבג את הקוד שלו.

יניב: כן, זה גם יכול להיות שאני גם מדבג את עצמי, כאילו בתהליך של הפיתוח של איזה פיצ'ר יש לי בעיה שאני לא מצליח לפתור אותה ואני צריך להשתמש בלייטרן כדי לפתור, אז יש פה איזה מן כזה דיבוג כפול כזה וחוויית המשתמש היא לא הכי נוחה. אז אחד מהדברים שכן חשוב, כדי שבאמת  דוג פודינג יצליח, זה לדעת להנגיש את המוצר שלך לעצמך, לפעמים אתה...זה לא פשוט, ואחד הדברים שעשינו ב Lightrun כדי שבאמת יהיה פה adoption מאוד טוב, זה את ה ease of use של הדוג פודינג. בגלל שלדבג את עצמנו זה לא פשוט, קצת קשה לי להסביר את ה details אבל יש לנו פה אתגרים טכנולוגיים, השקענו הרבה שזה יהיה קל ופשוט.

ישי: אז אתה אומר השקעת, בחרת להשקיע ביכולת שבעצם היא לא transferable ללקוחות שלך.

יניב: נכון.

ישי: רק לטובת הדוג פודינג.

יניב: נכון, נכון, שה spinning up של הפתרון שלנו יהיה קל, לדעת להריץ כמה פלאגינים על אותו מחשב, משהו שהלקוחות פחות משתמשים בו, כדי שה ramp up של המפתחים יהיה פשוט. ולקוחות אחרים זה לא, אין צורך, אבל לנו בתור לקוח יש לנו דרישות מיוחדות וכדי להגיע לרמה שבעצם המשתמשים בעצם לא יצטרכו לעשות בויילר פלייט (boilerplate) מאוד מורכב כדי להשתמש בפתרון של עצמנו, אלא יחוו אותו כמו שהם רוצים, ואז בעצם הם ייהנו ממש מהמוצר בקלות, וזה דרש מאמץ. לא פשוט.

ישי: זה מעניין שאתה אומר אני מוכן להשקיע ולבנות משהו שהוא, איזשהו סטארט,

יניב: נכון.

ישי: רק לטובת הדוג פודינג, וזה לא שאני משתמש במוצר as is. 

יניב: נכון, כי הערך של זה הוא כל כך כל כך גדול בהמשך, אז אתה חייב לעשות פה איזה הקרבה ראשונית כי אחרת בעצם זה יפגע ב adoption הפנימי שלו.

"הערך של זה הוא כל כך גדול בהמשך, אז אתה חייב לעשות פה איזה הקרבה ראשונית כי אחרת בעצם זה יפגע ב adoption הפנימי שלו."

(מוסיקת מעבר)

ישי: איך אתם משלבים את הנושא של  דוג פודינג בתהליך של שחרור פיצ'ר, זה בלייף סייקל של יכולות שנבנות?

יניב: יפה. משלבים אותו all over, אולי ניתן טיפה איזה רקע, טיפה על המוצר, ואז בעצם, על ה use cases השונים שלו, ואז בעצם נספר לך בעצם איך זה משתלב בתהליך. אז בגדול Lightrun, מה שהיא יודעת לעשות, זה לחבר בין מפתחים ל-live application, חיבור שהוא לא אך ורק חיבור בצד הפיזי, אלא פשוט לייצר relation עם הקוד שאתה מפתח. ה-use case הכי obvious להסביר אותו זה בעצם use case של troubleshooting. יש לך איזה בעיה, האפליקציה שלך רצה ב production, אין debugger, כי זה אפליקציה שהיא distributed ואתה רוצה, כחלק מתהליך של ההגעה ל-root cause, להוסיף לוגים לקבל ערכים של משתנים וכד'. את כל זה Lightrun יודעת לעשות. אבל Lightrun, אם אני חוזר ל core premise שלה, היא יודעת לחבר בין המפתח ל-live application. אז היא יודעת לעשות הרבה דברים מעבר לזה, היא יודעת לעשות verification לפיצ'ר חדש, יצאת עם פיצ'ר חדש לקנארי (canary), רוצה לראות איך הוא מתנהג? אז אתה יכול להוסיף שמה אינסייטים. יש לך CI שהוא broken ואנחנו יודעים שקשה לדבג הרבה פעמים ב-CI. אז אתה יכול לדבג את זה ב-CI. יש סביבות סטרס, סביבות פרפורמנס שהן מידי פעם אתה מגיע לבעיות ביצועים, אתה יכול לדבג אותם. אז יש לנו המון use cases למוצר. ואחד מהדברים שהחלטנו,  דוג פודינג הוא נמצא anywhere. כי אתה לא יודע איפה תהיה הבעיה הבאה ואיפה הצורך שיהיה. אז בעצם הקמנו סביבה, שהיא סביבה מלאה של Lightrun והיא מסמלצת אותנו כלקוח און פרם (on-prem). לקחנו את עצמנו לאקסטרים, שבעצם אנחנו מאפשרים בעצם להכניס תמיכה של Lightrun לכל האספקטים של ה-software development lifecycle שלנו. זאת אומרת כל הסביבות QA, הסביבות של הפיצ'ר branch שלנו,  דוג פודינג באייג'נטים, בפייפליינים של ה-CICD, יש לנו גם  דוג פודינג, ב-SaaS. כל ה-SaaS שלנו מנוטר, בנוסף המוצר שלנו מכיל כל מיני third-party services, גם להם אנחנו, הרי Lightrun יודעת גם לנטר גם לא רק את המוצר שלנו, גם מוצרי צד שלישי, אז גם להם הכנסנו  דוג פודינג. אז קודם כל המטרה שלנו הייתה לייצר ease of use ושהמוצר, הדוג פודינג שלנו יהיה widely widely spread across כל מה שאנחנו משתמשים ביום יום, כחלק מתהליך הפיתוח והניטור של התקלות. אז זה דבר אחד, הדבר השני, מבחינת ה-software development lifecycle, בתהליך השחרור של הגרסה יש לנו כל מיני מיילסטונים, אנחנו כל פעם מייעלים ומשפרים אותם, אבל יש לנו בעצם תהליך של code freezing לפני גרסת מיינור, ואז אנחנו בעצם מעדכנים את סביבות הסטייג'ינג שלנו, בודקים אותם, ולפני שדרוג הלקוח שהוא ה-P0. ממש הגרסה כבר אמורה לצאת, זה בעצם לשדרג את הדוג פוד, כאילו זה מיילסטון משמעותי, לא הגיוני במיינדסט שלנו שהגרסה החדשה תפגוש לקוח חיצוני לפני שהיא פוגשת את עצמנו, אז בעצם זה משהו שהוא מיילסטון חשוב.

ישי: אז בעצם כל גרסה יש לה שלב שבו היא רצה ללקוח הראשון שזה הדוג פוד environment,

יניב: ואז היא יוצאת ל-, בדיוק, לשאר הלקוחות. ואנחנו יודעים את זה, אין מה לעשות, הרבה פעמים אנחנו בודקים טוב מאוד regression, functional testing, אבל מה לעשות, המיגרציה נדפקה ותהליכים כאלה, זה עוזר לך למנוע באמת מצבים של פדיחות של בעיות migration וכד', וזה הציל אותנו לא מעט פעמים שבעצם הדוג פוד שימש אותנו פנימית.

ישי: כן, אנחנו, אם אני אשתף קצת ב-LinearB, עושים  דוג פודינג כל הזמן למוצר וכמעט כל פיצ'ר יש לו לייף סייקל משלו. זאת אומרת אנחנו עושים רול-אאוט לפיצ'רים עם פי'צר פלגס (feature flags), ויש שלב מוגדר בתהליך של בשלות של פיצ'ר שהוא אומר זה נכנס לדוג פוד, זה לא רק לטובת QA אלא גם אוקיי, פידבק האם זה מועיל, האם הצרכנים, שהם אנחנו, זה יכול להיות מנהל הפיתוח, זה יכול להיות אנשי פרודקט, טים לידרס, מפתחים, איך הם חווים את זה. ובהרבה מקרים אנחנו עושים את זה יחסית מוקדם. את השלב של הדוג פודינג, הפידבק מהיוזרים האלה, שזה אנחנו, משנה את הפי'צר ואת התפירות האחרונות של המוצר ושל החוויה, כי בסוף היוזרים שלנו זה מפתחים, אז אני רוצה מפתחים שיתנו לי פידבק. אח"כ זה הולך ל-early access לכמה לקוחות, וגם שם יש פידבק סייקל, אבל כל פיצ'ר יש לו שלב שהוא מוגדר ואנשי הסיילס מכירים אותו, אה, הפיצ'ר הזה כבר בדוג פוד, הפיצ'ר הזה עוד מעט מגיע, וזה מאוד משרת אותנו בהבנה של אוקיי, ככה צריך לבנות את זה. 

יניב: מסכים לחלוטין. אז זה לגבי ה-SDLC שלנו, איך אנחנו משלבים, אבל באמת אני רוצה קצת לדבר על השימוש היום יומי והאימפקט של המפתחים. עשינו תהליך השקעה מאוד גדולה מבחינתו, פנימית, באמת להטמיע את הסביבה הזאת across the board, וגם בעצם להנגיש אותה כמה  שיותר, ובעצם משם החלטנו באמת לעשות תהליך של שימוש ואדופשיין יום יומי, אנחנו מדברים פה על מוצר שהוא קטגוריה חדשה, ואחד מהאתגרים הגדולים זה בעצם לשנות הרגלים. אנשים לא קל להם לשנות הרגלים, וגם לנו היה בהתחלה קשה, והיום כבר אנחנו רואים שזה בעצם כבר ה-DNA שלנו משתנה ואנחנו משתמשים באמת כמו הלקוחות ה-widely used שלנו, ועשינו כמה דברים בדרך. אז אחד, החלטנו שזה משהו שאנחנו באמת רוצים לעשות לו embrace מאוד חזק בתוך הארגון והחלטתי שכדי לעשות את זה אנחנו צריכים באמת כמה צ'מפיונים מבפנים, באמת שיעזרו לייצר early adoption ואת המיינדסט שיפט, קראנו להם Dog Fathers. מכל צוות יש לנו נציגים, נציג אחד שאנחנו, אני מקיים איתם שיחת weekly, שהמטרה היא בעצם אנחנו עוברים על ה-usage השבועי, הכל אצלנו כמובן מנוטר, ומפיקים באמת, מסתכלים על הדברים שעולים מהשטח. זאת אומרת גם מה-usage מהאנליטיקס, גם יש לנו בעצם פידבקים שעולים מהג'ירות (JIRA), והמטרה היא, מעבר לשימוש, בעצם לעשות bottom up ל surface של innovation feature שעולים, והדבר הכי כיף זה בעצם הישיבות האלה שמזקקים את הרעיונות ולתת למפתחים אח"כ, שהציעו את הרעיונות, לבוא ולעבוד על פיצ'רים. ויש כמה דוגמאות דווקא בגרסה האחרונה שהוצאנו שבאמת תולדה מאינפוטים שהגיעו מה-day by day usage של המוצר. 

ישי: אז נגעת פה קודם כל בשאלת המדידה, אני מניח שזה אותה מדידה שאתם עושים ללקוחות שלכם.

יניב: אותו הדבר לחלוטין, זאת אומרת יש לנו את ה-,

ישי: אותם מטריקות ו-goals שה-customer success מפעיל, 

יניב: הדוג פוד הוא כמו...

ישי: עוד לקוח.

יניב: כמו לקוח נוסף, כל הניטור שיש ללקוח רגיל, יש לדוג פוד. 

ישי: אולי רעיון, אני לא יודע אם אתם עושים את זה, זה לא תמיד טריוויאלי, אבל מעניין להפעיל על הלקוח האפס הזה גם את customer success. זאת אומרת יש מעין customer success manager שינהל את אותו קיידנס מול הלקוח הזה, זה יכול להיות מעניין.

יניב: נכון.

ישי: זה מייצר עוד ציר. והדבר השני שהעלית, זה בעצם ייזום של פיצ'רים ושל יכולות או הצפה של גאפים, מתוך הקבוצת יוזרים הזאת, שהם יכולים גם על הדרך לדעת אוקיי, אני כבר יודע איך לממש את ה-, איך לפתור לעצמי את הבעיה.

יניב: נכון.

ישי: אז אתם מצליחים באמת לייצר עוד ערוץ של אינפוט לפרודקט בעצם?

יניב: בוודאי, בוודאי. 

ישי: מה זה עושה למפתחים, היכולת שלהם להשפיע ככה?

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

(מוסיקת מעבר)

ישי: אז אני רוצה לחפור קצת על העולם של המפתחים, על ה-developer experience, כשהם יכולים ומצליחים באופן שיטתי לעבוד עם המוצר שהם בונים ולעשות  דוג פודינג. אני ראיתי ואני רואה איך זה עוזר ומשפיע על תהליך הגיוס, אתה גם הזכרת. איפה עוד אתה רואה את ההשפעה של זה על המפתחים? את ה-benefit, או אולי הפוך, שהעובדה שהם צריכים, נאלצים, יכולים, לעבוד עם המוצר שהם בונים, איך זה משפיע עליהם על היום יום ועל החוויה שלהם כמפתחים?

יניב: זה משפיע בהמון רבדים. אלף, מחבר אותם למוצר, דבר שני, זה פותח לנו את העיניים ל-use cases חדשים, אולי בהמשך אני אספר לך על כל מיני בעיות, אבל זה בעצם המוצר שלנו הוא מאוד בסיסי מבחינת היכולות, אבל עליו אפשר לייצר כל מיני use cases ומספר use cases הגיעו מהמפתחים עצמם.

ישי: זה benefit לחברה, מה זה עושה למפתח? שה-use case הזה מגיע ממנו?

יניב: המון גאווה, דחפתי אינוביישן, אני חושב שהתפקיד שלי בתור מפתח זה ליצור, ופה אני באמת יוצר אינוביישן עסקי עם ערך אמיתי, אז זה פן אחד. דבר נוסף, תראה, מפתחים, אחד הדברים שאתה רואה, שהם לא תמיד יודעים לחבר את הפוקוס של מה שהם עובדים, את הפריוריטי של מה שהם עובדים, לפוקוס הארגוני. ודרך ה דוג פודינג ודברים שעולים, הם באמת יודעים להבדיל בין עיקר לטפל, ולתעדף נכון את המשימות שלהם. אז זה משהו נוסף שאני רואה, וגם שגרירים טובים, מספרים לחברים, כאילו. once אתה באמת משתמש במוצר שלך וזה עובד, אתה הולך ומספר לחברים, ולא מעט מההזדמנויות העסקיות שלנו מגיעות באמת גם מהמפתחים עצמם שנפגשים ועושים bottom up spread של הפתרון שלהם.

ישי: כן, אני ראיתי גם אמפתיה עם הלקוח.

יניב: נכון.

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

יניב: אני מסכים, ואפילו יש לי איזה כמה דוגמאות קונקרטיות, זאת אומרת הוצאנו לפני שבוע גרסה, גרסה חדשה של המוצר, ועם הרבה מאוד דגש ל-dev experience ובקשות שעלו מהלקוחות. והיו לא מעט בעיות ו enhancements שפיתחנו שגם הגיעו מלקוחות וגם חווינו אותם ב"דוג פוד", כאילו עצמנו. זה גורם לאמפתיה הרבה יותר גדולה כי חלק מהבעיות, אני זוכר הגענו, ראינו אותם ב"דוג פוד" רק אח"כ, ואז כאילו הפריוריטי שלהם הוא לא היה ממש גדול, אבל ברגע שהמפתח גם חווה אותו על בשרו, זה באמת גרם לו לחיבור הרבה יותר משמעותי גם לבוא עם פתרון יותר טוב, אז definitely, זה מאוד עוזר. פה במקרה הזה יש כמה דוגמאות קונקרטיות, אבל לא צריך לצלול אליהן, אבל זה באמת ראינו את זה בגרסה האחרונה שלנו. 

ישי: אני חושב שעוד אתגר שהוא נכון לחברות בכלל, הוא נכון לארגוני פיתוח בפרט, החיבור הזה של ה-why, למה בכלל אנחנו עושים משהו. אני חושב שמפתח או מפתחת לא יכולים לעשות עבודה טובה בלי להבין את ה-why, ויש תמיד אתגר של איך ה-why הזה מחלחל מלמעלה ואיך הקונטקסט הזה, איפה הפריוריטיס של החברה, למה אנחנו עושים מה שאנחנו עושים, כשהמפתחים חווים את ה-usage בעצמם, הם היוזרים, 

יניב: נכון.

ישי: הם מבינים את ה-why בצורה שאי אפשר, אי אפשר להתחרות בה. 

יניב: נכון מאוד. 

ישי: זה, ואני רואה שמפתחים שהם מחוברים ל-why הם מפתחים יותר שמחים, יותר פרודוקטיביים, יותר שמחים, יותר מחוברים, כל הדברים האלה בסוף בעיניים שלי משליכים על ה-developer experience באופן הכי ישיר שיש. 

יניב: אני מסכים, בגלל זה גם אני חוזר למה שאמרתי אפילו עליי. שבאמת אני הגעתי למסקנה יחסית אחרי הרבה זמן, חברות שבאמת אני יכול לעשות  דוג פודינג אמיתי, זה המקום שלי הכי מתאים, וגם אני חושב שאני מחפש אנשים כאלה, כי אז באמת אני מאוד מחובר ל-why ויש לי באמת אפשרות להשפיע בצורה מאוד משמעותית על הפרודקט vision, על ה direction וכד', אז באמת כאילו זה האספקט הזה שבאמת מגיע מדוג פודינג.

ישי: אני רוצה לשאול אותך על קצת מעבר לארגון הפיתוח. 

יניב: כן.

ישי: בחברות שבונות מוצרים למפתחים או לתהליכי פיתוח, במקרה הזה גם Lightrun, גם LinearB, אנחנו בספייס הזה אז קל לעשות  דוג פודינג. איך זה משפיע על אנשים שהם בדיסציפלינות ליד, למשל אנשי פרודקט, אפילו אנשי מכירות, customer success. יש איזה השפעה של, כאילו אנחנו מוכרים לארגוני פיתוח אז נבחר אנשים עם רקע מסוים, אנשים שיודעים להעריך את הדוג פודינג הזה או להשתמש בו אפילו. איפה ראית שזה גולש מעבר לפיתוח?

יניב: תראה, אצלנו זה גולש בכמה רבדים, אחד, אנחנו מצפים שכל מי שעובד ב Lightrun לפחות בשלב הזה, ידע להבין את הערך של המוצר. ובתפקידים שהם יותר קרובים במעטפת, אחד מה-, ככה בשלבים בריאיון, זה בוא, תתקין, תנסה ותראה שאתה מצליח. ואנחנו מחפשים את האנשים עם הסקיל סט, אוקיי? אומנם אתה לא תפתח או אומנם לא תהיה משתמש, אבל לפחות תבין את הערך של המוצר ותעבור את הדרך חתחתים ותתקין אותו, אז אנשי פרודקט שאנחנו מראיינים, אנשי support, אפילו אנשי SE, עוברים את הדרך הזאת. אז זה ברובד אחד. ברובד אחר, תראה, אנשים, זה מפתיע, ולא מפתיע, אבל במוצרים כאלה טכנולוגיים הלקוחות שלך, אחת מהשאלות הראשונות ששואלים, אתם עושים  דוג פודינג? כאילו זאת אומרת זה אחת השאלות שלא מעט פעמים, אני כשאני עולה לשיחות, וכמובן אנשי מכירות, זה בעצם העדות שלך עצמך היא מאוד חשובה, ואנחנו מאוד גאים במה שאנחנו עושים, אנחנו גם מראים את זה בדמואים, אוקיי? זאת אומרת ללקוחות, כן, אנחנו עושים והנה, תראו איך זה נראה אצלנו, גם זה מאפשר לך, לאיש מכירות, ל-SE, גם להראות איך בונים מערכת נכון, איך אתה עושה את ההגדרה שלה נכונה. אז כן, זה פילוסופיה שהיא מאוד קריטית, בטח ובטח לגוף הפיתוח, אבל יש לה גם השפעה למעגלים הרחבים, והדוג פודינג הוא משתמשים בו כמוצר פרסונות אחרות. 

ישי: אצלנו אנחנו לקחנו את זה עוד צעד ואיפה שאנחנו יכולים, ומשתדלים שזה יקרה הרבה, required background של אנשים בארגון הפרודקט, בארגון ה-customer success, אפילו במכירות, זה שיש לך עבר כמפתח.

יניב: נכון. גם אצלנו.

ישי: כלומר אתה מכיר, אתה חיית את החיים האלה, גם אם זה בסוף לא הקריירה שבחרת, זה חלק מה-required skills, וזה, אנחנו רואים שזה עושה הבדל, שוב, באמפתיה וביכולת להבין את המוצר. המקום השני, אנחנו, מוצר SaaS, הדמו שלנו, שאיתו אנשי המכירות עושים דמו ללקוחות, זה תמיד לייב וזה תמיד על הפרודקשיין של הדוג פודינג. זאת אומרת, LinearB על LinearB, זה אומר שבתחילת הדמו הוא לא יודע מה הוא יראה, זאת אומרת אולי הוא בדק כמה דקות לפני, אבל זה לייב דאטה של מה שקורה אצלנו היום, ואם הפיתוח שלנו מתנהג בצורה קצת שונה היום אז הדאטה ייראה אחרת. וכולם רגילים לעבוד עם הדמו environment הזה. ואז זה מייצר בעיה בצד השני של דוג פוד של רגע, יש נגיד פיצ'ר שהגיע לשלב ה-דוג פוד והוא עדיין לא לגמרי בשל וצריך לראות ׳רגע איך זה לא דופק את הדמו?׳. כי עכשיו אנשי מכירות שעוד לא עברו טריינינג על הפיצ'ר הזה, פתאום רואים אותו ופתאום צריכים להדגים ואולי הוא לא 100% מוכן לרמה שאתה רוצה לדמו. אז זה אתגר מהצד השני, אבל אנחנו מתייחסים גם בצד הזה של מכירות לדוג פוד, כלומר אם הנה, LinearB, LinearB, בלי, בלי הסתרות, זה מה שאתה רואה, זה מה שיש בדמו. 

יניב: הכי אותנטי, הכי אמיתי, וכשאתה באמת כאילו, באמת מציג איך אתה בתור לקוח, אז יש פה…אנחנו בסופו של דבר מאוד ביקורתיים כלפי עצמנו, ככה אני רואה את זה, ואם הצלחנו לשכנע את עצמנו שזה עובד, אז יש פה, סיכוי טוב שיש פה משהו אמיתי. אבל זה ללא ספק גורם לאתגרים. ללא ספק, גם אני מבין את האתגרים שאתה אומר, כדי להשתמש בזה ולהטמיע בזה צריך כאילו מאמץ שהוא מעבר של מאמץ של לקוח אחר שמשתמש בזה. 

ישי: מעניין אותי איך אתה מתמודד או מציע להתמודד עם נגיד רמות שונות של  דוג פודינג או כיסים של  דוג פודינג, לתת דוגמה לאתגר שאנחנו חווים, אבל בטח קיים בעוד מקומות. הזכרת תמיכה ב-IDEs, משהו ש Lightrun נותנים, יש בסוף כמה IDEs שונים ואולי ארגון הפיתוח שלך אוהב לעבוד עם VSCode. אז רמת ה דוג פודינג לתמיכה ב IntelliJ תהיה מאוד נמוכה כי אתה לא עכשיו תתחיל מלאכותית, תגיד טוב, 10 אנשים עובדים IntelliJ רק בשביל ה דוג פודינג, הרי בעולם שלנו יש לנו תמיכה ב Slack וגם ב-MS Teams, אנחנו פנימית עובדים עם Slack, אז כמעט by definition, הרמה של ה דוג פודינג ואני הייתי אומר אפילו כנ"ל גם הרמת בשלות או תמיכה של פיצ'רים ב-MS Teams היא טקט אחד אחרי, כי אנחנו לא חיים את זה, אז יותר קשה לנו לתמוך, יותר קשה לנו לעשות  דוג פודינג. איך ניגשים לשאלות האלה? בסוף מוצר מורכב יש לו כל מיני, לא תצטרך להשתמש בהכל כל הזמן.

יניב: אז הגישה שלי תהיה אותנטית.

ישי: אתה חוזר ל Sun.

יניב: כן, זה חוזר ל Sun, זאת אומרת אל תייצר מצב, בוא ניקח את זה לאקסטרים, שבגלל שאנחנו רוצים שהדוג פוד יעבוד, תכריח את הצוות הירוק להשתמש בסלק, והצוות הכחול ב-MS Team, למה? כי זה נוח לנו להשתמש בהם כשפני ניסיון של הפיצ'ר, לא, LinearB צריכה להמשיך לעבוד, הארגון פיתוח, כמו שהם עובדים, ולשלב בעצם את Linear -B המוצר על בסיס ה deployment שיש, ככה אנחנו עושים את זה בLightrun. use case הנוספים, ה-capabilities, התמיכה ב-IDEs,  runtimes שונים, שהם לא נתמכים אצלנו, זה בעצם נבדק כחלק מה-QA, אבל תשקיע את המאמצים להטמיע את מה שאתה יכול ורלוונטי לארגון, כחלק מה"דוג פוד". זה ה-,

ישי: אני אהבתי את הגישה של ה-תהיה אותנטי, אני חושב שבאופן כללי, ומפתחים יש להם אלרגיה לדברים שהם לא אותנטיים, 

יניב: נכון.

ישי: וכשאתה מנסה לעשות משהו ככה שהוא לא באמת דוג פוד זאת אומרת "דוג פוד" תבוא, צריך לבוא רעב, ואתה אוכל את הדוג פוד רק בשביל לטעום, בשביל QA? זה not good enough.

יניב: נכון.

ישי: צריך להיות לשימוש, לא רק ל-QA. ואולי לפעמים אפשר לגשר על הפער ב-, טוב, בוא תמצא כמה לקוחות friendlies או חברות קרובות אפילו שלא ישלמו, והם יהיו ה dog fooders שלך ל footprints שאתה לא חי אותם. ששם הם יהיו אותנטיים, ותייצר איתם את המערכת יחסים שהם יוכלו לתת לך את ה דוג פודינג experience אומנם קצת מבחוץ, אבל שלא תהיה עיוור לאזורים האלה ותעשה טוב, יש לי רק QA וכמו שתיארת, נגיד בנייס או בחברה שאין שום קשר בין החוויה שלך לחוויה של הלקוח. 

(מוסיקת מעבר)

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

יניב: אוקיי, אז הייתי מתחיל קודם כל בלנסות להבין אם אני מנהל מוצר בחברה שהמוצר שאני מפתח הוא רלוונטי, אליי כחברה, בעצם אם אנחנו ICP כן או לא, ideal customer profile. במידה ואנחנו לא ideal customer profile והמפתחים שלי הם לא יוזרים של המוצר, אין טעם להשקיע ב דוג פודינג.

ישי: אתה חוזר לאותנטיות.

יניב: כן, חוזר בהחלט לאותנטיות. במידה וכן אז צריך להבין שזה פרויקט, זה פרויקט שהוא כמו כל פרויקט, יש פה השקעה בהתחלה. ובאמת צריך להבין, זה תלוי במוצר, יש פה רמת הרכבה, מורכבות שיכולה להיות בהנגשה שלו, ב deployment שלו, ובכלל יש מוצרים שהם דורשים גם שינוי של state of mind והתנהלות, אז יש פה באמת תהליך של adoption של המוצר.

ישי: מה גם שכל אחד מהלקוחות שלך יצטרך לעבור, אז אתה לומד גם את זה משם.

יניב: בדיוק, אתה לומד מזה. תנסה לזהות צ'מפיונים מתוך הארגון.

ישי: אהבתי את השם הזה Dog Fathers, זה מעולה.

יניב: כן, צ'מפיונים בתוך הארגון שבעצם יעזרו לך לדחוף אותו bottom up, לעשות לזה embrace להצלחות, לדוגמה לנו היו כמה אירועים משמעותיים מאוד לאחרונה שאנחנו עושים עליהם סשנים מיוחד ברמת מאוד גדולה, כי הפקנו הרבה מאוד תובנות, הרבה רעיונות, באמת לעשות embrace, כדי שבאמת הדבר הזה יהיה מוטמע ביום יום, ואני מאוד ממליץ.

ישי: יש לדעתך זמן מוקדם מידי? או שהיית אומר זה, אם אפשר מ-day zero להתחיל עם...

יניב: כמה שיותר...כמה שיותר מוקדם. ברגע שיש לך, אני חושב, ברגע שאתה כבר מוכר את המוצר ואתה בפוטנציאל ICP, אתה צריך להיות ה-P0, ה-customer zero.

ישי: מעולה. יניב, תודה רבה שבאת.

יניב: תודה לכם.

ישי: היה מצוין.

יניב: יופי.

(מוסיקת מעבר)

** לינקים לקהילות שהוזכרו בפרק - כאן.**

Yishai:         Welcome to “Dev Interrupted", LinearB's podcast which discusses everything that hinders the daily work of engineering managers. I'm Yishai Beeri, CTO at LinearB. We are happy to bring you the podcast in Hebrew where we host leaders in the industry to talk about everything that interests engineering managers, those who work with them, and those who want to one day manage an engineering organization.

In this episode, we are happy to host Eti Dahan Noked, engineering manager at Wilco. Hi Eti, how are you?

Yishai: In this episode I am happy to host Yaniv Shani, VP R&D at Lightrun, hello Yaniv.

Yaniv: Hey, what's up?

Yishai: What fun you came at short notice, you delivered!

Yaniv: Fun, fun.

Yishai: And today we will talk about dogfooding. Before that I want you to tell me a little about yourself, how you got this far, a few words about your career so far, and then we'll dive in. 

Yaniv: How fun. I'll tell you about my career and I'll also put in a little, as a trigger for the conversation, some interface points of dogfooding during the process. 

Yishai: Go for it.

Yaniv: So basically I've been in the industry for 25 years, I studied at Reichman University (in the precasts), and at the very beginning, at the end of the first year of studies, that's how I started working in the industry. My first position was at a company called VCON, a company that actually developed Polycom style "video conferencing" systems and the large systems that we used to see in meeting rooms, which today no longer exist, and I specialized in the field of voice over IP, a lot of communication, a lot of image processing, and I think its name. Actually, if I look at it in the context of the conversation, for the first time I actually experienced a product and the first aspects of dogfooding. I really believed in the field of video conferencing, I was sure that it was the next thing in communication, and later on, and we may come back to it later, as a user, who started using it not only as a developer, just doing tests that the communication works and watching video, but really as a real user who tries make a call, I realized that something is not working.

Yishai: It took about 20 years...

Yaniv: Yes, it took about 20 years, I think the two main problems I felt is that the conversations are set up, these conversations require a very high emotional involvement, you can't talk about this about this and that. Heavy conversations, and there was no eye contact in these devices either. I think we fixed it with the laptops, we also fixed it with the accessibility of things and the ease of setting up, but to me it's basically like this, a first anecdote about dogfooding and we'll touch on that later. After 8 years at VCON, I made a shift to another domain. I joined the development center of Sun Microsystems, a company that was a leader at the time, today it has unfortunately already been swallowed up by Oracle for the Java body. Actually, here in Israel we developed virtual machine solutions, and I actually entered the field of Java for Mobile, what used to be called J2ME, and I led projects of implementing the virtual machine to the devices of the manufacturers. A position I held for 8 years, a company I worked for 8 years, and eventually I led the development, a global development body that was responsible for actually developing and implementing the Java virtual machine for mobile. 

Yishai: So before we dive in, let's help define, for those who may not know, what dogfooding is?

Yaniv: Okay, I don't...I don't have any ownership of the term, but in general dogfooding, the meaning of this is to use a new service product developed by the company and test it before it is available to all customers.

Yishai: And why do we call it dogfooding, dog food, historically - because of advertisements for dog food that the advertisers' dogs were the first to taste.

Yaniv: If I look, here, at some dogfooding anecdotes I do remember from my Sun days. This is one, we are talking about the development of the virtual machine. And the part that intrigued me in the development process is that the developers wrote it in such a way that the compiler would actually check itself, the ahead of time compiler that we had in the hotspot implementation, as part of the compilation process, would actually build itself and do ahead of time compilation. And it was a very, very important milestone, after developing within the same compiler, to see that basically everything works as it should, so that was my first experience of dogfooding from Sun.

Yishai: The compiler compiles itself into the VM.

Yaniv: Yes, actually doing a ahead of time compilation.

(transitional music)

Yishai: So maybe we'll start with how I, as a manager, identify the opportunities, how I find when it's worthwhile and when it's right to dogfood the products I'm building.

Yaniv: Good question. First, I'll start from the end. I know that for me, when I'm the customer of the product I'm working on, it's like my dream job, and that’s a conclusion that took me a relatively long time to reach. Let's really look at two examples that are mine from the past, the example of Sun and the example of Lightrun at Sun actually. I think there was a mistake here, that they tried to force the entire organization, we are talking about an organization of tens of thousands of people to use a product that doesn't work, and if we really are not the ICP (ideal customer profile), nor did they try to listen to the problems bottom up. There it was a lose-lose situation, because it hurts productivity. The perception is not good, so I think that dogfooding should not be at all costs. First of all, we need to really see that the product we are actually developing, we as a company can really be a relevant ICP and not try to create a situation where we actually force ourselves to use the product just so that it is good for us for business reasons or,

"I think that dogfooding should not be at all costs. First of all, we need to really see that we as a company can really be a relevant ICP..."

Yishai: To say that we did it.

Yaniv: Yes, as part of the testing process. So that's one facet, to see that really, to try to see that we can be a relevant ICP. 

Yishai: I would perhaps add to that, dogfooding in my eyes when the organization that develops it uses it.

Yaniv: True. 

Yishai: Not necessarily the business company, in the end you didn't develop "Star Office", and you had no influence over it, 

Yaniv: True, true.

Yishai: So at least the core of dogfooding means that the one who develops it is the user.

Yaniv: True, in these aspects it is actually the best, but situations happen, both at JFrog, and at Sun, for whatever reason, they want you to use internal products, and do it in a different way. In some organizations I saw that they did it in a different way, that I wasn't the developer either but I had the ability to influence and give feedback, and the goal here is to do QA and help us as a company test the products better, but definitely. The ultimate dogfooding, in my opinion is also the simplest, is actually that you use your own product. So that's one thing that was important for me to emphasize. Second thing, dogfooding, from my experience, there are technological complexities here, let's take Lightrun for example, our Lightrun product actually allows you to debug live applications directly from the developer environment and update them with additional insights, add logs, receive snapshots of information, metrics, etc. To dogfood it is not easy because it is actually a product for developers which is a plugin that goes into the IDE, and actually in order to debug itself you have to do something technical here in order to not confuse the developer. How can you actually debug the plug-in by the fact that you integrate the dogfooding through another plug-in. 

Yishai: You debug the plug-in, while your client debugs his code.

Yaniv: Yes, it could also be that I am also debugging myself, as if in the process of developing some feature I have a problem that I can't solve and I have to use Lightrun to solve it, so there is some kind of double debugging here and the user experience is not the most comfortable. So one of the things is important, for dogfooding to really be successful, is knowing how to make your product accessible to yourself, sometimes you... it's not easy, and one of the things we did at Lightrun so that there would really be very good adoption here, is the ease of use of dogfooding. It's a little difficult for me to explain the details, but we have technological challenges here, we invested a lot to make it easy and simple.

Yishai: So you say you invested, you chose to invest in a capability that is actually not transferable to your customers.

Yaniv: True.

Yishai: Only for the benefit of dogfooding.

Yaniv : True, true, that the spinning up of our solution will be easy, knowing how to run several plugins on the same computer, something that the customers use less, so that the ramp up of the developers will be simple. And other customers are not using, there is no need, but we as a customer have special requirements and in order to reach a level where the users will not actually have to do very complex boilerplate to use our own solution, but will experience it the way they want. And then they will actually really enjoy the product easily, and this required effort. It was not simple.

Yishai: It's interesting that you say I'm ready to invest and build something that is, some kind of start-up,

Yaniv: That's right.

Yishai: Only for the benefit of dogfooding, and it's not that I use the product as is. 

Yaniv: That's right, because the value of this is so so great later on, that you have to make some initial sacrifices here because otherwise it will actually harm its internal adoption.

(Transitional music)

Yishai: How do you integrate the issue of dogfooding into the process of releasing a feature, is it the lifecycle of capabilities that are being built?

Yaniv: Nice one. Integrate it all over, maybe we'll give a little background, a little about the product, and then actually, about its various use cases, and then we'll actually tell you how it fits into the process. So in general, what Lightrun knows how to do is to connect developers to the live application, a connection that is not only a connection on the physical side, but simply to create a relationship with the code you develop. The most obvious use case to explain is actually a troubleshooting use case. You have a problem, your application runs in production, there is no debugger, because it is a distributed application and you want, as part of the process of getting to the root cause, to add logs to receive values ​​of variables, etc. Lightrun knows how to do all this. But Lightrun, if I go back to its core premise, it knows how to connect the developer to the live application. So it knows how to do many things beyond that, it knows how to do verification for a new feature. You “canary rolled out” a new feature, do you want to see how it behaves? Then you can add insights. You have a CI that is broken and we know that it is often difficult to debug CI. So you can debug CI. There are stress environments, performance environments where from time to time you come across performance problems, you can debug them. So we have a lot of use cases for the product. And one of the things we decided, dogfooding is found everywhere. Because you don't know where the next problem will be and where the need will be. So basically we set up an environment, which is a full Lightrun environment and as an on-prem client. We have taken ourselves to the extreme, in that we actually allow Lightrun support to be introduced into all aspects of our software development lifecycle. I mean all the QA environments, the environments of our feature branch, dogfooding in the agents, in the CICD pipelines, we also have dogfooding, in SaaS. All of our SaaS is monitored, in addition our product contains all kinds of third-party services, for which we also, because Lightrun also knows how to monitor not only our product, but also third-party products, so we introduced dogfooding to them as well. So first of all our goal was to produce ease of use so that dogfooding our product, would be widely spread across everything we use on a daily basis, as part of the development process and monitoring of faults. So that's one thing, the other thing, in terms of the software development lifecycle, in the release process of the version we have all kinds of milestones, we optimize and improve them every time, but we actually have a code freezing process before the minor version, and then we actually update the environments. Our staging, checks them, and before upgrading the client which is the P0. Actually, the version is already supposed to be released, it's actually upgraded to dogfood status, as a significant milestone. It doesn't make sense in our mindset that the new version will meet an external customer before it meets ourselves, so actually it's something that's an important milestone.

Yishai: So basically every version has a stage where it runs for the first customer, which is the dog food environment,

Yaniv: …and then it goes out to, exactly, the other customers. And we know it, there's nothing to do, many times we check very well regression, functional testing, but what to do, the migration was screwed up and processes like that, it really helps you prevent situations of failure of migration problems, etc., and it saved us quite a few times actually when dogfooding, and used internally by us.

Yishai: Yes, we, if I will share a bit at LinearB, we are constantly dogfooding the product and almost every feature has its own lifecycle. I mean, we do a roll-out for features with feature flags, and there is a definite stage in the process of maturity of a feature that says it goes into dogfooding, this is not only for the benefit of QA but also okay, feedback is it helpful , are the consumers, which are us, it can be the development manager, it can be product people, team leaders, developers, how do they experience it. And in many cases we do it relatively early. The dogfooding stage, the feedback from these users, which is us, changes the feature and the final stitching of the product and the experience, because in the end our users are developers, so I want developers to give me feedback. Then it goes to early access for some customers, and there is also a feedback cycle there, but each feature has a stage that is defined and the sales people know it, oh, this feature is already in dog food, this feature is coming soon , and it serves us very well in understanding OK, this is how it should be built. 

Yaniv: I completely agree. So it's about our SDLC, how we integrate, but I really want to talk a little about the day-to-day use and the impact on the developers. We made an early and large investment in the process, internally, to really integrate this environment across the board, and actually make it as accessible as possible. And actually from there we decided to really do a process of daily use and adoption, we are talking here about a product that is a new category, and one of the big challenges is actually to change habits. It's not easy for people to change habits, and it was hard for us at first too, and today we already see that it's actually our DNA changing and we really use it like our widely used customers, and we did a few things along the way. So first, we decided that this is something we really want to embrace strongly within the organization and I decided that in order to do this we really need some champions from within, who will really help produce early adoption and the mindset shift, we called them Dog Fathers. We have representatives from each team, one representative that we hold a weekly conversation with, the purpose of which is basically we go over the weekly usage, everything is monitored with us of course, and we are really productive, looking at the things that come up from the field. I mean also from the usage from the analytics, we also actually have feedbacks that come up from the JIRAs, and the goal is, beyond the use, to actually bring bottom up to surface innovation features that come up, and the most fun thing is actually these meetings that distill the ideas and give the developers then, who proposed the ideas, time to work on these features. There are some examples in the latest version that we released that really resulted from inputs that came from the day by day usage of the product. 

Yishai: So you first touched on the question of measurement here, I assume it's the same measurement that you do to your customers.

Yaniv: Exactly the same, I mean we have the,

Yishai: same tactics and goals that customer success activates, 

Yaniv: dog food is like...

Yishai: Another customer.

Yaniv: Like another customer, all the same monitoring that a regular customer has, the dogfooding has. 

Yishai: Maybe an idea, I don't know if you do it, it's not always trivial, but it's interesting to run customer success on customer zero as well. I mean, there's a kind of customer success manager that will manage the same cadence with this client, it could be interesting.

Yaniv: Right.

Yishai: It creates another axis. And the second thing you brought up is actually the initiation of features and capabilities Or flagging gaps, from this group of users, that they can also on the way to know OK, I already know how to realize the, how to solve the problem for myself.

Yaniv: True.

Yishai: So you are actually managing to create another channel of input for the product?

Yaniv: Of course, of course. 

Yishai: What does this do for the developers, their ability to influence like this?

Yaniv: So that's amazing. Look, that's one of the things that, first in the recruiting process we’ve talked about. That you really have the opportunity to work on a product that you are also expected to wear the hat of the product, come with the ideas, it's challenging, it connects you. There is the book everyone knows by Marty Cagan. About product, okay, that talks about... that you want to... in product people, product people who are missionaries, not mercenaries, and this is where you really create the real connection of the developer with the product. I kind of think that it's really the ultimate win-win, and it's fun, like you know, that you're working on a feature that you are, then you get to provide input and feedback for, and it doesn't have to be the most radical thing, but it's things that we don't pay attention to until you actually use the product and you, when you use it as a real customer, you experience it and it gives a significant say here.

(transitional music)

Yishai: So I want to dig a little deeper into the world of developers, about the developer experience, when they can and are systematically successful to work with the product they are building and dogfood it. I have seen, and continue seeing, how it helps and affects the recruitment process, which you also mentioned. Where else do you see the effect of this on the developers? The benefit, or maybe the opposite, that the fact that they need, are forced , to work with the product they are building. How does it affect their day-to-day life and their experience as developers?

Yaniv: It affects a lot of layers. First, it connects them to the product, secondly, it opens our eyes to new use cases, maybe in the future I will tell you about all kinds of problems, but actually our product is very basic in terms of capabilities, but on it you can create all kinds of use cases and a number of use cases came from the developers themselves.

Yishai : It's a benefit to the company, what does it do for the developer? That this use case came from them?

Yaniv: A lot of pride, I push innovation, I think my job as a developer is to create, and here I really create business innovation with real value, so that's one facet. Another thing, look, developers, one of the things you see, is that they don't always know how to connect the focus of what they are working on, the priority of what they are working on, to the organizational focus. And through dogfooding and things that come up, they really know how to differentiate between what is important to take care of, and how to properly prioritize their tasks. So this is something else I see, and good ambassadors also tell friends, like. Once you really use your product and it works, you go and tell your friends, and quite a few of our business opportunities also really come from the developers themselves who meet and do a bottom up spreading of their solution.

"I push innovation, I think my job as a developer is to create, and here I really create business innovation with real value..."

Yishai: Yes, I also saw empathy with the customer.

Yaniv: True.

Yishai: It is difficult to reach them in any other way, the developers in many cases have to support the customers, directly or indirectly, and, while I am working on a feature, my empathy, my thinking about the user, since I am the user, is on a completely different level . And developers, even those who like to think of themselves, I'm only technical and I'm not interested in business and I'm not interested in people, even these extreme cases, in the end they do care, and when they see, when they built something and they use it, then they also have the achievement of voila , I built something and it lives in production and has usage, for example. Me, I really enjoy what I've built, I see the same with me in the past, I completely agree that it makes a fundamental difference for developers.

Yaniv: I agree, and I even have some concrete examples, I mean we released a version a week ago, a new version of the product, with a lot of emphasis on dev experience and requests that came from the customers. And there were quite a few problems and enhancements that we developed that both came from customers and we experienced them at dogfooding, ourselves. It causes much greater empathy because some of the problems, I remember we arrived, we saw them in the dogfooding only later, and then their priority was not really high, but once the developer also experienced it first hand, it really made them connect. It is also much more significant to come up with a better solution, so definitely, it is very helpful. Here in this case there are some concrete examples, but we don't need to dive into them, but we really saw it in our latest version. 

Yishai: I think another challenge that is true for companies In general, it is true for development organizations in particular, this connection of the why, why do we do something at all. I think that a developer cannot do a good job without understanding the why, and there is always a challenge of how this “why” permeates from above and how. This context, where are the company's priorities, why do we do what we do, when the developers experience the usage themselves, they are the innovators, 

Yaniv: True.

Yishai: They understand the why in a way that you cannot compete with. 

Yaniv: True 

Yishai: …and I see that developers who are connected to the why are happier developers, more productive, happier and more connected, all these things in the end, in my eyes, affect the developer experience in the most direct way there is. 

Yaniv: I agree, that's why I’ll also go back to what I said even about myself. That I really came to the conclusion relatively after a long time, at companies that I can really dogfood properly, this is the most suitable place for me, and I also think that I am looking for such people, because then I am really very connected to the why and I really have the possibility to have a very significant influence on the product vision, about the direction, etc., so it's really like this aspect that really comes from dogfooding.

Yishai: I want to ask you about - a little more about the engineering  organization. 

Yaniv: Yes.

Yishai: In companies that build products for developers or engineering processes, in this case also Lightrun, also LinearB, we are in this space so it's easy to dogfood. How does this affect people who are in adjacent disciplines, for example product people, even sales people, customer success. There is some effect of, as if we sell to an engineering organization, so we choose people with a certain background, people who know how to appreciate this dogfooding or even use it. Where did you see this expand beyond the engineering team?

Yaniv: Look, for us it goes through several layers, one, we expect that everyone who works at Lightrun at least at this stage, knows how to understand the value of the product. And in positions that are more adjacent disciplines, even in the interview stages, we ask them to install, try and see if you succeed. And we're looking for the people with that skill set, okay? It is true that you will not write code or you will not be a user, but at least you will understand the value of the product and go through the process of installing it, so product people we interview, support people, even SE people, go through this path. So that’s one layer. On another level, look, people, it's surprising, and not surprising, but with such technological products, your customers, one of the first questions they ask, do you dogfood? As if to say this is one of the questions quite a few times, when I get on calls, and of course sales people, it's actually your testimony yourself that is very important, and we are very proud of what we do, we also show it in the demos, okay? I mean to the customers, yes, we do and here, look how it looks with us, it also allows you, a salesperson, SE, to also show how to build a system correctly, how to define it correctly. So yes, it is a philosophy that is very critical, certainly for the engineering body, but it also has an effect on the wider circles, and dogfooding is used as a product of other personas. 

Yishai: We have taken it a step further where we can, and we try to make it happen as often as possible where we require an engineering background from people in the product organization, or in the customer success organization, even in sales, that you have an engineering past is key.

Yaniv: True. Here, too.

Yishai: I mean you know, you lived this life, even if in the end it's not the career you chose, it's part of the required skills, and we see that it makes a difference, again, in empathy and the ability to understand the product. A second area for us as a SaaS product is our demo. When the sales people do a demo for customers, it is always live and it's always on the dogfooding production. I mean, LinearB on LinearB, it means that at the beginning of the demo they don’t know what they will see, I mean maybe they checked a few minutes before, but this is live data of what is happening with us today, and if our development behaves a little differently today then the data will look different. And everyone is used to working with this demo environment. And then it creates a problem on the other side of the dogfood if for a time, there is, say, a feature that has reached the dogfood stage and it is not yet fully mature and you have to see 'Wait, how does it not screw up the demo?'. Because now salespeople who have not yet been trained on this feature, suddenly see it and suddenly have to demonstrate it and maybe it is not 100% ready for the level you want to demo. So it's a challenge from the other side, but we also refer to this side of sales for dogfood, meaning where here, LinearB is using LinearB, with full transparency, this is what you see, this is what is in the demo. 

Yaniv: The most authentic, the most genuine, and when you really, like, really present how you are as a customer, then there is a point...we are ultimately very critical of ourselves, that's how I see it, and if we managed to convince ourselves that it works, then there is a point, there's a good chance there's something real here. But this undoubtedly causes challenges. Undoubtedly, I also understand the challenges you say, to use it and integrate it requires an effort that is a transition of the effort of another customer who uses it. 

Yishai: I'm interested in how you deal with or propose to deal with, say, different levels of dogfooding or pockets of dogfooding, to give an example of a challenge we experience, but it probably exists in other places. You mentioned support for IDEs, something that Lightrun provides, there are a few different IDEs out there and maybe your development organization likes to work with VSCode. So the level of dogfooding to support IntelliJ will be very low because you will not now start artificially, say well, 10 people work on IntelliJ just for dogfooding, in our product we have support for Slack and MS Teams, we internally work with Slack , so almost by definition, dogfooding and I would say even raising the maturity or support of features in MS Teams is one step after, because we don't live it, so it's harder for us to support, and even harder for us to dogfood. How do we approach these questions? In the end a complex product has all kinds of integrations, you won't be able to use everything all the time.

Yaniv: So my approach will be authentic.

Yishai: Going back to Sun.

Yaniv: Yes, it goes back to Sun, I mean don't create a situation, let's take it to the extreme, that because we want the dogfood to work, you force the green team to use Slack, and the blue team to MSTeams, why? Because it's convenient for us to use them as test subjects for the feature, no, LinearB should continue to work as the engineering organization regularly works, and actually integrate the LinearB product based on the existing deployment, this is how we do it at Lightrun. The additional use cases, the capabilities, the support for IDEs, various runtimes, which are not supported by us, it is actually tested as part of the QA, but we invest the efforts to integrate what we can and that is relevant to the organization, as part of the dogfood. It's the,..

Yishai: I liked the approach of the be authentic, I think in general, and developers have an allergy to things that are not authentic, 

Yaniv: Right.

Yishai: And when you try to make something so that it's not really dog​​fooding, with dogfooding you have to come hungry, if you’re eating the dogfood just to taste it, for QA? It's not good enough.

Yaniv: True.

Yishai: Should be for use, not just for QA. And maybe sometimes the gap can be bridged by, well, let's find some friendly customers or close companies even if they won't pay, and they will be your dogfooders for footprints that you don't live in your engineering organization. That there they will be authentic, and you will create a relationship with them so that they can give you the dogfooding experience, albeit a bit from the outside, but don't be blind to these areas and say ‘well, I only have QA’ and as you described, say in Nice or in a company that there is no connection between your experience and the experience of the customer. 

(Transitional music)

Yishai: Towards the end, give us your recommendation for a manager in an engineering organization who may not be doing dogfooding today or not enough, how/what, how to start, how to move from zero to one, where it is relevant but there is no such habit or there is no such habit yet. Where to start or how to approach…?

Yaniv: Okay, so I would first start by trying to understand if I am a product manager in a company whose product I am developing is it relevant to me as a company, basically if we are an ICP yes or no–– ideal customer profile. If we are not an ideal customer profile and my developers are not users of the product, there is no point in investing in dogfooding.

Yishai: You return to authenticity.

Yaniv: Yes, definitely returning to authenticity. If so, then you have to understand that this is a project, it is a project that is like any other project, there is an investment here at the beginning. And you really have to understand, it depends on the product, there is a level of assembly, complexity that can be in its accessibility, in its deployment, and in general there are products that also require a change of state of mind and conduct, so there really is a process of product adoption here.

Yishai: What's more, each of your customers will have to go through this too, so you learn that from there as well.

Yaniv: Exactly, you learn from it. Try to identify champions from within the organization.

Yishai: I liked the name Dog Fathers, it's great.

Yaniv: Yes, champions within the organization who will actually help you push it bottom up, help embrace success, for example we had several very significant events recently that we are doing special sessions on at a very wide level, because we generated a lot of insights, a lot of ideas, really to embrace it, so that this thing is really embedded in everyday life, and I highly recommend it.

Yishai: Do you think it's too soon? Or you would say this, if it is possible from day zero to start with...

Yaniv: As soon as possible... as early as possible. Once you have, I think, once you're already selling the product and you're ICP potential, you have to be the P0, the customer zero.

Yishai: Excellent. Yaniv, thank you very much for coming.

Yaniv: Thank you.

Yishai: It was excellent.

Yaniv: Nice.

(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:

• Lightrun
• Marty Cagan: Inspired: How to Create Tech Products Customers Love
• Visual Studio Code
• MS Teams
• Slack