רוב הפגישות הראשונות על MVP מתחילות ברשימה: הרשמה, פרופיל, חיפוש, התראות, תשלומים, ממשק ניהול, אפליקציה לשני הצדדים. הרשימה הזאת היא תיאור של המוצר שרוצים בעוד שנתיים — לא של הגרסה שאפשר לבדוק בחודשים הקרובים.
המדריך הזה מציע סדר אחר: קודם מחליטים מה צריך להוכיח, אחר כך בוחרים את התוצר שמוכיח את זה, ורק אז מפרקים את הרעיון לתכולה. בסוף יש דוגמה עובדת — מסומנת כהמחשה — של רעיון שמפורק לטבלת עכשיו/אחר-כך.
מה צריך לבדוק?
לפני שמדברים על מסכים, כותבים משפט אחד בשלושה חלקים: למי זה מיועד, איזו בעיה זה פותר, ומה המשתמש יעשה אחרת אם זה עובד. המשפט הזה הוא ההנחה שה-MVP בודק. אם קשה לכתוב אותו — זה הסימן הראשון שהרעיון עדיין רחב מדי לגרסה ראשונה.
| חלק | שאלה | סימן שהתשובה עדיין רחבה מדי |
|---|---|---|
| משתמש | מי האדם הראשון שישתמש בזה, ואיפה פוגשים אותו היום? | "עסקים קטנים", "כולם", שני צדדים של שוק בבת אחת |
| בעיה | מה הוא עושה היום במקום, וכמה זה מפריע לו? | הבעיה מתוארת במונחים של הפתרון ("אין להם אפליקציה") |
| התנהגות | מה הוא יעשה אחרת אחרי השימוש — פעולה שאפשר לראות? | "יהיה מרוצה", "יבין את הערך" — דברים שאי אפשר למדוד |
הנחה טובה היא כזו שאפשר להפריך. "אנשים רוצים לחסוך זמן" לא ניתנת להפרכה; "מנהלי משמרות בבתי קפה יזינו את סידור השבוע הבא דרך הטלפון במקום בקבוצת וואטסאפ" — כן.
אבטיפוס, POC או MVP?
שלושת המונחים משמשים לעיתים כמילים נרדפות, אבל הם עונים על שאלות שונות ועולים אחרת. בחירה לא נכונה היא אחת הסיבות הנפוצות ל-MVP שמתנפח: בונים מוצר עובד כדי לענות על שאלה שאבטיפוס לחיץ היה עונה עליה.
| תוצר | על איזו שאלה הוא עונה | מה הוא בדרך כלל | מה הוא לא מוכיח |
|---|---|---|---|
| אבטיפוס | האם המשתמש מבין את ההצעה ורוצה את זה? | מסכים לחיצים בלי שרת, סקיצות, או דף נחיתה עם הרשמה | שהמוצר ישים טכנית או שישתמשו בו שוב |
| POC (הוכחת היתכנות) | האם החלק הטכני המסוכן אפשרי בכלל? | קוד שבודק אינטגרציה, אלגוריתם או ביצועים — בלי ממשק ובלי משתמשים | שמישהו צריך את זה |
| MVP | האם משתמשים אמיתיים עוברים את התהליך המרכזי ומקבלים את התוצאה? | מוצר עובד, צר ככל האפשר, שמשתמשים משתמשים בו בפועל | שהמוצר המלא יצליח, או שהוא מוכן לקנה מידה |
לפעמים הסדר הנכון הוא שניים מתוך השלושה: אבטיפוס כדי לבדוק את ההצעה, ואז MVP סביב התהליך שהמשתמשים הגיבו אליו. POC נכנס לתמונה רק כשיש רכיב טכני שבלעדיו המוצר לא קיים — למשל תלות במערכת חיצונית שלא ברור אם מאפשרת את מה שצריך.
מפרקים רעיון לתכולה
הכלי המרכזי הוא התהליך המרכזי: המסלול האחד שמשתמש אחד עובר מהבעיה ועד לתוצאה. כותבים אותו כסדרת צעדים, ואז שואלים על כל צעד — האם בלעדיו המשתמש לא מגיע לתוצאה? אם כן, הוא ב-MVP. אם לא, הוא מועמד לדחייה.
לפני: הרעיון כפי שהוא מגיע לפגישה הראשונה
- הרשמה והתחברות לבעלים ולעובדים, כולל התחברות דרך גוגל ואפל
- בניית סידור שבועי עם גרירה, תבניות, חזרתיות ושכפול שבוע
- בקשות החלפה בין עובדים עם אישור מנהל
- שעון נוכחות, חישוב שעות ודוח שכר
- התראות דחיפה, SMS ואימייל
- צ'אט פנימי לצוות
- ממשק ניהול לרשת עם כמה סניפים ודוחות
- אפליקציה ל-iOS ול-Android ואתר
התהליך המרכזי
- המנהל מזין את רשימת העובדים ואת המשמרות של השבוע הבא.
- המנהל מפרסם את הסידור, והעובדים מקבלים קישור.
- כל עובד רואה את המשמרות שלו ומאשר אותן.
- המנהל רואה מי אישר ומי לא.
ארבעה צעדים. כל מה שלא נדרש כדי לעבור אותם פעם אחת עם בית קפה אמיתי — נדחה. התוצאה היא טבלת עכשיו/אחר-כך שבה כל דחייה מנומקת.
אחרי: טבלת עכשיו / אחר-כך
| רכיב | עכשיו / אחר-כך | נימוק |
|---|---|---|
| הזנת עובדים ומשמרות | עכשיו | צעד 1 בתהליך; בלעדיו אין סידור |
| פרסום סידור וקישור לעובדים | עכשיו | צעד 2; זה בדיוק מה שמחליף את קבוצת הוואטסאפ |
| אישור משמרת על ידי עובד | עכשיו | צעד 3; זו ההתנהגות שההנחה מנבאת — חייבים לראות אותה |
| מסך "מי אישר" למנהל | עכשיו | צעד 4; בלעדיו המנהל חוזר לוואטסאפ כדי לברר |
| התחברות דרך גוגל ואפל | אחר-כך | קישור אישי לכל עובד מספיק לבדיקה; התחברות חברתית לא משנה את התשובה |
| גרירה, תבניות, שכפול שבוע | אחר-כך | נוחות עריכה; בודקים קודם אם מפרסמים דרך האפליקציה בכלל |
| בקשות החלפה | אחר-כך | תהליך שני; ייתכן שיתברר כחשוב יותר — ואז הוא יהיה הגרסה הבאה |
| שעון נוכחות ודוח שכר | אחר-כך | מוצר אחר עם דרישות דיוק ורגולציה; לא קשור להנחה |
| התראות דחיפה, SMS ואימייל | אחר-כך (חלקית) | ערוץ אחד — הודעה עם קישור — מספיק כדי שהעובד יגיע למסך; שאר הערוצים אחר-כך |
| צ'אט פנימי | אחר-כך | מתחרה בכלי שהצוות כבר משתמש בו; לא נדרש לתהליך |
| ניהול כמה סניפים ודוחות | אחר-כך | המשתמש הראשון הוא בית קפה אחד; רשתות הן קהל אחר |
| iOS, Android ואתר | עכשיו: ערוץ אחד | בוחרים את הערוץ שבו המשתמשים הראשונים נמצאים בפועל; השאר אחר-כך |
כשהטבלה הזאת קיימת, המסמך הבא נכתב כמעט מעצמו: המשתמשים, התרחיש המרכזי, המסכים הנדרשים לו וקריטריוני הקבלה. זה המקום שבו ההחלטה הופכת למסמך שצוות פיתוח — שלנו או אחר — יכול לתמחר ולבנות ממנו. מסמך דרישות לאפליקציה — דוגמה ממולאת ותבנית להורדה
מה דוחים ומדוע?
אין מספר פיצ'רים נכון ל-MVP, ואין רשימה אוניברסלית של "דברים שתמיד דוחים". יש ארבעה סוגי נימוקים שחוזרים ברוב הפרויקטים, וכדאי לכתוב ליד כל דחייה לאיזה מהם היא שייכת:
- לא נדרש לתהליך — המשתמש מגיע לתוצאה גם בלעדיו (התחברות חברתית, נוחות עריכה).
- תהליך אחר — זה מוצר או מסלול שני, שאולי יהיה הגרסה הבאה (בקשות החלפה, שכר).
- קהל אחר — נועד למשתמש שאינו המשתמש הראשון (רשתות, מנהלי אזור).
- אפשר לעשות ידנית — בשלב הבדיקה אדם יכול לבצע את זה מאחורי הקלעים (שליחת ההודעה, אישור חריג).
שני דברים לא דוחים גם כשהם לא "פיצ'ר": הדרך לראות מה המשתמשים עושים בפועל (אירועים בסיסיים או לפחות לוג), והאפשרות לדבר איתם אחרי השימוש. בלעדיהם ה-MVP מייצר רושם, לא תשובה.
ההיפך גם נכון: יש דברים שנראים כמו "תשתית" ובכל זאת נדחים — למשל יכולת לקנה מידה גדול. MVP שעובד למאה משתמשים ודורש שינוי כדי לעבוד לעשרת אלפים הוא תוצאה טובה, לא כישלון; מה שחשוב הוא לדעת מראש איפה הגבול ולכתוב אותו.
הנחה, מדד ותנאי עצירה
לפני שמתחילים לפתח כותבים שלוש שורות שיקראו גם אחרי ההשקה. ההנחה כבר קיימת; מוסיפים לה מדד ותנאי עצירה. המדד הוא ההתנהגות מההנחה, מתורגמת למשהו שאפשר לספור. תנאי העצירה הוא התשובה המוסכמת מראש לשאלה "מתי נודה שזה לא עובד כמו שחשבנו".
| שורה | בדוגמה (המחשה) | מה חשוב בניסוח |
|---|---|---|
| הנחה | מנהלי משמרות בבתי קפה קטנים יפרסמו את סידור השבוע דרך האפליקציה, והעובדים יאשרו בתוכה | משתמש, בעיה והתנהגות — לא תיאור של הפיצ'רים |
| מדד | מתוך בתי הקפה שנכנסו לבדיקה: כמה פרסמו סידור בשבוע השני ברצף, ואיזה חלק מהמשמרות אושרו בתוך האפליקציה | ספירה של ההתנהגות הצפויה, אצל קבוצה מוגדרת, בחלון זמן מוגדר; לא "הרשמות" ולא "הורדות" |
| תנאי עצירה | אם אחרי חלון הבדיקה רוב בתי הקפה חזרו לוואטסאפ — עוצרים ומבררים למה לפני שמוסיפים פיצ'רים | מוסכם מראש, כתוב, וקשור למדד — לא "נראה איך זה הולך" |
מתי ממשיכים לגרסה הבאה?
ההחלטה להמשיך נשענת על שלושה מקורות, ולא על אחד מהם לבדו:
- משוב — מה המשתמשים אמרו אחרי השימוש, ובעיקר מה הם עשו כשמשהו חסר (עקפו? ויתרו? ביקשו?).
- שימוש — המדד שהוגדר מראש, ולצידו מה שלא ציפיתם לו: איפה נתקעו, מה לא נגעו בו, מה השתמשו בו אחרת מהכוונה.
- החלטה עסקית — האם הכיוון עדיין מתאים למה שהעסק רוצה לבנות, ומה התקציב והזמן שיש להמשך.
הגרסה הבאה לא חייבת להיות "עוד פיצ'רים מהרשימה המקורית". לעיתים קרובות היא אחד משלושה דברים אחרים: להעמיק את התהליך הקיים (לעשות אותו מהיר וברור יותר), להרחיב את הקהל (סוג משתמש שני), או לקחת רכיב מעמודת "אחר-כך" שהתברר כקריטי — למשל בקשות ההחלפה מהדוגמה, אם רוב השאלות של העובדים נגעו דווקא אליהן.
ואם תנאי העצירה התקיים — זו לא תוצאה ריקה. MVP צר שהוכיח שההנחה לא נכונה חסך את העלות של לבנות את המוצר המלא על אותה הנחה. במקרה כזה חוזרים לשורת ההנחה, לא לרשימת הפיצ'רים.
איך זה נראה בעבודה איתנו
כשסטארטאפ מגיע אלינו עם רשימה, הצעד הראשון שלנו הוא לא הצעת מחיר אלא הטבלה מהמדריך הזה: ההנחה, התהליך המרכזי, ועמודת עכשיו/אחר-כך עם נימוקים. רק אחריה יש תכולה שאפשר לתמחר ולהתחייב עליה. איך צוות ה-MVP שלנו עובד, מה כלול ומה סדרי הגודל — בעמוד השירות. צוות פיתוח לסטארטאפים — מ-MVP ועד הסבב הבא
ואם השאלה הבאה היא כמה זה עולה — ממה מורכב המחיר של גרסה ראשונה, ומה מזיז אותו למעלה או למטה — פרסמנו על זה מדריך נפרד. כמה עולה לפתח אפליקציה בישראל ב-2026 — פירוק העלות