אנחנו מראיינים לאחרונה מנהלי מוצר (אגב, אם אתם מנהלי מוצר שמחפשים לרענן - שלחו קו״ח דחוף, יש בונוס מפחיד) וזה נושא מעניין לכתוב עליו.
אנחנו עדיין חברה קטנה, ותהליך הגיוס של מנהלי מוצר הוא חדש. למען האמת, זו הפוזיציה הראשונה של מנהל/ת מוצר שאנחנו מראיינים אליה מאז שהחברה התייצבה והקמנו קבוצת פרודקט.
מן הסתם, היו המון מחשבות על איך לגייס את התפקיד הזה, איזו משרה זו הולכת להיות, ואיך מייצרים תהליך שיעזור לנו לגייס גם את הפרודקט הבא/ה.
אחת ההחלטות המשמעותיות שעשינו בדרך היא שצוות הפיתוח יקח חלק אקטיבי בתהליך הגיוס של המועמד/ת. אתם יודעים איך זה, גם ככה אין לנו הרבה עבודה במהלך היום.
למה בכלל שמהנדסים יראיינו מנהלת מוצר?
בחברה שלנו המהנדסים עובדים מאוד צמוד למנהלי מוצר. הצוותים שלנו בנויים כסקוואדים או Stream-aligned team (על זה בהרחבה, בפוסט על Team Topologies שיעלה בקרוב) [עריכה: הנה עלה, אנחנו מקיימים הבטחות].
מדובר בהרבה שמות לאותו הדבר: צוות שהמטרה שלו היא להתמודד עם בעיה ביזנסית, ויש לו את הרכב האנשים ואת המנדט לעשות מה שצריך בשביל לפתור אותה - החל במפתחת הפרונט, מפתח הבק, מובייל או דאטה אנג'יניר שמכירים טכנולוגיות מסויימות, ועד למעצב והאנליסטית - כולם חלק מאותו סקוואד.
הגדרת התפקיד של כולם היא: לפתור את הפאקינג הבעיה.
בצוות מסוג כזה, העבודה של מנהלת המוצר יכולה להיות מאוד מורכבת. בתור התחלה, היא צריכה כל הזמן לשמור את הצוות מפוקס על הבעיה, ולהזכיר לאנשים שזו המטרה. כתיבת קוד איכותי, עיצוב פיצ'רים יפים, ביצוע ניתוחים אנליטיים מרתקים - כל הדברים האלה לא רלוונטים אם הם לא מקדמים את הבעיה.
נשמע מובן מאליו? דמיינו את השיחה שבה אתם מסבירים לפיליפ (בן 32, בקאנדיסט כבר 28 שנה) שהקוד האיכותי שלו זה לא מה שבאמת חשוב, ושהתפקיד האמיתי שלו זה לפתור בעיה עסקית. יותר מזה, גם אשכרה מצפים ממנו להתעסק בכל השיט הזה של הביזנס. זה לא תמיד פשוט.
בצוות מהסוג הזה, יש משמעות אדירה ליכולת של מנהלת המוצר לדבר ולרתום את המהנדסים. היא צריכה מצד אחד לתת push backs למשימות שלא נותנות ערך למשתמש, מצד שני לפקס ב-critical path לפי ה-roadmap של החברה, ומצד שלישי להיות מסוגלת להקשיב ולנהל דיון על הקטנת ה-scope בהתאם ל-Technical debts.
בקיצור, היא חייבת להכיר כל מיני מושגים בעברית-אנגלית.
מדובר בערוץ תקשורת קריטי בארגון, ואם הוא לא יעבוד כמו שצריך היכולת של הצוות להתקדם תהיה נמוכה מאוד.
נגיד יותר מזה - עבור מנהל הפיתוח, מנהלת המוצר היא הפונקציה בצוות שהתקשורת איתה משמעותית לא פחות מהתקשורת עם המפתחים שהוא מנהל, או עם המנהלים והמנהלות שלו. מכיוון שבתרבות העבודה שלנו הצוות הוא במרכז הארגון - מנהלת מוצר שהצוות שלה לא מתפקד == מוצר לא מתפקד.
ככה פשוט.
מה אנחנו לא בודקים, או, מה פרודקט מחפש בפרודקט
אנחנו לא פה כדי להחליף את מנהל המוצר המראיין, זו לא עוד אחת מהמשימות שהוא יפיל עלינו.
יש גבול נשמה.
מנהלי המוצר שמראיינים מוודאים שיש למרואיין את הskillset הפרודקטי וזה לגמרי לא תחום המומחיות שלנו, אנשי הפיתוח. חשוב לייצר את ההפרדה הזו בסוג המטריקות שאנחנו מבקשים לבדוק. כדי להבין יותר לעומק במה מדובר נצלול לאיך פרודקט מראיין פרודקט.
יש מלא שיטות שונות לנהל גיוס של מנהלי מוצר, אבל בין אם אנחנו שואלים שאלות פרודקט סנס בסגנון פייסבוק, נותנים מטלות בית לבניית פיצ'רים, או מקבלים החלטות על המועמד בשיטת התרנגול (טריגר סאות׳ פארק), אנחנו בסוף מחפשים את הדברים הבאים:
אנשים חושבים. כאלה שלא קופצים למסקנות לפני שהם חושבים ברצינות הבעיה.
אנשים שחושבים על הבעיה לפני שהם חושבים על הפתרון שלה. קשה להפריז בחשיבות של הנושא הזה - לצערנו ראינו המון מועמדים שמסיטים את עצמם לפתרון לפני שהם העמיקו בבעיה עצמה.
אנשים שמסוגלים לפרק בעיה למרכיבים הראשוניים שלה
אנשים עם חוש ביקורת בריא, שמסוגלים לנהל דיון סביב פתרונות אפשריים וכאלה שלא מתאהבים בפתרונות של עצמם
בקיצור, אנשים יותר חכמים מאיתנו שמסוגלים to call bullshit (לקרוא צואה?) על כל מיני הנפצות שמנהלי מוצר צריכים להתמודד איתם ביום יום.
כדי לוודא שהמועמדת עומדת בקריטריונים לעיל, מנהל המוצר שמראיין אותה ישאל שאלות מהסוג הבא:
את מנהלת מוצר באמזון (מזל טוב!). מגיע אלייך צוות הפיתוח ואומר לך כך: "תקשיבי, מצאנו דרך לשפר את האלגוריתם של ההצעות שלנו, ככה שכל הצעה תהיה מדויקת יותר ב-30%! הבעיה: זמן הטעינה של כל עמוד באתר יהיה ארוך יותר ב-3 שניות". השאלה: איך תחליטי אם בונים את הפיצ'ר או לא?
קחו שניה ותחשבו מה אתם הייתם עונים.
זה לא להיט גדול אם התשובה שלכם הייתה משהו בסגנון הבא:
״תראו, בסוף היתרון הכי גדול של אמזון זה שהם אוספים מלא מידע ויודעים להציע לך בדיוק את מה שאתה רוצה. בנוסף, הם מונופול. המסקנה המתבקשת היא שזמן טעינה קצת ארוך יותר לא ישפיע יותר מדי על המשתמשים.
הייתי משפרת את האלגוריתם ומנסה בטווח הארוך לשפר את הביצועים.״
למה זה לא להיט?
היינו מצפים לראות את הדברים שדיברנו עליהם למעלה:
אנחנו רוצים שמנהלת המוצר תיקח נשימה, ותנסה להבין איך שני הדברים הלכאורה לא קשורים האלה ("זמן טעינה" לעומת "דיוק בהמלצות") מתחברים כדי שהיא תוכל לשקול את הטרייד אוף בצורה טובה יותר. לצורך העניין, התשובה למעלה תגרום לנו לשאול "ואם מדובר על 4 שניות? או 5? או 10?". בלי שנבין איך שתי האפשרויות מזיזות את אותה המטריקה יהיה מאד קשה לענות. במקרה הזה, אפשר לדמיין פלואו של יוזרים שבסופו יש קנייה. כשמסתכלים על זה ככה, אנחנו יכולים לראות שאנחנו בעצם בוחנים איך כל אפשרות תשפיע על הסיכוי שהיוזר יגיע לסוף הפלואו. בעוד שזמן טעינה ארוך יגרום ליוזרים לשבור את המחשב מעצבים בשלבים המוקדמים של הפלואו, דיוק בהמלצות יגדיל את הסיכוי (במידה שהמחשב עדיין שלם) שהוא יבצע קנייה.
אנחנו רוצים שהיא תבין איזה הנחות היא חייבת לעשות בשביל לענות, ותעשה את ההנחות האלה בצורה מפורשת. למשל, התשובה למעלה מניחה שהמטרה של העיקרית של אמזון היא להוציא את מירב הכסף מכל סשן של יוזר. אם זה המצב, המלצות יותר מדויקות על חשבון פחות סשנים יכול להיות הגיוני. באותה מידה, אולי הדבר הנכון הוא לייצר כמה שיותר סשנים, שיחשפו את היוזרים לכמה שיותר המלצות (פחות טובות) אבל שסך כל הכסף יהיה גדול יותר? אולי המטרה של אמזון כרגע היא להביא יוזרים חדשים ממגזרים שפחות מחוברים (למשל, קשישים) ואז חוויית המשתמש הופכת למשהו מאוד חשוב?
אנחנו רוצים שהיא תראה ששתי האפשרויות הן דרכים להשיג אותה מטרה, ותייצר בין האפשרויות "מכנה משותף" שמראה איך כל אפשרות עושה את זה.
את כל זה היא אמורה לעשות תוך כדי שאילת שאלות וניהול דיון סביבה הבעיה.
איך מפתחים מראיינים פרודקט
אז אמרנו מה מנהלי מוצר מחפשים אצל מנהלי מוצר אחרים.
אבל מה מנהל פיתוח צריך לבחון אצל מנהל מוצר, ואיך?
בשונה מהראיון לעיל, אין הרבה ספרות על צוותי פיתוח שמראיינים אנשי פרודקט (ברצינות, אם אתם מכירים משהו שלחו ווטסאפ), והיינו צריכים לחשוב ברצינות מה היינו רוצים להשיג בסוג כזה של ראיון ומה בדיוק היינו רוצים לבחון אצל מועמדת לסוג כזה של משרה.
לתפיסתנו, אלה הם הדברים שחשובים לצוות הפיתוח כשהם מראיינים מנהלי מוצר:
כימיה, תקשורת ויצירת אמון - זה אולי הנושא הטריוויאלי מכולם, אבל חשוב לתת עליו את הדעת. התנהלות מול מפתחים היא skill שלם, והיכולת הזאת מאוד משתנה בין מנהלי מוצר. וזו יכולת קריטית.
יכולת לנהל שיח טכני ממקום לא טכני - חלק ניכר ממנהלי המוצר מגיעים מהעולם הטכני. האתגר של מנהלי מוצר מהסוג הזה הוא לקחת צעד אחורה כשעוברים לדבר על הפתרון הטכני ולא להתפתות להתחיל לדבר על הארכיטקטורה של המערכת. הדבר הכי גרוע שמנהל מוצר יכול לעשות הוא להתחיל להתווכח עם המפתח על הדרך הנכונה לממש את הפתרון שלו. אתה רוצה לכתוב קוד נשמה? בוא שב על הכיסא וניתן לך טאסקים.
מסוגלות לפקס ולנהל tradeoffs - היכולת לזהות שצוות הפיתוח מתקדם לכיוון הלא נכון, והיכולת לתת push backs בהתאם.
ראיון לשם ראיון - לעצם הראיון יש חשיבות. יש מקומות שבהם מנהלי מוצר חושבים שהם מנהלים את המפתחים. זה לא עובד ככה אצלנו, לפחות לא בצורה ישירה. הראיון היא דרך טובה לגלות אם זה המצב ולטפל בזה מלכתחילה.
חיבור לבעיה שהחברה פותרת (משהו שפחות היינו מצפים ממפתחים בשלב הזה בתהליך הגיוס) - אנחנו רוצים לראות שמנהל המוצר מבין מה הבעיה שאנחנו מנסים לפתור וכמה הוא מתחבר אליה. מנהל המוצר צריך לדחוף את צוות הפיתוח קדימה ואם הוא לא passionate about מה שאנחנו עושים זו הולכת להיות בעיה גדולה מאוד. מצד שני, אנחנו רוצים לראות שהוא מתייחס בצניעות לכמה הוא מבין את הבעיה ולראות שהוא מסוגל לזהות את ה-blind spots שיש לו כרגע.
יכול להיות שתהיתם לגבי הנקודה האחרונה - למה שמנהל הפיתוח יבדוק את זה?
לתפיסתנו, בשלב הזה המועמד בדרך כלל כבר מגיע אפוי אחרי מספר ראיונות אצל אנשי המוצר וזו הזדמנות טובה לרדת קצת יותר לפרטים. אם המועמד/ת לא מבינ/ה בכלל על מה אנחנו מדברים איתם - זה דגל אדום.
אז איך הלך הראיון?
הראיון שלנו התחלק לשלושה חלקים בני 15 דקות: החלק האישיותי, החלק המוצרי והחלק הטכני.
החלק האישיותי
בחלק האישיותי התחלנו בשאלות הרגילות - סיפורים על פרויקטי עבר ועבודה עם מפתחים ע״מ לנסות ולבחון את הנושא הראשון: הכימיה.
לא נרחיב עוד על החלק הזה כי הוא הכי פחות מעניין. לא שאנשים זה לא מעניין, פשוט, אתם יודעים...
החלק המוצרי
בשלב הזה דברים מתחילים להיות מעניינים יותר, והאי ודאות גדלה.
היינו רוצים לבחון את היכולת של הפרודקט לעבוד עם המפתחים בצורה שוטפת, ואיך היא תהיה מסוגלת לקבל החלטות במוצר שלנו ולהבין את המשמעויות שלהן.
לשאלה כזו כנראה אין פתרון אחד, וחשובה יותר הדרך מאשר הפתרון עצמו.
בחלק המוצרי, אנחנו מספרים למועמד על אתגר שאנחנו מתמודדים איתו. למשל: קיבלנו לפני חודשיים
החלטה להתמקד בבעיה מסוימת שאנחנו רוצים לפתור, וכל הפיצ׳רים שעבדנו עליהם מאז הם סביב פתרונות לבעיה הזאת.
מה הדבר הראשון שתעשה כשתגיע, כדי לוודא שאנחנו בכיוון הנכון.
זאת שאלה שהיא מטבעה קצת עמומה, ואנחנו לא נכנס כאן לפרטים כדי לא לעייף אתכם יותר ממה שכבר עשינו - אבל תנסו לחשוב על use case אצלכם שאתם פותרים לאחרונה ועוד אין לכם ולידציה טובה עליו.
כאן אנחנו בודקים כמה המועמד engaged למוצר ולבעיה שאנחנו פותרים ובאמת חקר עליה, וכמה הוא צנוע ביכולת שלו להתמודד עם בעיה חדשה.
בחלק הזה אנחנו בדרך כלל מגלים מנהלי מוצר שלא עשו שיעורי בית על השוק שאנחנו עובדים בו, ולא מכירים את בעלי התפקידים והכוחות שפועלים בו.
נגיד שוב - כמובן שאנחנו לא מצפים לרמת היכרות אינטימית עם השוק שלנו. אבל אם המועמד לא מסוגל למשל לדבר על בעלי התפקידים שהם הלקוחות שלנו (Data Engineers מכל הסוגים והמינים) - זה אומר הרבה.
תשובות שאנחנו אוהבים לשמוע ממועמדים לשאלת הולידציה לעיל, מתחילות ככה:
״דבר ראשון אקח שבוע ללמוד, לראיין לקוחות ולקוחות פוטנציאליים…״.
כל תשובה שתתחיל בפתרון כלשהו (לדוגמא: ״אני יכול כבר עכשיו להגיד שנראה לי מוזר שאנחנו עושים את פיצ׳ר y ולא x, כי נראה לי שהבעיה ש-x פותר הרבה יותר משמעותית״) ישר ירים לנו דגל אדום.
כשהכל הולך כיף וטוב, אנחנו עוברים לחלק הטכני.
החלק הטכני
בחלק הזה, אנחנו לוקחים פרויקט שהמועמד מכיר טוב: משהו שהוא עבד עליו בתפקיד האחרון שלו ויש לו בראש vision שלם עבורו, ומבקשים ממנו לספר לנו על המערכת הזו ולרדת לכמה שיותר פרטים.
זה חלק חריג קצת ושונה מראיון רגיל, וזה מצריך מאיתנו להיות מאוד מרוכזים וחדים.
אנחנו שואלים את המועמד שאלה מהסוג הבא:
״איזה פיצ'ר הכי היית רוצה לעשות במוצר שלך, ולמה לא עשית אותו״?
כאן למועמד יש המון קונטקסט שהוא צריך להעביר לנו, ולנו יש gap דיי רציני .זה מזכיר קצת את העולם האמיתי בצוות כמו שלנו, כשעובדים על פיצ'ר חדש שמגיע ממנהל המוצר.
אחרי שהמועמד יתאר את הפיצ'ר, ננסה לצלול לבעיה, לתאר את הארכיטקטורה של המערכת שלו כמו שאנחנו מבינים אותה, ולנסות להציע פתרונות אפשריים לבעיה הזאת:
למה שלא נלך על פתרון מסוג x? פתרון מורכב שידרוש עבודת תשתית של כמה חודשים?
למה שלא נלך על פתרון מסוג y? פתרון פשוט שיעבוד רק על חלק מהמקרים?
בשלב הזה, היינו רוצים לראות איך המועמד מסוגל לנהל tradeoffs ולקיים שיח טכני ממקום לא טכני.
אנחנו רוצים לראות איך הוא מבין את המגבלות הטכניות שהמהנדסים נתנו לו והאם הוא יודעת לגבות אותם.
תשובות שלא היינו רוצים לשמוע, הן מהסוג הזה:
״וואלה האמת מה שאתם מציעים אפשרי, אני אלך להגיד להם לעשות את זה ככה.״
״לא יודע. אמרו לי שזה הרבה עבודה והסבירו לי למה (או, לא הסבירו לי למה) אבל אני לא כלכך יודע לחזור על זה.״
מה הלך טוב, ומה לא?
רצנו עם התהליך הזה על כמה וכמה מועמדים, ואנחנו חושבים שבשורה התחתונה הוא היה דיי מוצלח.
היינו נותנים לעצמנו 7 מתוך 10 כזה.
או 5 מתוך 7.
החלק האישיותי היה קריטי אמנם, אבל אנחנו מעריכים שזה נדיר שמועמד שעבר כבר תהליך רציני והגיע עד אלינו יפול על החלק הזה של הראיון. במיוחד במשרות כמו מנהל מוצר שם יש דגש רציני על האישיות כחלק מה-skillset שנבחן בתהליך.
מה שהיה מעניין בחלק הטכני הוא שהצלחנו לחלץ ממועמדים מה הם באמת הם חושבים על הבעיה שאנחנו פותרים, כמה הם Engaged למה שהם הולכים לעשות אם יגיעו אלינו, וכמה הם מבינים את התרבות הארגונית שלנו ואיך אנחנו עובדים כצוותי מוצר.
הצלחנו להוציא מהרבה מועמדים צניעות וענווה ואהבנו מאוד את העובדה שהם ידעו להצביע על ה-blind spots הרציניים שלהם.
ראינו אנשים שחושבים טוב ויודעים לפתור בעיות.
הבעיה היא, בכנות, שאנחנו עדיין לא יודעים אם היינו מצליחים לפסול מועמד לא טוב מלהגיע אלינו, ובאופן כללי, כנראה שקל מאוד לשקר לנו - מה אנחנו מבינים הרי בניהול מוצר.
נכתב בשיתוף עם שני קינן, Director Of Product @ Databand.ai.
תעקבו אחריו, הוא מבין עניין.