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

במסגרת הרצון לשתף את הלמידות שלנו ב Augury, שילבנו כוחות עם Michal Lupu, Group PM @ Monday ועם רם Rahm Fehr, Group PM @ Gong כדי להציג את התפיסות השונות והניואנסים של צוותים מועצמים בכל חברה


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

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

 

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

 

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

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

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

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