או: איך להשיג user insights במינימום מאמץ ובלי לחלק תלושי מתנה
מה אנחנו רוצים? דאטה!
ומתי אנחנו רוצים את זה? עכשיו!
דאטה דאטה דאטה. מנהלי מוצר חיים דאטה, נושמים דאטה, אוכלים דאטה וישנים דאטה. כל ההחלטות המקצועיות (ולפעמים גם האישיות) של מנהל מוצר טוב אמורות להיות מונעות מניתוח נתונים והסקת מסקנות על בסיס הנתונים האלה.
מנהל מוצר טוב מגדיר לעצמו ולמוצר שלו מה הן נקודות הדאטה, מקורות המידע והיעדים הרלוונטיים עבורו בשלבים השונים של חיי המוצר.
על פי הנתונים האלה יישק דבר. ניתוח הנתונים יתן מענה על שאלות קיומיות בחיי המוצר והחברה (האם המוצר עומד ביעדי הגדילה שצפינו? האם החברה מתקדמת ליעדים העסקיים שלה? מה השלב הבא במוצר?), אבל גם על שאלות יומיומיות, כמו על מה נעבוד ברבעון הקרוב? איך נדע שהפיצ'ר שפיתחנו נותן מענה אמיתי ללקוח? ומה בעצם הלקוח באמת רוצה?
זאת הסיבה שמנהלי מוצר משקיעים המון משאבים ואנרגיה בתכנון מערכת איסוף דאטה שתאפשר להם לענות על השאלות החשובות האלה באופן משכיל ולא בשליפה מהמותן. צוותי פרודקט עובדים עם צוותי פיתוח על דשבורדים ודאטה בייסים שעוקבים אחרי ההתנהגות של המשתמשים ומודדים כל פרט ופרט ב user flow, מנהלים ישיבות של שעות עם דאטה אנליסטים על איכות ומובהקות הדאטה, וגם מנהלים שיחות עומק וראיונות עם משתמשי המוצר עצמם כדי לוודא שהפיצ'ר אכן עונה על הצרכים שלהם.
כל אלה חשובים וקריטיים להמשך הצלחת המוצר, אבל הם גוזלים המון זמן וקשב ממנהלי המוצר, שגם ככה מתעסקים במיליון אייטמים נוספים על השולחן שלהם.
מה אם הייתי אומרת לכם שממש מתחת לאף של מנהלי המוצר, בתוך המשרד, בחדר הסמוך, קיים משאב של דאטה איכותי, שאפשר לשבת איתו על כוס קפה ולקבל תובנות מרעננות?
אני מדברת על הכתב הטכני שלכם. הכתב הטכני שבדרך כלל מקבל את המוצר ואת הפיצ'רים כחקוקים בסלע, הכתב הטכני שנמצא בסוף שרשרת הפיתוח ותפקידו להבין את הפיצ'ר ולהסביר אותו למשתמשים, הכתב הטכני שיושב ממש חדר לידכם אבל מעולם לא יצא לכם ממש לשוחח.
מה הקשר כתב טכני עכשיו?
אולי זה מפתיע אתכם, אבל עבודתו של הכתב הטכני רחבה ומקיפה יותר מאשר תיעוד פשוט של המוצר או הפיצ'ר שפיתחתם. העבודה על התיעוד מעמידה את הכתב הטכני בצומת דרכים קריטית שבה מתמזגות נקודות מבט שונות על המוצר: מצוות הפרודקט הוא לומד על הפיצ'ר ועל ההתנהגות שלו, מהQA הוא מבין מה יכול להשתבש במהלך השימוש, ואז הוא שם את עצמו בנעליו של המשתמש עצמו כדי לספק לו את הידע שהוא צריך כדי להשתמש במוצר בהצלחה. באופן הזה הכתב הטכני יכול לספק לכם תובנות שאתם, כמנהלי מוצר, לא תוכלו להשיג ממקור אחר בתוך החברה.
הזדהות עמוקה עם המשתמש
כמו זיקית מצויה, גם הכתב הטכני צריך להתאים את עצמו לכל מוצר אותו הוא מתעד, בין אם המוצר עוסק בAd-tech, ביטוח, לוגיסטיקה או בריאות. כדי לעשות זאת, הוא חייב להכיר את משתמשי המוצר כמו שהוא מכיר את עצמו: מי הם? בני כמה הם? מה ההשכלה שלהם? איך הם משתמשים במוצר? איך נראה סדר היום שלהם? באיזו תדירות הם משתמשים במוצר, ומה השאלות שעלולות לצוץ אצלם במהלך השימוש?
הכתב הטכני משתמש בידע הזה כדי לנסות ולחזות באיזה תחומים המשתמשים יצטרכו עזרה, באיזה צורה לספק להם את העזרה הזאת, ואיזה תסכולים הם עלולים לחוות במהלך השימוש. אם אתם, כמנהלי מוצר, לא משוחחים עם הכתב הטכני שלכם על הנושאים האלה, אתם זורקים את התובנות החשובות האלה לפח. לא הייתם רוצים לדעת מראש מה בפיצ'ר החדש שלכם עלול לגרום למשתמש לתסכול, ואולי למנוע את החוויה הזאת מלכתחילה?
היכולת לפשט רעיונות מסובכים
בתור מנהלי מוצר שעובדים עם צוותי פיתוח, הנהלה ובעלי עניין אחרים בתוך החברה, אנחנו נוטים לפעמים "להתאהב" במוצר או בפיצ'ר שאנחנו עובדים עליו. זה טבעי, אנחנו בני אדם. כמו כל אדם יוצר, גם איש הפרודקט מרגיש שהמוצר שלו מורכב, מתוחכם, הדבר הכי טוב שיכולנו לעשות כדי לפתור את כאבי המשתמש.
יכול להיות שכל זה נכון ואמיתי, אבל כשהפיצ'ר מגיע לשלב התיעוד, שבו הכתב הטכני אמור להסביר את הפעולה שלו למשתמשים, ברוב המקרים זה נגמר ב2-3 שורות של טקסט ותמונה אחת. אולי כפרודקט זה מאכזב מעט, אבל זה תפקידו של הכתב הטכני: לקחת קונספט מסובך בעל רבדים שונים, ולהפוך אותו לבייט אכיל וקל לעיכול עבור המשתמש. הכתב הטכני מסיר את כל מה שמיותר למשתמש לדעת, ומזקק את הפיצ'ר להסבר פרקטי ופשוט.
דרך מעולה לנצל את היכולת הזאת של הכתב הטכני היא להציג בפניו את הפיצ'ר עוד בשלב הפיתוח, לפני שהשקענו בו 5,000 שעות אדם, ולשאול אותו מה הוא חושב. תתפלאו לגלות שלפעמים יכולת הפישוט הזאת יכולה לספק פתרונות "זולים" יותר ופשוטים יותר ממה שחשבתם עליהם בתור אנשי פרודקט. נקודת המבט החיצונית הזאת היא נכס מאחר והיא לא מצריכה מכם לצאת מגבולות החברה או המשרד, היא קיימת בסביבה הקרובה שלכם, זמינה, ונוחה יותר מאשר קמפיין ראיונות משתמשים שיגזול מכם משאבים רבים. באופן הזה תוכלו גם לקבל תובנות על הפיצ'ר בשלבים מוקדמים, שאליהם לא בדרך כלל משתמשים אינם נחשפים, וכך לחסוך זמן פיתוח ואיטרציות.
תשומת לב לפרטים
כשכתב טכני מתחיל לתעד מוצר או פיצ'ר, הוא מבצע את סדרת הפעולות שהמשתמש אמור לבצע, ומתעד פעולה פעולה בסדר הנכון, בלי לפספס אף פרט. התיעוד גם מצריך לפעמים גזירת תמונות של המוצר בשלבים השונים של התהליך, בזמן לחיצה על drop-down או כאשר שדה מסוים ריק או מלא. הגרנולריות של התהליך הזה גבוהה מאוד, ובמהלכו הכתב הטכני נחשף לכשלים לוגיים בUX או בפיצ'ר עצמו שהצליחו לחמוק מאנשי הQA. אבל לצערו של הכתב הטכני שלנו, הוא מקבל את הפיצ'ר רגע לפני שחרור הגירסה, אין זמן לשפר ולשנות, ואין אפילו אוזן קשבת לתובנות ולהערות שלו.
כמנהלי מוצר, פגישה קבועה עם הכתב הטכני של החברה לפני שחרור המוצר, תועיל לכם ותעלה בפניכם באגים שלא ידעתם על קיומם, בעיקר בחווית המשתמש. אל תוותרו על הפגישה הזאת, היא יכולה להציל אתכם מסיטואציה מביכה מול הלקוח, כשהפיצ'ר ששחררתם אולי עובד בבקאנד אבל השימושיות שלו לא קלה או הגיונית עבור משתמש הקצה.
מקור ידע מהימן
לא נעים לומר, אבל ברוב המקרים הכתב הטכני מכיר את המוצר שלכם טוב יותר ממה שאתם מכירים אותו. כמנהלי מוצר, חלקנו עובדים על אספקט אחד במוצר, ביזנס, growth, fraud וכולי, אנחנו גם לא מעצבים ומתכננים את הפיצ'ר מהתחלה ועד הסוף אלא משתפים בתהליך אנשי מקצוע אחרים כמו אנשי UX, מעצבים, אנשי QA ומפתחים. אבל הכתב הטכני מתעד את הכל, ולכן יש לו תמונה מקיפה על המוצר הסופי בכללותו, היכולות שלו, המגבלות שלו, ואפילו הגרסאות הקודמות שלו וכיצד הוא השתנה עם הזמן.
נצלו את מקור הידע הזה אם יש לכם שאלות על המוצר עצמו וכיצד הוא מתנהג. אתם חדשים בחברה? תנו לכתב הטכני להעביר אתכם הדרכה על המוצר, השימושיות, ועל איך הוא נראה והתנהג לפני שהגעתם.
אז מה עושים?
ברגע שהבנתם את החשיבות של הדאטה פוינט הסמוי שנקרא הכתב הטכני, אתם כבר בדרך הנכונה. מנסיוני, תוכלו להשתמש במשאב הזה בצורה מיטבית אם תבצעו את הצעדים הבאים:
הכניסו את הכתב הטכני לתוך צוות הפרודקט. הכתב הטכני אמור לחיות ולנשום את המוצר בדיוק כמוכם, ולכן יש חשיבות גדולה להזמין אותו לפגישות פרודקט, לשתף אותו בפיצ'רים החל משלב התכנון ולקבל את הפידבקים שלו בזמן אמת.
אל תפחדו לקחת את הפידבק של הכתב הטכני שלכם ולחזור חזרה אל שלב התכנון. פידבק טוב הוא כזה שיגרום לכם להסתכל על הפיצ'ר שלכם מנקודת מבט רעננה, כזאת שלכם אין.
השתמשו בשיחה עם הכתב הטכני כשלב מקדים לפני ריאיון משתמשים. לפני שאתם אוספים משתמשים ומתחילים לחלק תלושי מתנה, שבו לשיחה עם הכתב הטכני שלכם ובקשו ממנו להתחבר לנקודת המבט של המשתמשים ולענות על השאלות שלכם. השיחה הזאת תוביל לראיונות מדויקים וממוקדים יותר עם משתמשים אמיתיים.
הכתב הטכני מכיר את המוצר טוב יותר מכם וברוב המקרים הוא מקור הידע הפנימי והחיצוני של החברה. אל תהססו להיעזר בו עם שאלות לגבי פיצ'רים שאתם לא מכירים או כיצד פיצ'ר השתנה והתפתח עם הזמן. השתמשו בנכסי הידע הכתובים שהכתב הטכני מייצר כדי ללמוד עוד על המוצר מנקודת המבט של המשתמש.
נקודה אחרונה וחשובה - אם התיעוד של המוצר שלכם מרגיש לכם ארוך ומורכב מדי - כנראה שיש לכם בעיית UX. אם המשתמשים שלכם צריכים כל כך הרבה עזרה כדי להשתמש במוצר, אתם צריכים לעצור הכל ולחשוב מחדש על נושא השימושיות. הכתב הטכני יוכל לספק לכם אינדיקציה אם הדוקומנטציה שהוא כותב מהווה "קביים" לחווית המשתמש או מספקת למשתמש מקור למידע נוסף ולפתרון תקלות.
אני יודעת, זה המון וזה כבד, אבל גם אם תאמצו הצעה אחת מתוך חמשת ההצעות שלי, אני מאמינה שתוכלו להרוויח התנהלות טובה יותר כמנהלי מוצר וכפועל יוצא, תוכלו לדלוור מוצרים שעונים טוב יותר על הצרכים של הלקוחות שלכם. אז תבררו איפה הכתב הטכני שלכם יושב, ואל תשכחו להגיע עם כוס קפה וסבלנות :)
Comments