CB Insights מפרסמת ניתוח שנתי של הסיבות לכישלון סטארטאפים. במשך שנים, הסיבה המובילה הייתה זהה: "אין צורך בשוק". לא ביצוע גרוע. לא גמר כסף. לא צוות גרוע. המוצר פשוט לא פתר בעיה שאנשים אכפת להם ממנה מספיק כדי לשנות את ההתנהגות שלהם.
הנתון הזה מדהים כשאתה חושב כמה מאמץ מושקע בבניית מוצרים. צוותים מבלים חודשים — לפעמים שנים — בעיצוב מערכות, כתיבת קוד, ויכוחים על ארכיטקטורה, ושיכלול זרימות. והסיבה הנפוצה ביותר לכישלון שלהם היא שאף אחד לא שאל אם כל זה פותר בעיה אמיתית.
לבנות מוצרים שאנשים באמת רוצים זה לא כישרון. זה משמעת. יש לזה שיטה, והשיטה הזאת ניתנת ללמידה.
טעות המוצר הנפוצה ביותר היא להתאהב בפתרון לפני שאתה מבין לעומק את הבעיה. זה כמעט אוניברסלי בקרב מייסדים לראשונה ומפתיע בשכיחותו בקרב מנוסים. הדפוס תמיד זהה: למישהו יש רעיון, הוא מוצא אותו משכנע, ומתחיל לבנות. הלקוח הוא מחשבה שנייה — מישהו לשכנע, לא להבין.
התרופה אינה מסובכת אבל דורשת משמעת: בלה יותר זמן על הבעיה ממה שאתה חושב שמוצדק, לפני שאתה בכלל שוקל פתרונות. דבר עם אנשים שיש להם את הבעיה. צפה בהם עובדים. הבן את הפתרונות הזמניים שהם משתמשים בהם היום ולמה הם לא מושלמים. רק אז יש לך מספיק הקשר לעצב משהו שמתאים באמת.
פיתוח מוצר טוב הוא לא קו ישר — הוא לולאה. כל חזרה על הלולאה היא הזדמנות להחליף הנחות בעדויות. הצוותים שבונים מוצרים שאנשים רוצים הם אלה שמשלימים את הלולאה הזאת במהירות ולעתים קרובות.
הלולאה אינה פורמליות. לכל שלב יש פלט ספציפי שהופך לקלט של השלב הבא. דילוג על שלבים — הנפוץ ביותר הוא לקפוץ ישירות מבעיה לבנייה — הוא מה שמייצר מוצרים שמפספסים את המטרה.
לא כל הבעיות שוות פתרון. לבעיית מוצר טובה יש שלוש תכונות: היא תכופה (משפיעה על אנשים לעתים קרובות, לא לעתים נדירות), היא עזה (אנשים מרגישים אותה מספיק כדי לרצות הקלה), והפתרונות הקיימים אינם מספקים באמת (לא רק שונים מעט ממה שהיית בונה).
הטעות היא לאופטימיזציה לתכונה הראשונה ולהתעלם משתיים האחרות. "אנשים מבזבזים זמן בפגישות" זה תכוף. אבל אם הכאב נמוך — אם אנשים מצאו פתרונות זמניים טובים מספיק — הבעיה אולי לא שווה פתרון מסחרי. ואם כבר יש שתים עשרה כלים שעושים מה שאתה רוצה לעשות, אתה צריך סיבה ספציפית מאוד לכך שהכלי שלך ייבחר.
למחקר יש מוניטין רע בחוגי מוצרים — הוא מקושר לחברות ייעוץ איטיות, דוחות עבים, וממצאים שאף אחד לא קורא. זה כישלון של ביצוע, לא של הפרקטיקה. מחקר מוצר טוב הוא מהיר, ספציפי, ומשנה את מה שאתה בונה.
מטרת המחקר אינה לאשר שהבעיה אמיתית. אתה אמור כבר להאמין בזה לפני שאתה משקיע רבות במחקר. המטרה היא להבין את הבעיה מספיק לעומק כדי לדעת איך נראה פתרון טוב: מי ספציפית סובל מהבעיה, באיזה הקשר, מה הם כבר ניסו, באילו מילים הם מתארים אותה, ומה "פתרה" נראה עבורם.
השערה היא תחזית ספציפית וניתנת להפרכה על מה שאתה מאמין שנכון. היא מאלצת בהירות. אם אתה לא יכול לכתוב השערה ברורה, אתה עדיין לא מבין את הבעיה מספיק כדי לבנות פתרון.
להשערת מוצר שימושית יש שלושה חלקים:
האות הוא החלק החשוב ביותר — והנפוץ ביותר להשמטה. ללא אות מחויב מראש, כל ניסוי "עבד איכשהו". צוותים מוצאים דרכים לפרש נתונים מעורפלים בחיוב. השערה ללא תנאי הפרכה היא רק משאלה.
שלב הבנייה הוא המקום שבו רוב הצוותים מבלים יותר מדי זמן. המטרה אינה לבנות את המוצר — היא לבנות את הדבר המינימלי שייתן לך אות על ההשערה שלך. אלה יעדים שונים והם מייצרים פלטים שונים מאוד.
לרוב ההשערות בשלב מוקדם, המינימום קטן הרבה יותר ממה שצוותים חושבים. האם אתה יכול לעשות ידנית מה שהתוכנה תעשה, לעשרה אנשים, כדי לבדוק אם הם מעריכים את התוצאה? האם אתה יכול לחבר כלים קיימים ולבדוק את זרימת העבודה לפני שתבנה תשתית חדשה? האם אתה יכול לשרטט אב-טיפוס ולעבור איתו עם חמישה משתמשים לפני שתכתוב קוד כלשהו?
המשמעת כאן היא לשאול, לפני שבונים משהו: "מה אני מנסה ללמוד?" ו"מה הדבר המינימלי שיאפשר לי ללמוד את זה?" התשובה כמעט תמיד קטנה יותר ממה שהצוות רוצה לבנות.
לאחר ההשקה — בין אם זה אב-טיפוס, פיילוט ידני, או תכונה פרוסה — שלב המדידה הוא המקום שבו צוותים מרמים את עצמם בדרך כלל. הם שואלים משתמשים אם הם אהבו. המשתמשים אומרים כן. הצוות מסמן את הניסוי כמאומת.
רגש אינו אות. האות היחיד האמין הוא התנהגות: האם אנשים עשו את הדבר? האם הם חזרו? האם הם שילמו? האם הם סיפרו למישהו אחר?
למדידה כמותית, הוסף מכשור לפני ההשקה. דע אילו פעולות ספציפיות אתה עוקב אחריהן. קבע סף מראש — "נחשיב זאת כמאומת אם X% מהמשתמשים ישלימו Y בתוך Z ימים." למדידה איכותנית, ערוך ראיונות מעקב מובנים, לא סקרי שביעות רצון פתוחים.
שלב הלמידה עוסק בעדכון המודל המנטלי שלך של המשתמש והבעיה, לא רק בהחלטה מה לבנות הבא. צוותים שמדלגים על שלב זה אוספים נתונים אבל לא צוברים הבנה. הם מבצעים במהירות אבל לא משפרים את שיקול הדעת שלהם לאורך זמן.
מפגש למידה טוב שואל: מה חזינו? מה קרה בפועל? מה הפער אומר לנו על ההנחות שלנו? מה הדבר החשוב ביותר שאנחנו לא יודעים עכשיו?
הפלט של שלב הלמידה הוא הגדרת בעיה חדה יותר, השערה מתוקנת, או — אם הניסוי נכשל בבירור — החלטה לרדוף אחרי כיוון אחר לחלוטין. כל התוצאות האלה בעלות ערך. התוצאה הגרועה ביותר היא עמימות: "למדנו כמה דברים אבל לא בטוחים מה לעשות הלאה." זה סימן שהניסוי לא היה ספציפי מספיק.
פיתוח מוצרים לא מגיע לשלב שבו אתה מפסיק להריץ את הלולאה הזאת. השאלות משתנות — בשלב מוקדם אתה מאמת אם הבעיה אמיתית; מאוחר יותר אתה מאמת אם אלמנט פתרון ספציפי עובד — אבל המבנה תמיד זהה. תצפה, השער, בחן, למד.
הצוותים שבונים מוצרים שאנשים רוצים הם לא אלה עם התובנה הראשונית החכמה ביותר. הם אלה שמשלימים את הלולאה הכי מהר ובכנות הרבה ביותר. מהירות הלמידה, לא מהירות המשלוח, היא היתרון התחרותי.