הטור האחרון הסתיים בשאלה (הלא פשוטה) ״איך אנחנו בוחרים שותפים לרוץ איתם על הסטארטאפ?״ אבל רצים לאן בדיוק? רצים לעבר ה״רעיון״ העילאי? ״איך לשנות את הצורה שבה מסתכלים על…!״, נכון? אז זהו שלא בדיוק. אני רואה המון מייסדים בתעשייה שלנו  (במיוחד מייסדים כולם טכנולוגיים) שמביאים לשולחן פתרון טכנולוגי שעושה משהו, אבל הרבה פעמים קשה להבין מהי ה״בעיה״ שאנחנו מנסים לפתור. מצב שבו אנחנו עושים reverse engineering  מהפתרון לבעיה לעיתים מעוות לנו את התמונה וגורם לנו לספר סיפור קצת אחר, לרוב לא מדוייק באופן מלא. זה יוביל כמובן הרבה פעמים לבזבוז זמן ומשאבים שנשקיע בכיוון הלא נכון. 

חלק מהתהליך שצריך לעשות בשלב ההגיה (Ideation) של הרעיון הוא המחקר. אנחנו צריכים לבדוק ולחקור את  ״הבעיה שאנחנו רוצים לפתור״. עבודה יסודית על השלב הזה תאפשר לנו לזהות את החלקים הנכונים לפתרון שלנו ויותר מזה את ההבדל ברמות החשיבות של החלקים השונים. נסו לענות על השאלות הבאות:

1. מה התהליך הקיים היום (ואם בכלל קיים)? מה הבעיות בו?
2. האם יש פתרונות קיימים בשוק היום בכלל? (מישהו אמר ״מתחרים״?)
3. מה גודל השוק? (TAM - Total Addressable Market), מה גודל הבעיה?
4. האם מישהו מוכן לשלם על פתרון כזה? (דבר חשוב שהרבה מפספסים) וגם כמה?

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

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

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

בואו נחזור לשאלות המקוריות:

1. יש תהליך קיים? איך אתם שואלים? אקסלים שנשלחים במייל. מביך.  הבעיות בשיטה הקיימת הן שהתהליך הזה הוא ארוך, לא מספק מענה אמיתי ואיך לא, שני הצדדים שונאים אותו (גם הצד המעריך וגם הצד המוערך).
2. כן, כמובן שיש פתרונות קיימים בשוק (למזלנו לא היינו צריכים לעסוק יותר מדי ב״חינוך שוק״). משהו נוסף טוב, יש מתחרים! (מישהו מוכן לשלם כסף על פתרון).
3. זה קצת היה יותר קשה להעריך בתחילת הדרך, כי כפי שזה היה נראה, כל אחד צריך את השירות הזה ועושה את תהליכים כאלה ואחרים. אבל בפועל לא באמת כל אחד מוכן לקנות מוצר כזה שמנהל את תהליך של Third Party Security Risk Management (נשמע קצת מפחיד :) ). לכן, עשינו הערכה גסה שהבעיה היא גדולה מספיק (אפשר לזרוק מספר של 10 מיליארד דולר - נשמע גדול מספיק?)
4. ״האם מישהו מוכן לשלם על זה?״ - עצם העובדה שיש לנו מתחרים קיימים בשוק - התשובה היא כן. ולא רק כן, אלא גם יכולנו להבין מה התמחור המקובל בשוק. 

תודה לאל, עשינו ולידציה לרעיון, או ליתר דיוק ל״בעיה״ שאנחנו מנסים לפתור, עכשיו צריך היה לרוץ ל״איך״.  ידענו שאנחנו הולכים לכיווון שהוא לא שוק חדש לגמרי כי יש מתחרים, שיש בו אתגרים משלו, אבל הוא גם לא מה שנקרא ״Red Ocean״ (שוק רווי מידי עם פתרונות).

חשוב לשים לב שיש עוד הרבה פרמטרים שצריכים לקחת בחשבון - למשל, מה קורה אם אין מתחרים? מה קורה אם צריך לעסוק בחינוך השוק? איזה עוד אסטרטגיות אפשר לבחון ומשם נוכל להתחיל לעסוק ב GTM (בשפה אנושית - Go To Market) וכמובן, איך אנחנו ניגשנו לשוק עם הפתרון שלנו - אנחנו עוד נדבר על זה כשנדבר בתהליך בניית המוצר.

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