נושא

השלישייה — מי אחראי על מה

ומה מנהל המוצר מביא שאף אחד אחר לא מביא.

החלוקה

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

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

פיתוח → טכנולוגיה. מעצב → UX. ומה נשאר?

ביזנס. את התחום הזה אף אחד אחר בשלישייה לא מכסה.

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

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

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

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

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

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

התאמת צבעים שייכת למעצב. זו המקצועיות שלו, ולא רק מטעמי כיבוד.

מנהל המוצר אחראי לתכלול של הכל — כולל חוויית הממשק — ויש שם שיח. אבל אחריות על השלם אינה בעלות על החלק.

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

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

יפתחו משהו שלא בהכרח יוביל להצלחה ולא ייצור אימפקט לחברה.

הפיתוח יעבוד. המוצר יצא. ואף אחד לא ירוויח מזה. הכשל אינו טכני.

שיעור 3 חידד את החלוקה למשפט אחד:

ההחלטה	של מי
מה לפתח	מנהל המוצר
איך לפתח טכנולוגית	צוות הפיתוח

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

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

לא מעניין את הלקוחות אם זה פייתון או C-sharp. רק שזה יעבוד כמו שצריך.

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