תמלול: ב-2026 פחות מהנדסים, יותר מנהלי מוצר - דניאל מרקוס (April)

היכרות עם דניאל ואפריל (50 הסטארט-אפים המבטיחים של כלכליסט)

אייל דוד: [00:00] דניאל, מה קורה? טוב, תודה, מה איתך? מצוין, אני לא הולך אחרי זה לנמל, אירוע שם.

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

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

DIY מול Human in the Loop בעולם המסים

דניאל מרקוס: [00:54] כן, בטח. אז אני אתן קצת קונטקסט, שאייפריל היא איזושהי סוויטה של כלים לטאקס, שמה שאנחנו עושים זה עבור אזרחים אמריקאים מייצרים סוג של רואה חשבון וירטואלי, שעושה הכל מטאקס פלאנינג לטאקס אופטימיזיישן, לטאקס פיילינג. אז בעצם מטפל בכל מה שקשור למיסים עבורך. עכשיו, באותה אפליקציה שיש בה כבר מיליוני משתמשים, אז יש לנו כמה פלייבורים, ובאירוע הכואב והנוראי הזה שקורה פעם בשנה שהוא חובה בארצות הברית שנקרא טאקס פיילינג, אז יש לנו את האפליקציה שהיא 100% DIY. זאת אומרת, אתה נכנס עכשיו לאפליקציה, ממלא את הפרטים שלך באיזשהו תהליך כזה עם מינימום פריקשן, בסוף לוחץ סאבמיט, ואנחנו מחשבים כמובן הכל מאחורי הקלעים ומגישים את זה עבורך ל-IRS ולכל הסטייטס. אבל יש עוד איזשהו פלייבור, שיש Human in the Loop, רואה חשבון, בסדר? שעושה לך או איזשהו ריוויו או ממש עוזר לך להכין את המיסים עבורך. כי בסך הכל עדיין יש כמות מאוד מאוד גדולה באוכלוסייה שרוצה את ה-Trust ואת ה-Human הזה, ולראות פנים של בן אדם, ולדבר איתו, וכן הלאה. עכשיו, בעונה האחרונה, צרות של עשירים בגדול, אבל נתקלנו בסקייל יותר גדול ממה שהתכוננו אליו, וכשאנחנו מסתכלים על המטריקות ועל הפאנלים, התחלנו להבין שיש לנו בעיות של bottlenecks בפייפליין של אותם רואי חשבון, שעושים ריוויוז לטאקסס של המשתמשים. במיוחד שהיו פתאום משתמשים שלא ציפינו שהם ישתמשו בטיר הזה עם מורכבות, שפתאום מישהו בא ומעלה לך 40 מסמכים שונים. כאילו, לך תעשה על זה ריוויו, זה שירות שעולה אלפי דולרים, אם הבן אדם היה עושה את זה איפשהו בחוץ, ובטיר הזה אצלנו ברוב המקרים זה היה כמה עשרות דולרים. עכשיו, הגענו למסקנה הרגע שאנחנו צריכים לבוא עם פתרונות יצירתיים בשביל לפתור את הסוגיה הזאת, והיו לנו הרבה חומרים מקדימים. היה לנו את אותו דטרמיניסטיק טאקס אנג'ן, שיודע לעשות כל מיני חישובי מס ולקבל מספרים ולהפיק פלטים. היו לנו צ'קליסטים של מה בדיוק אמור ריוויואר, רואה חשבון, לחפש ב-review, והיה לנו דאטה של כבר מאות משתמשים שעשו את זה. ככה שיש לנו גם את האינפוטים וגם את האאוטפוטים של מה רואה חשבון היה אומר, והחלטנו לעשות איזשהו בליץ כזה סופ"ש האקתון בגדול, על בואו ננסה רגע גישה חדשה, אג'נטיק לחלוטין, 100% vibe coding, של לכתוב איזשהו agent שעושה את ה-Preliminary Review, לוקח את כל המסמכים של היוזר, את כל הדאטה, משתמש בטאקס אנג'ן שלנו, מריץ את כל הצ'קליסט הזה, מוצא כל מיני דברים כמו אומישנס, זאת אומרת, דברים שיכול להיות שהיוזר פספס, דברים חסרים, עונה על השאלות של היוזר, שלפעמים באות מראש, ועושה כל מיני דברים, גם אפילו קצת יותר מורכבים, כדי להשוות לצורך העניין, האם כדאי לך לקחת מה שנקרא Standard Deduction או Itemized Deduction, משהו כזה סופר... הרגתי אותך להתחלה, כן, אוקיי. אז בסופו של דבר, אחרי סופ"ש מאוד עמוס, הגענו ליום שני עם המערכת הזאת באוויר, מהרואה חשבון, יאללה, בואו תשתמשו בזה, תריצו, קיבלנו את הפידבקים, עשינו איטרציות סופר מהירות בעיקר על הפרומפטים, תוך יומיים, ואחרי יומיים אמרנו, אוקיי, מעולה, כל רואי החשבון עכשיו עוברים מהמוצר הזה למוצר אחר, שבאמת צריך לעשות את הפרפריישן עבור היוזרים, והמוצר הזה עובר להיות, בגדול, 99% AI. עבד מדהים, היה חוויה מרגשת.

הצוואר בקבוק שהתפוצץ עלינו בעונת המסים האחרונה

הסופ"ש שבו בנינו אג'נט ב-Vibe Coding והפכנו את ה-Review ל-99% AI

אייל דוד: [04:49] אז אוקיי, מפה אנחנו מקבלים שני דברים, אז רק long story short, בעצם גם כבר סיפרנו בעצם את מה אתם עושים, גם השם שלכם גם מייצג בעצם את ה-deadline שהיה בעצם להגשת המסמכים באפריל, את הדו"ח בעצם, זה דו"ח מס, אם נקביל את זה לעברית, אני מבין? בדיוק. ובעצם היה לכם צוואר בקבוק, היומנס לא יכולים לעבור כל כך מהר על כל התוכן הזה, אז בעצם הכנסתם פנימה רכיב שפיתחתם עם וייב קודינג, שבעצם פישט את כל הדבר, וזה מוביל אותנו בעצם לכמה דברים שעולים. אז באמת, הדבר המרכזי, כשאנחנו דיברנו בשיחת הכנה, אמרת לי, דיברנו בעצם על תוכנית הגדילה שלכם, או הגיוס שלכם בעצם קדימה, ואמרת לי, תשמע, אני כרגע פחות צריך מפתחים, אני צריך יותר אנשי פרודקט. נוסיף כאן כוכבית, אולי אפילו ג'וניורים, אולי יש פה הזדמנות. יש פה גם את האסכולה השנייה של, היי, למה לא עוד מפתחים כדי לייצר עוד? אז תסביר את זה קצת. והדבר השני שכאילו חשבתי עליו כשזה, ואתה תספר גם, אני אשמח, זה כאילו, מה התהליך שלכם היום בין רעיון מוצרי לבין ניסוי והשקה? כי כאילו, את זה עשיתם נורא מהר, אז אני אסכם על... נכון, זה לא מקרה סטנדרטי לגמרי. בול. יש לנו עוד מקרים אחרים,

הריישו בין מנהלי מוצר למהנדסים השתנה - 1:10 כבר לא תקף

דניאל מרקוס: [06:01] או בוא נגיד, תהליך ה-best practice שלפעמים עובדים בו ולפעמים לא, כמו בכל סטארט-אפ צריך, העיקר שזה explicit של מתי אתה מעגל פינות ומתי לא. אז רגע, אני אחזור לשאלה הראשונה שלך, בנושא הגיוסים. אז כן, אכן יש לנו משרות פתוחות היום מהכל מהכל, גם engineering, גם פרודקטים, אבל כן בחודשים האחרונים נפלה עליי בעיקר ההבנה הקצת יותר עמוקה, שה-ratio בין, נקרא לזה, בילדרים שהם לא engineering, זאת אומרת, פרודקט מנג'רס ודיזיינרס, ואצלנו דיזיינרס זה פרודקט דיזיינרס, זה מישהו שגם עושה את ה-UX research עד לכדי ה-Finalized Figma, זה לא רק מישהו שבא ומזיז פיקסלים, זה ממש הכל מהכל, לעומת כמות האנג'ינירס צריכה להשתנות. ואני אישית הייתי באסכולה מאוד קיצונית, שהאחוז PMים לאנג'ינירס בחברה שלנו היה בערך 1 ל-10, אוקיי, ובאיזשהו שלב גם אני הייתי לבד כ-PM היחיד עם 20 מפתחים, ולאט לאט אנחנו מתחילים לשנות את זה, ואנחנו רואים גם את הטרנד שנהיה הרבה יותר קשה ל-PMים לעמוד בקצב של האנג'ינירינג, כשה-Velocity נהיה יותר מהיר, בעיקר בגלל כלי AI שנכנסו בשנים האחרונות, ופשוט נהיים דרמטית יותר טובים month over month, זה פשוט לא מפסיק, ה-Velocity רק עולה, עד לכדי זה שממש אני מבין שה-bottleneck הבא שלי הולך להיות ב-Product Managers שהם לא מצליחים לייצר את הדרישות המדויקות מספיק מהר של מה צריך לעשות, והולך להיות לי צוות Engineering שנשאר איידל ועובד על לצורך העניין technical debt, אלוהים ישמור,

