היתרון בלהלחין בלי לדעת לנגן

או: כמה טכנולוג מנהל מוצר צריך להיות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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