איך מתעדפים מה לפתח במוצר דיגיטלי?

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

המאמר מסביר איך אוספים בקשות, איך מפעילים את ארבע השאלות, ואיך מתקשרים את ההחלטות למשתמשים.

למה תעדוף קשה

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

איסוף בקשות

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

ארבע שאלות

1. השפעה

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

2. היקף

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

3. ביטחון

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

4. מאמץ

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

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

לקוח גדול שמבקש התאמה

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

לומר "לא עכשיו"

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

דוגמה היפותטית: מערכת לניהול תורים

טעויות נפוצות

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

רשימת בדיקה

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

שאלות נפוצות

כל כמה זמן לעדכן את סדר העדיפויות?

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

מי מחליט על סדר העדיפויות?

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

איך תעדוף קשור לשימור?

ישירות. שינויים שעוזרים למשתמשים להגיע לערך ולהישאר משפיעים לאורך זמן על כל ההכנסה החוזרת. על כך יש הרחבה במאמר על נטישת משתמשים ב־SaaS.

השורה התחתונה

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