מתי מיזם הוא סטארטאפ דיפ טק?

מה הופך מיזם לסטארטאפ דיפ טק, ואיך זה צריך להשפיע על התוכנית שלו?

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

מקור אי־הוודאות הוא שמבדיל בין המיזמים

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

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

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

ראו גם מה EZ Dev מספקת.

כך התוכניות שונות זו מזו

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

בחרו תוכנית שמתאימה לאי־הוודאות המרכזית

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

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

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

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

הפכו את אי־הוודאות לתוכנית עבודה

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

תכננו לפי ההקשר הישראלי בלי להניח שיש מסלול אחד

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

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

ראו גם הפרויקטים שלנו.

שלבו את המומחיות הנכונה בנקודה הנכונה

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

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

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

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

עיקרי הדברים

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

שאלות נפוצות

האם כל סטארטאפ דיפ טק צריך חומרה?

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

איך מייסד בוחר בין POC ל־MVP?

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

ראו גם צרו קשר.