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