תשאלו את ת’אנוס: גם השמדת חצי יקום דורשת מנהל מוצר טוב

תתפלאו. מנהלי מוצר יכולים ללמוד לא מעט מהטיטאן הנבל

מקור: Marvel

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

החשיבות בזיהוי בעיות

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

1. זיהוי והגדרת הבעיה

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

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

2. תכנון הפיתרון

עם אפיון בעיות לא הולכים למכולת, ואחרי שהבעיה הוגדרה כהלכה, מגיע שלב אפיון הפתרון. זהו חלק שהוא רובו ככולו פנימי (Inbound) בו מעורבים בעיקר צוותי עיצוב המוצר והפיתוח. חלק חשוב מהתהליך כולל גם קביעת מדדי הצלחה לפיתוח החדש: האם הכפתור החדש מוביל לתוצאות הרצויות? האם הגדלנו את ההכנסות? האם הורדנו את קצב הנטישה (Churn)? האופן בו הדבר נעשה תלוי בגודל החברה, אופי הפעילות, כישורי הצוות ועוד. בדרך הכלל זה יבוא בצורת מסמך אפיון (PRD). מנהל המוצר הוא לרוב הבעלים של המסמך ומוודא שכל חבר צוות כותב את חלקו או מבין את החלק עליו הוא אחראי. כך למשל ייתכן שאת תיאורי מקרה (user stories) ועיצוב המסכים ראשוני (wireframres) יעשה מנהל המוצר בעצמו וישנן חברות בהן יש מאפיין UX שאחראי על הנושא.

3. תעדוף

אם יש סיבה אחת לקנא בת’אנוס זה העובדה שהמוצר שלו פותר בעיה אחת: העדר משאבים לכמות היצורים החיים ביקום. בדרך לשם יש לו בעיות אחרות “שמפריעות”: להשיג את האבנים, להלחם בנוקמים ועוד. אבל כל אלו בעיות בדרך לפתרון של הבעיה אותה הוא ניגש לפתור. אין לו צורך לתעדף אותם, כי הם טוריים: תשלים משימה אחת תעבור לבאה. בתור מנהל מוצר, אם הייתי צריך לבחור בין להשמיד חצי מאוכולוסיית העולם או לשבור את הראש על מה לפתח קודם מתוך רשימת המשימות (Backlog) שיש לי בכל רגע נתון הייתי לוקח את הסיכון שהאנשים הקרובים אליי יעלמו. כי במציאות, מנהל מוצר מתמודד בכל רגע נתון עם מספר בעיות ועליו להחליט על סדר הטיפול בהן. חלק מהגורמים המשפיעים על קבלת ההחלטה הם חיצוניים כמו לקוח חשוב שלוחץ, דרישות רגולוציה וכו’. וחלקם פנימיים הנובעים מפוליטיקה פנים ארגונית, צרכים טכנולוגים ועוד. אבל גם אם מנטרלים אותם, ישנם הרבה מדדים שהוא היה רוצה לשפר או מטרות שהוא היה רוצה להשיג בעצמו כמו שיפור סיום תהליך ההרשמה למשל. לכן לפני כל ספרינט או תכנון גרסה מנהל המוצר צריך להחליט מה יקבל קדימות, שכן יש מגבלה לכמות האנשים שיכולים לעבוד בכל רגע נתון. יש דרכים רבות לתעדוף וכמו הרבה דברים בכל הקשור לניהול מוצר אין נכון או לא נכון – יש מה שמתאים למנהל המוצר ולחברה. שיטה אחת (אותה פיתח יובל גלברד), המתאימה יותר ל-MVP מתייחסת לשני מרכיבים עבור כל פיצ’ר: תדירות שימוש וכמות משתמשים. שני אלו משמשים כמימדים בטבלה שעוזרת לנו להכריע אלו הכרחיים לגרסה הראשונה ואלו סובלים דיחוי לגרסאות עתידיות.​​

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

מאחר וטבלה זו אינה מכניסה שיקולים של זמן ומאמץ היא מתאימה יותר ל- MVP. כשאנחנו רוצים לגשת לשיפורים ושינויים כלליים, ניתן להשתמש ב- RICE שמוסיף עוד שני שיקולים. לכל פיצ’ר נותנים ציון בארבעה קריטריונים: Reach, Impact, Confidence, Effort.

4. ניהול התהליך

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

5. מדידת הצלחה

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

ת’אנוס ובעיית המשאבים

