האם אתה צריך לבנות את ה-AI Agent שלך – או פשוט לקנות אחד מוכן?

מכיוון שאנחנו ב-https://enso.bot - מוכרים Agentים מוכנים, שמחתי להתייחס לזה רגע.

אז ככה, זו כבר לא שאלה טכנית. זו שאלה אסטרטגית עמוקה. כי ב-2025, AI Agents כבר לא נתפסים ככלי עזר. הם עובדים.

הם עושים את העבודה – במקום בני אדם:

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

והשאלה שכל יזם שואל את עצמו עכשיו היא:

לבנות בעצמי – או לקנות Agent מוכן שעובד מהיום להיום?

הצד של ה-BUILD:

לבנות נשמע מפתה.

• יש לך שליטה.
• אתה מכיר את הקוד.
• זה "שלך" – ייחודי.

אבל הנה המציאות:

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

ומה יצא לך מזה?

אם Agent זה לא הליבה שלך – לא בנית IP.

בנית עובד. אחד. שעושה פעולה אחת.

והוא מצריך משאבים כמו כל עובד אחר.

הצד של ה-BUY:

לקנות Agent מוכן – זה לא פחות סקסי, אבל -

• אתה חוסך שבועות.
• אתה עולה לאוויר תוך שעה.
• אתה מקבל תוצאה. מהר.
• ואם זה לא עובד – עברת הלאה, בלי כאב.

אתה לא משקיע בלבנות – אתה משקיע בלבחור נכון.

וזה שינוי עמוק בתפיסה:

אז מתי כן כדאי לבנות?

• אם ה-Agent הוא חלק מה-DNA של המוצר שלך.
• אם הוא יוצר לך יתרון תחרותי אמיתי.
• אם אין פתרון מדף שמתקרב למה שאתה צריך.
• ואם יש לך משאבים (וזמן) להתמודד עם זה.

בכל מקרה אחר?

תקנה. תבדוק. תתקדם.

התכלס בדילמה הזו עמוק יותר:

השאלה היא לא רק איך אתה בונה מוצר,

אלא איך אתה בונה חברה.

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

AI Agents הם לא טרנד. הם שכבת ביצוע חדשה.

ומי שיידע להשתמש בהם – בלי לבזבז את זמנו בלבנות את מה שכבר נבנה – ינצח.

יזמים חכמים לא שואלים יותר "איך אני בונה את זה",

אלא:

"איך אני גורם לזה לקרות – מבלי לבנות כלום?"

וברוב המקרים, התשובה היא:

Buy. ואז תתפנה לבנות את מה שחשוב בחברה באמת.

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

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

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

אחת הגישות שצוברת תאוצה היא שימוש ב-Agentic Layer: שכבת תיווך שמחברת בין מודל השפה לבין המערכות הארגוניות, תוך ניהול הקשר (Context), ההרשאות, והכלים בצורה מבוקרת.

MCP - עקרונות ויתרונות

Model Context Protocol (MCP) הוא דוגמה לגישה סטנדרטית להעשרת מודלי שפה בהקשרים חיצוניים בצורה מודולרית וניטרלית למודל. הוא מאפשר למערכות חיצוניות “לדבר” עם מודלים מבלי להינעל לספק יחיד, ומקל על הרחבה הדרגתית של היכולות.

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

מה זה באמת “ללא קוד” כשמדובר באנטרפרייז?

עולם ה-No/Low-Code הוכיח את עצמו בשירותי SaaS פשוטים, אבל בארגונים גדולים נכנסים אתגרים ייחודיים: הרשאות מרובות שכבות, VPN, רשתות מבודדות, סכמות משתנות.

הפתרון: לקחת את הפשטות של Drag-and-Drop ולשלב אותה עם יכולות Enterprise - מודלי אבטחה מרובי-רולים, ניהול הרשאות דינמי, תמיכה ב-On-Prem ובעננים מעורבים, והתאמה למדיניות ארגונית.

Chat/Prompt-to-Workflow - מגישה לשגרה

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

גישת ה-Chat-to-Builder מאפשרת למשתמשים לנסח צורך בשפה חופשית, לקבל וורקפלואו מוצע, ולערוך אותו בצורה ויזואלית - שילוב שמקצר את הדרך מהגדרה ליישום.

שכבת Agent Core

כל סוכן AI צריך שלושה מרכיבים: מודל (LLM), זיכרון (Context / DB), וכלים (Connectors / Actions).

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

