סטארט אפ

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

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

מהו PRD?

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

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

יש לשים לב להבדל בין PRD ל-MRD, שהוא מסמך דרישות השוק, או Market Requirement Document. השוני הוא פשוט: MRD מתאר את ההזדמנות או את צרכי השוק, בעוד שה-PRD קשור למוצר, המתייחס להזדמנות או לצרכים.

מדוע PRD כה חשוב למנהלים?

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

מדוע מנהל מוצר מצליח זקוק ל-PRD? מכיוון שמטרתו העיקרית של PRD היא להגדיר את המוצר שרוצים ליצור – מתכליתו ועד לפיצ׳רים ולפונקציונאליות שלו. מסמך זה אינו רכושו הפרטי של מנהל המוצר, משום שעליו להיות משותף עם הצוותים הטכניים והעסקיים: מסמך PRD מעוצב היטב מספק הנחיות ברורות להשגת מטרות המוצר, ביצירתו הבנה משותפת בין הצוותים העסקיים והטכניים.

יתרונות וחסרונות ה-PRD

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

יתרונות ה-PRD

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

חסרונות ה-PRD

-צורך מזמנו של המנהל, לשם זיהוי ורישום כל הדרישות לפרויקט
-צורך כסף לפיתוח מסמך מפורט הכולל את כל האפיון

מה דורשת תבנית PRD איכותית?

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

-מטרות
-רכיבי מפתח
-User Flow
-פרטים אודות כל צעד ב User Flow
-אנליטיקה
-פיצ’רים עתידיים

כיצד ליצור PRD מעולה?

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

הקדמה (מטרות ויעדים): הצעד הראשון בהחלט בדרך ליצירת מסמך צריך להיות קשור למטרותיכם. זהו המקום בו אתם מציעים לקוראים אינפורמציית רקע, שתעזור להם להבין מהו המוצר.
שאלו את עצמכם: מיהו קהל היעד של המוצר שלכם? מהי הבעיה הגלובלית שאתם מנסים לפתור? מהן מטרות המוצר? וכן הלאה. כאן אסור להציג שום ספק, רק הבנה ברורה של הצורך ושל האופן בו המוצר נותן לו מענה.
באפשרותו של מנהל המוצר לייצר הצעת ערך ברורה ותמציתית, שתתקשר בקלות עם כולם – חברי הצוות, מנהלים ביצועיים, לקוחות, מנהלי מכירות ועוד.

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

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

פרטים אודות כל צעד ב User Flow: לאחר הגדרת המטרות, הרכיבים וה-user flow, הגיע הזמן לקבוע את מאפייניו של כל עמוד. עליכם לשרטט את האלמנטים של כל פיצ׳ר שעליו אתם עובדים ואת כל המצבים השונים שעשויים להתקיים.

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

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

כיצד ליצור PRD מעולה?

ניתן להפיץ את המסמך על כל שלביו באמצעות Google Doc פשוט או אפילו בקובץ אקסל. ואולם, במאה ה-21 צעדים גלובליים ואסטרטגיים רבים נעשים באמצעות כלים ושירותים ידידותיים.  

Roadmap יכסה את כל הצרכים הניהוליים שכם, ויקל על הדרך ללכידת אסטרטגיית ודרישות המוצר ולתקשורת עם הצוות. לא משנה אם בכלי האסטרטגי הזה משתמש מנהל מוצר אג׳ילי או אם מדובר ב-roadmap שיווקי – הפונקציונליות שלו תספיק ליישום אסטרטגיות ארוכות טווח ותוכניות יומיות כאחד.

מסקנות

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

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

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

מדוע זה כך?

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

בהערכת סטראט-אפ, המייסדים עושים תחילה את מה שהם יכולים לעשות, ו״חושבים ומדברים על המוצר״ בהחלט כלול בקטגוריה הזו. מתי הם מרגישים שהם כבר אינם עושים זאת בעצמם? כשמגיעים לתוצרי העבודה הממשיים שמנהלי מוצר מעבירים: שרטוטי מסכים וסיפורי משתמש. בערך באותו זמן העבודה מול ה-R&D (מחקר ופיתוח) מתחילה להיות אינטנסיבית יותר, כך שדרושה פעילות מאומצת מצד ניהול המוצר.

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