ה-Velocity של מהנדסים גדל פי 1.3-1.5 - מה זה אומר על R&D

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

דניאל מרקוס: [08:15] ועכשיו אתם נמצאים במקום הזה על אחת כמה וכמה, או שזה, מה דעתך? אני חושב שאנחנו פגשנו בזה קצת יותר מהר, גם בגלל שעשינו אולי דברים קצת יותר מסודר ומדויק, וכל מיני שינויי אינפרה בשביל סקיילביליטי שאנחנו רואים שעכשיו אנחנו קצת פחות bound to it, ורצים יותר מהר, אבל הטרנד הוא חד-משמעית שם. כל פאונדר שאני מדבר איתו מדבר על איך ה-velocity ב-engineering גדל, ורואים את זה בכל מקום, וזה ברמה גם שכשאני מתכנן עכשיו roadmap לשנה הבאה קדימה, נגיד שנה, פלוס מינוס שנה, אני אוהב לתכנן, בגלל שהעסק שלנו הוא נורא מוזר, ומיסים, זה נורא סיזונלי, זה פעם בשנה פיילינג כזה, אז אנחנו עושים באמת פעם בשנה תכנון מסיבי. אני מתכנן שלשנה הקרובה, ה-velocity של ה-engineering group שלי צריך להיות בין פי 1.3 לפי 1.5 ממה שהוא היה היסטורית עד היום. בהינתן העלייה הליניארית ב-velocity, ואיך שאני רואה שדברים מתקדמים, ואיך שאני רואה שהאימוץ בכלים מתחיל להיות יותר ויותר חזק, ואני מבין שה-bottleneck עובר למקום אחר. עכשיו, אני כבר רואה את הבוטלנקים האלה נוצרים בפרודקט בכל מיני ניואנסים ספציפיים, בספרינטים מסוימים, פעם בכמה זמן, שפתאום קצת יותר קשה, ואתה רואה שהטיקטים קצת פחות מדויקים, וה-engineers, בוא נגיד, יש להם יותר חופש פעולה להמציא. שאתה יודע, מצד אחד זה נחמד שפעם יש ספרינט קצת יותר פנוי, אבל מצד שני זה טרנד. ובשביל לפתור את הבעיה הזאת צריך לעשות איזשהו re-balancing בארגון. וככל שעושים את הדברים האלה, את ה-practices של איך עובדים בארגון יותר קיצוניים, אז גם אני רואה שה-balancing משתנה עוד יותר. אז נגיד, דברים שעשינו אצלנו אפילו בחודשיים האחרונים בערך, נתנו, עשינו איזה double-down סופר רציני אחרי המלחמה האחרונה באיראן. תרחיב, מה זה אומר? הרבה מצוות האנג'ינירינג שנמצא בישראל לא יכול כל כך לעבוד, והיינו מטר מעונת המיסים, ואז אמרנו, אוקיי, פתרונות יצירתיים עכשיו, אז 1. עושים double-down on vibe coding, 2. בוא רגע נשקיע, יש לנו עכשיו, בגדול לי, שכפאונדר אין לי כל כך את הפריבילגיה להיות עם המשפחה בזמן הזה וצריך לחשוב על הפתרון ל-15 באפריל ול-VP R&D שנמצא בארצות הברית, עושים רגע איזה brainstorming, איזה hackathon על איך אנחנו משפרים את יכולות האג'נטיק קודינג שלנו בארגון, ופיתחנו איזה multi-agent system בעזרת קרסר שיש בו סופטוור ארכיטקט וסופטוור אינג'ינייר ו-QA ואוטומציה וטסט אינג'ינייר ופרודקט מנג'ר ודיזיינר וכן הלאה, כדי להגביר את ה-velocity לכמה שבועות הקרובים, זה עבד הרבה הרבה יותר טוב ממה שהיינו יכולים לצפות. אנחנו מנסים לעשות איזה ליפ כזה פעם בחצי שנה, ואתה יודע, לפעמים זה עובד, לפעמים לא. זה תלוי בטכנולוגיה, מתי היא שם ומתי היא לא.

איך מלחמת איראן הפכה לקטליזטור לקפיצה הבאה

Brainstorming/Hackathon פעם בחצי שנה

אייל דוד: [11:43] בוא, בוא, בוא, בוא, שנייה, נחנה, כי רצת, וואו, אולי מזל ש... לא מזל, אבל זה שהייתה מלחמה בעצם דחקה אותנו. לגמרי, דחף אותנו לפינה, ועם הגב לקיר אתה מוצא פתרונות יצירתיים. זהו, אבל רצת על זה נורא מהר, בוא נחנה שם רגע. אוקיי, יש מלחמה, ובאמת עונת המיסים מגיעה, ומה היו ההימורים הנוספים שיכולתם לקחת בעצם בסיטואציה הזאת?

המודל העסקי B2B2C של אפריל - והלחץ של עונת המסים

דניאל מרקוס: [12:07] מה עוד היה על השולחן? אז לא אמרתי את זה קודם, אבל המודל העסקי שלנו, המודל Go-To-Market, הוא B2B2C, בסדר? אז אני לא פונה ישירות אליך כלקוח של האפליקציה שלי, אני פונה למוסדות פיננסיים, ואני חותם איתם כבר על העסקאות חודשים לשנים מראש, על כמות מסוימת של יוזרים שהם יביאו, שאני אתן להם את אותו product/service של טאקס פיילינג, אופטימיזיישן וכן הלאה. עכשיו, פורצת מלחמה בסוף פברואר, שזה כבר בתוך עונת המיסים, אני כבר לייב עם כל הלקוחות האלה, אני לא יכול להפסיק לשרת אותם, ולחלק מהם, לפחות, אתה יודע, זה לא הכי גרוע, זה היה יכול לקרות בדצמבר, לפני שמתחילה העונה בינואר, זה היה נורא. נורא. כי אז לא היו מעלים חומרים, נכון? כן, ואז לא היינו מצליחים לעמוד בהתחייבויות של הלאנצ'ים, אבל זה כבר היה אחרי הלאנצ'ים, והיו לנו עוד אקסטרה התחייבויות, על כל מיני פיצ'רים שאמרנו, אוקיי, כן, זה במהלך העונה במרץ אנחנו נעשה לכם, או זה לפני הפיק של ה-15 באפריל, שזה הדדליין, וכולם אוהבים לעשות דברים בדדליין, כי כולם יומנס בסופו של דבר, אז אנחנו משיקים עוד פיצ'ר כזה וכזה. אופציה אחת הייתה לא לעמוד בהתחייבויות, וללכת רגע ללקוחות שלנו, ולהתנצל, ולספר איזה סיפור עצוב וקצת דמעות, וכן, אנחנו, כל צוות האנג'ינירינג שלנו בישראל, ואין ברירה, וכאלה, ונפצה אתכם. ואופציה אחרת זה לנסות למצוא פתרון יצירתי, בסדר? בוא נגיד ככה, שום דבר לא היה נשבר, זה לא שהאפליקציה הייתה נופלת, או משהו כזה, הכל עבד, והיו לנו עוד התחייבויות שלא יכולנו לממש אם לא היה צוות אנג'ינירינג עובד לאותה תקופה.

אייל דוד: [13:52] ואז בעצם, אוקיי, כנראה שהיו שם עוד אופציות סביב זה, אבל, אוקיי, החלטתם ללכת בדרך הזאת, אז איך אפיינתם את זה, איך בעצם בניתם את הצוות הזה, ואיך זה נראה?

איך בנו צוות מולטי-אג'נט: Architect, Engineer, QA, PM, Designer

דניאל מרקוס: [14:02] אה... אז... איך מגדירים הצלחה בכלל של דבר כזה? כי זה אופורטוניסטי לגמרי. שאלה מצוינת. זה אופורטוניסטי לגמרי, אנחנו אוהבים לעשות כאלה מונשוט פעם בכמה חודשים, בשביל לנסות דברים, to take the technology to the max, ואנחנו מסתובבים בטוויטר, ואנחנו רואים שאנשים עושים דברים כאלה בעולם. פשוט לא על ניסים. יאללה, לא חושבים, פשוט עושים, ותוך כדי שעושים, גם רואים best practices וגם עושים מחקר כזה עצמאי, ה-VP R&D ואני, ואני רואה את ה-Practices האלה, והוא רואה את אלה, ואנחנו מריצים, ואנחנו בודקים את זה על פיצ'רים אמיתיים. ככה שבאותו שבוע, בגדול, פלוס-מינוס ה-VP R&D ואני הרמנו ספרינט של כמעט צוות מלא,

