מה ה-MVP של ה-SaaS שלכם צריך — ולא צריך — לכלול בהשקה

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

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

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

מה MVP באמת הוא (ומה הוא לא)

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

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

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

מצאו את העבודה האחת שהמוצר שלכם עושה

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

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

מה כל MVP של SaaS באמת זקוק לו

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

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

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

מה להשאיר בכוונה מחוץ ל-v1

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

חיוב אוטומטי ותמחור מורכב

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

תפקידים והרשאות מורכבים

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

אינטגרציות, אפליקציות מובייל מקוריות, ולוח המחוונים

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

שיטה פשוטה למתיחת הקו

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

1. 1
   רשמו כל פיצ'ר שדמיינתם

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

   עבור כל פיצ'ר, שאלו: האם משתמש זקוק לזה כדי להשלים את העבודה המרכזית האחת, מקצה לקצה? סמנו אותו 'מרכזי', 'מועיל' או 'מתישהו'. היו כנים — רובם נוחתים בשניים האחרונים.
3. 3
   השאירו רק 'מרכזי' ל-v1

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

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

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

בר-קיימא עדיין אומר שזה צריך להרגיש אמיתי

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

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

ה-MVP אינו קו הסיום — הוא הקריאה הראשונה

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

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

שאלות נפוצות