מאמר זה יציג בפניכם את 5 האתגרים הבולטים בניהול מוצר תוכנה ארגוני, ואת האופנים שבהם ניתן לנהל את האתגר.
ניהול מוצר הוא תחום מתפתח, מימי תוכנת הדסקטופ המוקדמים ועד למקום בו אנו עומדים היום. חברות רבות מציעות הכשרה בניהול מוצר, אפילו תעודת הסמכה, והן עושות עבודה מעולה בלימוד היסודות – פרסונות, הבנת הלקוח, בעיות השוק, דרישות ועוד.
ועדיין, תרגום ההכשרות וההסמכות הללו ליישום מוצלח בעולם האמיתי הוא מאתגר. ישנן אינספור קהילות שבהן מנהלי מוצר חולקים ידע ומחליפים ביניהם טיפים וטריקים, ואולם מנהלי מוצר של אפליקציות ארגוניות הם חבורה בודדה למדי. לעתים קרובות מדי ההצעות הרווחות אינן רלוונטיות לאפליקציות ארגוניות, שם הדינמיקה עשויה להיות שונה מאוד.
אלה האתגרים:
#1 לא תמיד הלקוח הוא המשתמש
פרסונות אינן דבר חדש לאיש בתחום ניהול המוצר, ומרבית אנשי ניהול המוצר מיומנים בהתמקדות בפרסונות משתמש. אך בעולם האפליקציות הארגוניות יש צורך לא רק בהכרת המשתמשים אלא גם בהבנה של המניעים או מערכת היחסים של המשתמשים עם הלקוח.
מדוע האתגר הזה חשוב? מכיוון שייתכן ולא תתאפשר גישה אל משתמשי הקצה לשם איסוף משוב, ובמקרים מסוימים המוצר מסופק כשירות למשתמשי הקצה על ידי הלקוח. הדבר דורש משנה זהירות בהשקת עדכונים לאפליקציה או בשינוי חוויית המשתמש באופן משמעותי, אפילו אם מדובר בשיפור. במצבים כאלה עדכונים שעומדת מאחוריהם כוונה טובה הופכים לשטף של שיחות טלפון למוקד התמיכה של הלקוח מצד משתמשים מבולבלים. שטף השיחות מסלים עד מהרה לכדי בעיה של מנהל המוצר.
איך מתמודדים עם האתגר?
1 במידה ואתם שוקלים שינוי בחוויית משתמש הקצה, ודאו שצוות ה UX שלכם יכול לבנות מוקאפים או מוקאפים אינטראקטיביים שניתן להראות אותם למדגם של משתמי קצה
2 נסו להבין את מערכת היחסים המסחרית בין הלקוח ללקוחותיו שלו, שכן הדבר עשוי לספק קונטקסט חשוב שיכול להיות לו ערך רב
3 שקלו להשקיע בהדרכה שטחית ואינטראקטיבית אודות המוצר. ישנם כלים ביניהם: Walkme, Pendo שיכולים לספק הדרכות קצרות למשמשי קצה כאשר אתם מציגים בפניהם שינוי
#2 לרכש לא אכפת עד כמה האפליקציה שלכם מדהימה
אחת הפרסונות הכי מפוספסות על ידי מנהלי מוצר המתעסקים לראשונה באפליקציה ארגונית היא מחלקת הרכש. לרוב, הרכש נכנס אל התמונה לאחר שהאפליקציה נבחרה, ואם חשבתם שזהו הרגע שבו הסתיימה העבודה הקשה – חשבו שוב… עבודת הרכש היא להבטיח שהחברה תשיג את המחיר הטוב ביותר האפשרי ולהגן על עובדיה באמצעות תנאים והסכמים שישחקו לטובתם.
מדוע הרכש עשוי להיות מאתגר? כיוון שעבודת צוות הרכש היא להבטיח את ביצוע העסקה הטובה ביותר עבור החברה, הם ישוו את האפליקציה שלכם לאחרות. אם מרחב של האפליקציה שלכם מוגדר היטב, לא תהיה כל בעיה והם ימצאו את המתחרים שלכם בקלות. אם לא, תהיה חשיבות קריטית לאופן בו תמצבו את האפליקציה שלכם, משום שלא תרצו להיות מושווים אל האפליקציות הלא נכונות.
איך מתמודדים עם האתגר?
1 ודאו שהחומרים השיווקיים שלכם מתמקדים בערכי הליבה שמבדלים אתכם מהמתחרים
2 נסחו רשימה קצרה של המתחרים ושקלו לספק אותה לצוות הרכש כסוג האפליקציות שאליהן יש להשוות את זו שלכם
#3 התייחסו אל צוות השירותים המקצועי שלכם כלקוח הראשון
באפליקציות ארגוניות נעשה תמיד שימוש בצוותים פנימיים או חיצוניים. תוכלו לבנות אפליקציה מהוללת, אך אם לא יהיו לכם משאבים הבקיאים באופן בו יש לפרוש ולקבוע את הקונפיגורציה עבור הלקוח, הסיכוי שהאפליקציה תאומץ נמוך.
עליכם להתייחס אל קבוצות השירותים המקצועיות כלקוח הראשון שלכם. ממש כאילו אתם עובדים על MVP (מוצר בר-קיימא מינימלי) מוקדם בעולם האפליקציות ה״רגילות״, בו הייתם יכולים לקבל פידבק רב מהלקוחות, בעולם האפליקציות הארגוניות עליכם לשכפל ולהרחיב זאת לפידבק מצוותי השירותים שלכם.
מדוע ההתעלמות מצוותי השירותים שלכם מאתגרת? פעמים רבות צוותים אלה מופנים כלפי הלקוח והם בעלי ידע עשיר בנוגע לאופן בו פועלים הלקוחות. ככל הנראה, פיתוח פונקציונאליות שחדשה להם לחלוטין או שאינה מבוססת על הידע הקיים שלהם יגרום להם להיאבק בניסיון ליישמה. מכיוון שמדובר במשאב שעבורו משלמים, סביר להניח שכל עיכוב ביישום יגרום להם לנסות ולקבל לעזרתם בצורת משאבי מוצר והנדסה. הוגן או לא, קל הרבה יותר לנדב ״בחינם״ זמן מניהול ההנדסה או המוצר מאשר לשכנע את הלקוח שעליו לשלם עבור יותר שעות.
איך מתמודדים עם האתגר?
1 התייחסו אל צוות השירותים שלכם כלקוח הראשון שלכם. למשל, ערבו אותם בשלב מוקדם במחקר השוק שלכם. נוסף על כך, הם יוכלו להצביע על לקוחות קיימים שעשוי להיות להם אינפוט בעל ערך לבעיה שבה אתם מתמקדים
2 במהלך העיצוב והפיתוח, כדאי לכלול אותם בתהליך הסקירה
3 תכננו מראש את הטכנולוגיה ואת הכשרת הסגל. כמו במקרה של קבוצות ההנדסה, גם לקבוצות השירותים יש כישורים וידע מגוונים
#4 האפליקציה שלכם היא רק חלק אחד בפאזל
לעתים קרובות אפליקציות ארגוניות מכוונות לפתרון בעיות עסקיות הנוגעות לתחומים רבים של החברה. למשל, על פניו אפליקציות CMMS (אחזקה ממוחשבת של מערכות ניהול) נוגעות לסדרי עבודה. הגדרת הנתונים המתאימים עבור העובדים מתורגם לאינטגרציה עם פתרונות משאבי אנוש שבהם משתמש הלקוח. מובן שהאינטגרציה יכולה להיות ידנית או ממוכנת, אבל כך או כך – זו עדיין דרישה.
הנקודה היא שהאפליקציה שלכם היא אחת מני רבות בנוף, ובמקרים מסוימים היא עשויה אפילו שלא להיות אפליקציית מפתח בעיניי הלקוח.
מדוע זה אתגר? טבע האדם הוא להאמין שהדברים שאנו עובדים עליהם הם בעלי חשיבות גבוהה. באופן דומה, מנהלי מוצר מרגישים שיש לאפליקציה שלהם חשיבות מרכזית והם יכולים להיאבק בניסיון לתקשר עם לקוח שעוסק במגוון אפליקציות. סביר להניח שחוסר הבנה בנוגע למקום אליו שייכת האפליקציה שלכם בנוף הרחב יגרום לכם לפספס דרישות מפתח באינטגרציה של APIs (ממשקים לתכנות מחשבים).
איך מתמודדים עם האתגר?
1 הבינו את מהלך העבודה: חשוב שתקנו לכם הבנה הולמת של מהלך העבודה של הלקוח. ניתן לעשות זאת על ידי פעילויות מחקר משתמש, כמו ראיונות קונטקסטואליים או מיפוי מסע לקוח
2 תכננו את העתיד והתמקדו בבניית APIs: הדבר יעניק לכם דרך להשתלבות עם אפליקציות אחרות
3 תכננו מתן גישה לנתונים: לקוחות ארגוניים אוהבים דאשבורדים מתוחכמים שמספקים נראות של KPIs (מדדי ביצוע מרכזיים) ועוד. ישנם לקוחות שהם גדולים מספיק להקדשת צוותים פנימיים למטרה זו, וגם אם לא – בניית אלמנט מוצלח של ויזואליזציה של הנתונים שלכם תהיה בכל אופן דבר שיועיל למוצר שלכם
#5 הבינו את מודל החדירה לשוק (Go to Market)
כאשר אתם שוכרים מנהלי מוצר חדשים אל צוות, עליכם להזכיר להם שוב ושוב שאפליקציות ארגוניות יכולות להיות מרובות-מסלולים מבחינת החדירה אל השוק, ומיצוב המוצר משחק תפקיד עצום בהצלחת ערוצי ה-go to market הללו.
הערוצים יכולים להיות שונים מאוד, אבל במאמר זה נצטמצם לסוגים הבאים:
מוכרים המספקים ערך מוסף (VARs) – שותפים המוכרים את האפליקציה שלכם עם ערך מוסף או מומחיות מצדם.
ספקי טכנולוגיה או שירות – שותפים המוכרים את האפליקציה שלכם אך למעשה הם ספקים של החברות שלהם.
אינטגרטורים – חברות גדולות המנסות להציע פתרונות מוכנים לשימוש לחברות אחרות, באמצעות שילוב פתרונות של מוכרים שונים.
איך מתמודדים עם האתגר?
1 דברו עם עמיתיכם בצוות המכירות על מנת להבין את סוג השותפים הקיימים כיום ומהו סוג השותפים שדרכם החברה מחפשת למכור את המוצר. דרישות המוצר ישתנו בהתאם לסוג השותפים, ויש להיות מודעים לכך
2 קבעו מיצוב ברור. יש להבין שהשותפים אינם מומחים באפליקציה שלכם וההבנה שלהם אותה תהיה מבוססת על מידת החוזק של חומרי ההכשרה שתכינו עבורם (אם בכלל)
3 יסדו תהליכי תמיכה ואסקלציה ברורים. חשוב ביותר שתגדירו תהליכים ברורים לאופן שבו שותף מספק או מקבל תמיכה בנוגע למוצר, ולמקרים של אסקלציה. כמנהלי מוצר, יש לכם אינטרס לדחוף לקביעת התהליכים הללו, אפילו אם הם לא בתחום אחריותכם, משום שסביר להניח שהם יהוו הסחת דעת עבורכם בעתיד אם לא יוגדרו מראש
דברי סיכום
תפקיד מנהל המוצר במקרה של אפליקציות ארגוניות עשוי להיות מאתגר, אך בה בעת מתגמל מאוד. קנה המידה שבו הלקוחות הללו מתמודדים עם בעיות הוא מעורר השראה, והתחושה שכל יום אלפי אנשים עושים שימוש באפליקציה היא מתגמלת להפליא. מאמר זה נועד להדגיש את האתגרים שיש להיות ערים להם, ולספק דרכי התמודדות עמם.
מאמר זה יציג בפניכם את 5 האתגרים הבולטים בניהול מוצר תוכנה ארגוני, ואת האופנים שבהם ניתן לנהל את האתגר.
ניהול מוצר הוא תחום מתפתח, מימי תוכנת הדסקטופ המוקדמים ועד למקום בו אנו עומדים היום. חברות רבות מציעות הכשרה בניהול מוצר, אפילו תעודת הסמכה, והן עושות עבודה מעולה בלימוד היסודות – פרסונות, הבנת הלקוח, בעיות השוק, דרישות ועוד.
ועדיין, תרגום ההכשרות וההסמכות הללו ליישום מוצלח בעולם האמיתי הוא מאתגר. ישנן אינספור קהילות שבהן מנהלי מוצר חולקים ידע ומחליפים ביניהם טיפים וטריקים, ואולם מנהלי מוצר של אפליקציות ארגוניות הם חבורה בודדה למדי. לעתים קרובות מדי ההצעות הרווחות אינן רלוונטיות לאפליקציות ארגוניות, שם הדינמיקה עשויה להיות שונה מאוד.
אלה האתגרים:
#1 לא תמיד הלקוח הוא המשתמש
פרסונות אינן דבר חדש לאיש בתחום ניהול המוצר, ומרבית אנשי ניהול המוצר מיומנים בהתמקדות בפרסונות משתמש. אך בעולם האפליקציות הארגוניות יש צורך לא רק בהכרת המשתמשים אלא גם בהבנה של המניעים או מערכת היחסים של המשתמשים עם הלקוח.
מדוע האתגר הזה חשוב? מכיוון שייתכן ולא תתאפשר גישה אל משתמשי הקצה לשם איסוף משוב, ובמקרים מסוימים המוצר מסופק כשירות למשתמשי הקצה על ידי הלקוח. הדבר דורש משנה זהירות בהשקת עדכונים לאפליקציה או בשינוי חוויית המשתמש באופן משמעותי, אפילו אם מדובר בשיפור. במצבים כאלה עדכונים שעומדת מאחוריהם כוונה טובה הופכים לשטף של שיחות טלפון למוקד התמיכה של הלקוח מצד משתמשים מבולבלים. שטף השיחות מסלים עד מהרה לכדי בעיה של מנהל המוצר.
איך מתמודדים עם האתגר?
1 במידה ואתם שוקלים שינוי בחוויית משתמש הקצה, ודאו שצוות ה UX שלכם יכול לבנות מוקאפים או מוקאפים אינטראקטיביים שניתן להראות אותם למדגם של משתמי קצה
2 נסו להבין את מערכת היחסים המסחרית בין הלקוח ללקוחותיו שלו, שכן הדבר עשוי לספק קונטקסט חשוב שיכול להיות לו ערך רב
3 שקלו להשקיע בהדרכה שטחית ואינטראקטיבית אודות המוצר. ישנם כלים ביניהם: Walkme, Pendo שיכולים לספק הדרכות קצרות למשמשי קצה כאשר אתם מציגים בפניהם שינוי
#2 לרכש לא אכפת עד כמה האפליקציה שלכם מדהימה
אחת הפרסונות הכי מפוספסות על ידי מנהלי מוצר המתעסקים לראשונה באפליקציה ארגונית היא מחלקת הרכש. לרוב, הרכש נכנס אל התמונה לאחר שהאפליקציה נבחרה, ואם חשבתם שזהו הרגע שבו הסתיימה העבודה הקשה – חשבו שוב… עבודת הרכש היא להבטיח שהחברה תשיג את המחיר הטוב ביותר האפשרי ולהגן על עובדיה באמצעות תנאים והסכמים שישחקו לטובתם.
מדוע הרכש עשוי להיות מאתגר? כיוון שעבודת צוות הרכש היא להבטיח את ביצוע העסקה הטובה ביותר עבור החברה, הם ישוו את האפליקציה שלכם לאחרות. אם מרחב של האפליקציה שלכם מוגדר היטב, לא תהיה כל בעיה והם ימצאו את המתחרים שלכם בקלות. אם לא, תהיה חשיבות קריטית לאופן בו תמצבו את האפליקציה שלכם, משום שלא תרצו להיות מושווים אל האפליקציות הלא נכונות.
איך מתמודדים עם האתגר?
1 ודאו שהחומרים השיווקיים שלכם מתמקדים בערכי הליבה שמבדלים אתכם מהמתחרים
2 נסחו רשימה קצרה של המתחרים ושקלו לספק אותה לצוות הרכש כסוג האפליקציות שאליהן יש להשוות את זו שלכם
#3 התייחסו אל צוות השירותים המקצועי שלכם כלקוח הראשון
באפליקציות ארגוניות נעשה תמיד שימוש בצוותים פנימיים או חיצוניים. תוכלו לבנות אפליקציה מהוללת, אך אם לא יהיו לכם משאבים הבקיאים באופן בו יש לפרוש ולקבוע את הקונפיגורציה עבור הלקוח, הסיכוי שהאפליקציה תאומץ נמוך.
עליכם להתייחס אל קבוצות השירותים המקצועיות כלקוח הראשון שלכם. ממש כאילו אתם עובדים על MVP (מוצר בר-קיימא מינימלי) מוקדם בעולם האפליקציות ה״רגילות״, בו הייתם יכולים לקבל פידבק רב מהלקוחות, בעולם האפליקציות הארגוניות עליכם לשכפל ולהרחיב זאת לפידבק מצוותי השירותים שלכם.
מדוע ההתעלמות מצוותי השירותים שלכם מאתגרת? פעמים רבות צוותים אלה מופנים כלפי הלקוח והם בעלי ידע עשיר בנוגע לאופן בו פועלים הלקוחות. ככל הנראה, פיתוח פונקציונאליות שחדשה להם לחלוטין או שאינה מבוססת על הידע הקיים שלהם יגרום להם להיאבק בניסיון ליישמה. מכיוון שמדובר במשאב שעבורו משלמים, סביר להניח שכל עיכוב ביישום יגרום להם לנסות ולקבל לעזרתם בצורת משאבי מוצר והנדסה. הוגן או לא, קל הרבה יותר לנדב ״בחינם״ זמן מניהול ההנדסה או המוצר מאשר לשכנע את הלקוח שעליו לשלם עבור יותר שעות.
איך מתמודדים עם האתגר?
1 התייחסו אל צוות השירותים שלכם כלקוח הראשון שלכם. למשל, ערבו אותם בשלב מוקדם במחקר השוק שלכם. נוסף על כך, הם יוכלו להצביע על לקוחות קיימים שעשוי להיות להם אינפוט בעל ערך לבעיה שבה אתם מתמקדים
2 במהלך העיצוב והפיתוח, כדאי לכלול אותם בתהליך הסקירה
3 תכננו מראש את הטכנולוגיה ואת הכשרת הסגל. כמו במקרה של קבוצות ההנדסה, גם לקבוצות השירותים יש כישורים וידע מגוונים
#4 האפליקציה שלכם היא רק חלק אחד בפאזל
לעתים קרובות אפליקציות ארגוניות מכוונות לפתרון בעיות עסקיות הנוגעות לתחומים רבים של החברה. למשל, על פניו אפליקציות CMMS (אחזקה ממוחשבת של מערכות ניהול) נוגעות לסדרי עבודה. הגדרת הנתונים המתאימים עבור העובדים מתורגם לאינטגרציה עם פתרונות משאבי אנוש שבהם משתמש הלקוח. מובן שהאינטגרציה יכולה להיות ידנית או ממוכנת, אבל כך או כך – זו עדיין דרישה.
הנקודה היא שהאפליקציה שלכם היא אחת מני רבות בנוף, ובמקרים מסוימים היא עשויה אפילו שלא להיות אפליקציית מפתח בעיניי הלקוח.
מדוע זה אתגר? טבע האדם הוא להאמין שהדברים שאנו עובדים עליהם הם בעלי חשיבות גבוהה. באופן דומה, מנהלי מוצר מרגישים שיש לאפליקציה שלהם חשיבות מרכזית והם יכולים להיאבק בניסיון לתקשר עם לקוח שעוסק במגוון אפליקציות. סביר להניח שחוסר הבנה בנוגע למקום אליו שייכת האפליקציה שלכם בנוף הרחב יגרום לכם לפספס דרישות מפתח באינטגרציה של APIs (ממשקים לתכנות מחשבים).
איך מתמודדים עם האתגר?
1 הבינו את מהלך העבודה: חשוב שתקנו לכם הבנה הולמת של מהלך העבודה של הלקוח. ניתן לעשות זאת על ידי פעילויות מחקר משתמש, כמו ראיונות קונטקסטואליים או מיפוי מסע לקוח
2 תכננו את העתיד והתמקדו בבניית APIs: הדבר יעניק לכם דרך להשתלבות עם אפליקציות אחרות
3 תכננו מתן גישה לנתונים: לקוחות ארגוניים אוהבים דאשבורדים מתוחכמים שמספקים נראות של KPIs (מדדי ביצוע מרכזיים) ועוד. ישנם לקוחות שהם גדולים מספיק להקדשת צוותים פנימיים למטרה זו, וגם אם לא – בניית אלמנט מוצלח של ויזואליזציה של הנתונים שלכם תהיה בכל אופן דבר שיועיל למוצר שלכם
#5 הבינו את מודל החדירה לשוק (Go to Market)
כאשר אתם שוכרים מנהלי מוצר חדשים אל צוות, עליכם להזכיר להם שוב ושוב שאפליקציות ארגוניות יכולות להיות מרובות-מסלולים מבחינת החדירה אל השוק, ומיצוב המוצר משחק תפקיד עצום בהצלחת ערוצי ה-go to market הללו.
הערוצים יכולים להיות שונים מאוד, אבל במאמר זה נצטמצם לסוגים הבאים:
מוכרים המספקים ערך מוסף (VARs) – שותפים המוכרים את האפליקציה שלכם עם ערך מוסף או מומחיות מצדם.
ספקי טכנולוגיה או שירות – שותפים המוכרים את האפליקציה שלכם אך למעשה הם ספקים של החברות שלהם.
אינטגרטורים – חברות גדולות המנסות להציע פתרונות מוכנים לשימוש לחברות אחרות, באמצעות שילוב פתרונות של מוכרים שונים.
איך מתמודדים עם האתגר?
1 דברו עם עמיתיכם בצוות המכירות על מנת להבין את סוג השותפים הקיימים כיום ומהו סוג השותפים שדרכם החברה מחפשת למכור את המוצר. דרישות המוצר ישתנו בהתאם לסוג השותפים, ויש להיות מודעים לכך
2 קבעו מיצוב ברור. יש להבין שהשותפים אינם מומחים באפליקציה שלכם וההבנה שלהם אותה תהיה מבוססת על מידת החוזק של חומרי ההכשרה שתכינו עבורם (אם בכלל)
3 יסדו תהליכי תמיכה ואסקלציה ברורים. חשוב ביותר שתגדירו תהליכים ברורים לאופן שבו שותף מספק או מקבל תמיכה בנוגע למוצר, ולמקרים של אסקלציה. כמנהלי מוצר, יש לכם אינטרס לדחוף לקביעת התהליכים הללו, אפילו אם הם לא בתחום אחריותכם, משום שסביר להניח שהם יהוו הסחת דעת עבורכם בעתיד אם לא יוגדרו מראש
דברי סיכום
תפקיד מנהל המוצר במקרה של אפליקציות ארגוניות עשוי להיות מאתגר, אך בה בעת מתגמל מאוד. קנה המידה שבו הלקוחות הללו מתמודדים עם בעיות הוא מעורר השראה, והתחושה שכל יום אלפי אנשים עושים שימוש באפליקציה היא מתגמלת להפליא. מאמר זה נועד להדגיש את האתגרים שיש להיות ערים להם, ולספק דרכי התמודדות עמם.
