Augury

בשני משפטים, מה זה Empowered Product Teams אצלכם?

צוות מוצר באוגורי (סקוואד) הוא צוות שהקיום שלו משרת מטרה עסקית מסוימת וההחלטות לגבי אילו בעיות פותרים, ואיך פותרים אותן במסגרת המטרה העסקית הזו, מתקבלות בעקבות דיסקברי שהצוות עושה יחד (שיחות עם משתמשים, stakeholders שונים בתוך החברה, ניתוח של דאטה, פרוטוטייפינג, ואיטרציות קצרות). המהות של העבודה באופן הזה, גורמת לכל חברי.ות הצוות להיות accountable למטרה העסקית וליעדים המוגדרים תחת המטרה הזו, מה שתורם לכך שהבעיות יהיו מחודדות יותר, הפתרונות יהיו יצירתיים יותר, והתכנית תהיה מבוצעת בזמן שהצוות הגדיר (או קרוב לזמן שהגדרנו 🙂 ).

מה מגדיר צוות? מטריקה? האם זו חייבת להיות מטריקה אחת פר צוות?

האידיאל הוא שצוות מגדיר לעצמו מטריקה אחת – במקרים רבים יחד עם צוות ״שירות״ (Customer Success, Support, etc). לרוב, המטריקה הזו מהווה את אחת מהמטריקות הראשיות של החברה ועליה הצוותים נמדדים (למעשה מודדים את עצמם). בפועל, לעיתים בגלל שאין מספיק צוותי מוצר, צוות מסוים יכול להחזיק איזור עם 2 North star metrics, ואז חלק מהדיסקברי משרת את התיעדוף של על איזו מטריקה הצוות יעבוד ברבעון או שניים הקרובים. זה לא אידאלי כי באופן הזה הצוות לא 100% מפוקס על איזור בעיה ספציפי, אבל לרוב האזורים מאד חופפים.

איך מייצרים אליינמנט בין צוותי מוצר לצוותי ״שירות״ (service) שעובדים על מטרות-דומיינים דומים או חופפים?

טרם פיצחנו 🙂 זה אחד האזורים שאנחנו עובדים עליהם הכי חזק ב Augury, והמסקנה הברורה היא שיש הרבה דמיון בין צמדי הצוותים השונים (צוות מוצר <> צוות שירות), אבל גם הרבה שוני, לכן כל צמד צריך למצוא את הדרך הנכונה ביותר לעבוד יחד. בגדול, הכל מתחיל ביישור קו לגבי המטריקה (במקרים טובים גם ממש הגדרה משותפת של המטריקה) כדי לוודא שהמטרות מיושרות. שנית, אנחנו מנסים לייצר שגרת עבודה משותפת, שבה אנחנו עושים דיסקברי משותף כדי להבין מהם הגורמים לעלייה או ירידה במטריקה המשותפת, האם אלו בעיות שמאפיינות סגמנט מסוים של משתמשים או לא, ועורכים ראיונות משותפים עם משתמשים כדי להבין את בעיות השורש. אחרי שהבנו את הבעיות, אנחנו משתדלים לבנות רודמאפ משותף בו מחליטים על איזו בעיות מתפקס צוות המוצר, ועל אילו בעיות מתפקס צות השירות, כשלרוב המטרה היא שצוות המוצר יתקס על בעיות שצוות המוצר כבר הצליח לעשות עליהם ולידציה ידנית עם משתמשים (לדוגמא, report ששלחנו בצורה ידנית במשך חצי שנה, עשינו ראיונות עם משתמשים כדי לקבל פידבק שאיפשר הרבה איטרציות מהירות), ורק אז נעשה לו productization. זה תהליך שלא תמיד קל לעשות אותו, אבל מאפשר חיסכון בזמן פיתוח.

מה האתגר הכי גדול שחווים מנהלי מוצר שעוברים לראשונה למודל של עבודה ב Empowered Product Teams ?

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

מה משותף/מאפיין סקוואדים שלא הצליחו להשיג את המטרות שלהם?

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