אייל דוד: [14:49] רק שנינו. איך זה עובד? אתם בעצם, אתם מגדירים תכולה. מגדירים תכולה. ואז פוגשים אותם בסוף? איך זה נראה?

דניאל מרקוס: [14:57] ואנחנו, ורצנו על זה בשיטה של, אוקיי, הנה הדברים שלצורך העניין אנחנו יותר בטוחים שאפשר לעשות איתם וייב קודינג. אה, אוקיי. בואו נתחיל מהם, בואו נתחיל מהדברים הקלים. שינוי UI, הדבר הזה לא נראה טוב ב-Dark mode, זה צריך לזוז הצידה, קל. הכפתור הזה לא עובד? קצת יותר קשה, אוקיי? צריך להבין מה הכפתור הזה עושה. פיצ'ר שלם של Document Management, אוקיי, וואו. בואו ננסה את זה, בואו נעצור פה. יש לזה גם Public API, זה צריך גם לראות Webhook, עוד כל מיני דברים. בואו נראה איך אנחנו עושים. ותוך כדי האיטרציות האלה, כל פעם אנחנו, כאילו, קריטי בכל דבר שעושים בווייב קודינג. ברגע שאתה עושה את האיטרציות, אוקיי? ברגע שאתה בונה משהו, זה להסתכל בפינצטה על ה-reasoning. אוקיי? כל כלי שבעולם שעובדים איתו היום יכול להראות לך את ה-thoughts תוך כדי, את ה-reasoning, להסתכל בדיוק מה הוא חושב, מה הוא עושה, והוא מסביר מדהים למה. לקרוא כל שורה, לא לפספס כלום, הרבה הרבה יותר חשוב לקרוא את ה-reasoning מאשר את ה-code שזה מייצר בסוף, בסדר? לראות את ה-reasoning ולראות למה הוא קיבל החלטות מסוימות, ובגדול, מה שאתה צריך להבין מזה זה איזה קונטקסט היה לו חסר. ברגע שהוא מקבל החלטה לא נכונה, לעצור שנייה ולהבין למה. ולפעמים, גם כשאתה לא מבין למה הוא קיבל החלטה, אז האיטרציות הכי טובות עם האג'נטים זה לשאול אותם: רגע, אני רואה שרשמת ככה וככה, למה עשית את זה ולא את זה? ואז הוא אומר לך, ומשם עושים את האיטרציות. וכל פעם מגדילים ומוסיפים ומוסיפים עוד אג'נט לטים הזה, ועושים את האיטרציה רגע עם משהו צריך להיות סקיל במקום אג'נט. וגם זה, זה קצת מצחיק, אבל אתה בונה כאילו את המערכת מולטי אג'נט של הווייב קודינג עם וייב קודינג, כי מי אני שאדע אם הדבר הזה יהיה הכי טוב לקרסר עם אופוס 4.6 כסקיל או כאג'נט?

אייל דוד: [16:48] אז אני אשאל אותו והוא יגיד לי, ברור. אז זה מה שניסיתי להבין, כמה אקטיביים הייתם בעצם שניכם בתוך האירוע הזה,

דניאל מרקוס: [16:55] ומה נחשב להצלחה? זה היה שבוע? איך הגדרתם את זה? זה היה איזה שבוע של אנחנו נותנים כזה בליץ מ-0 למערכת עובדת, שאנחנו יכולים לפתח את הפיצ'רים, ואז עוד שבועיים של איטרציות תוך כדי פיתוח פיצ'רים אמיתיים. אז כאילו הייתם על זה, הייתם על זה כאילו ב-full capacity. כן, זה היה די full capacity, וזה היה בדיוק השבוע הראשון הזה של המלחמה, שכולם ירדו כמעט ל-0 capacity כדי להתאפס. אז כאילו אנחנו ניצלנו את זה בשביל לעלות ל-100% capacity על איזשהו מונשוט כזה או אחר. עכשיו השאלה המתבקשת זה, מה זה אומר?

העלות האמיתית: $1000-$2000 לחודש לכל Power User

אייל דוד: [17:33] שאלה מצוינת. אז ברגע שיש דבר כזה שהוא עובד, והוא עושה עבודה טובה, בסדר? אז נשאלת השאלה רגע, כמה הוא עולה? כמה הוא עולה? כאילו ביחס, משמעותית כאילו לא, משמעותית אפשר להריץ עכשיו

איך עובדים על 3 פיצ'רים במקביל

דניאל מרקוס: [17:50] מאות צוותים כאלה. נכון. תשמע, זה לא, בגלל שבסך הכל אתה בן אדם, נכון להיום, לפחות איך שאנחנו משתמשים בזה, אתה בן אדם שמשתמש באותו צוות agentים, וכשאתה משתמש בצוות agentים, אתה מסתכל על הריזנינג, ובסוף אתה עושה לפעמים איזשהו review לקוד, רואה מה קורה. זה לא שאתה מריץ עשרה צוותים כאלה במקביל על כל העשרה פיצ'רים הכי גדולים שלי. אתה עושה פלוס מינוס שלושה במקביל, שזה גם קונספט מעניין על איך עובדים עכשיו. לא עובדים על טיקט אחד או על פיצ'ר אחד, עובדים על שלושה במקביל, כי בזמן שהאג'נט הזה עובד, מה אני אעשה? יש לך הפרעת קשב, ואני גם ככה אענה לזה, בסדר, אוקיי. אז אתה עובד על איזשהו שלושה במקביל, ואתה עושה איטרציות, וכל פעם שהוא מסיים את האיטרציה, אתה צריך לעשות שינויים, ואתה צריך לחשוב, ולוקח לך הרבה יותר זמן לכתוב פרומפטים, אז אופי העבודה משתנה. אבל בגדול, מישהו שעושה לזה דאבל דאון, קורע את המערכת למשך חודש, יוצא בין 1,000 ל-2,000 דולר בחודש, מישהו שעובד פה ושם 500, מישהו שכמעט ולא 100 דולר. אוקיי? והציפייה שלי היא שאם כולם עובדים בין ה-1,000 ל-2,000, בסך הכל ה-ROI שהם מייצרים הוא כל כך הרבה יותר גדול ממה שהוא היה לפני, שאני בכיף מוכן לשלם את זה בשביל האימפקט של ה-velocity.

אייל דוד: [19:09] בדיוק, לא, אז כאילו, לשם אני לוקח את זה. בסדר, זה לא עניין אותי הדולר סיין הספציפי, אבל בעצם בסוף השבוע הזה אתם יוצאים עם הבנה של, אוקיי, יש פה, ברור שיש פה עתיד, אבל יש פה עתיד שהוא מתאים לנו. נכון מאוד. ואז בעצם, שוב, אם יש מאות teams כאלה שאתה יכול להריץ, כמה אנשי צוות אתם היום בפיתוח, כולל פרודקט? אנחנו באזור ה-30, כולל פרודקט ודיזיין. אז כאילו יש לך הבנה שאוקיי, סתם, כל מי שיש לו הבנת דומיין, מה נקרא לזה, הבנה פרויקטית כדי,

