בשנים האחרונות עושים יזמים רבים של חברות סטארט-אפ שימוש תכוף במונח MVP - קיצור של Minimum Viable Product או מוצר בר-קיימא מינימלי – עבור רכיב הפיתוח הראשוני אותו הם מבקשים להקים כחלק מהמיזם כדי לקדם בעזרתו גיוס הון ממשקיעים, רכישת לקוחות ראשוניים, בניית שיתופי פעולה וכו'.
למרות שחשיבות בניית MVP כחלק מתהליך New Product Development) NPD) - פיתוח מוצר חדש - ברורה ומשמעותית, הרי שהשימוש התכוף במושג הפך אותו לרב-משמעי וכיום בחלק לא מועט מן המקרים היזמים מתכוונים ב-MVP למעשה למשהו אחר, וגם אם כן מתייחסים לכוונה המקורית - אין זה בטוח ש-MVP הוא אכן הרכיב הראשוני אותו יש לפתח ולהציג.
המושג, שנטבע בתחילת העשור כחלק ממתודולוגיית Lean Startup מדבר על גירסא ראשונית של מוצר המאפשרת לארגון שפיתח אותו לקיים מקסימום למידה על לקוחות המוצר במינימום השקעה. המוצר לא צריך להיות מושלם, שלם או מעוצב - מה שחשוב ב-MVP הינו שהמשתמשים הפוטנציאליים יבינו על מה המוצר, כיצד הוא עובד ואיזה ערך הוא נותן להם. למרות שהמושג חדש יחסית התפיסה שהוא מציג אינה חדשה וקיימים מושגים ותיקים ומקבילים עבור גירסא ראשונית של מוצר כמו גירסת ביתא (Beta Version), גירסת היכרות (Familiariztion) ומוצר בסיס (Baseline Product). בכל המקרים מדובר על מוצר עובד (גם אם חלקית) ובהשקה מוגבלת, אבל "בשטח" ולא בתנאי מעבדה.
בצורה סכמתית ניתן לראות MVP כאוסף של פונקציות אשר בפני עצמן חסרות שימוש כמוצר עצמאי אך הן גם חלק ממוצר מלא.
אך האם MVP הוא אכן הדבר הראשון שמיזם צריך לפתח ולהציג כדי להתקדם לאחר ה-executive summary ומצגות הפאוור פוינט?
במאמר זה אנסה לעמוד על ההבדלים בין MVP לבין שני מושגים מקבילים אך שונים מהותית – דמו והוכחת היתכנות (Proof of Concept) או POC. לשם הדוגמא נניח כי המיזם שלנו הוא אתר לניהול פיננסי אשר מאחוריו קיים "מנוע" חכם המקבל החלטות ומבצע פעולות עבור המשתמש.
דמו
למרות שדמו של מוצר יכול להתקיים במספר אופנים כולל גירסא חלקית/מנוונת של מוצר סופי – הרי שהדבר המרכזי המאפיין דמו היא העובדה כי הוא רק צריך להיראות כמו המוצר אך לא להיות מוצר בפועל או אפילו לפעול על הפלטפורמה של המוצר עצמו. למשל בדוגמא שלנו דמו יכול להיות סרטון קצר המדמה את התנהגות השימוש באתר עבור מקרה שימוש (use case) מסוים, כלומר - אנו לא מפתחים בפועל אתר וודאי לא את המנוע החכם מאחוריו אלא משתמשים בכלי כלשהו (וקיימים כלים רבים וחינמיים) כדי לבנות דמו.
ככלל, דמו אינו עוסק בתיאור מפורט של תכונות ופונקציונאליות המוצר. לדמו מטרה אחת – להראות כיצד המוצר יוכל לספק תועלת ספציפית החשובה ללקוח, ולכן מבחינה מעשית בניית דמו היא בדרך כלל השלב הבא לאחר שלבי הרעיון והמצגות, ולפני שהחלה השקעה כלשהי בפיתוח עצמו. בכדי לבנות דמו אפקטיבי נדרשים השקעת זמן ומחשבה לא מעטים: בחירת ה- use case המתאים, העיצוב הכללי וממשק המשתמש של המוצר והדגמה של צורת השימוש בו. אך אלה ודאי ידרשו הרבה פחות משאבים מאשר השקעה בפיתוח של גירסא ראשונית של המוצר.
לכן, דמו יהיה טוב בעיקר לחשיפה ראשונית - למשל למשקיעים או לשותפים פוטנציאליים – של מיזם לא ממומן שעלות הפיתוח שלו גבוהה יחסית גם עבור גירסא ראשונית. עבור מקרים בהם יש את היכולת לפתח משהו הדומה יותר למוצר הסופי כדאי לשקול מראש בניית POC.
POC
כאמור, דמו הינו כלי אפקטיבי ביצירת רושם ראשוני כיצד המוצר אמור להיראות ולעבוד, אך מהגדרתו הוא אינו מוכיח כי ליזמים יש אכן את היכולת לפתח ולהשיק את הפונקציונליות המובטחת במוצר, בעיקר כשמדובר במוצר חדשני. לשם כך דרושה הוכחת היתכנות Proof of Concept או POC כלומר המחשה של פעילות "ממשית" של המוצר, גם אם מוגבלת ובתנאי מעבדה. עיקרון ה-POC דומה (אך לא זהה) לעיקרון של אב-טיפוס (Prototype) כאשר אב-טיפוס בדרך כלל ידרוש זהות גדולה יותר למוצר הסופי ו-POC צריך בעיקר להמחיש את פעולת הפונקציות העיקריות. לכן אב-טיפוס יהיה רלוונטי יותר לעולם של מוצרים פיזיים ו-POC לעולם של מוצרים "גמישים" כמו למשל מוצרי תוכנה. חברת פיקסאר לדוגמא נוהגת ליצור סרטי אנימציה קצרים כהוכחת היתכנות לטכניקות מורכבות או חדשות לפני הפקת סרט מסחרי באורך מלא.
בניגוד לדמו, ה-POC כן צריך להיבנות ולרוץ על פלטפורמה דומה לזו בה ירוץ המוצר הסופי. כך למשל בדוגמא שלנו יש לפתח את האתר עם כמה מסכים עיקריים, וכן לבחור use case כזה שניתן לבנות עבורו פונקציה שתמחיש את פעילות ה"מנוע החכם" שמאחורי האתר. האינטראקציה של המשתמש אמורה להיות אמיתית ולא "מוקלטת" כמו בדמו, גם אם מוגבלת ובתנאי מעבדה (למשל מחשב בודד).
כשה-POC אפקטיבי הדבר מוכיח את היכולות של היזמים, מראה שהטכנולוגיה מאחורי הרעיון או התיאוריה ישימה ושלצוות העומד מאחוריה יש את הכישורים הדרושים. עבור מיזמים השואפים לשיתוף פעולה עם ארגונים גדולים ה-POC הוא הכלי המאפשר לתאם ציפיות ולעזור לשני הצדדים להבין טוב יותר את הצרכים והיכולות ההדדיות. בכזה מקרה ה-use case צריך להגדיר מענה מדויק שהמיזם מספק לצורך אמיתי של הארגון.
לכן, POC יהיה טוב או לחשיפה ראשונית - למשל למשקיעים או לשותפים פוטנציאליים – של מיזם לא ממומן שעלות הפיתוח שלו נמוכה יחסית עבור גירסא ראשונית, או - לאחר גיוס ממשקיעים המבוסס על דמו – לחשיפה בפני ארגונים/לקוחות פוטנציאליים כדי לעורר עניין טרם פיתוח המוצר עצמו.
לפיכך, יזמים רבים המתייחסים ל-MVP מתכוונים למעשה ל-POC. בהקשר זה יש לציין כי הן דמו והן POC הם בסיכומו של דבר כלים מכירתיים וכמעט תמיד לא יהיה שימוש במה שפותח עבורם (למעט ידע נצבר) בפיתוח המוצר עצמו. לעומת זאת MVP יכול (אך לא חייב) להיות גירסא ראשונית של המוצר עצמו, כלומר תשתית הפיתוח שלו תוכל לשמש - לפחות בחלקה - את פיתוח המוצר גם בשלבים הבאים.
MVP
הגדרתו המקורית של המונח מתייחסת בעיקר לצוותי סטארטאפ המחזיקים ביכולת פיתוח ניכרת לייצר מוצר של ממש (גם אם מוגבל) ולא רק POC. השקת ה MVP הינה למעשה תחילתו של "ניסוי שטח", כאשר תהליך הפיתוח-מדידה-לימוד עליו נשענת מתודולוגיית Lean Startup מסתמך על האפשרות לפתח מוצר דינמי ולשנותו על פי תוצאות הניסוי, תוך קיום קשר מתמיד בין המפתחים לאנשי השטח. ביסודו של דבר, מדובר בתהליך מיקוד המוצר ושיפורו בהתאם לפידבק של המשתמשים בשטח.
מוצר MVP לא חייב להציג את מלוא יכולות המוצר הסופי או להיות מושלם טכנית. כפי שאמר סטיב בלאנק, אבי מתודולוגיית Lean Startup ומי שטבע את המונח MVP: "אתה מוכר את החזון ומספק את התכונות המינימליות למשתמשים החולקים את החזון – אך לא לכולם". למשל בדוגמא שלנו – נשיק אתר (חי) עם קונספט וממשק דומים למוצר הסופי ומאחוריו גירסא חלקית ומוגבלת - אך אופרטיבית - של המנוע החכם, עבור use case או קבוצת לקוחות שיוכלו להעניק פידבק אפקטיבי.
בניית MVP אפקטיבי הינה מתאגרת ודורשת השקעה רבה של מחשבה טרם הפיתוח. יזמים רבים נוטים לחשוב כי MVP הוא גרסה מקוצצת כנפיים של המוצר האמיתי, וכך יתחילו ב"רשימת החלומות" של המוצר ואז יבחנו אילו פונקציות ניתן להוציא מגרסת ה-MVP. אך MVP טוב מתרכז באימות הצורך בפתרון מול בעיה ספציפית ולא באוסף של פונקציות, לכן יש לנתח היטב את הצורך העיקרי שהמוצר בא לפתור ולתכנן סביבו את ה-MVP גם במחיר שחלק מן ההשקעה לא יחזור לפיתוח המוצר המלא.
כיצד נכון לפתח MVP אפקטיבי