המשתמשים שלך מתלוננים? זה דבר טוב!

דרישות המוצר החבויות בתלונות המשתמשים של המוצר שלך

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

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

***

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

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

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

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

***

"דרישות מוצר חבויות (Hidden Requirements)"

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

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

"… אם היינו שואלים את האנשים מה הם רוצים, הם היו אומרים סוסים מהירים יותר… "

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

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

איך מזהים דרישות מוצר חבויות

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

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

לשאול "למה?" שוב ושוב, היא למעשה טכניקה מוכרת שנועדה לאיתור בעיות בתהליכים במהירות מקסימלית, והיא עדיין מיושמת כיום בצורה נרחבת בתעשיות שונות. הטכניקה הזו, בשמה המוכר The 5 Why’s, שפותחה בשנות ה-50 של המאה הקודמת על ידי סאקיצ'י טויודה  ו-טאיצ'י אונו, מאבות המהפכה התעשייתית ביפן, טוענת שאתה יכול להגיע לשורש של כל בעיה שהיא על ידי שאילת השאלה "למה?" 5 פעמים או פחות. שורש הבעיה, היא הבעיה הבסיסית במוצר שלכם שיוצרת את הסימפטומים אשר מפריעים למשתמש, או אותו צורך משתמש שנותר ללא מענה בזמן השימוש במוצר שלכם. זהו בעצם הדבר שאתם רוצים לפתור על מנת לשפר את המוצר שלכם, או אפילו מעבר לכך – להפוך אותו לטוב ביותר בתחומו. דוגמאות נוספות לשימוש בשיטה

 

בחזרה לאפליקציית החדשות הצעירה שלנו…

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

מציאת דרישות המוצר החבויות

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

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

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

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

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

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

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

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

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

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

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

"אפשרו לנו לשנות את הגדרות הצליל של ההתראות (push notification)"

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

אבל, הצורך בצליל התראות ייחודי לא היה המסקנה העיקרית שלנו מהפידבק הזה. העובדה שהמשתמשים ביקשו זאת שוב ושוב לא היתה הסיבה שהשקענו משאבים בפיתוח שני פיצ'רים שונים תוך זמן קצר, סביב אותו נושא. הייתה זו בעצם "דרישת המוצר החבויה" מאחורי הבקשות הללו, שהיתה חשובה הרבה יותר מבחינתנו. הנה המסקנות שהסקנו מתוך יישום שיטת ה 5 why’s גם על הבקשה השלישית:

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

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

***

סגירת המעגל – השאר את המשתמשים שלך בתמונה

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

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

***

לסיכום

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

 

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

• דרישות המוצר החבויות
• התנהגות משתמשים
• מחקר
• ניהול מוצר