דניאל מרקוס: [19:39] יכול להריץ נגיד שלושה פיצ'רים במקביל, לצורך העניין? כן. שלושה צוותים? כן. ועכשיו נשאלת השאלה, מה אתה מחלק למי? בדיוק, לשם אני חושב. אנג'יניר זה מדיין אנג'יניר, נכון? יש להם יכולות טכניות מאוד מאוד גבוהות, הם יודעים לכתוב קוד. בסופו של דבר, במערכת שבמיוחד במיסים שאני מתעסק בדאטה פיננסי, אני צריך שהכול יהיה דטרמיניסטי, אני צריך שהכול יהיה בדוק ויעבור QA, לפחות נכון להיום, לפני שהוא נכנס לפרודקשן, בסדר? אז הפיצ'רים המורכבים הולכים לאנג'ינירינג. אני מצפה שאנג'ינירס ישתמשו באותו מולטי-אייג'נט סיסטם לווייב קודינג בשביל לייצר baseline, תמיד, אוקיי? ומשם יעשו איטרציות. האיטרציות האלה יכולות להיות במקרים מסוימים 100% וייב קודינג, ויכולות להיות לא. תלוי במורכבות של הפיצ'ר, והרבה פעמים מה שאתה לומד מזה, זה דווקא אם זה לא עבד טוב, זה מה אני צריך לשנות באייג'נטים ואיזה קונטקסט היה חסר. כי בסך הכל, כמעט ואין מקרים שיש את כל הקונטקסט וזה לא עובד טוב. רוב המקרים זה פשוט חסר קונטקסט. אבל יש סוג אחר של פיצ'רים ושינויים ותיקונים, שפתאום אני אומר, אני יכול להוציא אותם 100% לפרודקט מנג'רס, לדיזיינרס, ואפילו יותר מזה, לבילדרים אחרים בארגון. אז כמה דוגמאות לזה. אז ה-obvious ל-product מנג'רס זה לעשות data analysis, אוקיי? להבין למה משהו עובד ככה ולא ככה, וכמה משתמשים בו, וה-MCP מאחורי הקלעים מתחבר ל-BigQuery שלי, ועושה את השאילתות, וכן הלאה, מייצר את הגרפים, מחקר. איך הקוד נראה ואיך הוא עובד, כאילו מה הדבר הזה עושה, ומתי יוצאת תשובה כזאת ולא תשובה כזאת, פתאום ה-PMs הם not bound יותר ב-Engineers, שיספקו להם תשובות, אוקיי? תכנון ספרינטים קדימה, ופיצ'רים קטנים, לדוגמה, פיצ'רים שהם בעיקר user experience oriented, לדוגמה, אמרנו, הדבר הזה לא עובר מספיק חלק, או פה אנחנו מבינים, היה לנו איזה קטע כזה עם document management, שהבנו שיש איזה use case שלא חשבנו עליו מראש, שיוזרים רוצים לראות את כל הדוקיומנטים שלהם אחד אחרי השני, אוקיי? ואז הדרך לעשות את זה במערכת שלנו, זה הייתה לפתוח אחד, ללחוץ x, לפתוח את השני, ללחוץ x, אז הוספנו כאלה חצים של next ו-previous, זה בדיוק של סירקולציה כזאת כמו הקרוסלה בלינקדאין. 100% vibe coded, פיצ'ר קטן, סופר פשוט, PM עושה אותו מקצה לקצה, ואותו דבר גם לצוות הדיזיין. כל פעם שהם רואים איזשהו mismatch בדיזיין, איזשהו משהו שהם חשבו בצורה מסוימת, אבל אז כשהם רואים אותו לייב, הוא לא עובד טוב. הם יכולים לעשות אותו ב-100% vibe coding, הם עושים אותו, ה-100% vibe coding הוא כזה פשוט, שזה ברמה של, אתה עושה את זה דרך ה-Slack, אתה ב-Slack מתייג את, במקרה שלנו, Cursor, אתה אומר לו פלוס-מינוס מה אתה רוצה, אתה יכול לתת לו לינק לפיגמה או לטיקט אם יש, ותוך כמה דקות אתה מקבל סביבה לייב, שאתה יכול ללחוץ עליה ולקבל remote desktop איפה שהדבר הזה רץ ולראות את זה לייב, אם זה באמת עבד או לא.

מה מנהלי מוצר יכולים לעשות עכשיו לבד - Data Analysis, Sprint Planning

איך גם CS ו-Finance באפריל בונים אפליקציות

איך לוודא שמנהלי מוצר לא בונים מרפסות מוזנחות

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

דניאל מרקוס: [23:30] איך אתה יודע להיות עם האצבע על הדופק כשאתם מודדים את זה איכשהו? אז לגמרי, תפקיד ה-PM, כמובן, לתעדף מהו הפיצ'ר שיזיז את המחט, נכון? ועל מה צריך לעבוד. ומה שלצורך העניין נכנס ל-Linear ול-Roadmap ולספרינטים הבאים צריכים להיות באמת הטיקטים that matter. ובהינתן שה-Velocity, אנחנו שוב פעם חוזרים לאותו סייקל של הבעיה, שה-Engineers פתאום נהיו יותר מהירים, הם יכולים לרוץ על הכל, ואז נשארת יותר עבודה לפרודקט להבין מה באמת חשוב, לייצר פול יותר גדול של משימות, כי אפשר לרוץ על יותר משימות. ויותר מזה, אם כאילו ממש לוקחים לקיצון את ההבנה הזאת שפתאום רצים יותר מהר ואפשר לרוץ על הרבה יותר פיצ'רים, אז גם מבחינה אסטרטגית, הרבה פעמים אתה רוצה לחשוב שונה, ו-PM, במקום לתעדף כל כך אגרסיבית כמו שהיה נהוג עד עכשיו, יכול להגיד, אוקיי, רגע, במקום לעשות איזשהו A-B טסט קטן על הקופי 1 מול 2, אני אצור לי איזה חמישה וריאנטים, והם לא יהיו רק קופי או קולר, הם יהיו ממש התנהגות שונה, ואין בעיה לרוץ איתם, ואז אני אהיה בטוח באלף אחוז, כי זה יהיה בפרודקשן, מה באמת עובד יותר טוב. אז גם אסטרטגית זה נהיה שונה. אז אני אקח את השאלה הזאת לעוד מקום.

מ-A/B Test של 2 וריאנטים ל-5 וריאנטים שלמים

אייל דוד: [24:57] עכשיו זה הופך להיות גם, שוב, שיפור המוצר הקיים שלכם, versus לייצר בטים חדשים.

דניאל מרקוס: [25:03] נכון. איך אתה מתעדף בין זה? וואי, זו תמיד שאלה ממש-ממש קשה. אז תראה, אנחנו כן משתדלים, כמו כל חברה נראה לי, להסתכל במוצרים קיימים על כל מיני אינדיקציות של product market fit, בשביל להבין אם אתה ממשיך לתעדף דברים במוצר קיים, או שאתה עובר לבטים חדשים, או סגמנטים חדשים, או כן הלאה. ואז האינדיקציות של product market fit, אז יש כל מיני. יש את ה-NPS score, יש את ה-conversion שלך במוצר שלך לעומת המתחרים, יש את השאלה הקלאסית הזאת של אם היית מאבד את המוצר הזה, מה היית מרגיש, וכן הלאה. ואנחנו תמיד מנסים להריץ את הדברים האלה במקביל, בשביל לתת איזשהו cap ולראות גם את הקצב של ההתקדמות, כדי לראות אם אנחנו נתקעים בתקרות זכוכית במקומות מסוימים או לא, ולעבור הלאה. אבל כן, כפאונדר של החברה, אני הרבה יותר פתוח לבטס בעולם כזה כמו של היום. במיוחד כשאני רואה שאחרי שעה של וייב קודינג, פתאום אני מייצר משהו שעושה אימפקט בפרודקשן.

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

למה שוק המסים בארה"ב הוא מונופול של 30 שנה

דניאל מרקוס: [26:25] הוא מאוד סנטרלייזד, יש מונופול בארצות הברית, טורבוטקס של אינטואיט, ששולט על בין 70% ל-80%, תלוי איך סופרים מהמרקט שבעולם הזה, ובגלל דווקא החסם הרגולטורי והלוגיסטי שנובע מכך, שלקבל רישיונות להגיש מיסים בכל הסטייטס השונים, בכל סטייט בארצות הברית יש חוק מיסוי שונה, אז בעצם יש חסם כניסה עצום, שלא הרבה חברות מעוניינות או שואפות לעבור אותו. אז אנחנו עשינו איזושהי החלטה כשהקמנו את החברה, שאנחנו צוחקים עליה, שממש ממש מזל שלא ידענו כמה זה הולך להיות מסובך, של אנחנו נרוץ לזה, ועכשיו זה הזמן to disrupt an industry שלא היה בה innovation 30 שנה. אבל אנחנו די מקדימים את התעשייה בצורת המחשבה הזאת ובצורת העבודה הזאת, אבל יש לגמרי ניצנים שרואים אותם, של כל מיני סטארט-אפים חדשים, שמנסים לעשות בעיקר, נקרא לזה Analysis עם AI. לקחת דאטה שכבר קיים איפשהו אחר, בלי חסמים רגולטוריים, בלי לנסות לחשב או להגיש את המיסים, רק לעשות Analysis מעל. שזה נותן איזשהו חלק מה-Pie, וזה טוב ומגניב, אבל אנחנו נורא מאמינים ביכולת שלנו להיות Uniquely Positioned, כאילו לעשות את ה... ממש את הפול סייקל של כל מה שקשור למיסים, כי יש לנו גם את ה-Rails וגם את היכולות לעשות את ה-AI Analysis,

אייל דוד: [27:59] וגם את ה-User Experience וכן הלאה. וההסכמים שציינת, ו-Human in the Loop, כאילו את הרואה חשבון, אז זה נותן את כל ה... טוב, אנחנו אולי נחזור לזה. אז כן, אני רוצה לקחת את זה שנייה למקום מסוים. אז אוקיי, התחלנו, בעצם התחלת בעצם להצביע על סקילים שהם חשובים בעיניך כשאתה מגייס אנשים, נכון? כשאתה בונה את הצוות שלך. ובוא, בוא שנייה נהדק אותם רגע. אתה יכול לחזור אליהם רגע? כן, בטח. אז משהו שהיה נהוג להגיד הרבה... אתה יכול, האמת, לספר את זה אולי סביב הסיפור שלך עם יונתן,

הסיפור על Vibe Coding עם יונתן (ג'ון ג'ון) בן ה-5.5

