פרק 473 של רברס עם פלטפורמה, שהוקלט ב-27 ביוני 2024 - אורי ורן מארחים את הילה פוקס מ-Forter, כדי לדבר על “איך חושבים מוצרית” לאנשי טכנולוגיה או - איך אנשי טכנולוגיה חושבים (יכולים לחשוב? עלולים לחשוב?) מוצרית.
00:40 הילה והצוות המועצם
- (הילה) אז אני הילה - אני מובילה טכנולוגית, עם מעל עשר שנות ניסיון.
(רן) משום מה, חבריי ב-Augury - לא שיש לי - אבל תמיד אומרים שאתם לא מוכרים, ותמיד כולם מכירים אתכם . . .
סנסורים למנועים, למכונות וכל זה.
- (הילה) נכון, יפה . . . . כן, זו חברה חיפאית, מי בכלל זוכר, מי יודע?
(רן) אולי בגלל ה”חיפה” זה עובד . . . אז יאללה, נרים לכולם. טוב - אז את עובדת ב-Forter עכשיו, כ-Staff Engineer. למה מעניין אותך מוצר? כאילו - את מי זה מעניין? את רק רוצה להעביר ביטים, לא?
- (הילה) אז לא . . . אולי אני אביא את זה קצת גם מתוך הסיפור האישי שלי - כי בתקופה שלי ב-Augury, בעצם אני הגעתי בתור Backend, מפתחת-Backend.
- ולאורך התקופה שלי שם, התפתחתי גם ל-Squad-Lead - ובסופו של דבר לארכיטקטית.
- ואני חושבת שחלק מאוד מהותי מההתפתחות המקצועית שלי בעצם הגיע מתוך הבנה ביזנסית (Business) וחשיבה מוצרית.
- אז אולי זה הדבר הראשון ל”למה אכפת לי אישית מהדבר הזה” - כן, זה מאוד תרם לי לקריירה.
- מעבר לזה שאני מוצאת את זה מאוד מעניין - זה מאוד מחבר אותי לארגון, אני מבינה איך משפיעים.
- אז זה בא לי עם המוטיבציה, זה עוזר לי ל”למה אני קמה בבוקר, למה אני עושה את מה שאני עושה”.
(אורי) אז רגע, רגע . . . אני הקהל, נכון? . . . מתי פגשתי את זה בפעם הראשונה? זאת אומרת, מתי בפעם הראשונה אמרת “אה, רגע! אני מתחילה לחשוב מוצרית! אני . . . “ . . . מה גרם לך להגיע בכלל לאיזור הזה?
(רן) אני אעשה את זה תיאטרלי - “ממחר בבוקר קמים ומתחילים לחשוב מוצרית!”
- (הילה) אני חושבת ש . . . קודם כל, גם ב-Fiverr עובדים כזה מאוד Oriented ללקוחות, כן?
- ועבדתי בצוות Web-י - והיה לנו איש מוצר שהיה ביחד עם הצוות, ואפשר להגיד ששם התהליך קצת התחיל.
- באמת להבין - מה משפיע על הלקוח? מתי זה משפיע על הלקוח?
- אבל אני חושבת שה-Ramp-up האמיתי שלי מסביב לזה היה ב-Augury.
- כש-Augury האמת היא קצת כזה . . . חברה שבשביל אנשי-מוצר היא קצת כזה “חלום רטוב”, כן?
- הם עובדים שם כזה בצורה נורא הוליסטית, יחסית לפרקטיקות של עבודה של אנשי-מוצר.
- אם אתם מכירים את המונח הזה, “Empowered PM” - שמגיע מתוך הדיונים והשיחות של Marty Cagan והמתודולוגיות שהוא מוביל [Product management theater | Marty Cagan (Silicon Valley Product Group)].
- אז בעצם בגלל שהם נורא מאמינים גם ב-”Empowered PMs” ובלתת הרבה כוח לאנשי מוצר להוביל את הצוותים שלהם, זה גם נורא התחבר לזה שהאנשים הטכנולוגיים צריכים להיות חלק מזה בסופו של דבר.
- (אורי) גם הם Empowered . . .
- (הילה) נכון . . . בסופו של דבר, מ-Empowered PM אתה עובר גם ל-Empowered Team - ואיך אתה עושה את זה?
- קודם כל על ידי זה שכולם ביחד יכולים לשרת את אותה מטרה, ויש להם את כל ה-Skill-set שהם יכולים.
- כמו שיש לנו Squad-ים - צוותים אוטונומיים, נכון? אז יש לנו גם בעצם יכולת להיות Empowered מבחינת ה-Business, נכון?
(אורי) שנייה, שנייה . . . קחי אותי מהאזור של המילים הגדולות וה-”Empowered” וזה - ביום-יום, מה קרה בפעם הראשונה שהבנת שאת “חושבת מוצר”?
- (הילה) אז זה . . . היתה תקופה ב-Augury . . .
(אורי) איך זה נראה ביום-יום, מה קרה?
- (הילה) אני אספר איפה אני התחלתי - איפה זה התחיל לפגוש אותי יותר ויותר.
- היתה תקופה שבה Augury בעצם עברה להיות מחברת “מוצר אחד” לחברת Portfolio - והמוצר החדש שרצו להקים הגיע אליי לצוות.
- והיתה לנו המון עבודה משותפת לי ולאיש-מוצר, ו...
(אורי) כשאת כבר היית Squad-Lead?
- (הילה) הייתי Squad-Lead כבר בצוות, כן.
- ובעצם, אחד מהדברים שהיו הכי קריטיים לנו לעשות, כשמביאים מוצר חדש, זה לעשות MVP ו-to-Scope-it
- וכמה שיותר להוריד תוכן שלא רלוונטי, בשביל להתחיל ולרוץ וללמוד מהר.
- ושם התחיל מאוד מאוד חזק הפינג-פונג בין האתגרים הטכנולוגיים וכמה אנחנו באמת רוצים להשקיע עכשיו או לא עכשיו - איזה Requirements אנחנו באמת רוצים למלא או לא למלא, כן?
- ואני חושבת שפה זו נקודת החיבור הכי חזקה, בין Product ל-Engineering
- וגם איפה שעולה החשיבה המוצרית ביחד.
(אורי) מה שאת אומרת זה בעצם שלצורך בניית ה-MVP הזה, היינו צריכים, אני - את, כן . . . - וה-Product Manager- כל אחד היה צריך להבין קצת ב-Domain של השני, כדי שתהיו מוכנים ותוכלו בעצם “לקלף את הבצל הזה” ולהגיע לליבה שלו, ולהבין בעצם מה אתם מקלפים . . . זאת אומרת, הוא היה צריך להבין מה קשה טכנולוגית
ומה לוקח יותר זמן, ואת היית צריכה להבין מה חשוב מוצרית.
- (הילה) נכון, נכון - מה בעצם אנחנו מנסים לבדוק בהתחלה? מה חשוב לנו לבדוק בהתחלה? איפה אנחנו יכולים להתפשר? כן . . .
- והיו הרבה פשרות שעשינו ברמה המוצרית - ברמה טכנולוגית, סליחה.
- היו הרבה מאוד פשרות בעולם הזה, היו הרבה דברים שעשינו כזה Hot Fixes, Quick & Dirty - רק בשביל שנוכל להתחיל לראות את זה במערכת.
- (אורי)למשל, לא חושבים על Scale בהתחלה . . .
- (הילה) לא, לא חושבים על Scale . . . זה לא היה בכיוון שלנו.
- אחר כך, אחרי שה-MVP הצליח, ובעצם היה לנו כזה “Pilot” - לקוח ראשון, לקוח שני, לקוח שלישי, והתחילו לדבר על איך זה משתלב באמת כ-Portfolio, שני מוצרים שנותנים ללקוחות - פתאום התחלנו לחשוב על איך אנחנו בונים לזה Vision ולאן אנחנו לוקחים את זה קדימה.
- ואיך זה מתחבר ב-UI, וב-Backend, מוצרית וטכנולוגית . . .
(אורי) לפעמים זה מצריך בשלבים המאוחרים פשוט למחוק הכל, לכתוב מחדש . . .
- (הילה) כן . . . נקודתית, לא היה לנו שם בדיוק את הסיטואציה הזאת, אבל כן - תיאורטית אני מסכימה איתך.
- לפעמים זה יהיה כזה, נכון - אפשר לדבר על MVP ו-POC.
- לפעמים אנחנו עושים POC בשביל לבדוק התכנות למשהו פשוט - ואנחנו נזרוק את זה אחר כך ונבנה את זה “כמו שצריך” אחרי שאנחנו באמת מבינים, ברמה הטכנולוגית, מה אנחנו צריכים.
(אורי) אבל במקרה שלך, כמו שאת אומרת, הטריגר להתחיל לחשוב מוצרית היה הנקודה הזאת שבה צריך “להפשיט את המוצר מכל מה שלא חשוב וקשה” . . .
- (הילה) כן, כי זו בעצם הנקודת-חיתוך שלי ושל כל הצוות - לא עשיתי את זה מתוך היותי Squad Lead - כל הצוות נמצא בדיונים, ובעצם מזה שמאתגרים אותנו כל הזמן לעשות את ה-Brainstorm ביחד עם האנשי-מוצר, זה מכניס אותנו נורא עמוק ל-Context.
- ובגלל שאנחנו מקבלים אתגרים נורא גדולים, אנחנו חייבים לעשות את ה-Back and Forth עם האנשי-מוצר, בשביל לדייק אותם למשהו שאפשר לדלבר (To Deliver) בזמן סביר, ושעדיין יביא את הערך.
- ובשביל הנקודות האלה - של היצירתיות, של איפה שאני רוצה גם להתעקש, כ-Engineering, “פה לא ופה כן” - אני צריכה להבין איפה כדאי לי דווקא לשחרר ואיפה לא.
- מתוך הבנה של איך המערכת בנויה - גם טכנולוגית וגם איך המוצר ומה חשוב ואיך זה מרגיש ללקוחות.
- ואז זה יוצר שפה משותפת וממש אינטראקציה, “חיכוך חיובי”.
(רן) זהו, אני חושב שהמילה שחיפשת, אני מנסה לנחש, זה “אמון” - זה מייצר איזשהו אמון. כי תמיד בין גורמים שונים - בין נגיד אנשי האופרציה לבין הפיתוח, בין אנשי הפיתוח לבין אנשי המוצר, בין ה-Recruiting . . . . - זאת אומרת, בין כולם לכולם תמיד יש איזשהו מתח ולפעמים גם יש איזשהו חוסר-אמון, כי מה לעשות? כולם מפשלים מתישהו, או שכולם מקבלים החלטות לא נכונות מתישהו - ואז האמון הזה קצת נשבר.
והחוכמה זה לבוא ולבנות את האמון הזה מחדש, או לייצר איזושהי קרקע - קרקע בטוחה יותר, שהאמון הזה לא יישבר.
ולשים את עצמך בנעליים של איש-המוצר - זה מבחינתם, אני רואה את זה כצעד-בונה-אמון, גם אם זאת לא הייתה הכוונה מלכתתחילה. גם אם זה בא לך כאינסטינקט, בסופו של דבר . . .
- (הילה) כן, בדיעבד הבניית שפה-משותפת הזאת - כאילו, אם אנחנו, כאנשים-טכנולוגיים מדברים כזה “לא, אבל השורת-קוד פה ופה לא נכונה, או לא נחמדה, או לא יפה מספיק!”, אנשי -מוצר . . .
- אנחנו עכשיו עם האשת-מוצר אצלנו בצוות, צוחקים שיש לה “פרצוף-Repository” - כל פעם שאנחנו אומרים את המילה או מתחילים לדבר על טכנולוגיה, כאילו הפרצוף שלה “נכבה” . . .
- אז צריך לדבר כאילו מן סתם ברמה שמתאימה לשני צדדים.
(אורי) כן, אבל זה גם עובד ב...נגיד, איש מוצר שמסוגל להבין את ה-Complexity של הארכיטקטורה - הדיון איתו הוא אחרת. ומהצד השני, מהנדס שמסוגל להבין את המוצר...
- (הילה) זה Skill-נרכש . . .
(אורי) . . . זה טוב לשני הצדדים. אגב, מה זה באמת השיחה הזאת, על ה-Scope של המוצר? זה משא ומתן, נכון? . . .
- (הילה) מסכימה.
(אורי) והא’-ב' של משא ומתן זה “תבין מה חשוב לצד השני” - וזו בעצם החשיבה המוצרית.
- (הילה) נכון, זו בעצם כאילו היכולת שלי להבין מה הצד השני צריך, וגם לנהל את המשא ומתן הזה “בגובה העיניים”, לשני הצדדים.
(אורי) כן, ומשא ומתן, כשמבינים האחד את השני - יש בו הרבה אמון.
(רן) יש! - חזרנו לאמון . . .
10:42 טיפים וטריקים
(רן) למי שזה לא בא טבעי . . . זאת אומרת, אני מניח שאת לא תכננת, לא עשית תוכנית-עשור, לעשר שנים קדימה - “מעכשיו אני רוצה להיות Product-Focused Engineer”, אבל זה בא לך. זה “התגנב” כנראה באופן אינסטינקטיבי, או שאולי היה איזשהו מקרה, וזה איכשהו זה הצליח.
אבל למי שעכשיו תופס את עצמו ואומר “רגע, רגע, זה דווקא נשמע לי רעיון טוב! אבל איך אני עושה את זה?”. כאילו, איך אני מפתח את האמפתיה? איך אני מייצר את השפה המשותפת הזאת?
תני לנו כמה טיפים וטריקים של דברים שאולי יכולים לעבוד לך - אם זה תכנון רבעוני, שיחות אחד-על-אחד או אחרים.
- (הילה) אז הייתי מתחילה בקודם כל בלדבר עם האיש או אשת-מוצר הכי קרובים אליכם.
- אני רוצה לקוות ולהאמין שאנשים יבואו ב-Good Faith, ושאם תרצו לבוא וללמוד, אז אנשים באמת גם “ישיבו את האנרגיה החיובית” ובאמת ילמדו אתכם.
- אפשר לבוא ולשאול שאלות מסביב למוצר עצמו, ל-Business עצמו - איך הם עושים דברים? איך אתה עושה פריוריטיזציה (Prioritization)?
- נגיד, הרבה פעמים אנחנו, כאנשים טכנולוגיים - לרוב האנשים זה מפתחים, מפתחות, לא מובילים,
- ואז בדרך כלל מגיע ה-Roadmap - וה-Roadmap כבר “אפוי”, ו”תודה - הנה, זה מה שקיבלתם”.
- שאלה מאוד מעניינת יכולה להיות “למה?” - למה דווקא זה קודם? למה זה בתחילת הרבעון? למה זה בכלל לא נכנס לרבעון?
- אז יש שאלות מאוד מעניינות, שאם נבין איך האיש-מוצר מסתכל על זה, אז כאילו . . . זה יעשה לנו גם הרבה יותר סדר, זה גם יוריד לנו תסכול.
- אולי לנו נורא חשובה איזושהי משימה, ואנחנו כזה “איך לא הכניסו את זה?! מה פתאום?! זה כזה קריטי!” - מתוך שיחה כזאת זה יכול להגיע.
- (רן) לא בקטע וכחני - פשוט כדי להגיע לסדר עדיפויות.
(אורי) דרך אגב, צריך להכין את זה - “כי למה דווקא זה? למה ה-Roadmap נראה ככה?” - כשזה בא מ-Engineering, בואו נודה על האמת, זו שאלה מעצבנת . . .
- (הילה) אז יש פה נקודה בין-אישית מאוד רכה, שצריך לנהל - צריך לבוא מאוד ממקום של למידה.
- אם נבוא ונגיד “אני רוצה לבוא וללמוד - איך אתם עושים פריוריטיזציה (Prioritization)? באיזו מתודולוגיה אתם משתמשים? מעניין אותי לשמוע”.
- “מה הקריטריונים שאתם שמים על משימות?”
- לא ב”למה דווקא זה או למה דווקא זה”, כן? כאילו, מה שניסיתי לעשות זה לשקף מחשבות שיש לנו בראש.
(רן) כן, יש הבדל. אני תמיד אומר לבנות שלי, הקטנות - יש הבדל בין “למה דווקא זה?!?!” ל”למה דווקא זה?” . . . זאת אומרת, צריך לדעת להגיד את זה - ואז אם זה בא מתוך באמת אמפתיה וניסיון להבין, אז זה נשמע אחרת.
(אורי) ו-Timing - אל תתפסו אותם כשהם לחוצים להציג את ה-Roadmap, בסדר? תתפסו אותם איפשהו באמצע הרבעון כזה, כשהם לא בלחץ, ו...
- (הילה) גם אפשר רק לשאול שאלות ולא באמת לקרוא תיגר על החלטות, כן?
- אם רק נשאל שאלות, לפחות במקום שבו אנחנו רק לומדים, ואולי וכנראה אין לנו משהו חכם עדיין לתת כ-Input, יהיה שווה שרק נשאל ונתעניין ונלמד.
(רן) אז לבוא ולשאול, להבין את השיקולים, להבין את סדרי העדיפויות ולפי מה קובעים סדרי העדיפויות - רק מזה כנראה נלמד הרבה.
- (הילה) נכון.
(רן) אוקיי, יש איזה-שהם Touch-points מיוחדים? זאת אומרת, אורי אמר “באמצע רבעון, לא בהתחלה ולא בסוף” - יש, נגיד, כמה נקודות יותר אסטרטגיות שאת מזהה? נקודות שבהן שווה באמת לדבר יותר קרוב עם אנשי המוצר?
- (הילה) אז זה קצת משתנה כנראה בתפקיד . . . לאנשי פיתוח, הייתי אומרת, אולי זה אפילו לא כזה קריטי - באמת לתפוס אותם בזמן שהם פנויים לזה, ולהתחיל להתעניין ולשאול שאלות.
- זה יכול להיות לפני Sprint Planning, אם זה על איזה משימות נכנסות ולמה.
- או אחרי שה-Roadmap מגיע - בואו נשב על זה ונבין יותר לעומק.
- בדרך כלל מציגים את זה, נגיד, לכל הקבוצה או לכל המחלקה - ואז זה כזה מאוד ב-High-level, אז זה מקום טוב.
- למובילים טכנולוגיים הייתי בכלל מציעה להבין איך הם, אפשר לומר “מסתננים” - עוד לפני שהדברים האלה אפויים.
- אם לבקש להיות חלק מה-Planning - לשבת בחדר, אפילו לא בשביל לקבל החלטות
- [למה לא?]
- באמת שאין לי כוח-וטו בחדר של ה-Planning, כי מי שאחראי על זה, זה לצורך העניין ה-Team-Lead והאשת-מוצר - אבל אני יכולה לבוא לתת את ה-Impact שלי ואת ה-Input שלי, ולעשות ככה השפעה על מה שקורה, מתוך הידע שלי.
(אורי) אגב, לא יודע - לפחות ב-Outbrain, הרבה פעמים ל-Spec-Review או מקומות כאלה, לא בהכרח ה-Team-Lead צריך להיות - כאילו, אם יש מפתח שהוא מספיק בכיר לקחת את זה, ולעשות את זה מול ה-PM - אחלה. אבל יכול להיות שבשלב שהוא לפני ה-Spec-Review - כבר לשבת עם ה-PM לשיחה של “למה?”: מה אמר הלקוח? מה רוצה הלקוח? דרך אגב - לא להתבייש, לפגוש לקוח.
- (הילה) לגמרי. כאילו, אני באמת רואה את זה בכל מיני נקודות, בתוך . . .
- יש לנו תכנון שנתי, תכנון רבעוני, אולי תכנון של ספרינטים - כל צוות או קבוצה, איך שהם רוצים לעבוד.
- אני חושבת שמובילים-טכנולוגיים חייבים להיות בתכנון שנתי ובתכנון רבעוני, בשביל באמת לבוא ולשאול את השאלות האלה, עוד לפני שהם נכנסים ל-Pipeline של הרבעון.
- אני חושבת שאנשי פיתוח - מפתחים - אם יש להם, נגיד, רצון להתקדם להובלת טכנולוגית וזה מתאים עם ההתפתחות המקצועית שלהם, עם ה-Skill-set שלהם - אולי גם יכולים לשבת שם.
- כאילו, יש הבדל בין מי שחייב לשבת שם - מתוך הגדרת-התפקיד, אפשר לומר - לבין מי שגם יכול לעשות את זה וכדאי שיעשו את זה, כי למה לא?
- למה לא לתת לאנשים להתפתח אם הם יכולים, ולבוא להשפיע.
(אורי) אני חושב שזה לא רק זה - פשוט יצא מוצר יותר טוב.
- (הילה) כן, לגמרי. אם מפתח, הוא Expert לאיזשהו איזור, והוא יכול לבוא ולהשפיע על ה-Scope של המשימה - אם היא צריכה להיכנס או לא להיכנס - אז שיהיה בחדר.
(רן) דרך אגב, קרה לך המצב ההפוך? שבא, נגיד, איש מוצר, ואמר “אני רואה ש-Feature מתעכב, או שיש פה איזשהו אתגר - אני רוצה להבין למה, רוצה להבין מה האתגר פה”?
- (הילה) בטח. כאילו, זה קורה כל הזמן . . .
- פחות עולה לי דוגמא לראש, נגיד, מסביב למוצר, למשהו שהתעכב, אבל תמיד כזה, בתהליך של עשיית Design-ים, תמיד זה כזה “למה זה כל כך הרבה זמן?! למה זה כל כך הרבה שבועות?!”
- והפרקטיקה שאני מאוד אוהבת, זה פשוט להיות מאוד Details-Oriented, ולצאת ממש מ-Design עם פירוק משימות מאוד מאוד ברור, עם ריאליזציה (Realization) מאוד ברורה מסביב לכל דבר.
- לבוא ולהגיד “זה חודש” - זה לא מספיק טוב.
- לבוא ולהגיד “הנה כל המשימות שפרטתי - פה יש לי כן Refactor קטן, אבל הוא רק שלושה ימים, וכל שאר הדברים הם ממש . . .”
- “זה עונה ל-Requirement הזה, וזה עונה ל-Requirement הזה”, כאילו...
(אורי) הנה טיפ לאנשי המוצר - תקשיבו על איזה חלקים ב-Spec Review ה-Engineering יותר מתעקשים . . . מה הם מתעקשים לא לעשות, או לשנות, או לבדוק להם אם אפשר לעשות אחרת . . .
בדרך כלל המקומות האלה יהיו המקומות שהם יותר קשים - ויקחו יותר זמן. אז כאילו, לפי זה, אפשר לדעת מה מסובך.
- (הילה) אני מסכימה. אני חושבת שיש גם הרבה דברים ברמה הטכנית, שאנחנו קצת יכולים לפשט ולהסביר יותר את ההשפעה שלהם על המערכת, ופחות באמת את הדבר הטכני.
- נגיד, לא מזמן הגעתי לאיזושהי שיחה, ומישהו התחיל להסביר - זה לא היו אנשי מוצר, אלו היו אנליסטים בחברה - אבל כזה, “כן, הבעיה פה” . . . .
- אתם יכולים להגיד להם ש”הבעיה היא ב-WebSocket!” - וכאילו, מפה ועד לזה שמישהו מבין מה ההשפעה, זה כמה קפיצות, נכון?
- אם אפשר לבוא ולפשט את זה . . .
- (אורי) מה ההשפעה על הלקוח או על המוצר?
- (הילה) כן, על המוצר - אבל אם פתאום, נגיד, נשנה את ההסבר, ונבוא ונגיד “תראו, למערכת יש כמה חלקים נעים - בעצם זו פעולה שקורית א-סינכרונית” . . .
- וניסינו להסביר להם למה ה-Event לא חוזר ל-UI, כן?
- אז המערכת שלנו מורכבת מכמה חלקים נעים - ומה שקורה זה שחלק אחד שולח הודעה לחלק השני, אבל משום מה החלק השני לא מחזיר הודעה בחזרה לחלק הראשון,
- עכשיו, זה הרבה יותר פשוט, כן?
- עכשיו, מן הסתם שבשיחה גם הסברתי מה זה כל חלק ומה זה כל קומפוננטה (Component) כזאת, בשפה שהן גם מכירות, כן?
- אז זה הרבה יותר מקרב והרבה יותר מחבר - במקום לדבר בשפה שלא מבינים, ואז הם במקום כזה של תסכול, אף אחד לא מבין את אף אחד.
19:37 איש המוצר התאום
(רן) יש לך איש מוצר, נגיד, שהוא “התאום שלך”? איש או אשת-מוצר, או שזה ככה מול כולם? זאת אומרת, מה ה-Working Set שלך?
- (הילה) אז אני יודעת שיש הרבה Setups בהרבה חברות שונות, אבל בשלוש החברות האחרונות שאני עבדתי בהן היה איש-מוצר או אשת-מוצר בתוך הצוות.
- זאת אומרת שזה כזה ממש ה-Go-To - ואנחנו Go-To‘s, זה אחד של השני, שזה Setup שאני אישית מאוד מאוד מאמינה בו ורואה בו את ההצלחה.
- אבל אולי גם אני מדברת מתוך זה שלא חוויתי גם את המשהו האחר - אולי זה טוב, אבל אני...
(רן) כן, זאת אומרת, אז בדרך כלל יש איזשהו Counterpart אחד - יש איזשהו איש-מוצר ספציפי שיש... יש לך איזשהו שגרת עבודה איתן? זאת אומרת, One-on-Ones, או לא יודע - ארוחת צהריים מדי פעם? או דברים כאלה, זה הכל כזה “מה שיוצא, יוצא?”
- (הילה) לא, זה לא “מה שיוצא, יוצא” . . . אנחנו - לצורך העניין, יש לנו Cadence כזה:
- ה-Leads של הצוות, שזה אני כמובילה טכנולוגית, ה-Team Lead וה-Product - מעבר לזה שאת ה-Sprint Planning אנחנו גם עושים ביחד, בתכנון הרבעוני יש לי גם חלק מאוד משמעותי שם.
- מן הסתם, כשיש כזה “בירות על הגג”, או כשעושים משהו ל-Fun - כולנו נמצאים שם, כן? אנחנו צוות אחד.
(רן) כן. עכשיו, בחברות יחסית בוגרות - ואני מניח ש-Forter בקטגוריה הזאת - יש, ככה, “עניין של Title-ים וקידומים’, וכל אחד רוצה להגיע לדרגה הבאה, וצריך להגיע לכל מיני מטרות . . . ולכל אחד מהמפתחים יש, פחות או יותר, לפחות אמור לדעת, מה הוא צריך לעשות כדי להגיע ל-Level הבא.
את יודעת את זה גם על איש-המוצר שלך? זאת אומרת את...
- (הילה) על מה הם צריכים לעשות בשביל להגיע ל-Level הבא?
(רן) כן, מה הם צריכים לעשות כדי להצליח? אני מפשט את השאלה. “מה הם צריכים לעשות?”, כן. מה המדד-הצלחה שלהם ומה הם רוצים להשיג?
- (הילה) אז אני לא יודעת מה ה-Responsibilities שלהם, בתוך ה-Job Description בדיוק.
- אני כן יודעת שאנשי מוצר לרוב נוטים להיות מאוד מפוקסים על ה-Business Metrics שמגיעים אליהם, שנגזרים מתוך ה-KPIs של החברה.
- אז יש את המטריקות שיש לנו ברמת החברה - ובדרך כלל כל חלק בארגון גוזר את זה אליו, עד שגוזרים את זה לאט לאט לתוך כל הצוותים.
- או KPIs או OKRs, שזה Objectives and Key Results או Key Performance Indicators
- אז זה כאילו, זה הדבר שעליו בסופו של דבר הם נמדדים.
- הם צריכים לאפיין על מה הם רוצים להשפיע ואיך זה מתחבר ל-Business - ובסופו של דבר זה נמדד על זה שבאמת הצלחנו לעשות את זה.
(רן) הבנתי, אז את ה-KPIs או את ה-OKRs של מנהלת המוצר שמולה את עובדת - אותם את מכירה.
- (הילה) אני מכירה - ומעבר “למכירה”. אנחנו צריכים - אשת המוצר אחראית על זה יותר ממני, כן? היא אחראית על זה האמת לבד, אבל אני צריכה להכיר, בעצם, איך כל משימה מתקשרת ל-KPIs האלה, כן?
- עכשיו אני גם אבוא ואחמיר ואומר - זה קצת לא מה ששאלת, אבל I'll go rogue - שכשאנשי המוצר עושים את זה, יש נקודה שאנחנו -כאנשים טכנולוגיים - מתי שאנחנו רוצים להשפיע ולשנות ולהביא, לא יודעת מה, אולי Refactor-ים גדולים או דברים שאמורים להשפיע על המערכת - אנחנו צריכים גם לדעת איך לקשר אותם ל-KPIs, כן?
- כאנשים טכנולוגיים, אם נגיד אני רוצה להכניס Refactor שעכשיו ייקח חודש או חודש וחצי, כי אני יודעת ש”וואו, איך זה חשוב, איך זה יעבוד” . . .
- אם אני לא אצליח להסביר בשפה של אנשי ה-Product למה זה מספיק חשוב, יהיה לי מאוד קשה לדחוף את זה קדימה.
(רן) כן, למעשה הקדמת את השאלה . . .
- (הילה) אה, יפה, אוקיי...
23:27 דילמה, Buy-In, חשיבה מוצרית ופול-גז בניוטרל
(רן) כן, אבל בעצם הרבה פעמים כמפתחים, יש לנו את הדילמה של “אנחנו יודעים שצריך לעשות פה איזשהו תיקון - איזשהו תיקון ארכיטקטוני, איזשהו Refactor - אבל אנחנו לא יודעים איך למכור את זה לאנשי המוצר”, במובן שיתעדפו את זה, שיהיה לנו מספיק זמן לעבוד על זה “בשקט” - ואולי גם לעזור לנו להבין מה חשוב מתוך זה ומה לא,
כי גם בכל דבר כזה יש אולי 80% חשוב שלוקח 20% מהזמן, ו-20% שלא - ולוקח את ה-80% האחרים.
אז איך באמת . . . קצת התחלת לענות, אבל באמת - איך מקבלים את ה-Buy-In הזה - מצוות המוצר, מאנשי המוצר - כדי לעשות את “ה-Refactor הזה”, שמבחינתם זה כאילו, זה “פול-גז בניוטרל”, הרבה פעמים? . . . או שלפחות ככה הם רואים את זה, כמובן.
- (הילה) נכון. בגלל זה אני התחלתי בלהגיד שאנחנו צריכים . . .שוב, אם זו עבודה משמעותית
- אני לא מדברת על איזה עבודה של יומיים - שאז אפשר תמיד, כנראה, לבוא ולהכניס בדרך כזו או אחרת.
- אבל אם זאת עבודה משמעותית - באמת לחבר את זה ל-KPIs או ל-Blocker-ים משמעותיים.
- לא יודעת, אולי תגידו “זה Pre-requisite למשימה מאוד משמעותית שרוצים לעשות ה-Product” - שמתקשר לדבר הזה.
- אולי מה שאנחנו רוצים זה ה-Enable ל-Build for Scale, שאנחנו צריכים שהמוצר שלנו יגיע לשם.
- אנחנו רוצים להבין איך הדברים האלה מתקשרים לצרכים Business-יים.
(רן) ודרך אגב - ואם זה לא, אז אולי לא צריך את זה . . .
- (הילה) לגמרי - אבל אני רוצה לתת פה סייג, שככל שאני מדברת על הנושא יותר, אני חושבת ש...
- כאילו, אוקיי - שני סייגים . . .
- אחד - נושא ה-Velocity, שמאוד מאוד קשה למדוד ונורא מורכב.
- וכמו שאמרתי לכם - “Repository Face” על האשת-מוצר אצלנו.
- כמובן שכולם רוצים שהאנשים - שהמפתחים - יזוזו מהר, אבל קשה להביא Impact מאוד משמעותי בזה הרבה מהזמן.
- זה דבר אחד שאני רוצה לשים בצד - אז מאוד קשה להסביר את זה טוב.
- ויש שם את ה-DORA Metrics ויש הרבה דרכים לבוא ולנסות לפרמל (To Formalize) את זה ולהביא את זה מתוך ה-Engineering כמשהו שאנחנו רוצים לקחת קדימה.
- והדבר השני שרציתי להגיד שהוא Outlier - לפי דעתי להכל - זה “Developer Happiness".
- [בשביל זה יש את okify, לא? Your feelings are more important than production]
- כן? כאילו, אנחנו צריכים לבוא ולהסביר, שלפעמים יש דברים שאין מה לעשות - אנחנו לא יכולים שמפתחים ישבו מתוסכלים ויעבדו בדרכים שפשוט גורמות להם תסכול כל היום . . .
- זה מוריד מוטיבציה - וגם זה קשור ל-Business, כן?
- אף אחד לא רוצה Attrition שלילי, חיובי, איך זה נקרא? - שאנשים יעזבו את החברה.
- אז פה דווקא אני מוצאת את עצמי באה ואומרת “לא - אבל זה נורא חשוב, מזה ל-Developers אכפת”
- “פה כן לבוא ולתעדף דברים כאלה” - גם אם זה לא על KPI.
- (הילה) זה . . . זה אתגר.
- אבל לפעמים, כן. אם מצליחים להביא טיעון טוב לאיך זה מתחבר וכמה זה משפיע - אז כן.
(אורי) אז יש שני דברים להתמודד עם הדבר הזה . . . אחד - זה פשוט לפתח אמון מספיק גדול. שאוקיי - “כשאת , ה-PM, אומרת לי שמשהו מאוד מאוד חשוב, אז אני מבין את זה. תביני גם כשאני - המפתח או הראש-צוות, אומר שמשהו מאוד מאוד חשוב” . . .
- (הילה) לגמרי. כראש צוות, בן אדם נמדד גם על זה שלאנשים טוב בצוות, נכון?
- זה חלק מהעניין - ואנשי מוצר נמדדים על KPIs . . .
(אורי) אבל תחשבי על דברים שהם לא רק “Happiness” או זה... החלפנו עכשיו איזשהו Infrastructure - הרבה פעמים אתה מחליף Infrastructure וזה בום! משפיע על כל הצוותים . . . אז כל אחד צריך לעשות את הדבר הקטן,
שלו . . .
(רן) . . . זה קודם כל משפיע לרעה - ואולי, אחר כך, גם לטובה . . .
(אורי) . . . כן - אבל בסוף אנחנו עושים את זה כדי להתקדם, נכון? אז דבר אחד זה אמון . . .
- (הילה) מסכימה מאוד.
(אורי) . . . והדבר השני הוא להגיד “קו בחול” - “20% מהזמן של המפתחים הולך לדברים שהם לא מקדמים את ה-Business”. הם מקדמים את הטכנולוגיה.
- (הילה) אבל גם פה - כאנשים טכנולוגיים - אנחנו צריכים פרקטיקות עם עצמנו, כדי להסביר גם לעצמנו וגם לאנשים...
(אורי) מה יותר חשוב? . . .
- (הילה) לא, אולי לא ספציפית לאנשי-מוצר, אבל כאילו - מגיעים בסופו של דבר לנקודה הזאת, מתוך מקום שרוצים קצת להוריד את ה-Friction של “האם כן זה או לא זה” ו-”כן קשור ל-Business או לא”.
- ולתת ל-Engineering איזשהו Bucket כזה.
- זה לא כזה “תלכו תהנו, תתפרעו”, נכון? צריך גם שם לעשות ריאליזציה מאוד חזקה.
- ופה כבר נכנס זה שאנחנו - בתור אנשים טכנולוגיים - צריכים בכלל Skill-set של אנשי מוצר, בשביל לנהל את ה-Backlog הזה.
- פתאום אנחנו עושים Prioritization, פתאום אנחנו מנסים להבין מה באמת עושה Impact . . .
(אורי) אני אגיד לך - זה כמו הילדים שלי וממתקים: זה אף פעם לא מספיק להם . . .
- (הילה) נכון - גם ל-Product לא מספיק . . . לאף אחד לא מספיק.
(אורי) נכון - אז כאילו, בסוף צריך לנהל עדיפויות בכל דבר.
- (הילה) נכון, אבל זה חלק מזה - לפתח את החשיבה המוצרית זה לא רק להבין את המוצר.
- זה להבין קצת את המתודולוגיות - וזה ישרת אותנו מאוד מאוד חזק, במקומות האלה של הניהול Technical Backlog, שאליו אנחנו רוצים.
- כי גם מתוך ה-Technical Backlog, אנחנו רוצים להביא את ה”הכי הרבה Impact”, מתוך איך שאנחנו מודדים את זה.
- ובין אם זה Refactor גדול או בין אם זה באמת להזיז גם מחט business-ית - הכל Fair.
28:57 העניין הזה עם הלקוח ולקחת חשיבה מוצרית לקצה
(אורי) אני רציתי להעלות עוד נקודה, שקשורה לזה - כי אנחנו כל הזמן מדברים על ה-PM, שמים אותו פה “על הגריל” . . .
- (הילה) אני בטוחה שהיא תשמח לשמוע שהשתמשתי ב-“Repository Face” כמה פעמים . . .
(אורי) . . . והיא לא שמעה על זה בכלל, זה רק מאחורי הגריל . . .
- (הילה) לא, היא יודעת שקוראים לה “Repository Face” - היא צוחקת על זה בעצמה.
- (רן) “מוקדש באהבה” . . .
(אורי) רציתי לדבר על הלקוח - כאילו, המפגש עם הלקוח. איפה זה? זה קורה?
- (הילה) אז אני יכולה להגיד שנגיד ב-Augury זה היה מאוד מאוד סטנדרטי.
- ברמת שמפתחים טסים עם אנשי-מוצר - לעשות סיור במפעלים, לפגוש לקוחות . . .
- במפעלים - כי זה בעצם הלקוחות שיש ב-Augury.
- שיחות עם לקוחות - להבין, לראות, לא יודעת . . . .
- לפעמים זה גם לא אפילו לעלות לשיחה עם האנשי-מוצר - יש המון כזה הקלטות - ב-Gong או איזה כלי שלא משתמשים - אז גם אפשר משם לדלות הרבה מאוד מידע ולקבל הרגשה.
- וגם ב-Forter - יש לנו המון אינטרקציות עם לקוחות, אז אנחנו גם עולים עם הלקוחות לשיחות, וגם בשיחות Discovery, מתי שאפשר.
- אנחנו באמת מנסים כזה לבוא ולהצטרף.
- כן, זה תלוי ב-Ballance - אבל אישית אני מוצאת בזה הרבה מאוד ערך, כי לפעמים לקבל את הכל, כזה, בלי פילטרים - שהם אולי Biased כבר על ידי אנשים קיימים.
- פתאום לשאוב את זה לבד - “פעם ב-”, לא כל שיחה.
- לא יודעת, “פעם ברבעון” - שכל מפתח יעלה לשיחה עם לקוח, נשמע לי כמו משהו מדהים.
(רן) דרך אגב - בין האיש-מוצר לבין הלקוח יש משרעת מאוד גדולה של תפקידים . . . זאת אומרת, יש אנליסטים ויש Product Marketing Managers ו. . . זאת אומרת, יש הרבה אנשים בחברה, שהם אולי לא אנשי המוצר “נטו” . . .
- (הילה) . . . כן, CS ו . . . [Customer Success]
(רן) . . . כן - והם בחלק מהמקרים מייצגים את הלקוח ובחלק מהמקרים מביאים איזושהי פריזמה שונה, שהיא גם מעניינת. אז גם איתם . . .
- (הילה) הם Stakeholder-ים, חד-משמעית.
- זה כאילו - אפשר לבוא ולדבר גם קצת על ההבדל בין B2C ל-B2B . . .
- אבל ב-B2B הם בעצם באמת מייצגים לנו את הלקוח בצורה פנימית.
- וגם ב-Forter - חברת B2B - ו-CS הם Stakeholder-ים מאוד משמעותיים בשביל להבין
(רן) "CS” זה “Customer Success” . . .
- (הילה) “CS” זה “Customer Success” ו-”B2B” זה “Business to Business”, ו-”B2C” זה “Business to Customer” . . . כן.
(אורי) אני חייב להגיד שראיתי פעם אחת מישהו שכמפתח, לקח את החשיבה המוצרית לקצה.
- (הילה) מדי? . . .
(אורי) לא . . . . וכשזה קורה, כש”הקסם” הזה קורה - “ה-KPI-ים עפים קדימה”.
איך זה קורה? זה פשוט - זה כאילו, זה גם בן אדם מיוחד, אוקיי . . . . שמסוגל לקחת דברים מקצה לקצה, גם מבחינת יכולות טכניות וגם מבחינה מחשבתית. הוא עבד על איזושהי מערכת, פיתח אותה, פיתח את ה... מבין טוב מה ה-KPI-ים שלו - ועכשיו המערכת יצאה לשוק, והוא שואל את עצמו “אוקיי - למה לא מצטרפים עוד לקוחות?”.
עכשיו, הוא לא הולך ל-PM . . . ובכלל, רוב המפתחים פיתחו - והם אפילו לא ישאלו את ה-PM, הם אפילו לא יסתכלו על המטריקות (Metrics), להסתכל אם הצטרפו עוד לקוחות או לא . . . מי שיש לו קצת חשיבה-מוצרית יסתכל, ישאל את השאלה “למה לא מצטרפים עוד לקוחות?”.
אז הוא לא - במקרה שלו, הוא לא הלך ל-PM לשאול. הוא הלך ל-Customer Success, ל-Account Management. לקח את הכיסא, ישב לידם - חצי יום - אמר “למה אתם לא משתמשים? למה לקוחות האלה ואלה ואלה שלכם . . .” - שהם מה שנקרא “ה-Ideal Customer” למוצר שלו - “למה הם לא משתמשים?”.
אז יש כל מיני תשובות . . . חלק מהתשובות לגיטימיות, חלק לא. כשהוא מגיע ושואל את השאלה "למה לא משתמשים?” אז זה מגרד למישהו בראש, והוא אומר “רגע, באמת למה לא?”. ואז הוא אומר לו “אוקיי, אז הנה, ככה תשתמש”. ואז מנסים, ומזה הוא מקבל פידבקים - והוא רץ חזרה למערכת ומתקן, וחוזר עם משהו יותר טוב . . .
- (הילה) אם לבן-אדם טכנולוגי - כאילו, בכללי - זה יהיה “PM נורא טכנולוגי” או “טכנולוגי נורא מוצרי”, זה לא משנה מה . . . המולטי-דיסציפלינריות הזאת מאפשרת לנו להוריד הרבה Feedback Loops, לרוץ מאוד מהר . . .
(אורי) בדיוק . . .
- (הילה) וגם עוד נקודה מאוד חשובה פה - זה כזה, זו עוד ולידציה (Validation), כן?
- כאילו, אני גם יודעת - גם הבת זוג שלי היא אשת-מוצר. כן, זה תפקיד קצת בודד בסך הכל . . .
- כל המשקל של הצוות על הכתפיים שלך, צריך להצליח - עם מי עושים Brainstorms? עם מי עושים זה . . .
- זה הופך את זה גם ליותר “ביחד” - וזה גם מקצץ הרבה מאוד מה-Feedback Loop, אם אתה בא בתור איש-טכנולוגי.
- ואפילו בקוד - כאילו, אתה בקוד בא ושואל את עצמך “אוקיי, פה זה אמור להיות ככה או שזה אמור להיות ככה?”
- אם אתה מכיר מספיק טוב את המוצר - אתה עונה לעצמך.
- “הורדת שאלה לאיש מוצר - פיתחת את הקוד יותר מהר”.
- אז יש לזה - מלמעלה ועד למטה - השלכות מאוד עמוקות.
(אורי) מפתח להצלחה, או להעלות KPI, זה פשוט היכולת לטעות מספיק מהר . . .
- (הילה) מסכימה . . .
(רן) דרך אגב - יצא לי גם לראות המקרה ההפוך, גם חיובי, כן? של איש-מוצר, שהיו חסרים לו Feature-ים ולא היה מי שעשה את זה - אז הוא עושה את זה בעצמו . . . אז נכון, הוא עושה את זה מכוער, ב-PHP . . . אזכור לו את זה לתמיד - אבל זה עבד . . . לא חשוב.
(אורי) . . . אבל הוא קיבל ולידציה מהר . . .
- (הילה) היום יש לך ChatGPT . . .
- איש מוצר מוציא קוד ב . . אתה יודע.
- [כן יודע - 472 Bumpers 83 - Nostalgia]
(רן) כן, אז לגמרי - זאת אומרת, חציית-הקווים קורית לחיוב - משני הצדדים. ולא לשכוח את האמפתיה!
- (הילה) כן,
35:37 תצאו מהקופסא
(רן) אז אוקיי - אז זאת היתה שיחה מעניינת, ואני חושב שאולי ה-Take-Away שלי - ואני מקווה שגם של אחרים מפה - זה “תצאו רגע מהקופסא שלכם”: אתם באמת רוצים לעשות Impact, תשאלו את האיש-מוצר שעומד לידכם, תשאלו את ה-Customer Success Manager שנמצא לידכם . . .
(אורי) תעניינו - במוצר ובלקוח.
(רן) . . . מה הם עושים? מה האתגרים שלהם? מה הלקוח רוצה? . . . ואתם תגלו מהר מאוד, שלכם כנראה יש יכולת מאוד מאוד גדולה להשפיע לחיוב גם על המטריקות (Metrics) שלו - אבל בסופו של דבר גם על שלכם, ולהיות Happy-Happy, כמו שמפתחים אוהבים להיות.
תודה רבה! איזה כיף.
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
אין תגובות:
הוסף רשומת תגובה