הגדרת מוצר כשלעצמה, אינה אסטרטגיה

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

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

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

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

גם העסקים הם העסק שלכם

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

במהדורה הראשונה של ספרו “Inspired”, מרטי קגן טוען שעל מנת שמוצר יצליח הוא חייב להיות בעל ערך, שמיש וישים. רק במהדורה השנייה, שהתפרסמה ב-דצמבר 2017, הוא הוסיף שהמוצר צריך גם להיות מעשי מבחינה עסקית. כמעט 10 שנים לקח לקגן להתייחס להיבט החשוב הזה בהובלת מוצר, כך שלא מפתיע שמובילי מוצר רבים אינם מבינים שהדבר מהווה חלק מתפקידם. למרבה הצער, מכיוון שמרבית המנכ״לים אינם מובילי מוצר מנוסים בעצמם או שלא עבדו בעבר עם כאלה, אין ביכולתם לומר למוביל המוצר שהדבר בתחום אחריותו, ודאי שלא להדריכו כיצד לעשות זאת.

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

תפקידו הכפול של מוביל המוצר

כאשר מתבוננים בתפקיד מוביל המוצר, או ה-CPO, בהשוואה לעמיתיו (CMO, CTO, CRO, CFO), תפקידו בולט. כל התפקידים הללו, כולל זה של ה-CPO, הם בעלי תחומי אחריות ביצועיים, כל אחד באגף שלו, וכולם הם מעין רשות מבצעת בתוך חברה, מה שאומר שהם חלק מהחלטות הקשורות לחברה, אפילו אם הן מחוץ לאחריותם הישירה. לכל בעלי התפקידים הללו יש תחומי אחריות אסטרטגיים בתוך הנישה שלהם, אך האחריות האסטרטגית של מוביל המוצר הולכת עד לרמת החברה וחוצה את כל שאר התחומים.

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

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

מסקנות

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

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

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

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

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

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

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

ייתכן וכבר חוויתם ישיבה גדולה בנוכחות אנשים רבים (20-25, לערך) הנחשבים לבעלי עניין, אשר הסתכמה בניהול תקשורת מורכבת. במקרים כאלה, רשימה ברורה של בעלי העניין מעניקה למנהלי מוצר הזדמנות לקבוע צוות ליבה וצוות מורחב, לניהול ישיבות אפקטיביות יותר ועל מנת להבטיח שהאנשים הנכונים נוכחים בישיבה, במקום לבזבז את הזמן על נוכחים נוספים. קבוצה קטנה מאפשרת את הסברת המצב לבעלי העניין באופן המוביל לתקשורת דו-כיוונית טובה יותר.

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

למשל, בפרויקט ניהול מוצר מומלץ ליישר קו בשלב מוקדם בנוגע להצהרת הבעיה (Problem Statement), לאחר מכן ליישר קו בנוגע לפתרונות העסקיים המוצעים ולבסוף ליישר קו בנוגע לפתרון המוצר. מכיוון שעל הארגון לקבל אישור של בעלי העניין בנוגע לכל שלושת השלבים הקריטיים הללו, יש ערך לשקיפות מלאה ביחס לגורמים שמהם יש לבקש אישורים להבאת מוצר לשוק, משום שהדבר יהפוך את תהליך המוצר לחלק הרבה יותר.

זיהוי בעלי עניין – התהליך לזיהוי בעלי העניין האמיתיים

צעד ראשון – סיווג צוות המוצר: פרקטיקה טובה היא להתחיל מלפצל את כל שיתופי הפעולה שלכם במסגרת הפרויקט באופן שיוצג מיד, מה שיסייע לכם להקטין את הפגישות המונות 20 איש ומעלה לקבוצות קטנות בנות פחות מ-10 משתתפים:

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

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

בעלי עניין: כל האנשים שיש להם עניין במוצר, כפי שפורט בתחילת המאמר – פנימיים וחיצוניים כאחד, ובהם משתמשים, לקוחות, VP ומנהלי C-level.

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

צעד שני – צלילה פנימה: הבחנה בין בעל עניין לבעל עניין מרכזי