דניאל מרקוס: [28:32] ואז... ושמחה, ושמחה, כן. אז אני אגיד ככה, יש לי בן, חמודון, שקוראים לו יונתן, או ג'ונג'ון. היום הוא בן חמש וחצי, לא בדיוק היום, היום, בסביבה הזאת. ולפני כמה חודשים התחלנו לעשות כל סופ"ש, איזשהו פרויקט כזה של שעה ביחד, שאנחנו עושים וייב קודינג, אוקיי? עכשיו, זה התחיל מאיזשהו רעיון קטן של, טוב, בוא נבנה משחק ביחד. בוא נעשה משהו מגניב, הוא התחיל להתלהב ממשחקים, בדיוק קיבל נינטנדו ליום הולדת, ואמרנו, אנחנו יכולים לבנות משחק. בוא נעשה גם משחק. ניסינו בפעם הראשונה, השקענו באזור השעתיים בלנסות לבנות איזשהו משחק שהוא דמיין בראש שלו, עם ציפור שהולכת בין ארמונות, עם תלת מימד ועניינים, עם יוניטי, עם 3D וכאלה. עשינו את זה עם Cursor, היה כישלון מזעזע. השתמשנו בהרבה וייב קודינג והרבה טיפים בשביל לכתוב את הקוד, אבל בפלטפורמה סופר מורכבת, עם איטרציות מאוד איטיות ועם הרבה מאוד קונפיגורציה. יש לציין שהילד שלי לפחות, בן חמש וחצי ישראלי, לא יודע לקרוא או לכתוב אנגלית. זאת אומרת, כל פעם שצריך לעשות גם את האיטרציות האלה, אני צריך להסביר לו בדיוק מה אני עושה. רגע, טוב, עכשיו אני צריך לקנפג בדיוק את ה-boundary של העולם ונהנהנהנהנהנהנה. לא עבד, טוב, זנחנו את זה לאיזה חודש, אחר כך חזרנו ואמרנו, נעשה Pivot, גישה חדשה לחלוטין, נחפש משהו עם חסם כניסה הרבה יותר נמוך, הרבה הרבה יותר פשוט, ונעשה את זה באיטרציות מאוד קטנות ואיטיות. עשינו ביחד איזה סשן רגע של סוג של Ideation, בוא תספר לי רגע על המשחק, בוא תספר לי, אני רוצה את הציפור, אוקיי, הציפור תהיה ככה, ומה יהיה בעולם, וזה, ואני רוצה שיהיו רעים, ואני רוצה שיהיה אפשר להרביץ להם, ואני רוצה שיהיה אפשר לקפוץ, זה אוקיי, סבבה, אני מבין את כל הדברים. בוא נתחיל לאט-לאט, בוא נעשה, עם ציפור שהיא יכולה ללכת. אוקיי, הגענו מפה לשם לגוגל AI סטודיו, מוצר מדהים לווייב קודינג לילדים, באמת, שפשוט הוא לא כל כך חושף את הקוד, הוא לא קוד-פורוורד, הוא פרומפט-פורוורד ו-UI-פורוורד. מדהים למשחקים, יש לך חלון קטן של פרומפט וחלון ענק של ה-UI, שאתה יכול בלייב לראות את המשחקים, והוא ממש עושה לך את השינויים בלייב. עשינו פרומפט אחד, תוך שתי דקות היה לנו את המוצר הזה עם קרקרה הנשר, ככה קוראים לאותה דמות של ג'ונג'ון, שהוא יכל לשחק בה, ותוך כדי ג'ונג'ון אמר, אוקיי, עכשיו בוא נוסיף רעים, עכשיו בוא נוסיף זה, ולאט-לאט התחלנו לעשות את האיטרציות. התחלנו לתעדף. ג'ונג'ון התחיל לזהות רגע את הבאגים, שפתאום הרעים הולכים עקום, או שפתאום אנחנו עוברים דרך קירות, או כאלה, וג'ונג'ון פתאום התחיל להבין שאם אנחנו מוסיפים יותר מדי דברים, ואנחנו נותנים לו איזשהו פרומפט ממש גדול, הוא פתאום דופק דברים אחרים. ואז ניסיתי ללמד אותו מה זה הקונספט של רגרסיה, שמשהו שכבר עבד, פתאום עכשיו לא עובד, ושעובר טוב, ואז למדנו לעשות איטרציות יותר קטנות, ולמדנו לזהות את הדברים האלה. וזה כיף. אז בואו, בואו נעשה, אני תוך כדי רואה גם את התמונות,

אייל דוד: [32:06] המשחק הראשון היה מדהים, ואז גרפית הדברים מידרדרים, אבל נראים יותר שלמים. אז לא, בואו נעטוף את זה, אבל שנייה, באמת. אז זה משל, משל, זו באמת דוגמה לבסוף תהליך למידה של לעבוד עם אייג'נטים, אבל ברמה מאוד בסיסית באמת. בוא, אבל קח את זה עכשיו, תחבר את זה באמת למה אתה מחפש. איך אתה רואה את הסטאף שלך בחברה. לגמרי. אז הרבה מהדברים של אותו

מה זה Builder Mindset - ואיך לזהות אותו

דניאל מרקוס: [32:37] חסם כניסה לעולם הזה של וייב קודינג, איך לעשות דברים בווייב קודינג, איך להשפיע ואיך לייצר מוצרים שבאמת עובדים, הם חסם כניסה שהוא לא מאוד טכנולוגי בעיקרו, אלא הוא הרבה יותר קשור לאופי בילדרי, ראייה בילדרית, והרבה פעמים ממה שאני מזהה לאומץ לעבור את האנטרי בריאר הזה. יש הרבה תירוצים של, רגע, אני לא מספיק טכני, אני לא יודע לקרוא קוד, אני לא יודע להתקין דברים על המחשב. כל הדברים האלה הם חסמים שאפשר להעלים מאוד מאוד בקלות. ברגע שיש את האומץ והמוטיבציה וה-fire הזה של אני רוצה ליצור משהו, ואני רוצה לעשות אותו רלוונטי, ואני רוצה לפתור בעיה אמיתית ורלוונטית, אוקיי? אז זה מוביל לסקילים שאני מאוד אוהב למצוא באנשים שעושים דברים כאלה, באנשים שאני מגייס לאייפריל, אנשים שהם ג'נרליסטס, אוקיי? זה תמיד היה נהוג, אבל אנשים שבאמת מרגישים בנוח לעשות הכל מהכל, ואנשים שאוהבים לדחוף דברים קדימה. וברגע שאתה נותן לאנשים כאלה את היכולת פתאום לדחוף משהו קדימה, מקצה לקצה, בלי להיתקע ב-red tape ו-bottleneck של אנשים אחרים בארגון, פתאום אתה רואה את ה-velocity של ה-10x ואת האימפקטים המטורפים. ואנשים שיודעים לזהות בעיות ולחשוב יצירתי על איך לפתור אותן, גם אם הם לא מאוד טכניים, גם אם הם לא מכירים מראש את הפתרון, אלא הם מזהים את הבעיה טוב, והם יודעים להתייעץ עם האייג'נט החביב עליהם, אם זה Claude או כן הלאה, על איך לפתור את הבעיה ומה לעשות, ואיך לגשת לכלים של הארגון ולפתור אותה, פתאום אתה רואה שדברים מצליחים להתקדם ומצליחים להגיע לפרודקשן, ברגע שיש לך את ה-builder mentality הזה, ומישהו שבאמת יש לו ownership על דברים. וזה ברמה שאני רואה את ה... אני רואה אנשים עם הסקילים האלה באייפריל בכל מיני קבוצות שהם לא רק engineering או product או design. יש לנו customer success ויש לנו finance, שיש שם אנשים שבנו אפליקציות vibe coding קצה לקצה על דברים מדהימים, כאילו עם בוטים בסלאק ועם dashboardים שמתחברים לדברים שלנו ומחליפים כל מיני כלים אחרים, וממש יצרנו להם מסלול לאיך הם מביאים את האפליקציות האלה לפרודקשן. עם מסלול DevOpsי כזה של הנה איזשהו System Prompt, והנה המסלול של איך אנחנו שמים אפליקציות וייב קודינג בפרודקשן,

אייל דוד: [35:19] והם מנצלים אותו והם עושים את העבודה שלהם פי עשר יותר יעילה. וואו, אז קודם כול, כן, זה מאוד מרשים, החלק האחרון דווקא, לא שומע על הרבה חברות כאלה כרגע. אבל בעצם מה שענית לנו זה א', מה זה בילדר, ומה שאני שומע תוך כדי זה בעצם עוד דברים שלא אמרת, כאילו מעבר לזה שהבנה טובה של הבעיה, ולרוץ קדימה, יש פה עקשנות, קצת כמו שג'ונג'ון ישב שם ובעצם ישב על התחת וחיכה, חיכה, חיכה עד שבעצם הוא יקבל את התוצאה ושייף אותה עוד קצת ועוד קצת ועוד קצת. יש פה עניין של לקיחת אחריות בעצם, שוב, לעבור דרך קירות, קראת לזה, אני חושב, או שאני שמעתי את זה ככה, זה באמת כאילו לגרום לדבר לקרות.