אבטחה ואמון

בסביבות אנטרפרייז, שקיפות ובקרה הן תנאי סף: לוג Audit, ניהול הרשאות, עמידה בתקני SOC2/ISO.

Agentic Layer שלא מטפל בזה - לא ישרוד בסביבה אמיתית.

מסקנה: הגישה המודולרית ב-Agentic AI לא רק פותרת בעיות טכניות - היא מאפשרת גמישות עסקית, שליטה באבטחה, והפחתת עלויות.

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

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

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

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

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

שני משתנים לפני כל ערוץ

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

חברה שמוכרת לעסקים (B2B) תפגוש את הפרסונה שלה במקומות שונים לגמרי מחברה שמוכרת לצרכנים (B2C) או ללקוחות דרך שותפים (B2B2C).

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

כל תהליך רכישה מדויק יושב על שני משתנים פשוטים (שקל לדלג עליהם):

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

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

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

דוגמה מהשטח: שינוי כיוון דרך הקשבה

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

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

כאן, ההבנה שמדובר ב־B2B מול B2C שינתה לחלוטין את הערוצים, המסרים והפעולות. הלקוח המשלם הוא גוף עסקי (B2B), ולכן הערוצים הנבחרים היו עסקיים לחלוטין - פגישות ישירות, הצגת ROI, והצבת המוצר כפתרון אסטרטגי - ולא ערוצים צרכניים כמו קמפיינים למטופלים.

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

הטכנולוגיה לא השתנתה.
הקשב - כן. וזה עשה את כל ההבדל.

שני כלים פשוטים לבחירה חכמה יותר של ערוץ רכישה

סוג החברה ואיך זה משפיע על חיפוש הערוץ

האם מדובר ב B2B, B2C, B2B2C, B2G וכו׳. 

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

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

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

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

טעויות נפוצות (ומה אפשר לעשות אחרת)

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

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

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

אז מה כן?

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

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

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

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

המציאות מורכבת: מנהלי מוצר כחלוצי AI

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

ולידציה מהירה פי עשר:

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

יצירת פרוטוטייפים ואינטראקציות במהירות שיא:

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

קבלת החלטות מבוססת מידע במהירות:

• ניתוחי דאטה בזמן אמת עם GPT ו-Claude
• יצירת מסמכי דרישות (PRD) וטיקטים אוטומטית עם אינטגרציה למערכות ניהול פרויקטים כמו ג'ירה והכנסתם כבר לספרינט (פלוס הeffort שהגיוני שיקח למפתח - לסידור יותר טוב של הספרינט). 
• בניית סוכנים שמדרגים רעיונות לפי ROI, effort, הזדמנויות שוק  - תעדוף הרואדמאפ על פיהם.

שימוש באייג'נטים אוטונומיים לניהול שוטף:

