איך מגדירים MVP שלא מתפוצץ באמצע

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

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

למה ההיקף גדל

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

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

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

מה כן חייב להיכנס

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

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

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

איך זה נראה בפועל

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

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

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

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

ומה עושים כשהחיתוך כואב

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

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