פודקאסט מספר 386 (מתקרבים לפנטיום?) של רברס עם פלטפורמה - אורי ורן מארחים בכרכור (בלי משקפיים) את תומר מחברת Natural Intelligence לשיחה טבעית על העיקרון של מוצרים פנימיים של חברה (שנועדו לשמש את החברה עצמה) - מתי נכון לקנות מוצרים כאלה ומתי נכון לבנות אותם (Build/Make vs. Buy).
- בן 37, גר בתל אביב, נשוי + 2 - והיום VP Product ב - Natural Intelligence, כמעט שנתיים בחברה.
- לפני כן כמה סטארטאפים קטנים יותר, בעיקר באיזור החיוג של Cyber Security, Analytics, Data
- היום ב - Natural Intelligence מתעסק בעיקר בעולמות של המוצרים הפנימיים ופחות בעמודי האינטרנט שהם Consumer-facing, יותר בכיוון ה-Back-office.
למעשה הנושא של Build vs. Buy הוא “בדמך” . . .
- לגמרי - ובשנה האחרונה זה בשיא.
קצת לגבי מה אתם עושים . . .
- החברה Natural Intelligence לא לגמרי צעירה - קיימת כבר למעלה מ-10 שנים, מעל 450 עובדים.
- מפעילים מאות אתרי השוואות שהמטרה שלהם היא לעזור לצרכנים מכל רחבי העולם לקבל החלטות נכונות יותר לגבי שירותים שונים, בדרך כלל שירותי Online.
- החל מהשוואות לשירותי ביטוח דרך Home improvements, פיננסים, שירותי B2B - כמעט לכל ורקיטל שיש לו “Service on a Click” אנחנו נביא ל-Consumer את ה - “Top 10 options” באיזור חיוג שלו כדי לעזור לו לבחור - זה בעצם מוצר ה-Consumer-facing שלנו.
- יש עולם מוצרי שלם עם Roadmap משלו מאחורי זה, שמאפשר את כל האופטימיזציה של החווייה הזו - ה-Data וה - A/B Testing וה - User acquisition וכו’ - וזה ה-Roadmap שאני מנהל ביחידה שלי.
אני מניח שלפחות את חלק מהאתרים האלה אנחנו ראינו - ואולי אפילו לא ידענו שזה מה שאנחנו רואים . . . איך זה נראה - כמו בלוג-פוסט שמישהו לכאורה כתב? איך נראה אתר כזה?
- שאלה טובה . . . גם וגם.
- בהרבה מאוד אתרים שלנו יש דוגמא טבלאית בצורה כזו או אחרת.
- חלק מהאתרים הם Non-branded - למשל אם תחפש VPN ותגיע ל-”Top 10 options for VPN” באיזור ניו-יורק או איפה שלא תיהיה.
- חלק מהאתרים הם כן Branded - ואז זה יופיע בצורה של טבלה או כתבה או בלוג שמשווה כמה אפשרויות טובות עבור אותו שירות.
- הקוספט בסוף הוא אותו הדבר - לזקק עבור הצרכן כמה אופציות טובות שרלוונטיות אליו - למיקום הגיאוגרפי, למגדר או לכל מאפיין אחר שלו.
מי הם הלקוחות?
- היום יש בעצם שני סוגי לקוחות, כשאנחנו רואים את זה כמעיין משולש - אנחנו ועוד שני פרטנרים:
- שותף ראשון הוא הצרכן - משתמש הקצה, שלא משלם לנו אבל הוא זה שנהנה מהחוייה ומהאתר
- שותף שני הוא הלקוח המשלם - אותם Brands שנמצאים אצלנו בתוך האתרים - כל מותג עם הסיפור העסקי שלו - הרבה מאוד Deals וסיפורים עסקיים שונים.
- אחד האתגרים שלנו, לפחות בצד של ה-Business, הוא לאזן את המשוואה בין טובת ה-Consumer לבין ה-Business, שצריך להחזיק את עצמו.
אני מניח שהתוכן הזה מיוצר (מג’ונרט, Generated) בצורה בעיקר (אם לא רק) אלגוריתמית, ובעצם המהות של זה היא נושא מעניין לפודקאסט - לא על זה נדבר היום, אבל אני מניח שיש מאחורי זה טכנולוגיה עמוקה ומעניינת ששווה לדבר עליה בהזדמנות.
- לגמרי . . . אפשר גם לנחש מהו מקור השם בהקשר הזה . . .
מה שאנחנו כן הולכים לדבר עליו זה יותר זה החלק שהזכרת קודם של ה - Back office: כל אותם מוצרים שגורמים לכל זה לפעול, מעיין “מערכת ההפעלה של החברה”.
בכל חברה מגודל מסויים יש סט כזה של מוצרים - החל מ-Dashboards פנימיים דרך מערכות לניהול קמפיינים (שתכף נדבר עליהם) ועוד - יש לא מעט כאלה.
איפה התחלתם לפגוש את הנושא הזה? היכן הגיע המפגש הראשון שלך עם הדילמה הזו של Build vs. Buy?
- המפגש הראשון היה בתרגיל בראיון שעשו לי כשהגעתי לחברה . . . התרגיל היה “שרטט על הלוח איך נראה ה-ETL של ה - Data Pipeline, ה-Revenue Data של החברה - עד שבסופו של דבר Business user יודע לצרוך אותו.
- בעצם ב-Sub-text נאמר שיש פה איזשהו מוצר שקנו לפני כמה שנים - מעיין Drag&drop GUI שמאפשר לבנות ETL “ללא מפתחים”…
- איך קראו לזה? נדלג, חברה ישראלית לשעבר . . . יש לא מעט בתחום אז קשה לנחש, אבל בסדר.
- בעצם אותו Drag&drop פשוט וקל להפעלה, שיהיה כמובן “מאוד אינטואיטיבי וירקיע שחקים יחד עם החברה” הפך פתאום לאיזשהו Bottleneck מאוד משמעותי
- הצוות שהטמיע כבר לא נמצא, כמות ה-ETL וה-Processes שהצטברו הפכו כל מסך כזה לבלתי-ניתן-להכלה ע”י עין אנושית.
- מאחר וזה ממש ב-Core של ה-Infrastructure,יש הרבה Processes אחרים שתלויים בזה ויש המון מוצרים עם אינטגרציה על זה - וזה הפך ל-Showstopper.
מה היה גודל החברה בשלב הזה?
- היינו עם Business די דומה בגודל, הרבה פחות אנשים - סדר גודל של כ-250 - אבל כבר אז זו הייתה בעיה קשה.
וכשהתחילו להשתמש באותו המוצר - מה היה גודל החברה?
- הרבה פחות . . .
סביר שזה מוצר שאולי גם היום טוב עבור חברות קטנות, אבל כשהגעתם לסדר גודל של כ-250 עובדים המוצר כבר לא החזיק מים . . .
- יכול להיות שזה באמת היה טוב בזמנו, אבל באיזה שלב אתה צריך להסתכל ולהגיד לעצמך “זה כבר לא משרת אותי”.
(אורי) העולם הזה, של כלים פנימיים - יש בו שני דברים: הראשון הוא גדילה (אתה גדל, יש יותר עבודה וצריך לפתח יותר כלים ואוטומציות כי יש יותר אנשים שיכולים לעשות טעויות); השני הוא (לפחות בחווייה שלנו ב-Outbrain) שיש Domain עסקי מסוים “שיושב” אצל איזשהו צוות והאנשים באותו צוות מתחילים לפתח גם כלים.
- הם מפתחים את הכלים וחוזרים להתעסק ב-Domain העסקי שלהם ובלהזיז אותו קדימה.
- האופרציה מתחילה להשתמש בכלים - כשלאט לאט הכלים האלה הופכים למעיין “בן-חורג” - והם תמיד הדבר האחרון שמתייחסים אליו כשבונים Roadmap או תוכנית עבודה
- (רן) ומחלידים . . .
- (אורי) לגמרי - עד שלב שהם הופכים ללא-שמישים, כי אתה גדל כל הזמן ואף אחד לא מתחזק אותם, והם לא מצליחים לעמוד בעומס.
- (רן) לפעמים אתה עושה טובה ונותן לסטודנט או לעובד החדש בצוות לתחזק אותם - ולפעמים גם זה לא.
אז הוצגת (תומר) בפני השאלה של בניית ETL - ואז התקבלת לעבודה ואמרו לך “אוקיי, בוא תבנה ETL”?
- לשמחתי לא אני בונה את ה-ETL אחרת הייתה קטסטרופה, אבל בהחלט התחלנו לאפיין את כל ה-Infra החדש של ה-Data ETL שלנו מ-Scratch.
- כמעט כל השנה שעברה הוקדשה ל”להרוג את הייצור הזה שהבאנו” ולהשתמש במוצר שמפותח פה.
- כזה שמתאים ל-Scale, ל-Business case, ל-Time-To-Market שאנחנו נדרשים אליו מה-Business users, כדי לייצר pipeline חדש של Data-source חדש.
- מאז אנחנו נתקלים בשאלה הזו בהמון מקרים…
ואם נסתכל רגע שוב על אותו מוצר - זה היה לפני שנתיים? מאז למעשה כבר כל החברה עברה Migration? כל ה-ETL עברו לשם?
- כן.
ובראייה לאחור - אם היית עכשיו מתחיל מאפס, בהסתכלות על מוצרים אחרי שיש בחוץ - היית עושה את אותו הדבר, או שאולי בכל זאת היית בוחר במוצר חיצוני במקרה הזה? האם בשלב הזה בדקתם מוצרים חיצוניים אחרים? אולי Open-sources?
- בשלב הזה ידענו שאנחנו רוצים לעשות משהו שיותאם מאוד ל-Use-case שלנו ולמבנה העסקי שלנו, שכלל לא רק ETL
- היה בזה גם מוצר יותר גדול שכלל אוטומציה מלאה של כל ה-Funnel של Revenue Data
- זה מורכב כיוון שה-Revenue לא נוצר אצלנו אלא אצל ה-Brands שמופיעים אצלנו ב-charts - אני צריך לגשת לכל אחד מ(מאות) הלקוחות ולהביא מהם את ה-Conversions וה-Commissions ולהזרים את זה אלי.
- זה היה חלק ממערך גדול יותר, שהבסיס שלו היה איזשהו ETL שעד אותו רגע היה תקוע במוצר שכבר לא כל כך ידעו איך להשתמש בו.
(רן) אני חושב שהרבה חברות באות עם גישה של “אוקיי, אז אנחנו עכשיו צריכים משהו - אם זה ב-Core שלנו אז נפתח את זה אנחנו; אם זה לא ב-Core שלנו, אנחנו נקנה את זה” - וזה אולי נשמע טוב על הנייר רק שהשאלה הראשונה כאן היא האם זה באמת ב-Core או לא?
- למשל - האם ETL זה חלק מה-Core? יש הרי ETL מהמדף, אבל אם כל אחד מהם שניסינו מאט לנו את ה-Business - גם אם זה לא ב-Core, זה הופך ל-Core . . .
מתי נפל האסימון בחברה ש-ETL זה אולי לא המוצר שלנו אבל זה מה שמניע את ה-Core ולכן אנחנו חייבים לפתח את זה?
- אנ חושב שזה בדיוק בשלב של הבגרות של החברה שבו היא מתחילה לגדול, ואז היא מבינה שה-Scale הוא כבר דרישה דרמטית.
- חברה קטנה שמתחילה - כל המשאבים שלה והפוקוס הפיתוחי והמוצרי חייב להיות במוצר, וחייבים להשקיע בלקוחות הראשונים ובמשקיעים הראשונים, אין את הלוקסוס להשקיע “בפריפריה”.
- כשהחברה גדלה, ויש לה כבר את המוצר הבסיס עומד ואין כבר לחץ של משקיעים (?) ולחץ של לשמור את חמשת הלקוחות הראשונים באוויר - הזה זמן להתחיל לדאוג למה שיקרה בעוד שנה או שנתיים מהיום
- איך אתה תומך ב-Scale יותר גדול, ביותר לקוחות, ביותר משתמשים פנימיים
(אורי) כשאני מדבר על זה עם יזמים - על Build vs. Buy - אני אומר להם “תזכרו תמיד שמתישהו תצטרכו לבנות, ותראו שאתם לא מפחדים להביא את הידע” - הרבה פעמים מפחדים לבנות כי אין את הידע - אבל הנקודה להתחיל להתעסק בדברים האלה היא הנקודה של Product-Market fit.
- עד ה - Product-Market fit אתה קטן ואתה לא עושה Scaling וחשוב לך להיות מהיר כמה שיותר ולהתעסק ב-Core שלך כדי להגיע לאותו Product-Market fit.
- שלב ה - Do things that don’t scale של Paul Graham (שווה להקשיב גם כאן)
- ברגע שהגעת לשם - יאללה, צריך לתחיל לחשוב על כל אותם דברים שהם Scale, וזה נוגע קודם כל ל-Scale הטכנולוגי (שבכלל יהיה אפשר לעשות את זה) - ולעלויות . . .
- (רן) מאוד מתאים למה שתומר אמר קודם - שהחברה נתקלה באתגרי scale והחליטה שה-ETL הקיים לא מתאים יותר.
- וקצת לאתגר אותך (את אורי) - השותף שלך ב-Outbrain - ירון - אמר פעם שנכון שיש Product-Market fit, אבל זה אף פעם לא סוף המשחק: עכשיו מחפשים את ה Product-Market fit הבא, וכל הזמן עושים על זה איטרציות.
- זה לא שיש נקודה שבה אתה קם בבוקר ואומר : “יופי, הגרפים מתחילים לעלות, יש Product-Market fit!” - זה חיפוש מתמיד.
- (אורי) נכון - אבל בשלב מסוים אתה מתחיל לגדל Core Business שמתחיל להוות “פרה חולבת” שהולכת ומשמינה (זו התקווה), ואם אתה לא תטפל בדברים שקשורים ב-Scale, אתה תעצור את ה-Business הזה.
- אתה צריך להיות מסוגל לתמוך בגדילה הזו של ה-Core, וכמו שירון פעם אמר לי: “אנחנו כבר חברה מספיק גדולה, כבר יכולים ללכת וללעוס מסטיק ביחד”.
- יש לנו את ה-Core שימשיך לגדול ולעבוד, אבל אנחנו צריכים להיות מסוגלים לפתח גם את הכיוונים הבאים ולעבוד עליהם בצד.
- (תומר) באיזשהו שלב פשוט ה-Core מתרחב עם הזמן - התפיסה של מהו Core ומהו Enabler להצלחת החברה הבוגרת, שכבר אינה סטארטאפ קטן, הולכת ומתרחבת.
- הרבה דברים הם Enablers על מנת להמשיך ולגדול למדרגה הבאה.
- (אורי) בהרחבות של Core, אם לצורך העניין יש לך סט Features בסיסי של המוצר - עכשיו כשאתה מביא את הפיצ’ר הנוסף, הוא לא כמו בפעם הראשונה כשבנית אותו עבור חמישה לקוחות ויכולת לעגל פינות באתגרים של Scale - עכשיו כשהפיצ’ר הזה יצא לשוק, הוא יצא למאות ואלפי לקוחות.
- פיתוחים ב-Core - צריכים להבין שהם מביאים איתם עוד משהו - זה לא Tech-debt אלה מעיין enablement . . . “אתה כבר צריך לחיות ב-Scale”
- (תומר) סוג של Biz-Debt - משהו שהוא כבר חלק הכרחי של ה-Business.
- ויש עוד שאלות בהקשר הזה (של תומר), למשל - A/B Testing: האם כלי לניתוח A/B Testing צריך להיות חיצוני או פנימי? אני חושב שחברה שרק מתחילה את דרכה בעולם ה-Online כנראה שתשתמש באיזשהו כלי חיצוני שזמין לה, כי יש לה דאגות אחרות על הראש (Google Analytics למשל).
- תוך כדי העבודה ב-2019 על ה-Roadmap, כשאמרנו שאנחנו צריכים לבנות כזה כלי והשאלה הייתה האם לבנות או לצאת החוצה, היינו כבר בתפיסה שזה חלק מה-Core של העבודה
- האופטימיזציה וכו’ - זה חלק מה-Core.
- לפני 6-7 שנים זה אולי לא היה ברשימת הדברים שהם חלק מה-Core של המוצר.
- (רן) אתה אומר שאולי לפני 6-7 שנים זה לא היה חלק מה-Core אבל ההגדרה של ה-Core הולכת ומתרחבת וגם את זה צריך לקחת בחשבון.
דיברנו קודם על מקרה שבוא היה מוצר שקניתם ובסופו שלדבר החלטתם לבנות - האם היה לכם גם מקרה מהסוג ההפוך, של מוצר שבניתם והחלטתם שאתם רוצים להפסיק לבנות והחלטתם לקנות?
- אנחנו עכשיו בהתלבטות כזו, עם משהו מאוד פשוט - פונקציונאליות של Fetching, מה-API החיצוניים אל תוך ה-Data Lake שלנו.
- פיתחנו Fetcher פנימי, in-house, שניגש לכל מיני מקורות מידע - אם זה Marketing channels או הלקוחות שלנו - והביא את ה-Data בקבועי זמן כלשהם.
- אנחנו נתקעים שם בבעיות של Time-to-Market - ה-Business unit רוצה מידע בקבועי זמן מסויימים מ-Channel חדש (נגיד Outbrain לצורך הדוגמא) - ועכשיו אני צריך להשקיע בזה אנשי פיתוח ו-Engineering, שלא יעשו משהו שתואם לליבה העסקית אלא ב-Fetching ל-API.
- וזה - כשיש כלי מדף שזה בדיוק מה שהם עושים, וגם אנשים שהם לא חלק מה-Engineering ואולי יותר זמינים (Availability) יוכלו לעשות איזשהו Drag&drop, יתחברו ל-API וזהו.
- בימים אלו אנחנו מתלבטים האם לעשות סוג של “אחורה פנה” ולהתחיל להביא Data מסויים באמצעות כלי שלישי ולאו דווקא באמצעות כלי Fetching שפיתחנו בעצמנו.
דיברנו על שתי דוגמאות, עכשיו ננסה לעשות הכללה, לראות מה הם הקווים המנחים ואיך אתה מחליט . . .
- הראשון היה “האם זה ב-Core או לא?”
אילו עוד פרמטרים אתה לוקח בחשבון כשאתה מתלבט האם לבנות מוצר פנימי או לקנות משהו?
- אני חושב שהצלחנו לגבש כמה שאלות שמנחות אותנו בתהליך ההחלטה או ה-Evaluation של הצורך שעלה מה-Business או הצורך הטכנולוגי שלנו.
- אחד מהם זו באמת שאלת ה-”Core או לא”’ וגם עד כמה ניהיה “נעולים” לתוך אותו מוצר - כמה שכבות של Processes או מוצרים אחרים “יתלבשו” עליו, ואז אני נשאר עם איזשהו 3rd-party שתקוע בליבה של שנים קדימה.
- מה שקרה לנו בעולם ה-Data…
- (רן) אתה קונה אוטו, ומרכיב עליו גגון - ועל זה יש אוהל, וסככה וכו’- ואז כשאתה רוצה להחליף את האוטו, אתה מגלה שזה לא גנרי, ואי אפשר “סתם” להחליף את האוטו.
- (תומר) או שהמחיר של החלפת האוטו הוא כל כך יקר שזה פשוט מגוחך.
- (אורי) אבל הסיכוי להחליף אוטו, שבדרך כלל יש לו ארבעה גלגלים, וגג וחיבור סטנדרטי לגגון . . . הסטנדרטיזציה במוצרי מדף תיהיה יותר גבוהה ממה שאתה תבנה בפנים.
- (תומר) זו בדיוק השאלה השלישית - האם ה-Business case שלי הוא ייחודי לי או שהוא גנרי מספיק? האם יש איזשהו צורך שכנראה עדיף לי לפתח In-house את המענה אליו, או שזה use-case שיש להרבה חברות כמוני ולכן אין סיבה להתמודד עם זה מאפס, ועדיף לקחת משהו שקיים בחוץ - כמו Fetching.
- (רן) … או A/B Testing - כל החברות עושות זה. האם הצרכים שלי ב-A/B Testing דומים לשאר החברות? אם כן אז סביר להניח שאני אמצא מוצר מתאים, אבל אם הצרכים שלי מאוד ייחודיים אז חבל לחפש כי כנראה שלא אמצא משהו מתאים ועדיף כבר לפתח בפנים.
- (תומר) כן - ושאלה שמתחברת לזה היא לא על הייחודיות שלה-Business case אלא על הייחודיות של ה-Best Practice אצלנו בחברה, בעיקר באוטומציות.
- כשאנחנו באים לאטמט (To Automate, ל”עשות אוטומציה”) תהליכים ידניים של Back-office או של Business או אופרציות כאלו, אנחנו תוהים האם יש לנו איזשהו Best Practice שאנחנו צריכים לשמר אותו על ידי פיתוח פנימי.
- נתקלנו בזה המון תוך כדי אוטומציה של user acquisition למשל, בעיקר Bidding מול Ad-words או Bing Ads -איך אני מאטמט את תהליך ניהול הקמפיינים? האם אני לוקח איזשהו כלי חיצוני (ויש המון כאלו שמאפשרים Bidding אוטומטי), או שאני מפתח פנימית?
- שם, החלטנו שבכל המקרים באמת החברה התמחתה לאורך השנים בכל מיני תהליכים של user acquisition ששווה לחקות אותם באופרציה הפנימית שלנו ולא להסתמך על כלי חיצוני.
- (רן) זאת אומרת שיש מעיין Business-Intelligence, הרבה חוכמה (know-how) שאולי לא ”קודדה” עד עכשיו, אבל שווה לקחת את הזמן ולקודד אותה כי סביר להניח שזה לא משהו שתמצא מבחוץ.
אילו עוד פרמטרים אתה לוקח בחשבון?
- הכל מתחבר אחד לשני . . . Time-to-Market זה גם משהו שאנחנו שואלים את עצמנו - האם יש לי בכלל שיקול Time-to-Market דרמטי בסוגייה? יכול להיות שזה צורך שהוא חשוב אבל לא כל כך דחוף, או שזה צורך דחוף ולכן “מחר בבוקר” צריך להעמיד איזשהו פתרון - ואז השאלה היא מה יהיה יותר מהיר: פיתוח של שני אנשים “בתוך הבית” שיכולים לרוץ מהר או דווקא אינטגרציה עם חברה חיצונית שאולי תיהיה יותר מהירה.
- (אורי) יש Time-to-Market ויש Time-to-Scale - המקום של כלים פנימיים מגיע הרבה פעמים ביכולת לאפשר Scale.
- אני יכול להגיע לשוק ולפעמים אני רוצה להגיע לשוק ולבדוק משהו, לאו דווקא כדי לרוץ ולשווק אותו - אז עבור חמשת הלקוחות הראשונים, על מנת שיהיה משהו לבדוק, אני יכול גם לאפשר מצב שבו אנשים יעשו משהו בידיים, סוג של POC, ובשביל זה אני לא אבנה כלים.
- כשאני מתחיל לחשוב אח”כ איך אני עושה לזה Scale, ברור שאי אפשר להעמיד צבא של אנשים שיעשו הכל ידנית.
- (תומר) התלבטות נוספת שאנחנו מתלבטים איתה ממש בימים אלו היא שעד היום רוב התקשורת מול ה-Brands שנמצאים אצלנו באתרים נעשתה ע”י אנשי ה-Business בדרכים שגרתיות של מיילים, טלפונים וכו’ - והחלטנו שאנחנו רוצים להעביר את כל התקשורת הזו לאיזושהי פלטפורמה מנוהלת מודרנית.
- סוג של CRM? אולי Marketo? יכול להיות, אבל יש לדוגמא גם מוצר שעליו הסתכלנו בין היתר של Salesforce בשם Communities, שהוא משלים ל-CRM ומאפשר את התהליך של user-login-כניסה, אפשר לצפות בביצועים שלו, באילו אתרים שלנו הוא נמצא, לראות Performance dashboard שלו - וכמובן אפשרות לצ’ט עם ה-Account Manager שלו וכן הלאה
- זו מעיין פלטפורמה שתיהיה חלק עיקרי בתקשורת שלנו מול הלקוחות וגם כאן יש שאלה - ברור שאם אני אקח כלי חיצוני, Salesforce לדוגמא - מחר בבוקר אני יכול יחסית בפשטות להביא כלי שעובד, אבל השאלה האם בטווח הארוך זה לא חלק דרמטי מהיחסים שלי עם ה-Business? האם יש כאן איזשהו use-case מאוד ייחודי שאני צריך לתמוך בו, מעבר לרק התצוגה של המידע?
- אנחנו בדיוק בשלב הזה של לאפיין בדיוק מה גם, שלוש שנים קדימה, הולך להיות השימוש של אותו אמצעי תקשורת - ומכאן לגזור האם כדי להביא כלי מבחוץ או לפתח בפנים - וזה אומר מאפס, כי היום אין לי שום תשתית לזה -
- להביא אנשי פיתוח, Frontend, Backend, Designers וכו’.
(רן) וזה מביא אותנו לשיקול הבא - כוח אדם (או תקציב או איך שלא תסתכל על זה) זה מן הסתם שיקול משמעותי. היום ב - Natural Intelligence אתה יכול להגיד מהי מצבת כוח האדם של אנשים שעובדים רק על מוצרים פנימיים? או כאיזשהו אחוז מכוח האדם?
- אצלנו ביחידה שעובדת בעיקר על מוצרים פנימיים מדובר על סדר גודל של כ-80 אנשי פיתוח, אולי 65 בלי אנשי מוצר, רק לכלים פנימיים.
- זה Data ופלטפורמת תוכן, אוטומציות . . . כל זה פחות או יותר
אנחנו מדברים על מוצרים פנימיים, לא תשתיות (ענן, Databases וכו’)?
- תשתיות כמו Data Lake למשל כן נכלל בזה מבחינתי, ה-ETL גם.
קבוצה גדולה . . .
- כן - קבוצה גדולה, והיא גדלה בעיקר בשנה וחצי האחרונות גדילה די מטורפת, כי החברה הגיעה לאיזשהו שלב בגרות שדורש אוטומציה ו-scale הרבה יותר רחב על מנת לתמוך ב-Business
- וזה כמובן מעלה שאלה של Cost - איפה כדאי להשקיע את הכסף: בקניית מוצר או ב-Headcount ולפתח אותו פנימית?
(אורי) אמרת “80” ואני הגבתי ב”וואו!” - כי ב-Outbrain הצוות שמוגדר עבור כלים פנימיים הוא 5-6 - אבל קל כביכול לשכוח שיש את כל מה שאנחנו מכנים “MIS” - כל ה-Salesforce וה-Marketo וכל הכלים שנמצאים שם והחיבוריות ביניהם והחיבוריות שלהם למוצר עצמו ול-Dashboards של המוצר עצמו
- (תומר) שאצלנו זה חלק מהמוצרים הפנימיים - כל ה-Visualization של הנתונים והבאת ה-Data ל-RedShift כדי שיהיה זמין ל - Business user . . .
- (אורי) מה שלפעמים מכנים “BI” או Dashboards . . . וואלה, אם אתה כולל בפנים את כל הדברים האלה, ב-Outbrain זה כנראה אותו סדר גודל.
- (תומר) הייתי שמח לשמוע שיותר אפילו . . . מעניין.
- ועדיין - גם כשגדלים זה בטוח לא אומר שצריכים להיות “קלים על ההדק” מבחינת הכנסת פיתוח של דברים ל-Roadmap.
- למשל Email Marketing - למה לפתח את זה פנימית? בדיוק עכשיו החלטנו לסגור עם איזשהו Vendor חיצוני, אין שום צורך לפתח משהו שהוא לגמרי סטנדרטי וגנרי - פנימית.
- עדיף להביא משהו מבחוץ וזו דוגמא למשהו כזה.
- (אורי) גם את ה-CRM של החברה לא . . . זה משהו להביא מבחוץ, וגם לא את ה-ERP של החברה. יש עוד ראשי-תיבות של 3 אותיות?
- אולי IDF . . . נשק זה משהו שכדאי לפתח פנימית? נושא לפרק עתידי עם רפא”ל.
לקראת סיום - משהו שרצית לכסות ועוד לא כיסינו?
- רק את המובן מאליו - בסוף, אחרי כל ההחלטה על פנימי מול חיצוני, יש את ההערכה עצמה של הכלי, כלומר - כמה הוא עולה? למה הוא טוב? מה חברות דומות לי עשו ובאיזה כלי הן בחרו? האם הכלי תומך ב-Scenarios שאני אדרש להם חמש שנים קדימה?
- לפתוח עוד Spreadsheet של Evaluations . . .
- (רן) אתה מכיר איזשהו אתר השוואות שיכול לעזור?
לסיכום -
- דיברנו על העיקרון של Build vs. Buy, עם כמה דוגמאות מהחיים ב - Natural Intelligence
- ניסינו להפיק כמה Rules of thumb על איך נכון להחליט - מהם הפרמטרים -
- האם זה חלק מה-Core?
- האם יש סכנה של Vendor Lock-in?
- האם יש Unique business case או איזשהו “secret sauce” של החברה?
- יש גם Time to Market כמובן
היה מעניין, תודה תומר. איפה אתם יושבים? מחפשים אנשים?
- ברור - משרדים הורסים ב-ToHa בתל אביב, אי שם בפריפריה שאחרי איילון
- לא, כי כרכור . . . :-)
- מגייסים כל הזמן - בואו בהמוניכם: מפתחים, אנשי Product - בואו.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
אין תגובות:
הוסף רשומת תגובה