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

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

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

MVP – לא מענה חד משמעי

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

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

ב. "המוצר נכשל, אבל אני מבין עכשיו מה הטעויות שלי ומאמין שיש לו עוד סיכוי."

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

ד. "האפליקציה גרפה הורדות מעל למצופה אבל קרסה כל הזמן כי לא צפינו לעומסים כאלה."

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

MVP מבוזבז

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

רוצים לבנות את המוצר שלכם עם ניצול אופטימלי של משאבים, מינימום סיכונים ומקסימום סיכויי ההצלחה? לחצו כאן!

MVP מכשיל

מה שיזמים רבים מפספסים זה ש-MVP לא מחושב יכול בעצמו לגרום למוצר להיכשל – גם אם הרעיון עצמו מעולה.

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

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

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

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

אז מהו האיזון הנכון בין רצון לייצר מוצר מצליח ובין מזעור סיכונים?

Growing MVP

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

שלב א – תכנון ה-MVP:

1. להבין היטב מה הציפיות מהמוצר בטווח הקרוב

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

3. לנתח מה חייב להיות קיים במוצר הראשוני יחד עם נתיב הגיוני להצלחה

4. לקבל החלטות מושכלות במה להשקיע

5. לאפיין היטב את ה-MVP מבחינה טכנולוגית, פונקציונלית ועיצובית

שלב ב – פיתוח MVP ראשוני:

בנייה והשקה של MVP אשר:

1. מה שנכלל בו עובד טוב, נכון ומרשים

2. נבנה בתשתיות שמאפשרות לו התפתחות הדרגתית בקלות

3. מודל הנתונים שלו נבנה בראייה עתידית

4. נבנה עם יכולת להגדלת משתמשים מהירה

שלב ג – הצמחה דינמית של ה-MVP:

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

בשלב זה החכמה היא באופן שוטף:

1. לקרוא את התוצאות מהשטח

2. לבדוק היכן אנחנו ביחס לתכנית המקורית ואם צריך לחשב מסלול מחדש

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

התוכן של איטרציות הפיתוח והקצב שלהן נקבע בהתבסס על:

1. פידבקים מהשוק (שימושיות, ביקורות, תחרות וכו')

2. נתוני הצמיחה של המוצר

3. התקדמות מול משקיעים/תקציבים נזילים

4. שיקולים עסקיים אחרים

Growing-MVP - גישה אופטימלית

גישה זו של פיתוח MVP צומח:

1. מנצלת בצורה מיטבית את ההשקעה במשאבים.

2. ממזערת את הסיכונים

3. ממקסמת את סיכויי ההצלחה

במאמר הבא אתייחס לשיקולים בתכנון של Growing-MVP.

רוצים לבנות את המוצר שלכם עם ניצול אופטימלי של משאבים, מינימום סיכונים ומקסימום סיכויי ההצלחה? לחצו כאן!