מאת דור ארד

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

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

חדש — 29 בספטמבר 2026

מאמרים אקטואליים

01AI Agents, מוצר ויזמות

מדמו להחלטה: כיצד מתכננים פיילוט AI Agent של 30 יום

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

מאת דור ארד · לקריאה ←
02IoT, מוצר והנדסת מערכות

פיילוט אינו דמו: כיצד מתכננים ניסוי IoT שמייצר החלטת מוצר

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

מאת דור ארד · לקריאה ←
03בלוקצ׳יין, נתונים ואמון ציבורי

כשהנתון הציבורי הופך לראיה: מה בלוקצ׳יין יכול לשנות בסטטיסטיקה רשמית

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

מאת דור ארד · לקריאה ←
04Web, זהות ואבטחה

WebAuthn Level 3 הפך לתקן: Passkeys עוברים מפיצ׳ר אבטחה לתשתית מוצר

W3C פרסם ב־25 באוגוסט 2026 את WebAuthn Level 3 כהמלצה. כך צוותי Web ו־SaaS צריכים לתכנן אימוץ Passkeys, שחזור, תאימות ומדידה.

מאת דור ארד · לקריאה ←
05SaaS ואמינות תפעולית

אחרי השבתת GitHub: שבעה לקחים לבניית SaaS עמיד באמת

GitHub דיווח על השבתה של 7 שעות ו־47 דקות ב־17 באוגוסט 2026. מה האירוע מלמד מנהלי מוצר והנדסה על קיבולת, תלות, מצב חירום ושקיפות.

מאת דור ארד · לקריאה ←
06Web ונגישות

ARIA ב־HTML עודכן: נגישות היא חוזה מוצר, לא שכבת תיקונים

המלצת W3C המעודכנת מ־11 באוגוסט 2026 מחדדת מתי ARIA מועיל, מתי HTML סמנטי עדיף וכיצד הופכים נגישות למשמעת מוצר והנדסה.

מאת דור ארד · לקריאה ←
07MiCA ותשתיות קריפטו

MiCA אחרי תקופת המעבר: רישיון הוא רק תחילת המוצר התפעולי

תקופת המעבר של MiCA הסתיימה ב־1 ביולי 2026. מה נדרש מספקי שירותי קריפטו בתחומי הרשאה, יציאת לקוחות, נתונים, AML ותפעול חוצה גבולות.

מאת דור ארד · לקריאה ←
08בנקאות דיגיטלית

בנקאות דיגיטלית מתחילה בארכיטקטורה, לא באפליקציה

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

מאת דור ארד · לקריאה ←
09כסף דיגיטלי

כסף דיגיטלי ותכנותיות: החדשנות חייבת להישען על אמון

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

מאת דור ארד · לקריאה ←
010בלוקצ׳יין

בלוקצ׳יין כשכבת מודיעין עסקי: משקיפות להבנת עסקאות

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

מאת דור ארד · לקריאה ←
011בלוקצ׳יין ופינטק

טוקניזציה וסליקה אטומית: להפוך תהליך מפוצל לפעולה אחת

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

מאת דור ארד · לקריאה ←
012פיזיקה וטכנולוגיה

חישה קוונטית: כאשר פיזיקה בסיסית הופכת לכלי טכנולוגי

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

מאת דור ארד · לקריאה ←
013פוטוניקה

מפוטון יחיד למוצר: הפיזיקה שמרחיבה את גבולות החישה והתקשורת

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

מאת דור ארד · לקריאה ←
014מתמטיקה שימושית

המתמטיקה השימושית שמפעילה מערכות דיגיטליות מודרניות

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

מאת דור ארד · לקריאה ←
015AI ו־Web

איך AI משנה את עולם ה־Web — ומה עדיין דורש שיקול דעת אנושי

מה משתנה בתכנון, פיתוח, תוכן ונגישות כאשר AI נכנס לכל שלב במחזור החיים של אתר.

מאת דור ארד · לקריאה ←
016פינטק ותשלומים

איך בונים תשתית תשלומים מודולרית: מאחורי ZeroFee Pay

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

מאת דור ארד · לקריאה ←
017אסטרטגיית מוצר

האם מודל ZeroFee יכול לעבוד? כלכלה, שקיפות וחדשנות בתשלומים

ניתוח מעשי של מודלים להפחתת עמלות תשלום בלי להעביר עלויות באופן סמוי ללקוחות ולעסקים.

מאת דור ארד · לקריאה ←
018AI ורגולציה

חוק ה־AI האירופי כבר נאכף: מה צוותי SaaS ו־Web צריכים לשנות עכשיו

מדריך מעשי לחובות השקיפות שנכנסו לאכיפה באיחוד האירופי ב־2 באוגוסט 2026 — מגילוי נאות ועד סימון תוכן ותיעוד מוצר.

מאת דור ארד · לקריאה ←
019זהות דיגיטלית ופינטק

ארנק הזהות הדיגיטלית האירופי מתקרב: כך מוצרי Web ופינטק צריכים להתכונן

מה המשמעות של EUDI Wallet למוצרי Web ופינטק — מאימות תכונות וצמצום נתונים ועד הרשמה כספק שירות ותכנון מסע לקוח.

מאת דור ארד · לקריאה ←
01מה השטח לימד אותי על בניית צוותים02מרעיון טכנולוגי למוצר שאנשים באמת משתמשים בו03לבנות באחריות בעולם פיננסי משתנה04למה יזמים צריכים ללמוד לחשוב כמו מהנדסים

מה השטח לימד אותי על בניית צוותים

מנהיגות אמיתית נבחנת פחות ברגעים שבהם הכול עובד, ויותר ברגעים שבהם המידע חסר, הלחץ עולה והאנשים מחפשים כיוון.

אמון לפני סמכות

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

בהירות היא כלי עבודה

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

רוגע הוא יכולת מקצועית

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

הצוות חייב לדעת למה

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

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

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

השורה התחתונה

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

חזרה למעלה ↑

מרעיון טכנולוגי למוצר שאנשים באמת משתמשים בו

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

להתחיל מהכאב, לא מהפתרון

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

להפוך הנחות לשאלות

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

המוצר הראשון הוא כלי למידה

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

למדוד התנהגות, לא התלהבות

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

לבנות לולאת משוב

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

להישאר נאמנים לבעיה

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

חזרה למעלה ↑

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

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

טכנולוגיה אינה מבטלת אמון

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

רגולציה כחלק מעיצוב המוצר

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

להסביר סיכון בשפה אנושית

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

אבטחה היא תהליך

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

הגשר בין הישן לחדש

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

חדשנות שמחזיקה מעמד

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

חזרה למעלה ↑

למה יזמים צריכים ללמוד לחשוב כמו מהנדסים

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

לפרק לפני שבונים

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

להגדיר אילוצים אמיתיים

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

לבדוק את נקודת הכשל

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

להבחין בין דיוק לדיוק מדומה

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

ליצור משוב מהיר

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

לשמור על האנושי

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

חזרה למעלה ↑