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

השילוש הקדוש – המשתמש, הצורך, הערך 

בתחילת דרכי כמנהל מוצר היה לי מנהל ומנטור (תודה, אשר ב.) ששינן לנו מדי יום (באמת!) מנטרה קבועה: "המשתמש, הצורך, הערך" – או באנגלית: "User, Use Case, Value". והוא צדק – השלישיה הזו היא התמצית המזוקקת של עיקר העבודה של מנהל מוצר – השילוש הקדוש, אם תרצו.  

וקצת בהרחבה, כשאנחנו בונים מוצר, אנחנו צריכים לשאול את עצמנו יום-יום שלוש שאלות: 

1. מי המשתמש של המוצר שלנו?  
2. מה הצורך שלו? 
3. מה הערך שהמוצר שלנו יתן לו? 

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

המשתמש – להבין עבור מי המוצר 

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

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

אחרי שזיהינו את כל הפרסונות באירגון, נאפיין כל אחת מהן: 

• הגדרת התפקיד – מה מטרת העל שלה, על מה היא נמדדת? תנסו להשלים את המשפט:  As a …, my goal is to… 

• מה היא עושה כשהיא קמה בבוקר – מה סדר היום שלה בעבודה, מה המשימות הקבועות שלה – יומיות, חודשיות או שנתיות – מה האתגרים שלה, מה מלחיץ אותה או מדאיג אותה?  

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

 שיטה לא רעה לאיפיון המשימות הקבועות של פרסונה נקראת לפעמים User Stories, כלומר הגדרת הסיפורים של הפרסונה (וכמעט תמיד יהיו יותר מסיפור אחד), והפורמט הוא: 
When <CONTEXT>, I want to {JOB}, because I {MOTIVATION}, so I can {OUTCOME}
שימו לב שהניסוח הוא בגוף ראשון, וזה ממש חשוב. השימוש ב-I מכריח אתכם להתמקד במה שחשוב אישית לפרסונה ולא לאירגון. לדוגמה, המוטיבציה היא לא "כדי שהאירגון ירוויח יותר כסף" אלא "כדי שאני אקבל את ההכרה הראויה לי מצד המנהלים שלי".  

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

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

הצורך – הבעיה האמיתית ולא הסימפטום 

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

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

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

שיטה שאני מאוד אוהב שמאפשרת להגיע לשורש הבעיה נקראת "טכניקת 5 הלמות", או באנגלית "The 5 Whys Technique". הרעיון הוא לשאול את הלקוח "למה אתה רוצה את המוצר הזה?", ואז לשאול שוב "למה", ואז שוב, ושוב – 5 פעמים. קצת כמו ילד בן 3, בעצם. זה נשמע מעיק, אבל הגישה הזו מחייבת את המשתמש לחפור לעומק ולהבין מה באמת גורם לבעיה שלו ומה הוא באמת רוצה. הנה דוגמה קצת מעצבנת: הלקוח מבקש שנכין לו סושי, אבל אם נשאל למה הוא יבין שהוא בעצם רעב, ואם נחקור עוד, נגלה שהסיבה היא שהוא לא הספיק לאכול ארוחת בוקר בבית, ובחקירה נוספת נבין שהסיבה היא שהוא לא קם בבוקר, וכשנשאל שוב נבין שהשעון המעורר שלו לא עבד כי הסוללות נגמרו. במקרה כזה, במקום להכין ללקוח סושי, נבנה לו שעון מעורר שמחובר לחשמל. זה פשוט כמו שזה טיפשי.  

הערך – מה יוצא למשתמש מהמוצר שלנו? 

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

כשאנחנו חושבים על הערך, משפט המפתח הוא "מה יצא לי מזה?", או באנגלית: "What’s In It For Me?". הערך עבור הלקוח הוא לא מה שאנחנו חושבים שהוא, אלא מה שהמשתמש מרגיש שהוא מקבל. אם פתרנו את הבעיה הלא נכונה – הלקוח לא ירגיש שיש במוצר ערך בשבילו ולא ירצה בו.  

לסיכום – חזרה אל הבסיס 

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

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