כותב המאמר: אלמוג בוים, מנהל מוצר בחברת Energy Team
RoadMap! אותו המושג הכל כך חשוב שגורם לכולנו להתכנס לחזון המשותף של העסק שלנו, לעבור באותו הווקטור להשגת המטרות והיעדים שלנו, כל אחד במחלקתו שלו. המושג הזה עבר אבולציה מרשימה בכל ימי חייו. וכן, פעם קראו לו גם תוכנית עבודה (מושג שנשמע מעט פרימיטיבי, ושנוא על כל מי שיש לו יד ורגל במוצר, בואו נודה על האמת).
למעשה, מדובר בכלי אסטרטגי להגדרת תהליך הפיתוח של המוצר מימיו הראשונים. הכלי כולל תוכנית ברמת "על" להגדרת התכולות המרכזיות שיפותחו במוצר, והוא הדרך המרכזית על מנת לתקשר לארגון את תהליך העבודה. על מנת לבנות אותו, יש לקחת בחשבון לא מעט נושאים, ביניהם, האסטרטגיה הארגונית, סדרי העדיפויות בחברה, אילוצים, אירועים על ציר הזמן ועקרונות מנחים נוספים.
כאשר אנו ניגשים לבנות Roadmap, אנחנו לוקחים את אותם הפרמטרים שבעצם יש לנו בידיים – מסגרת זמן וכסף. את הפרמטרים האלו אנחנו צריכים להפגיש עם מה שאנחנו רוצים לפתח. סליחה, מה שאנחנו צריכים לפתח.
איך נשקף את המשמעות של ה MVP בתוך ה RoadMap
מאוד חשוב להבין, בתחילת הRoadMap מונח לו ה – minimum viable product (MVP) נכון זה עוד מושג, אבל הוא חשוב. MVP – ובתרגום לעברית – המוצר המינימאלי האפשרי. הגרסה הזו למוצר מייצרת לנו משהו התחלתי שניתן להשתמש בו עבור לקוחות ראשוניים. החשיבות שלו היא קבלת פידבק רלוונטי ומהיר לפיתוח המשך של המוצר. הסבר מורחב על השלב הזה ואיך בונים אותו נכון, אביא במאמר נפרד.
ברגע שהבנתם מהו ה MVP שלכם, הגיע הזמן לשחק את המשחק – להבין כמה כוח פיתוח צריך על מנת להשיק את המוצר במינימום זמן. נכון, זה מתנגש עם התקציב שיש לכם, עכשיו צריך לשבור את הראש ולהבין מה ה Time To Live (TTL) שיש לכם, ולדחוק את כל הצוות לעמוד בו, כי אחריו, לא יהיה לנו יותר כסף לשלם משכורות
מה עם הערך ללקוח?
הכל נשמע מהיר, דינאמי, כמו דבר שיכול לשנות את פניו כל בוקר. זה נכון, ככה עובד מוצר. מוצר טוב זה מוצר שהמשתמש צריך אותו, יירצה לחזור אליו ולהשתמש בו, כי הוא מביא ערך ללקוח. ערך זו מילת מפתח. מעתה ואילך, כל פעם שאנחנו מכניסים משהו ל RoadMap, אנחנו צריכים להבין איזה ערך הוא נותן ללקוח, או להיפך – אם הוא לא נותן ערך, לשאול – למה הוא ב RoadMap?
דרישות לקוח (כולל בעלי עניין)
אם נדבר על מה מזין את ה RoadMap שלנו, נבין שהוא כולל לא מעט מקורות. הדרישות יכולות להגיע ממקומות צפויים. דוגמאות אפשריות –
● המשתמשים
● החברים לצוות
● דרישות הדירקטוריון לייצר עוד רווחים בפרק זמן מוגבל (גם על תיעדוף נדבר).
● פיצ'ר חדש שיצא אצל המתחרים ואנחנו חייבים שיהיה גם אצלנו, כי אם לא, אנחנו מאבדים את נתח השוק.
● דאטא! כמה שאנחנו אוהבים דאטא וניתוח שימושיות של המשתמשים, ומה מתאים לכל סגמנט של משתמש.
צפוי זה פשוט. בדרך כלל ברור לנו מאוד גם שצריך להפנות לשם קשב ותשומת לב. אבל צריך לזכור שמול כל המקומות הצפויים, שמהם נבין די בקלות איך נשיג את דרישות הלקוח, יש את המקומות הלא צפויים. דוגמאות אפשריות –
● המרקטינג, שדורשים דף נחיתה לא פחות ממושלם כי דף הנחיתה הקיים כבר לא רלוונטי, או שהם הולכים להשיק קמפיין שעלול רחמנא ליצלן להביא לעומס מטורף של לידים למוצר שלנו.
● מערך המכירות שנתקל בבלוקר כי יש באג קטן במודול שאף אחד עדיין לא עלה עליו.
● מה עם אותם הלקוחות שרוצים לקבל ערך מסויים מהמוצר אבל אין להם ערוץ לפנות אליו?
יש עוד המון דוגמאות, אבל צריך להבין שבשביל לקבל תמונה מלאה של דרישות לקוח עבור המוצר, צריך לפעמים לעשות חיפוש גם בפינות המעניינות ולא ישר ללכת לדאשבורדים ולנתח אותם.
גם על לקוחות משלמים אפשר לדון בהרחבה, אבל חשוב לומר דבר מאוד קריטי, צריך לזכור שהם אלו שמקדמים את המוצר, ומגדילים לנו את ה TTL צריך לבצע איתם העמקה ולהבין איך הם משתמשים במוצר ומה הם רוצים לקבל.
תיעדוף – 80% ערך, 20% סטוריטלינג. האמנם?
אחרי שיצרתם לעצמכם Backlog לא פחות ממרשים, כזה שאתם יכולים להראות כמו הורים שגאים בו, הגיע הזמן לנתח אותו. נדרש לצבוע את משימות הMVP בנפרד כך שנדע שזו משימה משמעותית שצריכה לקבל עדיפות. יש להבין איזו משימה בנויה על אחרת ולהתחיל לתעדף.
בנקודה הזו אעצור ואומר, לכל חברה ולכל מנהל מוצר יש את השיטה שלו לתעדף את הRoadMap, וזה בסדר גמור. אין אמת אחת. מה באמת חשוב? חשוב להבין שיש כסף, וכנגד הכסף שאנחנו מוציאים אנחנו צריכים גם לייצר כסף, או מלקוחות חדשים או מלקוחות קיימים. אני מדבר על לקוחות משלמים!. דבר נוסף, צריך לזכור שלכל פרק זמן, נניח חודש (שלרוב זה סיפור של 2 ספרינטים), אנחנו מכניסים את כל העקרונות שלנו בחלוקה ריאלית – דליברי ללקוח (משהו שייצר כסף), מדדים, הכשרות (כן! אני מזכיר לכם שה RoadMapשלכם בנוי מהצוות שלכם! יש לתכנן עבורו גם את ההכשרות, זמני חניכה, זמני "גדילה" של צוות ועוד), שיפורי UI, תיקוני באגים וכו'. מאחורי כל התעדוף הזה רצוי שיעמוד סיפור. הסיפור מורכב ממי שאתם כמנהלי מוצר ומהערכים שמניעים אתכם בבניית המוצר. הערכים יכולים להיות אישיים או ערכי חברה, אבל מה שחשוב הוא שכשאתם מכניסים משהו לפני משהו ב RoadMap, תמיד כדאי שהוא יתכתב עם הסיפור שלכם, כך הרבה יותר קל לדלבר אותו לעצמכם ולמי שמשלם על זה.
תמחורי זמנים – האם הכל מתכנס?
בניתם RoadMap לעילא ולעילא, תיעדפתם את כל הפיצ'רים, הכל נראה פרפקט. הגיע הזמן לעשות עבודת תמחור של זמן הפיתוח. לכו לשבת עם צוות הפיתוח ותתייעצו – כמה זמן ומה המורכבות בפיתוח של כל אחד מהדברים. הדבר יכניס אתכם לפרופורציות, ללוחות זמנים. דברים שנראו מורכבים הופכים לפשוטים ולהיפך, ודברים משמעותיים שלוקחים המון זמן, גורמים לצוות הפיתוח ללכת ולחשוב על פתרונות יצירתיים לקראת הפיתוח.
בימינו, קשה מאוד להתחייב מה ייקרה מעבר לרבעון הנוכחי. השוק משתנה, המתחרים משתנים, הלקוחות והצרכים שלהם משתנים, וגם אתם, החברה והצוות משתנים!. לכן רצוי לבנות RoadMap ל3 חודשים, עם תוכנית מגירה לשלושה חודשים נוספים. כאשר אתם במהלך הרבעון, תתחילו לייצר ולתעדף לעצמכם משימות לקראות הרבעון הבא, וחוזר חלילה.
בהצלחה!