– סקרו את רשימת כל האנשים מצוות הפרויקט לאחר שסווגו, והתמקדו ברשימות בעלי העניין ובעלי העניין המרכזיים בפרויקט.
– רשמו את שמותיהם ואז שאלו את עצמכם – מי מהם לא יוכל לישון היטב בלילה אם הפרויקט ייכשל? התשובה צריכה לכלול מספר מוגבל מאוד של בעלי עניין (5-8) וזוהי שאלת המפתח שעליה צריכים מנהלי מוצר להשיב לטובת הצלחת הפרויקט.
– ערוץ התקשורת לבעלי העניין המרכזיים צריך תמיד להיות פתוח, ויש לתת לו את מירב תשומת הלב משך כל מחזור חיי המוצר.

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

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

– כיצד הם מגדירים את הצלחת המוצר.
– כיצד נראית בעיניהם ההצלחה, במבט של 6-12 חודשים קדימה.
– מהו העניין שלהם במוצר.

במהלך הראיונות, על מנהל המוצר לקבל תחושה בנוגע למטריצת ההצלחה של כל אחד מבעלי העניין, 6-12 חודשים קדימה. ואולם, על מנת שהמוצר יצליח ויהיה מיושר קו עם מטרות בעלי העניין, כדאי להוסיף שערוך – בייחוד בנוגע למטריצת ההצלחה – כעבור 6-12 חודשים, לפחות מול בעלי העניין המרכזיים, שכן מטריצה זו יכולה להשתנות בחלוף הזמן.

מסקנות

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

תחום ניהול המוצר, כמו כל ענף מקצועי אחר, מלא בעצות מאנשים ש״היו שם ועשו את זה״. וזה אדיר! נפלא שיש קהילת מקצוענים מלאי תשוקה, שלהוטים לסייע לאחרים לפרוץ בתעשייה, לבצע שינויים, לקבל קידום, לנהל צוות או כל שאר הדברים שביניהם. מנהלי מוצר לומדים זה מזה, ועצות ממומחים הן נכס עצום. אבל יש סוג נוסף של עצות, כזה שכולנו חווים מעת לעת: עצות לא רצויות, או פשוט רעות.

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

״עבדו לבד על ה-Roadmap״

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

מדוע זו עצה רעה? העצה הזו שגויה בכל כך הרבה רמות… ראשית, מי שנותן אותה מניח שיכול להגיע רגע בו ה-roadmap יהיה מדויק ב-100%. בפועל, לא קיים roadmap מוגמר וללא רבב.

אם בחצי הדרך בפיתוח אתם מבינים שהמוצר שנבנה אינו מעולה כמו שחשבתם שיהיה, עליכם להיות מסוגלים לבצע התאמות לפיצ׳רים, מה שאומר לחזור אל ה-roadmap ולערוך בו כמה שינויים.
שנית, העצה הזו מניחה שמנהל מוצר הוא האדם היחיד שיכולה להיות לו נגיעה מועילה ל-roadmap. אך כיצד זה יכול להיות נכון, אם מנהל המוצר אינו האדם היחיד שעובד על המוצר הממשי? ארכיטקט אינו בונה בית שלם בעצמו!

העצה האמיתית: אל תחשבו על ה-roadmap כעל דבר שיכול להיות ״מוגמר״ אי פעם. גלו פתיחות לשינויים ולשיתופי פעולה. צוות שהולך לבנות מוצר מעולה ביחד חייב להיות מסוגל לבנות ביחד roadmap.

״אתם שולטים במפתחים״

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

מדוע זו עצה רעה? המחשבה שיש לכם איזושהי סמכות ביחס המהנדסים היא דרך מהירה לקנות לכם אויבים, בעיקר בקרב מובילי צוותי ההנדסה!

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

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

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

״אתם מנכ״לים״

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

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

אם תחשבו על עצמכם כעל מנכ״לים המסתכלים על דבר מה מלמעלה, זוהי תהיה החמצה גמורה של רכיב שנעדר מהעמדה שלכם – סמכות. הבעיה העיקרית היא שלבסוף תתפסו את עצמכם ככאלה שיש להם סמכות הרבה יותר גדולה ממה שיש לכם באמת.

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

