השבוע קיבלתי הודעה מחבר, ראש צוות פיתוח סופר מנוסה, שאמר לי: "אורי, אני רוצה להוסיף מנהל מוצר לצוות אבל המנכ"ל לא מבין למה צריך את זה ואני לא מצליח לשכנע אותו. יש לי פגישה איתו מחר, תעזור לי להבין איך אני מצדיק את זה". אז הרמתי אליו טלפון וסגרנו את זה בעשרים דקות.
אבל היות וזו שאלה שאני מקבל לעיתים קרובות אז הנה פוסט שמסביר את כל הסוד מאחורי שיחת ה-"איך אני מצדיק להביא פרודקט לפרויקט שלי". פעם הבאה במקום להתקשר אלי לגבי הנושא הזה, תקראו את הפוסט ואז תדאגו לשלוח לי בקבוק סיידר.
נתחיל בהתחלה, זה שאני מנהל מוצר פרילנס ואני מוביל את תוכנית ProductGO – זה לא אומר שאני בעד להכניס לכל מקום מנהל מוצר. בטח שלא בכוח. ואחת כמה וכמה אם לא באמת צריך. לא כל מקום צריך מנהל מוצר וגם המקומות שצריכים לא חייבים את מנהל המוצר שלהם בכל זמן.
אז איך יודעים האם אתם צריכים מנהל מוצר? ואיך מצדיקים את הגיוס הזה להנהלה?
אני חושב שלא יפתיע אתכם לשמוע שהדרך לגלות האם צריך להוסיף מנהל מוצר לצוות היא אותה דרך שבה אנחנו עושים כל תהליך מוצרי.
מתחילים בשלב הדסקוברי: קודם כל תגדירו מה הצרכים שלכם ואז תראו האם "הוספת מנהל מוצר" זה הפתרון שעונה על הצרכים הללו.
בשיחה הזו, פתחתי מחברת וביקשתי מהחבר שלי קודם כל להגיד לי ארבע דברים שהוא רוצה שמנהל המוצר החדש שלו יעשה. הדבר הראשון שהוא אמר היה שמנהל המוצר יעסוק בכתיבת איפיון פיצ'רים בשיתוף הלקוחות כדי למנוע אי הבנות ולקוחות לא מרוצים.
כבר פה עצרתי אותו וביקשתי שיתן לי דוגמה קונקרטית של מתי הבעיה הזו שהוא מתאר, כלומר אי הבנה באיפיון שנעשה מול ללקוח, התרחשה במציאות. הוא ענה שלפני חודשיים הם פיתחו פיצ'ר ספציפי ללקוח גדול, הפיתוח נעשה לפי ההבנות שלהם אבל בדיעבד התברר שהאפיון לא היה מפורט מספיק והיו המון מקרי קצה עסקיים שלא מופו. הלקוח היה מאוכזב ודרש תיקונים והשלמות. הם מצידם היו צריכים להתווכח עם הלקוח ולבסוף נכנעו ופיתחו מחדש כמה פיצ'רים כדי שהלקוח יהיה מרוצה.
עכשיו ניסיתי לעשות כימות של הסוגיה. כמה עבודה נוספת האפיון הלא שלם הזה ייצר? מה הוא סיכן?
ואחרי שסיימנו לדבר על המקרה הספציפי הזה שאלתי שאלות נוספות כדי להבין עד כמה נפוצה הבעיה הזו בשוטף: האם זה היה מקרה יוצא דופן? האם קרו מקרים דומים נוספים בחודשים האחרונים? כל כמה זמן זה מתרחש?
לאחר מכן עברנו לצורך השני שהוא רוצה שמנהל המוצר החדש יעשה ועשינו את אותו התהליך: מהו הצורך שמקבל מענה, נתינת דוגמה ספציפית, העלות של חוסר מענה לצורך הזה, ועד כמה נפוץ בפועל הביטוי של הצורך הלא מטופל הזה.
עכשיו שיש לנו את המידע, רק נותר לראות האם העלות של כל המקרים הללו גבוהה יותר מהעלות של שכירת מנהל מוצר חדש. אם כן – שווה לכם להביא מנהל מוצר נוסף. אם לא – כנראה שאפשר להמשיך עם מה שיש.
כמובן שלפעמים זה לא כל כך פשוט. לפעמים מדובר בסיכון שלא בא לידי מימוש ואנחנו רוצים להיות מוכנים אליו. כמו להביא מומחה אבטחה או Business Continuity לפני שיש פריצה או השבתה ואז השכנוע יכול להיות יותר קשה. אבל גם במקרים הללו זה צריך להיות בחינה של עלות הנזק הפוטנציאלי ביחס לסיכוי שיתרחש לעומת העלות של הגיוס.
יומיים אחרי השיחה קיבלתי הודעה מהחבר הודעת "תודה רבה! עבר בהצלחה, וכבר יש תקן לגיוס!". שלושה ימים אחרי כבר כתבתי את הפוסט הזה.
לסיכום: אם אתם רוצים להצדיק משהו, תמיד תבדקו יחס עלות מול תועלת שמבוסס על מקרים אמיתיים שהתרחשו ותראו שהחלופה שלכם יותר יעילה. ואם אתם צריכים משהו יותר ספציפי, דברו איתי.
