בשנים האחרונות התעשייה מגדירה כמעט כל תפקיד שיש בו ניהול שירות או ניהול מערכת כ"ניהול מוצר".
בעיני (ויסלחו לי רבים מחברי מנהלי המוצר), מנהל מוצר הוא באמת כזה כשהתנאים הבאים מתקיימים עבורו:
1. הוא Owner של מוצר או של אזור מוגדר במוצר. 2. למוצר יש או בדרך להיות Road Map.
3. למוצר יש או נבנים יעדים עסקיים.
4. למוצר יש פיצ'רים מוגדרים ומטרה ברורה.
יתכן והמוצר בתחילת דרכו ועדיין אין לו את כל אלה, אבל אם התהליך קיים - אז מי שיוצר אותו זכאי מבחינתי להגדרת התפקיד המדובר.
הנה לפניכם כל הטייטלים של העוסקים במלאכה (ויש הרבה) :
מנתח מערכות / System Analyst - תפקיד שבו יש להכיר את המערכת על בוריה, את האופן שבו היא עובדת עם דגש על הרכיבים הטכנולוגיים שלה. ככל שהמערכת הטכנולוגית יותר מורכבת, כך נדרש ידע רב יותר בהכנסת פיצ'ר חדש.
במערכות שבהן התנסיתי (שבחלקן היו גם מעל ל-40,000 פיצ'רים), נדרשה למידה וניתוח מאוד מעמיק כדי לבצע שינויים, אפילו הקטנים ביותר.
מנתח תהליכים עסקיים / Business Analyst - תפקיד שבו מכירים את התהליכים האופרטיביים של החברה. במקרה הזה, המערכת משחקת תפקיד משני אם כי נדרש להכיר אותה. ככל שלארגון תהליכי עבודה מורכבים יותר, כך נדרש ידע רב יותר בשינוי התהליך.
בתהליך המכירה של מכונית חשמלית לדוגמא, כלולים כמה מאות תהליכי עבודה ובדיקות שעל המוכר לבצע: הגדרות הנהג, הגדרות הרכב, התקנת עמדת הטעינה, הגדרת צריכת החשמל, הקשר עם ספקי החשמל, קשר לארכיטקט העירוני וכו'.
מתפעל מערכת / Product Operations - זוהי פונקציה שאמונה על תפעול המוצר, Customization, הגדרות ותחזוקה (לא טכנולוגית). מערכות מורכבות מאפשרות הגדרת תהליכים עסקיים חדשים או שינויים של תהליכים קיימים ללא צורך בפיתוח. לעיתים, זו הפונקציה שמשמשת כמו "מנהל מערכת". הם מקימים משתמשים (Users), מקימים מוצרים (למשל בתעשיית האיקומרס), מגדירים מחירונים ומפיקים דוחות שלמשתמשים בסיסיים אולי אין את הידע או הגישה אליהם. לעתים מי שיבצע את הפונקציה הזו יהיה משתמש Superuser.
אין לי תרגום טוב ל Product Owner - לפעמים נקרא גם PO לרוב בעל אחריות על ניתוח דרישות Inhouse. לפעמים כפוף למנהל מוצר. לרוב ההבדל בין מנהל מוצר ל PO הוא, ש PO הוא הפרסונה שאחראית לניהול הדרישות בתוך צוות Scume של Agile ולא האחריות הכוללת של ניהול המוצר.
מנהל מוצר \ Product Manager - בעל האחריות על הובלת המוצר כולו, אזור ספציפי במוצר או מקבץ פיצ'רים. הוא הסמכות שהיא ה-Owner בארגון מטעם העובדים, הלקוחות, הפעילות והדיווח.
כל הוספה או הורדה של רכיב חייבת לקבל אישור ממנהל המוצר. הוא אמון, אחראי וגם זה שיתן דין וחשבון במידה והמוצר לא מספק את התוצאות הרצויות.
לרוב, אין שני מנהלי מוצר על אותו הפיצ'ר (ואם יש, זה מאוד לא בריא). לילד יש רק זוג הורים אחד, ככל שיותר אנשים "ינהלו" את אותו המוצר או הפיצ'ר, הסיכוי להצליח להגיע ל-Road Map וליעילות מוצרית תקטן.
עם השנים, העולם נהיה מורכב יותר ובהתאם לכך התפתחו תתי סוגים לניהול מוצר.
סוגי מנהלי מוצר
תפקיד Product Inbound - מתייחס למנהלי מוצר שעיקר הפעילות שלהם היא: הגדלה, חידוד וייעול המוצר מול הצוותים בתוך החברה ובמיוחד מול צוותי הפיתוח.
תפקיד Product Outbound - מתייחס למנהלי מוצר שעיקר הפעילות שלהם היא התאמת המוצר ללקוחות. הם עסוקים בעיקר במחקרי שוק, לעיתים Customization מול לקוחות בעלי צרכים מבודלים במידה ומוצר ה-Core אינו תומך בהם.
תפקיד Product Marketing - מתייחס למנהלי מוצר שעיקר הפעילות שלהם היא שיווק, הכרת והצגת המוצר ללקוחות. הם הצלע המחברת בין צוותי המוצר למחלקות השיווק ולעיתים הם ינוהלו תחת מנהל שיווק ולא תחת צוותי המוצר.
תפקיד Technical Product Manager - בשונה מ Outbound \ Marketing הפועלים עם הפנים החוצה, ועוד יותר מ Inbound, בעל תפקיד זה הוא בעל האחריות הטכנולוגית של המוצר. לרוב התפקיד הזה קיים בחברות שבהן הטכנולוגיה של המוצר מורכבת ודורשת ידע מקדים או ניסיון רב בפריזמה הטכנולוגית, למשל חברות בתחום הרפואי, שבבים, רדיו, ביטחון, סייבר, פיננסים וכו'. גם במקרה זה מנהל המוצר פועל במתודולוגיות ניהול מוצר, אך מתמקד בקידום הטכנולוגיה, במחקר הטכני ובפיתוח. תוך שהוא לרוב עוסק פחות בעיצוב, מכירות, שירות ואספקטי ניהול מוצר רכים אחרים.
תפקיד Data Product Manager - הוא מנהל מוצר בתחום הדאטה, הוא תפקיד באותה מטריה של Inbound ומטרתו היא קידום המוצר הדאטאי. לרוב תפקיד זה קיים בחברות שהמוצר או רכיבים משמעותיים מהמוצר מוכרים מיעד למשתמשים. אין לבלבל את התפקיד הזה עם אנליסט או איש דאטה שמומחה בניתוח נתונים, על מנהל מוצר זה להבין בדאטה אבל להשתמש במתודולוגיות ניהול מוצר, תוך כדי אחריות על המוצר בתוצר הדאטאי שלו.
כל מנהלי המוצר נדרשים להכיר את המוצר לעומק, כולם יכולים לבוא בדרישות לשנות ולשפר את המוצר.
כאשר שני Outbound ו- Marketing מכירים טוב יותר את צרכי הלקוחות, Inbound ו - Technical מכירים הכי טוב את האופן שבו עובדת המערכת.
אם Outbound ו- Marketing מכוונים לספק את צרכי הלקוחות ושואפים להגדיל את המכירות, Outound ישאף לכך שהמוצר תמיד ייצמד ל-Road Map שישרת הכי טוב את צרכי החברה ויכתוב את הדרישה העסקית והניתוח הטכנולוגי.
שלושה מנהלי מוצר רבים על תעדוף? זה נשמע כמו צרות...
זה מתח בריא! זה איזון מצויין וקרקע פוריה לדיון והתפתחות של כל הצדדים. אז איך קובעים מי המנצח? זה שמוכיח שהשינוי תורם לטובת החברה באופן הטוב ביותר.
ה"דרגות" - תפקידים וטייטלים בניהול מוצר
לרוב, מנהלי מוצר מתחילים נקראים גם Junior Product Manager - זהו התפקיד ההתחלתי. נהוג שזהו הטייטל בשנתיים הראשונות.
כשמנהל מוצר מתחיל צובר ידע וניסיון הוא נקרא פשוט Product Manager.
כשמנהל מוצר מנוסה יותר, לרוב אחרי 5 שנים הוא נקרא Senior Product Manager.
למנהל צוות של מנהלי מוצר קוראים Product Manager Team Leader או Lead Product Team. לרוב ינהל 4-5 מנהלי מוצר. נהוג שהוא מקביל למנהל צוות המפתחים.
כשמנהל מוצר ספציפי הוא הפונקציה הבכירה ביותר בארגון בנושא מוצר הוא נקרא Director Of Product. הוא לא תמיד מנהל תחתיו מנהלי מוצר באופן ישיר, אבל הוא הסמכות שמקבלת את ההחלטות המשמעותית ביותר על המוצר/י החברה ובכלל זה הוא "חתום" על ההחלטות שיקבלו כלל מנהלי המוצר.
בארגונים ענקיים עם מוצרים רבים, ישנה לפעמים פונקציה הנקראת Program Manager, שהוא האחראי על המוצר מהצד המוצרי והטכנולוגי. למשל, מוביל המוצר Excel בחברת מייקרוסופט על כל היבטיה - העובדים, הלקוחות והפעילות.
ההגדרה CPO - Chief Product Officer מתייחסת לפונקציה הבכירה ביותר בארגון בנושא המוצר, לפעמים כפופה למנכ"ל ולפעמים ל VP.
ההגדרה VP Product מתייחסת לפונקציה של מי שכפוף למנכ"ל, מייעץ ומנהל את מוצרי החברה. והוא הפונקציה הבכירה ביותר בנושא מוצר גם מעל ל-Director. לרוב, ינהל מנהלי מוצר או מנהלי צוותי מנהלי מוצר.
בארגונים שונים ההגדרות שונות, לעיתים טייטלים הם רק טייטלים. מנהל מוצר יחידי בארגון של 5 עובדים יכול להקרא VP כשהוא בעל ניסיון של שלושה חודשים או כשהוא עצמו הבעלים של החברה. לכן לא מומלץ לייחס חשיבות לטייטל כמו לניסיון עצמו, לפרויקטים קודמים ולהצלחות.
מקווה שטיפה סייעתי עם הבלבול
רוצים לדעת איך מגיעים לתפקידים האלה?
לא בטוחים מה נכון לארגון שלכם?
דברו איתי