איך לאמת רעיון SaaS לפני שכותבים שורת קוד אחת

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

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

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

למה לבנות קודם מרגיש פרודוקטיבי — ובדרך כלל אינו כזה

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

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

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

מצאו את ההנחה האחת שיכולה להרוג את כל העניין

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

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

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

דברו עם אנשים — אבל עשו זאת נכון

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

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

שאלות שמקבלות תשובות כנות

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

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

דרכים זולות לבחון ביקוש אמיתי

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

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

1. 1
   העלו מצגת בעמוד אחד

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

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

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

   מתוך כל מי שבאמת הבין את ההצעה, כמה ביצעו את הפעולה? קומץ הרשמות אמיתיות מהאנשים הנכונים מנצח אלף איחולים מעורפלים.

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

מכרו את זה לפני שתבנו את זה

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

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

קריאת האותות בכנות

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

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

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

כשאתם באמת מוכנים לבנות

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

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

שאלות נפוצות