נושא

התפקיד — מיני מנכ"ל

עם מי מדברים, ומי מכריע.

מאיפה התפקיד בא

ניהול מוצר הגיע מהעולם השיווקי־עסקי, ונכנס לעולם הטכנולוגי.

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

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

מיני מנכ"ל

מנהל המוצר הוא כור היתוך עסקי. הממשקים שנמנו בכיתה:

מנהלי לקוחות · מכירות · פיתוח · שותפים עסקיים · תמיכה · הנהלה · פיתוח עסקי

למה הכינוי: מנכ"ל מדבר עם כמעט כל המחלקות. כך גם מנהל המוצר. הוא "מיני" כי הוא לא המנכ"ל — אבל בתוך היחידה שלו הוא לגמרי אחראי על הריצה.

והסדר שבו זה נאמר

קודם כל שהמוצר יקרה. ואחר כך שמה שקרה יהיה מוצלח ויביא לתוצאות.

הסדר לא מקרי. מוצר שלא יצא הוא לא מוצר גרוע — הוא לא קיים.

מי מחליט על מה

ההבחנה החדה ביותר בנושא:

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

כשזה עולה כסף

הסיפור שהובא מבזק, מניהול צוות האינטרנט שם.

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

השאלה שנשאלה בכיתה: אם הם האוטוריטה המקצועית אבל מי שחוטף זה מנהל המוצר — איפה עובר הקו?

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

ולא משנה ללקוח איך זה מפותח — לא ללקוח הקצה ולא ללקוח הביניים.

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

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

מספיק כדי להיות פרטנר. לא קוד.

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

ומי שבא מפיתוח — זו המלכודת שלו: הנטייה לרדת לשם במקום להישאר בביזנס.

סטארט-אפ מול ארגון גדול

אותו תפקיד, שתי מציאויות.

בסטארט-אפ אתה עושה הכל — כולל לצאת ולמכור בעצמך. לא כי אתה איש מכירות, אלא כדי להסביר את המוצר ולשמוע פידבק.

וגם כשיגיע איש מכירות: אתה זה שתצטרך לתת לו את ה-benefits, את מה שמוכר במוצר, ואת ה-value שהלקוחות באמת אמרו. בלי זה — that's it.

ואילוץ ארגוני משנה אסטרטגיה

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

build or buy אינה רק שאלה כלכלית. היא גם שאלה של כמה זמן לוקח לרכוש.

אינבאונד מול אאוטבאונד

התפקיד יכול לפנות פנימה — אל קבוצת הפיתוח — או החוצה, אל השוק והלקוחות.

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

מנהל מוצר מול פרודקט אונר

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

ומה הוא לא עושה: ארכיטקטורה טכנית. זה ראש הצוות הטכנולוגי.

איך זה עובד בפועל

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

הפתרון נבנה יחד. ההכרעה אם הוא בר־ביצוע שייכת לפיתוח.

וכשזה אדם אחד

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

בארגונים צבאיים

הבחנה שנאמרה על הכיתה עצמה, ורלוונטית למי שעובד שם:

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

המשמעות: חלוקת הסמכויות שתוארה למעלה — "מה" מול "איך" — לא בהכרח מתקיימת שם באותה צורה.

מה עוד יגיע

סשן נפרד על סופט סקילס ועל מה קורה כשיש בעיית סמכויות ומי מכריע — הוזכר במפורש כנושא שיילמד.