מה זה באמת MVP? הטעויות הנפוצות שמיזמים עושים

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

מה זה באמת MVP?

MVP ראשי תיבות של מוצר מינימלי בר-קיימא (Minimum Viable Product). המונח נשחט כי אנשים תופסים מילה אחת מהשלוש ומשמיטים את האחרות. כל המשמעות חיה בהחזקת שלושתן בו זמנית.

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

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

מה MVP הוא לא

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

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

דוגמאות טובות מול גרועות ל-MVP

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

MVP גרוע של אותו רעיון מגיע בשני טעמים. הראשון דק מדי מכדי להיות בר-קיימא: דף נחיתה יפה שאומר "חשבוניות בקלות" עם טופס הרשמה ושום דבר מאחוריו. אי אפשר לשלוח חשבונית, אז למדתם רק שאנשים אוהבים סלוגן. השני שמן מדי מכדי להיות מינימלי: המיזם בונה ניהול לקוחות, חיוב חוזר, מעקב הוצאות, מטבעות מרובים ודשבורד דוחות לפני ההשקה, מוציא ארבעה חודשים ו-30,000$ (בערך 110,000 ש"ח), ורק אז מגלה שפרילנסרים רצו משהו פשוט יותר - או לא רצו אותו בכלל. הגרסה הטובה עולה חלק קטן ממנה ומלמדת יותר.

הטעויות הנפוצות ביותר שמיזמים עושים

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

בנייה מופרזת

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

בנייה לפני אימות

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

פרפקציוניזם

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

היקף שגוי

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

הקשר בין MVP ל-v1

תפיסה שגויה נפוצה היא ש-MVP הוא רק גרסה מוקדמת של המוצר האמיתי - טיוטה מחוספסת של v1. עדיף לחשוב עליו כסוג שונה לגמרי של דבר. MVP הוא ניסוי שתפקידו לייצר למידה. גרסה 1 היא המוצר שבונים לאחר שהניסוי הזה גילה מה אנשים באמת מעריכים.

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

לעשות את ה-MVP נכון

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

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