דניאל מרקוס: [36:05] וגם יצירתיות שצריך נורא להיזהר לא לכבות אותה. בילדים כמובן, אבל גם התגובה הראשונית שלי, כשמישהו מהפייננס עושה פתאום אפליקציית וייב קודינג ומבקש ממני פתאום גישה לדאטה מ-BigQuery, זה פאק נו. ואם כן, אז טוב, אני אעשה, עכשיו אני צריך להשקיע יותר זמן בשביל שאני אעשה איזה קוד ריוויו ב... אז צריך נורא להיזהר בלא לכבות את היצירתיות הזאת, ולתת לה מקום ופשוט להפנות אותה לאיזשהו אפיק שמייצרים לדבר הזה, כמו האפיק הזה שייצרנו ל-non-engineers להביא וייב קודינג אפס לפרודקשן, עם בלאסט רדיוס מסוים ועם צורה מסוימת, ולכוון אותם לעבוד בצורה מסוימת. והאנשים האלה באמת לוקחים את זה, כי הם רוצים לייצר אימפקט, והם רוצים לעבוד, והם אוהבים את זה, והאיטרציות הסופר מהירות שאתה יכול, ממש לראות את הדברים שלך קורמים עור וגידים בעולם הווייב קודינג, זה משהו שהוא מאוד אפילינג,

הסכנה של גייט-קיפרים ולמה צריך לשחרר

אייל דוד: [37:06] זה ברמה שזה כמעט ממכר, כאילו. קוראים לזה god mode בכל מיני מקומות בטוויטר, אבל יש פה עוד דבר, אני חושב, כאילו, ברור שזה לנהל גם אייג'נטים, אבל יש פה גם עניינים של soft skills קצת, אני שומע. נכון. אני צריך לבוא, ואני צריך להעביר את הבקשה שלי בצורה מסוימת, ולשכנע אנשים שהם בעצם gatekeepers וכל מיני דברים, נכון?

דניאל מרקוס: [37:27] כן. אני צריך לשכנע בסיפור שלי, אני צריך. כן, כן, חד משמעית. ולהתנתק מהמנטליות הזאת של gatekeepers ו-red tape בארגון באיזושהי מידה, ולשחרר זה משהו שמאוד קשה, כי יש שם בגדול איזשהו ספקטרום, אתה לא יכול מן הסתם לעשות את זה ב-100%, כי אתה לא רוצה כאוס ואתה לא רוצה שהדברים האלה will bite you back later. ומצד שני, אם אתה לא משחרר, אז אתה עוצר את ה-velocity ואתה עוצר את ה-innovation, אז צריך למצוא איפה אתה על הספקטרום לכל ארגון לאיפה שנח לו, וזה לא קל. במיוחד לי, שדווקא התפקיד שלי בעבר, לפני אייפריל בווייז גוגל, זה היה, הקמתי שם איזשהו CTO אופיס עם VP R&D וכן הלאה, והתפקיד שלי היה להיות ה-gate keeper של כל מה שקשור לטכנולוגיה. אני הייתי הבן אדם שצריך להגיד לא על הכל. אז פתאום התפקיד שלי פה הוא הפוך לחלוטין של CTO בסטארט-אפ. זה לכבות את האנשים שאומרים לא ולדחוף קדימה, וכן, ו-we will figure out later how to scale it. זה בדיוק ה-soft skill שצריך ליישם בו את זה, אני חושב.

איך נראה ריאיון עבודה למנהל מוצר באפריל

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

דניאל מרקוס: [38:51] אז יש לנו כמה ראיונות, וזה תלוי כמובן באיזה תפקיד, הראיונות הם קצת שונים לכל... בסדר, בואו נלך לכיוון של PM, R&D, כזה, בסדר? לגמרי, כן.

אייל דוד: [39:01] אז יש לנו בהתחלה איזשהו ראיון ל-PM שהוא יותר פרודקטי. אתה יודע מה, סליחה, אני אשאל עוד פעם. כן. האם אתם, יש לכם בכלל משרות פתוחות לבילדרים?

דניאל מרקוס: [39:13] יש דבר כזה? יש לנו, אבל זה משרות כאילו של לצורך העניין PM, דיזיינר, אנג'יניר וכן הלאה. אוקיי, ואז בעצם, זה עדיין מחולק בעצם לפי הדרך. זה עדיין מחולק, כן. פשוט הציפייה היא שהעבודה בתוך התפקיד תהיה הרבה יותר הוליסטית, אוקיי? ש-PM הוא לא רק, לצורך העניין, מייצר טיקטים ו-Roadmap, אלא הוא עושה מעבר לזה, ודיזיינר הוא לא רק מקבל PRD מה-PM ומייצר Figma, אלא הוא עושה מעבר לזה, ואנג'יניר לא רק מקבל טיקטים פרפקטלי דאן ו-ready ומייצר קוד. אוקיי, אנחנו אנחנו מושכים כל תפקיד הרבה יותר לקצה והרבה יותר לכיוון התפקידים האחרים, כדי לפרק את החומות האלה שיש. והדרכים למצוא את הסקילים האלה, שכמובן, אתה יודע, אם הייתה לי יכולת magic crystal כזה של לראות בן אדם בראיון ולהגיד אם יש לו את זה או לא, אז הייתי במקום אחר כרגע, אבל האינדיקציות או הפרוקסים שאני אוהב לחפש זה לתת לאנשים בעיות ולראות איך הם ניגשים לפתור אותם, ויש סוגים של הדבר הזה גם באנג'ינירינג, אם זה יותר דומה לראיון ארכיטקטורה, וגם ב-PMים עם Product Sense, והרבה פעמים מה שאני עושה ב-Product Sense Interview זה לנסות לתת בעיה על איזשהו מוצר קיים ולראות איך הבן אדם חושב, אבל לפתור אותה ולא להמציא מוצר חדש מאפס, כי אז יותר קשה לי לדבר על קירות ואיך עוברים את הקירות האלה. ותוך כדי שהבן אדם מנסה לפתור את הבעיות, אני מערים עוד קשיים כל הזמן. בסדר, אני אומר, אוקיי, ועכשיו הדרישות השתנו והסקייל הוא 10x, ועכשיו הדרישות השתנו והיוזרים מתנהגים ככה, ועכשיו אני לא מבין למה, אבל המטריקה ככה. ולראות באיזה פתרונות יצירתיים, איך אנשים חושבים על הבעיות, האם בכלל משהו שאני הכי אוהב לראות בראיונות והוא סופר נדיר, זה אנשים מפקפקים בכלל בזיהוי של הבעיה, בפתרון הראשוני שנתתי להם וזה, שזה כאילו סופר נדיר, אבל זה, וואו, זה מדהים בעיניי, אם אני רואה מישהו שמנסה להבין לגמרי. זה מה שאתה עושה ברוב העבודה עם LLM, זה מה שאתה עושה. לגמרי, לגמרי. אז אני כאילו מנסה להבין,

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

דניאל מרקוס: [42:23] סביר מאוד להניח. אני משתדל לא, אתה יודע, להיות יומרני ולדעת לאן הטכנולוגיה הולכת, אבל אם הקצב ממשיך, אילון מאסק אמר את זה, כן, אבל... בסדר, לא מותר. אם הקצב ממשיך כמו שהוא עכשיו, אז הזמנים ממשיכים להתקצר, והאיכות ממשיכה לעלות, והדרך להביא רעיון לפרודקשן ממשיכה להתקצר, והרעיון הזה גם יכול להגיע לפרודקשן בצורה מאוד איכותית. זה לא חייב להיות איזה משהו סקרפי כזה שלא עובד ואי אפשר לעשות לו סקייל, אלא ברמה של מכמה משפטים וקונטקסט מתאים, אפשר להגיע לפיצ'ר בפרודקשן, ואז התפיסה האסטרטגית של מה סטארט-אפ צריך לעשות, איך צריך לעשות פריוריטיזיישן, איך בונים road map, על כמה דברים אנחנו רצים במקביל, מה המוט שלי כסטארט-אפ, כי ארבע שנים של קוד זה כלום. כן, לכם נראה לי שזה בסדר. טפו טפו, נו כל מוטו. מיסים, לא יודע, כן, מה ככה. מיסים, לא הולכים לשום מקום, נראה ככה. יש לנו כזה לוגו ענק במשרד של The only thing certain in life, זה איזה משפט שנאמר פעם, The only thing certain in life is death and taxes. יש לנו כזה מחוק על ה-death ויש tech and taxes. חמוד. זה לא הולך לשום מקום, ויש פה את המוט של הרגולציה, שהוא פתאום נהיה מוט הרבה הרבה יותר חזק, ששם יש הרבה humans involved של איך אתה מעביר את הרגולציה עם אותם humans ועם ה-connections וכן הלאה. אבל המוט של קוד הוא כבר משהו שלא קיים, ואז ה-innovation וה-ideation ולהמציא את עצמך מחדש ולחשוב על ה-next best thing, שכולם יכולים להביא את ה-next best thing לפרודקשן בשבוע, פתאום נהיה הרבה הרבה יותר מהותי, וזה משהו שהרבה יותר רואים אצל PM'ים את אותה יצירתיות והבנה עמוקה מאוד מאוד של היוזרים והבעיה כדי למצוא את הפתרון, מאשר אצל engineers, וזו עוד סיבה שהיחס בין PM'ים ל-Engineers משתנה. מעולה. אז כאילו מה שחשבתי זה שהראיון שיש היום,