———————————————

Michal, Monday

בשני משפטים, מה זה Empowered Product Teams אצלכם?

Empowered product team הוא צוות שיש לו משימה ואת כל המשאבים שהוא צריך (פרודקט, מפתחים, דיזיין ואנליסט) כדי לרוץ לבד ולמצוא את הדרך להצליח. הוא לגמרי ה owner של המוצר שלו ויש לו את החופש המלא לנסות דברים ולהצליח (וזה בסדר אם הוא נכשל בדרך ולומד)

מה מגדיר צוות? מטריקה? האם זו חייבת להיות מטריקה אחת פר צוות?

יש צוותים שמה שמגדיר אותם זה מטריקה ויש צוותים שאחראים על אזורים מוצריים (אבל גם הם מגדירים מטריקה למדוד את עצמם). בד״כ יש מטריקה אחת ראשית אבל כמובן ששוברים אותה לכמה תתי מטריקות שמשפיעות על המטריקה הראשית.

איך מייצרים אליינמנט בין צוותי מוצר לצוותי ״שירות״ (service) שעובדים על מטרות-דומיינים דומים או חופפים?

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

מה האתגר הכי גדול שחווים מנהלי מוצר שעוברים לראשונה למודל של עבודה ב Empowered Product Teams ?

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

מה משותף/מאפיין סקוואדים שלא הצליחו להשיג את המטרות שלהם?

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

Rahm, Gong

בשני משפטים, מה זה Empowered Product Teams אצלכם?

בגונג, כל סקווד אחראי על פרסונה או פרסונות מסוימות ועל בעיות עסקיות ספציפיות שהסקווד בא לפתור. סקווד מורכב (בדרך כלל) ממנהל מוצר, מעצב (אצלנו המעצבים אחראים על כל החוויה UX+UI), מנהל פיתוח ומספר מפתחים עם יכולות מגוונות (FE, BE, Mobile). מנהל המוצר הוא ה״מומחה״ בגונג לפרסונה ולבעיה העסקית שהקבוצה באה לפתור. הסקווד אוטונומי. לכל סקווד יש את ה-דזיין פרטנרז שלו מולם הם עובדים משלב הראיונות, דרך הרעיונות, הפרוטוטייפים, אלפות, בטאות, ועד למוצר הסופי. התוכניות הרבעוניות בהן מוחלט איזו בעיות עסקיות פותרים ובאופן כללי מה כיוון הפתרון נעשית בתיאום עם מנהלי הקבוצות וההנהלה. המטריקות והעבודה על הפתרונות בתוך הרבעון היא בניהול עצמי של הצוותים.

מה מגדיר צוות? מטריקה? האם זו חייבת להיות מטריקה אחת פר צוות?

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

לצוות יש בדרך כלל מטריקה מרכזית אחת שנתית עם נגזרות רבעוניות. אך פעמים רבות ״כוכב צפון״ אחד לא כל כך מתאים למוצרים חדשים שבהם לוקח זמן לראות אימפקט על מדדים מאוחרים. לדוגמא, בבעיה חדשה שהחלטנו לפתור השתמשנו במודל ה- ״Superhuman market fit” (״כמה תתאכזבו אם ניקח לכם את המוצר או הפיצ’ר הזה?״). קיבלנו תגובות מעולות שהראו את רמת החיבור הרגשי של הלקוחות לפתרון שייצרנו. זה היה מדד מצויין שהראה ש-85% מהמשתמשים שענו היו מתאכזבים מאוד, מה שעזר להבין שאנחנו בדרך הנכונה.

איך מייצרים אליינמנט בין צוותי מוצר לצוותי ״שירות״ (service) שעובדים על מטרות-דומיינים דומים או חופפים?

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

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

מה האתגר הכי גדול שחווים מנהלי מוצר שעוברים לראשונה למודל של עבודה ב Empowered Product Teams ?

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

מה משותף/מאפיין סקוודים שלא הצליחו להשיג את המטרות שלהם?

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

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