תשובה

אב טיפוס או MVP — מה לבנות קודם ומה ההבדל במחיר

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

מאת גל · מנכ״ל ומייסד, Juliusעודכן 5 דקות קריאה

העמוד הזה עונה על: “אב טיפוס או MVP מה לבנות קודם

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

מה ההבדל בפועל?

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

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

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

אז מה לבנות קודם?

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

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

ומה לגבי דף נחיתה?

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

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

האם אב טיפוס הוא בזבוז?

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

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

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

בקצרה

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

מניסיון שלנו

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

שאלות שחוזרות

האם אפשר להראות אב טיפוס למשקיע?

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

כמה עולה אב טיפוס לעומת MVP?

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

האם אפשר להפוך אב טיפוס ל-MVP?

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

מקורות

להמשך קריאה

תשובה

כמה זמן לוקח לבנות MVP באמת

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

5 דקות קריאה ·

כתבה

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

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

8 דקות קריאה ·

חזרה לאשכול: מרעיון ל-MVP