• איסוף פידבק מפלטפורמות שונות (Reddit, App Store, Twitter) באופן אוטומטי בשוטף.
• תיוג בקשות חדשות\ חוזרות, והזנתן למערכת שבה מתבצע התיעדוף אוטומטית (ראו הנ"ל).
• מחקר מתחרים אוטומטי עם perplexity, מעקב אחר טרנדים בשוק ואזהרות על שינויים רלוונטיים.

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

מנהל המוצר כאסטרטג בעידן החדש

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

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

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

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

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

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

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

כשהגבולות מטשטשים

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

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

במיוחד עם כל כלי הוייב קודינג שיש היום, רואים עלייה בתפקידים שנקראים "Full Stack Product Manager" - מנהלי מוצר שמבינים גם את הצד הטכני וגם את הצד העסקי של פיתוח מוצר. הם לא בהכרח כותבים קוד בעצמם, אבל יש להם בסיס טכני חזק שמאפשר להם לשתף פעולה ביעילות ובמהירות עם מהנדסים ולקבל החלטות מוצר מושכלות.

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

התפתחות המיומנויות: מה צריך ללמוד

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

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

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

עתיד תפקיד ניהול המוצר: אקורדיון

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

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

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

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

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

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

השילוש הקדוש – המשתמש, הצורך, הערך 

בתחילת דרכי כמנהל מוצר היה לי מנהל ומנטור (תודה, אשר ב.) ששינן לנו מדי יום (באמת!) מנטרה קבועה: "המשתמש, הצורך, הערך" – או באנגלית: "User, Use Case, Value". והוא צדק – השלישיה הזו היא התמצית המזוקקת של עיקר העבודה של מנהל מוצר – השילוש הקדוש, אם תרצו.  

וקצת בהרחבה, כשאנחנו בונים מוצר, אנחנו צריכים לשאול את עצמנו יום-יום שלוש שאלות: 

1. מי המשתמש של המוצר שלנו?  
2. מה הצורך שלו? 
3. מה הערך שהמוצר שלנו יתן לו? 

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

המשתמש – להבין עבור מי המוצר 

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

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

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

• הגדרת התפקיד – מה מטרת העל שלה, על מה היא נמדדת? תנסו להשלים את המשפט:  As a …, my goal is to… 

• מה היא עושה כשהיא קמה בבוקר – מה סדר היום שלה בעבודה, מה המשימות הקבועות שלה – יומיות, חודשיות או שנתיות – מה האתגרים שלה, מה מלחיץ אותה או מדאיג אותה?  

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

 שיטה לא רעה לאיפיון המשימות הקבועות של פרסונה נקראת לפעמים User Stories, כלומר הגדרת הסיפורים של הפרסונה (וכמעט תמיד יהיו יותר מסיפור אחד), והפורמט הוא: 
When <CONTEXT>, I want to {JOB}, because I {MOTIVATION}, so I can {OUTCOME}
שימו לב שהניסוח הוא בגוף ראשון, וזה ממש חשוב. השימוש ב-I מכריח אתכם להתמקד במה שחשוב אישית לפרסונה ולא לאירגון. לדוגמה, המוטיבציה היא לא "כדי שהאירגון ירוויח יותר כסף" אלא "כדי שאני אקבל את ההכרה הראויה לי מצד המנהלים שלי".  

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

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

הצורך – הבעיה האמיתית ולא הסימפטום 

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

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

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

שיטה שאני מאוד אוהב שמאפשרת להגיע לשורש הבעיה נקראת "טכניקת 5 הלמות", או באנגלית "The 5 Whys Technique". הרעיון הוא לשאול את הלקוח "למה אתה רוצה את המוצר הזה?", ואז לשאול שוב "למה", ואז שוב, ושוב – 5 פעמים. קצת כמו ילד בן 3, בעצם. זה נשמע מעיק, אבל הגישה הזו מחייבת את המשתמש לחפור לעומק ולהבין מה באמת גורם לבעיה שלו ומה הוא באמת רוצה. הנה דוגמה קצת מעצבנת: הלקוח מבקש שנכין לו סושי, אבל אם נשאל למה הוא יבין שהוא בעצם רעב, ואם נחקור עוד, נגלה שהסיבה היא שהוא לא הספיק לאכול ארוחת בוקר בבית, ובחקירה נוספת נבין שהסיבה היא שהוא לא קם בבוקר, וכשנשאל שוב נבין שהשעון המעורר שלו לא עבד כי הסוללות נגמרו. במקרה כזה, במקום להכין ללקוח סושי, נבנה לו שעון מעורר שמחובר לחשמל. זה פשוט כמו שזה טיפשי.  

הערך – מה יוצא למשתמש מהמוצר שלנו? 

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

כשאנחנו חושבים על הערך, משפט המפתח הוא "מה יצא לי מזה?", או באנגלית: "What’s In It For Me?". הערך עבור הלקוח הוא לא מה שאנחנו חושבים שהוא, אלא מה שהמשתמש מרגיש שהוא מקבל. אם פתרנו את הבעיה הלא נכונה – הלקוח לא ירגיש שיש במוצר ערך בשבילו ולא ירצה בו.  

לסיכום – חזרה אל הבסיס 

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

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

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

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

קצת קונטקסט תחילה על הסיפור היחסית חריג של Travelier. Travelier הוקמה כ-Bookaway ב-2018. העסק שלנו הוא לאפשר קניה קלה מקוונת ופשוטה של כרטיסי נסיעה לכל קו נסיעה קרקעי שקיים בעולם. עיקר הפוקוס שלנו היום הוא באוטובוסים, רכבות ומעבורות בחלקי העולם המורכבים יותר טכנולוגית - אפריקה, אסיה, דרום אמריקה. הקורונה הורידה את התעשיה שלנו על הברכיים, אבל אנחנו האמנו (הימרנו?) שהיא לא תישאר איתנו לנצח. לכן, בסוף 2020, רכשנו 5 חברות דומות לנו בכמה מקומות בעולם. זה לא עוד סיפור דוגמת גוגל רוכשת את Wiz, ולו רק בשל שלושה הבדלים עיקריים:

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

ב. רוב החברות שקנינו נמצאו בשלב יותר בשל ומתקדם משלנו.

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

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

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

א. בטווח הקצר - לאפשר לכל אחת מהחברות למכור באתר שלה את המלאי של כל אחת מהחברות האחרות

ב. בטווח הארוך - לבנות תשתית טכנולוגית אחת, מתקדמת יותר, שתשמש את כל החברות.

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

טרמינולוגיה 

איחוד הטרמינולוגיה הוא אחד הדברים הראשונים שעשינו. רצינו ליישר קו על שפה אחת משותפת לכל החברה. התחלנו בכתיבת האופן שבו נראה ה-API שלנו ולבאר מה השמות של הישויות שלנו בשפה של כל אחת מחברות הבנות. בין השאר, זה עוזר למפות את הפערים ולהבין איפה נמצאים ההבדלים בין השיטות והצרכים של החברות. הבדלים למשל - תוצאת חיפוש יכולה להקרא transport, trip, itinerary, result, segment… ולהכיל מודל מידע שונה לחלוטין בכל חברה.

דאטה

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

אינטגרציה

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

תקשורת 

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

זה מתחדד בחברה כמו שלנו שמורכבת מאנשים ב-54 (!!) מדינות שונות, ומכמה חברות עם תרבות ארגונית מאוד מגוונת. נטיה לתקשורת עודפת עוזרת לגלות את הפערים מוקדם.

חזון ואסטרטגיה

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

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

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

 למה לעשות כזה דבר מטורלל אתם בטח תוהים?

העיקרון שמנחה אותי: למזער חרטות, לא לפחד לנסות

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

בזוס תיאר איך דמיין את עצמו בגיל 80 ושאל:

“על מה אתחרט אם לא אנסה?"

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

אז על מה אתם תתחרטו אם לא תנסו?

אני ידעתי שאני רוצה לחוות את התהליך של יצירת מוצר מא׳ ועד ת׳ בעצמי, ושאם מישהי מסוגלת לעשות את זה לבד, זו אני.

הייתה לי 100% בטחון ביכולת ה-execution הטכנולוגי שלי, יש לי צד אמנותי מפותח דיו בשביל UX, וידעתי שנושאים כמו פרודקט, GTM ושיווק אני אוכל ללמוד מהר ולמצוא אנשים שישמחו ללמד אותי.

האפליקציה הראשונה: למה מוצר עם "כל הטוב שבעולם" לא עובד?

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

העלתי את האפליקציה לאפסטור, שיווקתי קצת. וכלום. צרצרים. ראיתי שאנשים מורידים, אבל אח״כ ב-mixpanel ראיתי שהם.. פשוט לא נשארים. גם אם היה conversion, ה-retention היה אפסי. אנשים הורידו את האפליקציה, היו מוצפים מהפיצ׳רים וסגרו אחרי שימוש אחד.

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

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

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

יש בעיות שאפשר לפתור עם לשפוך עליהן כסף - מוצר שהוא לא ווואו זו לא אחת מהן.

היות ואני סולו פאונדרית, ומממנת את עצמי, ידעתי שכל עוד לא יהיה לי conversion מדהים ו-retention מדהים, אזרוק כל כסף עתידי שאוציא על שיווק לפח.

Conversion - האחוז של אנשים שעושים את הפעולה שאתה רוצה מהם (הורדת אפליקציה ← רכישה, הרשמה לניוזלטר ← מנוי בתשלום, וכו')

Retention - כמה משתמשים חוזרים ונשארים פעילים לאורך זמן (יום אחרי ההרשמה, שבוע, חודש)

בקצרה: Conversion = כמה נכנסים, Retention = כמה נשארים.

השינוי בתפיסה: מה חשוב באמת במוצר B2C?

התחלתי לחקור איך אני מגדילה conversion ו-retention. המטרות שלי מעכשיו הן:

• אני רוצה שיוזרים יגיעו לאפליקציה כל יום
• אני רוצה שיוזרים יבלו באפליקציה לפחות רבע שעה כל יום
• אני רוצה שיהיה viral loop - מה יוזרים ירצו כל כך על מנת שהם ישתפו את האפליקציה? במקרה של base44 לדוגמא, אנשים כל כך אהבו לפתח, ונתקעו כשהם היו צריכים קרדיטים, ואז אם תשתף תקבל עוד. איזה פיצוח.

בראש של ״אני צריכה עכשיו לבנות מוצר שיגרום לאנשים לבוא כל יום, ויסב להם הנאה״ - זרקתי את כל הפיצ׳רים שפיתחתי לפח, והתחלתי לחשוב מהפריזמה של conversion ו-retention. כתבתי בסיס מאוד חזק ורובסטי לאפליקציה, ובסוף ה״בסיס״ של כל אפליקציה זהה - דף פרופיל, נוטיפיקציות, תקשורת עם שרת, שמירת והצגת assetים כמו תמונות וקבצים בצורה יעילה - ואם הוא כתוב טוב, יהיה קל להוסיף business logic מעל.

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

איך מגדילים retention ו-conversion באפליקציות B2C?

Onboarding ו-UX:

• Onboarding אינטראקטיבי ומותאם אישית - מדריך את המשתמש בצעדים ראשונים רלוונטיים
• Progressive profiling - איסוף מידע על המשתמש בהדרגה במקום טופס ארוך
• Social login - התחברות מהירה דרך רשתות חברתיות, או לא בכלל (הורדת friction)

התאמה אישית:

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

Gamification ומעורבות:

• נקודות, רמות ואתגרים - מערכת תגמול שמעודדת שימוש רציף
• Daily streaks - רצף פעילות יומי עם תגמולים
• באדג׳ים והישגים - הכרה בפעילות והתקדמות

תקשורת ועדכונים:

• Push notifications חכמות - התראות מותאמות אישית ובזמן הנכון
• In-app messaging - הודעות פנימיות לעדכונים חשובים (או כשאתה בתור המפתח רוצה לדבר עם יוזר מסוים ואין לך את המייל שלו)

חברתיות ואינטראקציה:

• חוות דעת וביקורות - אמון חברתי שמשפיע על החלטות רכישה
• שיתוף ברשתות חברתיות - הרחבת החשיפה דרך משתמשים קיימים
• תוכנית הפניות - תמריצים להפנית חברים חדשים
  

תמחור ותמריצים:

• Free trial או freemium - התנסות ללא התחייבות
• FOMO ו-scarcity - יצירת דחיפות ("נותרו 3 פריטים", "מבצע עד הערב")

אנליטיקה ואופטימיזציה:

• A/B testing מתמשך - בדיקת גרסאות שונות לאופטימיזציה
• Funnel analysis - זיהוי נקודות נשירה ושיפור התהליך
• Cohort analysis - מעקב אחר התנהגות קבוצות משתמשים לאורך זמן

תמיכה ושירות:

• Live chat או chatbot - תמיכה מיידית בזמן אמת
• פידבק מיידי - יוזרים מרגישים טוב אם כשיש באג/תקלה מישהו ישר שומע אותם. (או אשליה של זה)

ההוכחה בשטח: מה קרה אחרי השינוי?

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

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

זה הביא לי את היוזרים הראשונים.

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

אני מבינה שההחלטה לעזוב את Apple הייתה אחת ההחלטות הנכונות שעשיתי. לא בגלל שהצלחתי בגדול (עדיין בדרך), אלא בגלל שלמדתי דברים שלעולם לא הייתי לומדת בתוך החברה הכי מצליחה בעולם. למדתי שבניית מוצר זה לא רק טכנולוגיה טובה - זה בעיקר הבנה עמוקה של בני אדם. ושהדרך היחידה להבין באמת איך בונים משהו שאנשים אוהבים, זה לעשות, לטעות, ולעשות שוב. לדבר עם יוזרים (תקראו את the mom test). ולהתייעץ עם אחרים שכבר עשו את זה.

אולי התובנה הכי חשובה שלי - אם אתם בונים B2C, תתחילו מהשאלה "למה שמישהו יחזור מחר?" ורק אחר כך תשאלו "איזה פיצ׳רים להוסיף?". לרוב המוצרים הטובים בעולם אנשים חוזרים מדי יום. ואם אתם חושבים על לעזוב את העבודה היציבה ולנסות משהו משלכם - זכרו: בגיל 80, לא תתחרטו על השנה שניסיתם. תתחרטו על השנה שלא העזתם.