״הנתונים לא משנים״

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

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

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

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

״אין לכם את ההכשרה להיות מנהלי מוצר״

העצה: הדרך היחידה להפוך למנהל מוצר היא לרכוש תואר במדעי המחשב ולצבור ניסיון תעסוקתי בעולם הטכנולוגיה. אתם חייבים גם לדעת לכתוב קוד וגם להיות בעלי מיומנויות חזקות של ניהול עסקים. אגב, אתם צריכים גם לשלוט ב-AI, בבלוקצ׳יין וברובוטיקה קוונטית…

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

אבל האמת היא שישנם מסלולים רבים שמובילים אל תחום המוצר. אין שתי משרות ניהול מוצר זהות, מה שאומר שעליכם פשוט למצוא את זו הנכונה עבורכם. אם יש לכם רקע טכני, אתם נמצאים בעמדה טובה יותר לעבוד בענקית טכנולוגיה, כמו Google, Apple ו-Microsoft. אם הרקע שלכם נוגע יותר לשיווק, יעוץ עסקי או עיצוב, עדיין יש המון תקווה! כמה ממובילי המוצר הטובים ביותר הגיעו ממגוון רקעים ועם תארים שנעים מכלכלה ועד אמנות.

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

שיתוף מקצועי, אם כן, יכול להיות דבר נפלא, כל עוד לא לוקחים כל עצה כאורים ותומים. יש לא מעט עצות אחיתופל שם בחוץ…

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

מיתוס 1: מנהלי מוצר חייבים להיות בוגרי תואר בתחום מדעי המחשב

המיתוס הזה נובע מהתפיסה השגויה לפיה כל מי שעובד בתעשיית ההייטק חייב להיות בעל הבנה טכנולוגית עמוקה. אלא שכמו בכל תעשייה, הטכנולוגיה משגשגת על מצע מגוון של כוחות ושחקנים, כל אחד מהם בעל יכולות, חוויות וכישרונות אחרים. אפילו חברות הטכנולוגיה הבסיסיות ביותר יזדקקו לאגף משאבי אנוש, לצוות שיווק, למעצבים גראפיים ולמעצבי UX/UI. כל אלה תפקידים שדורשים, לכל היותר, עניין בטכנולוגיה, אך מובן שלא הבנה עמוקה של ידע מעשי בבניית אפליקציה.

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

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

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

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

ומה אם אין לי תואר במדעי המחשב?

ללא ספק תוכלו עדיין לעבוד בתחום! כמה מאנשי המקצוע המצליחים והמוערכים ביותר בענף מעולם לא למדו לתואר במדעי המחשב. אחרי הכל, תכנית העבודה של המוצר אינה נכתבת בקוד…

מי שאין לו ביד תואר במדעי המחשב, פשוט מחפש אחר תפקידי מוצר שאינם דורשים כזה. פירוש הדבר הוא הימנעות מכל מודעת דרושים שכותרתה כוללת את המילה ״טכני״, וככלל אצבע – גם כל מודעה בתחום שפורסמה מטעם Apple או Google. אם אתם מצויים ממש בתחילת הדרך, חפשו תפקידים בחברות קטנות ובסטארט-אפים, שם יעריכו יותר את כישוריכם הלא-טכניים.

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

מיתוס 2: מנהלי מוצר הם מנכ״לים של המוצר שלהם

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

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

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

אז איך משפיעים ללא סמכות…?

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

מיתוס 3: עבודתו של מנהל המוצר מסתיימת עם השקת המוצר

הייתם מתים… או במילים אחרות: מיתוס מוחלט. לאחר ההשקה, צוות המוצר מתחיל לאסוף את המשובים המתקבלים אודות המוצר ששוחרר, יהא זה מוצר בר-קיימא מינימלי (MVP) או האיטרציה ה-200 שלו… לא רק שאסטרטגיית המוצר אינה מסתיימת ברגע שהוא עובר לידי הלקוח, אלא שרבים יטענו שבשלב הזה רק מתחילה עבודתו האמיתית של בעל המוצר!

אז מה מנהלי מוצר עושים אחרי ההשקה?

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

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

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

מיתוס 4: ניהול מוצר זהה בכל חברה

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

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

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

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

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