אייל דוד: [44:33] הוא הולך להיות שונה מאוד כנראה מהראיון שיהיה בעוד שנה. סביר להניח. והציפייה תהיה אחרת לגמרי. אז אולי שנייה נדבר על איך אתה מציע בעצם להתכונן לזה. הדבר השני שחשבתי עליו, תגיד, כמה קרוב אתם עובדים בעצם ב-Product Engineering וכולם בצוות, איך זה נראה? קרוב מאוד, אני חושב. 30 אנשים? ברור, ברור. אז בעצם מה שאתה אומר זה שגם כל הסובבים את הפרודקט בעצם סופגים את היכולת הזאת, נכון?

דניאל מרקוס: [44:59] אז בעצם הרעיון, כאילו, אתם הולכים להיות הרבה יותר חזקים אובר טיים, בעצם, בצוות הקיים. כן, חד משמעית. זו הציפייה, ואנחנו גם מנסים כ-culture גם לעודד את זה, גם לעשות לדברים האלה סלבריישן של כל היוז קייסים האלה, שעובדים ושמגיעים מכל מיני מקומות בארגון, במיוחד ובמיוחד אם הם בוטום-אפ, שהם מגיעים מרעיון של מישהו, והנה, ועשיתי משהו כזה, ובואו תראו, לחגוג אותם ולהראות כמה הם טובים ולהעלות אותם ב-All Hands ולתת להם במה. וגם אנחנו עושים הכול Publicly Visible, זאת אומרת, יש לנו גם איזשהו ערוץ Shared Public Slack Channel, שבו אתה מתייג את קרסר ומבקש ממנו פיצ'רים, ואתה יכול לראות בדיוק מי עשה מה, ואם זה הצליח או לא, וכמה PMים אקטיב על זה, וזה דוחף אנשים קדימה לעשות את זה.

אייל דוד: [45:54] ברור, ששמים במה וזה, ומדידה זה תמיד עושה, אבל אז השאלה שלי בעצם, אוקיי, שאלתי את זה מקודם, בעצם הקטע של מרעיון עד להשקה או לניסוי, איך זה נראה אצלכם?

דניאל מרקוס: [46:08] אז... וכנראה שזה גם משתנה עוד מעט. משתנה דרמטית בהתאם לקומפלקסיטי של הפיצ'ר, ובואו נגיד גם כמה הפיצ'ר הזה מונע מרגולציה, או איזשהו חישוב דטרמיניסטי שלצורך העניין חישובי מס למיניהם, ששם הטסטינג הוא הרבה יותר ריגורוס. אבל בואו נגיד שיש קטגוריות של פיצ'רים שאני מצפה שה-PMים או הדיזיינרים ייקחו מקצה לקצה, והשלב הראשון שהם מגיעים לאנג'יניר זה לקוד ריוויו על ה-PR, שאני כבר מוכן, ומיותר לציין שלא ה-PR כתב את הקוד, ויש פיצ'רים שאני מצפה שיהיה לרמת ה... בואו נקרא לזה איזשהו ספק, לא חייב לקרוא לו PRD, אני לא מהמאמינים שכל פיצ'ר צריך PRD, אלא כל מקרה לגופו וזה. אבל איזשהו ספק שברמה של הספק הזה אני מצפה גם שהפרודקט/הדיזיינר יעשה עליו איטרציות עם אותם agentים כדי שהוא יהיה גם סופר טכני והוא ידע להפנות את האנשים למקומות הנכונים בקוד ולמה ה-impact ולמה ה-risks של הדברים האלה משתנים. ותודה לאל, גם agentים עושים את זה לבד, אז אפילו לא צריך להגיד להם יותר לעשות את זה, אלא חלק מה-instruction שלהם זה להוסיף את כל האלמנטים האלה, והוא עובר לאיזשהו engineer שצריך רגע to get the lay of the land מאותו ספק שהוא מאוד טכני, וברגע שהוא נותן את ה-green light הוא זורק אותו חזרה לצוות האג'נטים להתחיל לייצר לו את ה-baseline, ומשם הוא מתחיל לעשות איטרציות ולבדוק. שאתה יודע, ב-best case scenario האיטרציה הראשונה עבדה, בדרך כלל בפיצ'רים מורכבים זה לא קורה באיטרציה הראשונה, אבל זה מאוד קרוב וה-baseline הזה חוסך כמות דרמטית של זמן. והוא חוסך יותר ויותר זמן אם ידעת לתת לו את הקונטקסט הנכון. זהו. סביב ראיונות עבודה, באמת, לא נגעת איתי בכלל בקונטקסט, וזה לדעתי הדבר הכי מעניין לראות. לא, אולי זה יכול לחסוך המון המון זמן, נכון? אם אתה יודע בעצם... חד משמעית. אז יש את הקונטקסט במונח הסופר-טכני שלו, של מה אני מזין ל-LLM ולאיזה איג'נט, וכל איג'נט מקבל קונטקסט אחר, אבל בוא נגיד שאם יש לך איג'נט סטים, בדרך כלל יש איזה איג'נט שהוא האורקסטרטור של כולם, שהרבה פעמים הוא מנהל את הקונטקסט, והוא מכין אותו, והוא שולח אולי לאיזה איג'נט אחר לעשות איזה עבודת מחקר בשביל לאסוף קונטקסט. עכשיו, העבודת מחקר הזאת היא as effective as מה שהוא ראה בעבר וה-Knowledgebase שיש לו בשביל להבין את הקונטקסט, ומה שאתה כותב עבור ספציפית הפיצ'ר הזה. עכשיו, ככל שה-Knowledgebase שלו יותר מתוחכם ויותר מורכב, אתה צריך פחות לכתוב בפיצ'ר הבא שאתה נותן. ושם עוד פעם נכנס העניין על ה-reasoning, של לקרוא את ה-reasoning בשביל להבין מה חסר לו ב-Knowledgebase, בשביל לעדכן את ה-Knowledgebase. עכשיו, השיטה, השיטה לייצר את ה-Knowledgebase, זה לא בוא ניקח שבוע ונתחיל לכתוב knowledgebase,

אייל דוד: [49:21] אלא זה לתת, לא לכתוב את ה-Knowledgebase. אינג'ינירינג, מסכים. לא, אני התכוונתי דווקא ברמת הראיון שאתה עושה, לתפוס בעצם מה הקונטקסט שהבן אדם נותן, או מה הפרומפט שהוא כותב כביכול, זה חוסך הרי מן הסתם, המון איטרציות. לגמרי. טוב, אני רוצה שנעבור זריז לכמה טיפים. אני רוצה עכשיו, הדבר שהכי העליב אותי זה אני רוצה עכשיו צוות של אייג'נטים שעובדים איתי, איך אני עושה את זה?