ראשית, אם טרם ראיתם את הסרט ואתם לא רוצים לדעת עליו דבר, ראו הוזהרתם מספויילרים. למי שלא מכיר, הנה תקציר מנהלים: ת’אנוס (ג’וש ברולין) ראה כיצד הכוכב שלו טיטאן מכלה את משאביו. הוא זיהה בכך סכנה גדולה ולכן הציע פתרון פשוט: להשמיד בצורה אקראית חצי מהאוכלוסיה. מסיבה לא ברורה, המנהיגים של טיטאן לא הקשיבו לו. אלא שהוא צדק בכך שהמצב לא טוב והכוכב נהרס. ת’אנוס לא עשה תחקיר מעמיק אלא פשוט אמר: “הנה צדקתי. חייבים להשמיד את האוכלוסיה בכל כוכב ברחבי היקום כדי למנוע משברים נוספים”. וכך במשך עשרות שנים הוא עובר כוכב כוכב ומשמיד חצי מהאוכלוסיה. אלא שת’אנוס צריך פתרון סְקֵילָבִּילִי, כזה שיאפשר לו להגדיל את כמות הכוכבים בהם הוא מטפל בלי להגדיל באופן ישיר את כמות המשאבים שהוא מקדיש לכך. לשם כך הוא מצא פתרון קסם: כפפה שתוכל להשתמש בכוח ששת אבני האינסוף ועל ידי נקישה אחת בעצבעותיו חצי מאוכולוסיית היקום תושמד (זהו כמובן חלומו של כל מנהל מוצר: משאב שפותר את כל הבעיות בשנייה).

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

האם ת’אנוס נכשל?

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

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

“Little one, it’s a simple calculus. This universe is finite, its resources, finite… if life is left unchecked, life will cease to exist. It needs correcting.”

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

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

בכל הנוגע לתעדוף, ברור שהפתרון שהוא הציע חייב להיות אחרון, שכן הוא משפיע על הכי הרבה אנשים – אבל באופן שלילי. הוא גם הכי “יקר” כי הוא לוקח חיי אדם, אותו גורם שמנסים להציל. בעולם התוכנה, קל לנו לחזור אחורה, או לשפר במיידי, לעשות בדיקות מקבילות לפתרונות שונים (A/B testing). אלא שלת’אנוס אין את הפריבלגיה הזו. הפתרון שלו הוא מוחלט (עד הסרט הבא). עדיף לנסות פתרון אחר לקצת זמן ואם אין שיפור אז לשקול פתרון אחר. חשוב לציין שגם אם הפתרון שלו יתגלה כנכון, זה עדיין לא אומר שפתרונות אחרים לא היו יותר טובים – הוא הרי לא ניסה אותם.

הכשל האנושי

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

מקור: Marvel

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

בקומיקס עליו מבוסס הסרט יש לת’אנוס מניע אחר להשמדת חצי מאוכלוסיית היקום: להרשים את המוות עצמה. כשאתה מאוהב, אתה לרוב פועל בצורה אינסטנקטיבית ולא בצורה לוגית-אנליטית ובלי מחשבה על השלכות מוסריות. אלא שגם בסרט הזה ת’אנוס היה מאוהב: ברעיון שלו. זוהי הסכנה הכי גדולה שלנו כמנהלי מוצר – לפעול בצורה עיוורת ולא רציונאלית. ההבדל היחיד בנינו לבין ת’אנוס הוא מה שמונח על כף המאזניים כשאנו בוחרים לא נכון. הסכנה הכי גדולה של מנהל מוצר, מאפיין, מעצב וגם מנכ”ל היא העיוורון שאנו מפתחים כשמדובר במוצר פרי יצירתנו. הדבר נכון לכל תוצר שלנו (מי מאיתנו לא בטוח שהילד שלו באמת מוצלח). תאמינו לי, לקח לי זמן להבין שהגרסה המוקדמת של המאמר הזה לא מספיק טובה ולא עונה על הצורך שבגללו כתבתי אותו. אבל בתור מנהלי מוצר אנחנו חייבים לפעול בצורה הגיונית ואנושית. גם לטובת החברה (company) בה אנו עובדים. אבל יותר מכך, גם לטובת החברה (Society) בה אנו חיים.

פורסם במקור High Tech: The Movie Version

רותם יפעת

הגב

4 תגובות על "תשאלו את ת’אנוס: גם השמדת חצי יקום דורשת מנהל מוצר טוב"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
מישהו מת
Guest

ענק!

מנהל מוצר
Guest

אחלה מאמר!

אבי
Guest

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

ערן
Guest

פשוט מעולה!

wpDiscuz

תגיות לכתבה: