איך בונים MVP לסטארטאפ: מדריך מעשי למייסדים

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

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

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

שלב הראיונות מוסבר במדריך /guides/customer-discovery. מי שמדלג עליו בונה לפעמים MVP מצוין לבעיה שלא כואבת לאף אחד. אחרי הראיונות כתבו את ההנחה שאתם בודקים בצורה שאפשר להפריך: "המוצר יעזור ל-[לקוח] לעשות [משימה] טוב יותר ממה שהוא עושה היום, כי [סיבה]".

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

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

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

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

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

הטכנולוגיה הנכונה ל-MVP היא זו שהצוות שלכם מכיר היטב ושנותנת להגיע לשימוש אמיתי מהר. זה לא השלב לניסויים בתשתית.

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

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

אם אין במייסדים מישהו טכני, אפשר לעבוד עם ספק פיתוח, אבל מישהו מטעם המייסדים צריך להבין את ההחלטות הטכניות ולבדוק את העבודה. על האפשרויות ראו /guides/cto-as-a-service ו-/guides/chipus-shutaf-meyased. מה שאי אפשר להעביר לספק הוא הקשר עם הלקוחות. את השיחות עם המשתמשים, ואת ההחלטה מה לבנות בעקבותיהן, המייסדים צריכים לעשות בעצמם.

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

לכן כדאי לבדוק מוקדם מה השימוש המיועד ומה הסיווג, כפי שמוסבר במדריך /guides/samd-tochna-kemechshir-refui. בדיקה עם מטופלים או עם נתונים רפואיים צריכה את האישורים המתאימים, למשל של ועדת הלסינקי (/guides/vaadat-helsinki-madrich). עדיין אפשר ללמוד הרבה לפני כן: ראיונות עם צוותים קליניים, אב-טיפוס שמוצג להם, ובדיקה של התהליך בלי מטופלים.

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

MVP של אתר פשוט ידרוש פחות מאפליקציה לשתי מערכות הפעלה, ו-MVP עם חומרה או עם רכיב רפואי ידרוש יותר מכל אלה. הגורמים שמשפיעים על המחיר מפורטים במדריך /guides/kama-ole-lefateach-applicatzia. כדי לקבל הערכה אמינה צריך אפיון כתוב של מה בדיוק נכנס לגרסה הראשונה.

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

לפני ההשקה כתבו מה ייחשב הצלחה ומה ייחשב כישלון. למשל: כמה משתמשים חוזרים בשבוע השני, כמה משלימים את התהליך המרכזי, כמה מוכנים לשלם. אחרי ההשקה דברו עם המשתמשים, במיוחד עם מי שהפסיק להשתמש. השלב הבא, הבדיקה אם יש התאמה בין המוצר לשוק, מוסבר במדריך /guides/product-market-fit.

אלה הטעויות שחוזרות הכי הרבה:

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

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