דניאל מרקוס: [49:54] בוחר את הפלטפורמה החביבה עליך. אוקיי. ואני אסייג רגע שאני אחלק את זה לשניים. אני אחלק את זה על האנשים שכבר מרגישים בנוח עם קוד, גם אם הקוד הזה הוא רק מאחורי הקלעים, ויודעים שהוא שם ואין להם בעיה לעבוד ולפתוח טרמינל וכאלה, ולאנשים שמתחילים, שזו פעם ראשונה שאולי ישתמשו בדברים האלה רק ב-UI. לאנשים שמתחילים הייתי ממליץ לאט לאט טו איז אין אינטו הדברים היותר מסובכים, ולעבור קודם את החסם הזה של האומץ, של אני עושה דברים בווייב קודינג, אני רואה את הקוד, אני מסתכל, אני רואה שזה עובד, והדרך שאני הכי ממליץ מניסיון אישי לאנשים לעשות את זה, זה אם יש להם ילדים, וייב קוד סאמת'ינג ויז יור קיד. אתה חייב למצוא משהו, משחק, משהו לצביעה. משהו שאתה דומיין אקספרט בו, זו הפואנטה. משהו שאתה דומיין אקספרט, ובכלל, בסיטואציה עם הילד שלי, החלק שהיה לי לפחות כיף, זה שאני, וזה היה לי נורא קשה לשחרר, תאמין לי, בתור PM, זה שאני העברתי לו את הכובע 100% של הוא ה-PM, ואני הפרומפט אנג'יניר שלו, בסדר? הוא אומר לי דברים, ואני מדייק את זה, ואני מציע לו, ואני מסביר לו איך אני מדייק את זה, ורושמים את זה באנגלית לאותו כלי שאנחנו משתמשים בו, ולאט לאט אנחנו עושים את האיטרציות, עד ששנינו מרגישים בנוח בזה. לא אמרנו שסבלנות זה סקיל משוגע, אבל אוקיי, כן. חד משמעית, חד משמעית. אוקיי, אז ויתרת לו. אז אני הפרומפט אנג'יניר, ואני מתאמן, ואני רואה גם מה עובד ולא עובד, על איזשהו use case כזה שכיף לי איתו, שאני רוצה לעשות אותו, שאני רוצה להשקיע בו זמן, עד שאני מרגיש הרבה יותר בנוח לקפוץ לשלב הבא. השלב הבא מתחיל להיות לעבוד עם כלים יותר מתוחכמים, שיכולים להרים את הפלטפורמה הזאת של הצוותים. סטייל, קלוד קוד או קרסר, יש גם בדרך איזו עצירה למי שרוצה בקלוד קוורק, אבל הכלים הבאמת לצוותים של אייג'נטים זה קלוד קוד וקרסר, ושם אני יוצא מתוך נקודת הנחה שהמומחיות היא אצל האייג'נט שעוזר לי לבנות את הקוד ולא אצלי. זאת אומרת, אני מתחיל לראות קונטקסט של זה מה שאני רוצה לבנות, זה למה אני רוצה לבנות אותו, אני שוקל כל מיני אופציות, בוא תגיד לי מה אתה חושב. קראתי במקום הזה בטוויטר, אני נותן לו את הלינק לטוויטר, קראתי בכתבה הזאת והזאת, אני נותן לו את הלינק לכתבה, שאני רואה שה-Best Practices זה ככה וככה, והרבה אנשים עושים מולטי-אג'נטים עם Awesome Claude Skills ועם פייפרקליפ וכן הלאה. האם כדאי לי להשתמש בזה ל-use cases שלי? למה כן? למה לא? עושה כזה כמה איטרציות, מקבל ממנו איזשהו plan, איזושהי השוואה, שואל אותו שאלות על ההשוואה, מנסה לדייק עד שאני מבין שיש בינינו איזשהו fit, ושנינו מסכימים על תוכנית קדימה שאנחנו מרוצים ממנה, ואז מתחיל לממש, ובודק על use cases אמיתיים, והייתי עושה את זה כאילו כמו שעשיתי עם ג'ון ג'ון על בואו נתחיל רגע ממשחק שהוא רק ציפור שמסתובבת בעולם ולא עושה כלום, להתחיל פשוט ולעשות איטרציות. כי הרבה פעמים לבנות את הפריימוורק הזה של המולטי-אג'נטים ולראות מה הם אומרים, ולראות שהם מעבירים את הקונטקסט הנכון אחד לשני ושהם לא מפספסים דברים, זה הרבה יותר מסובך מאשר אחר כך לבנות פיצ'רים מורכבים. אז מתחיל את זה עם הדברים הכי פשוטים בעולם. אם להזיז את הכפתור הזה חמישה פיקסלים ימינה, אבל לראות שהקונטקסט עובר נכון ולקרוא את הריזנינג בין האג'נטים שלי, בין כל האג'נטים כראוי, ולראות שהוא יודע לבנות לי אחר כך טסט לזה שהכפתור עבר חמישה פיקסלים ימינה, או לראות שהוא יודע לעדכן את הטסטים הקיימים, וכן הלאה, להראות שהוא יודע להרים remote environment, וכל פעם שאני לא יודע משהו, לשאול אותו, לא להתבייש, כל פעם שמשהו לא עובד, לתת לו את ה-error, כל פעם שזה, ומלא מלא איטרציות, ובאמת, זה כיף, כאילו, למי שבילדר ורואה את הדברים האלה בעיניים, וכל פעם זורק פרומפט, ואז כזה פתאום מקבל גרסה חדשה? זה כיף. זה מקסים, אנחנו גם, אם תשתף, אנחנו גם נשים לינק בשואו נוטס בעצם ל... סליחה. מה שאני עוד מבין זה שאתה מצפה עכשיו לראות בראיונות עבודה גם אג'נט, בסוף אג'נט שבניתם. תשמע, אני חייב להגיד שלצורך העניין, הפיאמית האחרונה שגייסתי, נתתי לה איזשהו use case, איזשהו סוג של case study כזה הביתה, שמן הסתם, אני מניח, במאה אחוז מהמקרים, וזה מבחינתי יהיה דגל אדום אם לא, שאנשים משתמשים באיזשהו כלי החביב עליהם בשביל לבנות את התשובה ל-use case הזה, ללמה כדאי לי לעשות ככה או ככה, ולהשוות, ולעשות את ה-market research, וזה, זה given. אבל זה שהיא לקחה את ה-extra mile והביאה לי איזושהי אפליקציה עובדת, deployed על Vercel, שאני יכול לשחק בה ולראות את הפיצ'ר שהיא בחרה מתוך השניים, עם מלא אקסטרה דברים קטנים כאלה שלא היו קשורים בכלל ל-use case, אבל היא אמרה, אוקיי, זה הגיוני שהם יהיו פה, וכל פעם ששאלתי אותה על איזה משהו קטן שהיא עשתה שם, היא ידעה to reason על למה, ואם היא reason לא נכון על משהו, אז שאלתי אותה מאיפה קיבלת את הקונטקסט, ואז היא הראתה לי את הפרומפטים של, אה, כן, התייעצתי איתו, שאלתי אותו ככה, ואז נתתי לו איזה פרומפט כזה, שאני אוהבת להשתמש, של battle testing, תנסה to poke holes in my thesis, כאילו, עבדתי, אוקיי, זה הבן אדם שאני רוצה לעבוד איתו. ככה אנחנו מקפיצים את הארגון קדימה.

טיפים לאיך מתחילים לעבוד עם צוות אג'נטים

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

לאן עולם העבודה הולך - והפילוסופיה החדשה של Product Strategy

דניאל מרקוס: [56:04] לגמרי לכיוון שהוא הרבה יותר בילדר אוריינטד, והוא הרבה יותר, קשה לי למצוא לזה משפט טוב, אז אני אגיד את המשפט שהוא עושה דווקא קונוטציה לא טובה, אבל אני חושב שהוא פשוט הולך להשתנות, של ה-product strategy שהיה נלעג של spray and pray, של כאילו אני מוציא מלא דברים ואני רואה מה עובד, ולאו דווקא יש לי איזו אסטרטגיה נורא מוגדרת. אני פשוט רואה מה אנשים באמת אוהבים ומשתמשים. אני חושב שלשם העולם הולך, וככל שאתה acknowledging it faster ומתקדם יותר מהר, יהיה לך איזשהו gap על כל המתחרים, וזה מה שאנחנו מנסים לעשות באפריל בין היתר. והרבה מזה זה גם לערב את כל היכולות האלה שדיברנו, של agentים ו-AI וכאילו ממש בתוך המוצר עצמו, לבוא נדמיין מחדש מה זה חוויה של טקס פיילינג ב-2026, האם אני בכלל צריך UX? שאלה מעניינת. כן, עד היום התשובה שלי הייתה 100% כן, זה הולך להיות חוויה נוראית לשאול 100 שאלות בן אדם בצ'אט. מצד שני, הקונסומר האמריקאי, הציפייה שלו מתחילה להשתנות והיא משתנה דרמטית, וגם אם הדברים האלה הם אקספרימנטס, אני רוצה להיות הראשון ששם את האקספרימנט הזה מול אזרחים ומשתמשים בפרודקשן. בשביל ללמוד מזה, ככה אני אלמד הכי הרבה וככה אני אהיה הראשון למתי שזה באמת כן יעבוד.

אייל דוד: [57:43] מהמם, אחלה חזון. אז קודם כל ליצור איתך קשר, באמת נשים לינק ללינקדאין, אני מבין. בשמחה. ותכתבו לי אם אתם, כאילו אנחנו רוצים להחזיר אותו, ואנחנו גם נדבר על כל האירוע של Human in the Loop. בכלל, נגענו בו בסוג מוצרים הזה, זה סופר רלוונטי. אפשר, אנחנו נרחיב על זה בקבוצה אם אתם רוצים. יאה, דניאל, איזה כיף שבאת. יש כבר מעט אתגרים לעבוד עם רואי חשבון בצורה אג'ילית. אני ממליץ לכל מי שהוא יכול להרשות לעצמו. שזה צד אחד של המשוואה, אבל לגמרי. דניאל, איזה כיף שבאת. תודה לך, היה מעולה. תודה, אמורך. היה כיף גדול.