חוברת הקורס

שיעור 1 — מהו מוצר, ולמה לפתוח בבעיה

מפת השיעור

שעה שלמה הלכה על היכרות. מי שמדלג — תתחיל בדקה 60.

שלושת התנאים למוצר

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

1. כדאיות

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

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

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

2. ערך ללקוח

שזה יביא ערך למישהו ספציפי — שיעזור לו לעשות את העבודה מהר יותר או טוב יותר.

3. ישימות

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

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

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

מוצר מצליח, לא רק מוצר

היעד שהוגדר לקורס במפורש:

מוצר מצליח זה אומר עושה ערך ללקוח ואימפקט לחברה.

והאינדיקציה שניתנה לכך: אנשים רוצים להשתמש יותר, ויותר אנשים רוצים להשתמש. לא "הבנתי מה זה, לא צריך" — אלא שימוש שגדל.

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

בעיה וצורך — לא פתרון

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

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

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

ולקוחות פנימיים זה קשה יותר

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

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

מה יילמד בהמשך

רשימת המושגים שהוצגה כסקירה מקדימה:

נטפליקס ובלוקבאסטר

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

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

UX ותמיכה

בסוף השיעור עלתה נקודה שקל לפספס: כשלקוח מתקשר על פיצ'ר חדש והתמיכה לא יודעת עליו — זה כשל.

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

שיעור 2 — מוצר כשירות, והשלישייה

מפת השיעור

ממוצר לשירות, ומשם למוצר כשירות

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

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

ההבחנה: בשירות, הפתרון משתנה לכל פונה. במוצר, הוא חוזר על עצמו.

והמעבר שקרה

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

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

1. מסתכל על כל עולם הבעיה, לא על הפונה הבודד
2. מבין אותו לעומק ובודק אם לקהלים נוספים יש צרכים דומים
3. בונה משהו שב-day one פותר ללקוח הראשון — וב-day two כבר יודע לעשות scale

למה זה בכלל משנה: הניתוק משעות עבודה

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

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

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

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

והערה על AI ו-SaaS

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

השלישייה

השאלה שנשאלה בכיתה: מי הפרטנרים של מנהל המוצר?

המסקנה: את התחום שבו מנהל המוצר הכי חזק אף אחד אחר לא מכסה. זה לא שהוא רק ביזנס — אלא שזה מה שהוא מביא לשולחן.

המונח שהוזכר: Empowered Teams של מרטי קייגן — השלישייה הזו יושבת יחד.

מה נדרש מכל צד

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

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

UX: התאמת צבעים שייכת למעצב, וזו המקצועיות שלו. מנהל המוצר אחראי לתכלול של הכל, ויש שיח — אבל לא כיבוש התחום.

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

מה ללקוח לא אכפת

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

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

DAU — מה נחשב לקוח פעיל

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

למה "פעיל" ולא סתם "לקוח": אפליקציה פתוחה ברקע נותנת אפס ערך למשתמש ואפס לחברה. לכן מודדים Daily Active User.

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

מה מגדיר "פעיל"

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

ולמה גלילה נחשבת? כי היא מקיימת את שני הצדדים בו־זמנית:

• ערך ללקוח — הוא נחשף למידע שהוא רוצה, רואה מה קורה
• ערך לחברה — 87% מההכנסות מגיעות מפרסום

דוגמאות שוק שהוזכרו

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

והשאלה שנשאלה על SoundCloud — "איך נדע אם הוא בירידה או לא?" — היא בדיוק החיבור למדידה.

שיעור 3 — התפקיד בארגון, ועולם השוק

מפת השיעור

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

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

מנהל המוצר בארגון

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

"אנחנו לא יורדים לרמת המחרוזות — אלא ברמת העל ולרמת הרעיון."

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

מיני מנכ"ל

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

קודם כל שהמוצר יקרה, ואחר כך שמה שקרה יהיה מוצלח.

"מיני" כי הוא לא המנכ"ל — אבל בתוך היחידה שלו הוא אחראי על הריצה.

מה מול איך

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

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

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

סטארט-אפ מול ארגון גדול

אותו תפקיד, שתי מציאויות. הכיתה מיפתה את ההבדלים:

מה זה עושה לתפקיד

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

וגם כשיגיע איש מכירות: אתה זה שתצטרך להגיד לו מה ה-benefits, מה מוכר בתוך המוצר, ומה ה-value שהלקוחות באמת אמרו עליו. בלי זה — that's it.

ההשפעה על build or buy

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

הנקודה: אילוץ ארגוני משנה אסטרטגיה. build-or-buy אינה רק שאלה כלכלית — היא גם שאלה של כמה זמן לוקח לרכוש.

אינבאונד מול אאוטבאונד

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

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

מנהל מוצר מול פרודקט אונר

כשיש שני התפקידים:

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

ומה הוא לא עושה: את הארכיטקטורה הטכנית. זה ראש הצוות הטכנולוגי.

איך זה עובד בפועל

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

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

וכשזה אדם אחד

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

פורטר: כוח הקונים

הנושא המרכזי של השיעור, ותחילת עולם השוק והתחרות.

שני ממדים לכל כוח, והמרצה ביקשה להתרגל בשניהם:

1. איך זה משפיע על התחרותיות בענף
2. איך זה משפיע על הרווחיות שלנו

מה זה אומר שיש כוח לקונים

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

שתי דוגמאות תרבותיות:

• ספרד — העלו מיסים על סיגריות, פרצו מחאות, והממשלה נאלצה להוריד
• אנגליה — עלו מחירי החלב, והציבור התחיל לשתות תה בלי חלב

הדוגמה המרכזית: הסלולר בישראל

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

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

השלב השני: נכנסה סלקום, נכנסה תחרות.

והמחיר לא ירד.

לא היה תיאום מחירים רשמי — זה אסור — אבל ההתנהגות בשוק הייתה כזו. הכוח נשאר אצל חברות הסלולר.

השלב השלישי: היום משלמים 30–50 ש"ח.

ומה באמת גרם לשינוי

התשובה המהירה היא "הרפורמה של כחלון". והמרצה תיקנה את זה:

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

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

הלקח: תחרות אינה שם נרדף לכוח קונים. מספר המתחרים אינו הגורם — ההתנהגות שלהם היא.

מקורות מידע מהימנים

הבעיה שהוצגה במפורש: ה-AI ממציא מקורות, ומביא מקורות חלשים.

ורוב מה שכתוב באינטרנט עכשיו — נכתב על ידי AI אחר.

הכלי: להגיד לו מאיפה לקחת

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

המקורות שנמנו:

אימות

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

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

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

תרגול מחקר שוק, בכיתה

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

מה יצא

כלים שנוסו: צ'אט עם הנחיה לתפקיד ("מומחה בסקר שוק ומתחרים"), ו-Perplexity — שאסף 270 מקורות בשבע דקות ובנה דוח.

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

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

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

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

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

מה עוד יגיע

• קול הלקוח — הוזכר כמקום שבו יידונו הבנת צרכי השוק
• טווח גיאוגרפי — להתחיל בישראל כ-beta site, או ישר בארה"ב
• סשן נפרד על סופט סקילס ובעיות סמכויות
• לכל נושא בקורס יש תרגול בקבוצות הפרויקט

שיעור 4 — בידול, ולמה חמש פעמים

מפת השיעור

לפתח או לקנות

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

1. פתרון מדף — לקחת מה שקיים
2. לעטוף — לקחת פתרון קיים ולהגיש אותו כפתרון שלנו
3. קוד פתוח — להביא כלים ולבנות מעליהם

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

וזה מתחבר למה שעלה בשיעור 3 — תהליך רכש איטי יכול להפוך build ל-buy ולהפך. ההחלטה הזו אינה רק כלכלית.

מתחרים נכנסים זה לתחום של זה

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

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

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

הבחנה שימושית לתעדוף, שהוצגה על ארגון גדול:

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

ובהערכת חלופות נכנסים גם Time to market ומורכבות האינטגרציה מול ממשקי הליבה — הארגוניים או הממשלתיים.

בידול

השאלה: איזה ערך אני נותן מול המתחרים.

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

הבידול יכול להיות בפיצ'רים, במאפיינים, או בתמחור.

Deep Domain Expertise

הרעיון המרכזי של השיעור.

Deep expertise אומר שהסיכוי שמישהו יחליף אותי בקלות הוא נמוך מאוד.

הדוגמאות שניתנו

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

הלקח: בידול אינו "להיות טוב יותר בכל". הוא לבחור זירה.

ואיפה זה לא מחזיק

כאן ההערה החדה:

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

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

"זה לא משהו שמישהו בונה תוך חצי שנה עם Base44 ועושה אקזיט."

חמשת הלמה

הכלי המעשי של השיעור.

ההנחיה: תקשיבו ללקוח, תקשיבו לבעיות שלו. ותשאלו למה, חמש פעמים.

הדמו שהמרצה נתנה על עצמה

והשאלה שהיא שאלה את הכיתה: אז מה מטפלים? רק ברצועה?

התשובה: ברצועה וגם במקור. אחרת זה יחזור במקום אחר.

וזה נכון גם לבאגים

הנקודה שקל לפספס:

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

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

ולמה לא לקפוץ לפתרון

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

ואם רצים לפתרון בלי הפרטים של הבעיה — מבחן התוצאה יהיה כישלון ובזבוז.

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

מה יילמד בהמשך

מחקר משתמשים — מתודולוגיות וכלים, כולל A/B Testing, והגדרת פרסונות משותפת בקבוצות.

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

מהו מוצר

השאלה שממנה מתחילים

האם שווה להשקיע ולעשות את המוצר הזה?

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

התנאים

כדאיות

האם ההשקעה מחזירה את עצמה.

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

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

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

ערך ללקוח

שמישהו ספציפי ירוויח מזה — יעשה את העבודה מהר יותר או טוב יותר.

"ערך למישהו" זו לא תשובה. למי בדיוק, ומה משתנה אצלו.

ישימות

האם אפשר לבנות את זה. בקורס הכוונה לישימות טכנולוגית — do-able — ולא לישימות פיזית.

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

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

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

מוצר לעומת מוצר מצליח

ההבחנה שהוגדרה כיעד הקורס:

מוצר מצליח עושה ערך ללקוח ואימפקט לחברה.

איך יודעים שהוא מצליח

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

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

מה זה דורש ממנהל המוצר

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

הערת גבול

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

בעיה לפני פתרון

הכלל

מדברים על הצורך והבעיה — לא על הפתרון.

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

האנלוגיה שניתנה בכיתה

תחרות מלכת היופי. שואלים את המתמודדת איזו בעיה היא הייתה רוצה לפתור. התשובה: "שלום עולם."

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

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

הקושי האמיתי: לקוחות פנימיים

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

הדרישה הוטלה עליו מלמעלה, והוא רק מעביר אותה הלאה. הוא בעצמו לא מכיר את הלמה. הוא הגיע כי מישהו אמר לו להגיע.

המעבר שצריך לעשות

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

איפה זה נפגש עם השאר

הכלל הזה אינו עומד לבדו. הוא מה שמזין את שאר הכלים:

• מדידה — בלי לדעת מה הבעיה, אין דרך לבחור מדד תוצאה
• תעדוף — תעדוף בין פתרונות בלי בעיות מוגדרות הוא סידור רשימה
• User Story — המבנה I want to… so that I can… בנוי בדיוק כדי לכפות ניסוח של הצורך ולא של הפתרון

מה עוד יגיע

הכלים שהוזכרו כמה שיילמד ושקשור ישירות לנושא הזה: Voice of the Customer, מחקר שוק ומתחרים, ו-A/B Testing — שנזכר כמקום שממנו דווקא הגיע הדגש הזה.

מדידה ודאטה

למה זה עומד בפני עצמו

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

הניסוח שנאמר בכיתה: בלי דאטה הולכים עיוורים.

שני סוגי מדדים

ההבחנה שחוזרת בכל דיון על מוצר:

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

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

מדד מול יעד

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

זו הנקודה שבה נכנס OKR, שהוזכר כנושא שיילמד בהמשך.

דשבורד שהופך למוצר

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

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

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

אימפקט

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

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

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

DAU — מה נחשב לקוח פעיל

הדוגמה משיעור 2, עם פייסבוק.

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

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

ומה נחשב "פעיל"

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

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

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

מה עוד יגיע

שני מודלים הוזכרו כמה שיילמד ונוגע ישירות למדידה:

• OKR — יעדים ותוצאות מדידות
• AARRR — acquisition, activation, retention, revenue, referral

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

תעדוף ומפת דרכים

הרעיון המרכזי

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

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

הדוגמה שניתנה

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

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

מסגרת העבודה

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

זה הרציונל מאחורי טקסי הסקראם, שהוזכרו כנושא להמשך:

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

תעדוף מול מחקר

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

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

RICE — המודל שיילמד

הוזכר בשיעור 1 כמודל התעדוף שיילמד בהרחבה. ארבעה פרמטרים:

מה שהופך אותו לשימושי: Confidence הוא הפרמטר שמכריח להודות בכמה שלא יודעים. בלעדיו כל תעדוף נשען על הערכות שנשמעות ודאיות.

מה עוד יגיע

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

מוצר כשירות

שלוש תפיסות, לא שתיים

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

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

ההבחנה: בשירות הפתרון משתנה לכל פונה. במוצר הוא חוזר על עצמו.

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

הניתוק משעות עבודה

זה הרעיון המרכזי של הנושא.

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

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

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

מה זה דורש ממנהל המוצר

הדפוס שהוצג בשלושה צעדים:

1. צעד אחורה — להסתכל על כל עולם הבעיה, לא על הפונה הבודד
2. להרחיב — לבדוק אם לקהלים נוספים יש צרכים דומים
3. לבנות לשני מועדים — day one פותר ללקוח הראשון, day two יודע לעשות scale

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

הדוגמה מהכיתה

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

הבדל נוסף שצוין: הלקוח לא מבקש כל דבר. בשירות הוא מכתיב; במוצר כשירות הוא מקבל את מה שיש.

AI ו-SaaS

תחזית שנאמרה במפורש: יש ירידה מסוימת ב-SaaS בגלל AI, אבל היא זמנית.

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

השלישייה — מי אחראי על מה

החלוקה

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

התשובה לשאלה "מה בעצם מנהל מוצר עושה"

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

פיתוח → טכנולוגיה. מעצב → UX. ומה נשאר?

ביזנס. את התחום הזה אף אחד אחר בשלישייה לא מכסה.

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

כמה טכנולוגיה צריך לדעת

מספיק כדי להיות פרטנר. לא יותר.

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

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

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

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

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

הגבול מול UX

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

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

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

מה קורה כשהחלוקה נשברת

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

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

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

הגבול המדויק: מה מול איך

שיעור 3 חידד את החלוקה למשפט אחד:

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

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

ומה ללקוח לא אכפת

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

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

התפקיד — מיני מנכ"ל

מאיפה התפקיד בא

ניהול מוצר הגיע מהעולם השיווקי־עסקי, ונכנס לעולם הטכנולוגי.

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

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

מיני מנכ"ל

מנהל המוצר הוא כור היתוך עסקי. הממשקים שנמנו בכיתה:

מנהלי לקוחות · מכירות · פיתוח · שותפים עסקיים · תמיכה · הנהלה · פיתוח עסקי

למה הכינוי: מנכ"ל מדבר עם כמעט כל המחלקות. כך גם מנהל המוצר. הוא "מיני" כי הוא לא המנכ"ל — אבל בתוך היחידה שלו הוא לגמרי אחראי על הריצה.

והסדר שבו זה נאמר

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

הסדר לא מקרי. מוצר שלא יצא הוא לא מוצר גרוע — הוא לא קיים.

מי מחליט על מה

ההבחנה החדה ביותר בנושא:

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

כשזה עולה כסף

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

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

השאלה שנשאלה בכיתה: אם הם האוטוריטה המקצועית אבל מי שחוטף זה מנהל המוצר — איפה עובר הקו?

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

ולא משנה ללקוח איך זה מפותח — לא ללקוח הקצה ולא ללקוח הביניים.

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

כמה טכנולוגיה צריך

מספיק כדי להיות פרטנר. לא קוד.

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

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

סטארט-אפ מול ארגון גדול

אותו תפקיד, שתי מציאויות.

בסטארט-אפ אתה עושה הכל — כולל לצאת ולמכור בעצמך. לא כי אתה איש מכירות, אלא כדי להסביר את המוצר ולשמוע פידבק.

וגם כשיגיע איש מכירות: אתה זה שתצטרך לתת לו את ה-benefits, את מה שמוכר במוצר, ואת ה-value שהלקוחות באמת אמרו. בלי זה — that's it.

ואילוץ ארגוני משנה אסטרטגיה

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

build or buy אינה רק שאלה כלכלית. היא גם שאלה של כמה זמן לוקח לרכוש.

אינבאונד מול אאוטבאונד

התפקיד יכול לפנות פנימה — אל קבוצת הפיתוח — או החוצה, אל השוק והלקוחות.

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

מנהל מוצר מול פרודקט אונר

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

ומה הוא לא עושה: ארכיטקטורה טכנית. זה ראש הצוות הטכנולוגי.

איך זה עובד בפועל

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

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

וכשזה אדם אחד

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

בארגונים צבאיים

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

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

המשמעות: חלוקת הסמכויות שתוארה למעלה — "מה" מול "איך" — לא בהכרח מתקיימת שם באותה צורה.

מה עוד יגיע

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

שוק ותחרות

שני הממדים

כל כוח בשוק נבחן בשתי שאלות, והמרצה ביקשה להתרגל בשתיהן:

1. איך זה משפיע על התחרותיות בענף
2. איך זה משפיע על הרווחיות שלנו

הפרדה שקל לדלג עליה. ענף תחרותי אינו בהכרח ענף לא רווחי, וההפך.

כוח הקונים

הכוח הראשון שנלמד מתוך המודל של פורטר.

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

שתי דוגמאות קצרות

• ספרד — עלו מיסים על סיגריות, פרצו מחאות, הממשלה נאלצה להוריד
• אנגליה — עלו מחירי החלב, והציבור התחיל לשתות תה בלי חלב

בשתיהן הקונים לא התלוננו — הם שינו התנהגות. זה הכוח.

הדוגמה שכדאי לזכור: הסלולר בישראל

היא חשובה כי היא שוברת הנחה אינטואיטיבית.

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

מה באמת שינה

התשובה המהירה היא "הרפורמה של כחלון", והמרצה תיקנה אותה:

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

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

הלקח: תחרות אינה שם נרדף לכוח קונים. מספר המתחרים אינו הגורם — ההתנהגות שלהם היא.

וזה גם אומר שכשמנתחים ענף, "יש בו חמישה מתחרים" אינו נתון שאומר משהו בפני עצמו.

כוח הספקים

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

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

הכשל לא היה שלהן. הן היו תלויות בספק.

גודל שוק — ומה שהוא לא אומר

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

השאלה שנשאלה: 4 מיליארד — שוק ששווה להיכנס אליו? הכיתה ענתה כן.

והתיקון:

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

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

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

טווח גיאוגרפי

החלטה שהוזכרה כחלק מהגדרת השוק: להתחיל בישראל כ-beta site, או ישר בארה"ב.

מה עוד יגיע

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

מקורות מידע ומחקר עם AI

הבעיה

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

ומעבר לזה:

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

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

הפתרון: להגיד לו מאיפה לקחת

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

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

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

אימות

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

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

הדוגמה מהכיתה

המרצה רצתה נתונים על היקף המשכנתאות.

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

ההבדל: שאלה פתוחה מקבלת מה שיש. שאלה עם מקורות מוגדרים מקבלת מה שאפשר לבדוק.

מהתרגול בכיתה

הכיתה הריצה מחקר שוק בזמן אמת, ושתי שיטות עלו:

הנחיית תפקיד — להגיד למודל שהוא "מומחה בסקר שוק ומתחרים" לפני השאלה.

Perplexity — אסף 270 מקורות בשבע דקות ובנה דוח. איטי יותר, ומחזיר פירוט מקורות.

והערה מהכיתה על השיח עצמו:

"הוא כל הזמן מציע עוד ועוד שאלות" — ולפעמים זה נוח, כי הוא מציע את השאלה הבאה.

מהמקרו למיקרו

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

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

ומה שצריך לזכור

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

מקור מהימן נותן מספר נכון. הוא לא נותן מסקנה.

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

השאלה

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

האסטרטגיה שהוצגה

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

ואז מגיעה ההחלטה שתלויה בשאלה אחת:

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

Deep Domain Expertise

ההגדרה שנאמרה, והיא מדויקת:

הסיכוי שמישהו יחליף אותי בקלות הוא נמוך מאוד.

זו לא "מומחיות" במובן של לדעת הרבה. זו מומחיות שיוצרת עלות החלפה.

הדוגמאות

מה שאנתרופיק ממחישה

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

הלקח: בידול אינו "להיות טוב יותר בכל". הוא לבחור זירה.

ואיפה זה לא מחזיק

ההערה הכי חשובה בנושא:

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

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

"זה לא משהו שמישהו בונה תוך חצי שנה עם Base44 ועושה אקזיט."

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

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

גבולות השוק זזים

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

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

ניתוח מתחרים לפי "מי בענף שלי" מפספס את מי שעומד להיכנס אליו.

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

הבחנה שקובעת לאן הולך המאמץ:

מה שבליבה — מפתחים ומבדלים. מה שלא — קונים, עוטפים, או מביאים שותף.

לפתח או לקנות

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

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

ובשיקול נכנסים גם Time to market ומורכבות האינטגרציה מול ממשקי הליבה. (ומשיעור 3: תהליך רכש איטי יכול להפוך buy ל-build.)

חמשת הלמה

ההנחיה

שני דברים, בסדר הזה:

1. תקשיבו ללקוח ולבעיות שלו
2. תשאלו למה — חמש פעמים

הדמו שניתן בכיתה

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

והשאלה שסוגרת את התרגיל

היא שאלה את הכיתה: אז מה מטפלים? רק ברצועה?

התשובה — ברצועה וגם במקור. הרצועה באמת נקרעה וצריך להחליף אותה. אבל בלי התחזוקה, זה יחזור במקום אחר.

זה הלב של הכלי: הוא לא מחליף את הטיפול בסימפטום. הוא מוסיף את הטיפול בסיבה.

וזה עובד גם על באגים

הנקודה שקל לפספס, והיא אולי השימושית ביותר:

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

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

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

למה לא לקפוץ לפתרון

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

ואם רצים לפתרון בלי הפרטים של הבעיה — מבחן התוצאה יהיה כישלון ובזבוז.

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

איפה זה נפגש עם השאר

הכלי הזה הוא הביצוע המעשי של הכלל מבעיה לפני פתרון.

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

אנלוגיית מלכת היופי — "שלום עולם" — נופלת על אותו כשל מהצד השני: הצהרה בלי מנגנון. חמשת הלמה חופרים מתחת להצהרה עד שמגיעים למשהו שאפשר לפעול עליו.

דוגמאות ומקרים

פייסבוק — מה נחשב משתמש פעיל

שיעור 2, דקות 150–170. הדוגמה המפורטת ביותר שניתנה עד כה.

השאלה: למה מודדים Daily Active User ולא פשוט כמה משתמשים יש?

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

ומה נחשב "פעיל"? הכיתה הציעה לייקים, תגובות, פרסום, שימוש בפיצ'רים. כולם נכונים — אבל הבסיסי ביותר הוא גלילה.

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

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

זימון תורים מהמדינה

שיעור 2. הדוגמה שמבדילה בין שירות למוצר.

המטרה זהה לכל אזרח והתהליך זהה — ולכן זה מוצר שניתן כשירות, ולא שירות.

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

רופא ועורך דין

שיעור 2. הדוגמה הנגדית.

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

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

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

נטפליקס ובלוקבאסטר

שיעור 1, דקות 80–90. הוצגה כפתיח, הניתוח יגיע בהמשך.

העובדה: נטפליקס כמעט נקנתה ב-1999 על ידי בלוקבאסטר. מבלוקבאסטר נותרה חנות אחת; נטפליקס נמצאת אצל כמעט כולם.

הוצגה תחת הכותרת "אסטרטגיות שהביאו להצלחה".

מלכת היופי

שיעור 1. אנלוגיה, לא מקרה אמיתי.

שואלים את המתמודדת איזו בעיה היא רוצה לפתור. התשובה: "שלום עולם." ואז כלום — אין פיצ'ר, אין אתר, אין צעד ראשון.

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

שוק המוזיקה

שיעור 2, דקות 105–135. סדרת דוגמאות שהוצגו עם נתוני מרקט־שייר.

נאפסטר · אייטיונס · Tidal · SoundCloud, ודוגמה נוספת מתקופת הקורונה.

והשאלה שנשאלה על SoundCloud — "איך נדע אם הוא בירידה או לא?" — היא בדיוק החיבור בין דוגמאות שוק למדידה. לא מספיק להרגיש שמשהו דועך.

פייתון או C-sharp

שיעור 2. לא דוגמה אלא ציטוט, ושווה לזכור אותו.

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

הובא בהקשר של מנהלי מוצר בארה"ב שמעבירים למפתחים את מה — לא את איך.

חומרי עזר

גיליון תמצית

הדברים שהכי כדאי לזכור, בשורה אחת כל אחד.

מילון מונחים

מונחים שנלמדו

מונחים שהוזכרו ועוד לא נלמדו

שירות מול מוצר מול מוצר כשירות

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

מי אחראי על מה

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

תרשים ההחלטה: האם זה מוצר

האם שווה להשקיע?
   │
   ├─ כדאיות?            לא ─→ לא מוצר
   │      ROI, או יעד שהתקבל
   ├─ ערך ללקוח?         לא ─→ לא מוצר
   │      למי בדיוק, ומה משתנה אצלו
   └─ ישימות?            לא ─→ לא עכשיו
          טכנולוגית. כמעט תמיד כן

        כל השלושה? ─→ מוצר

        ומוצר מצליח?
           רוצים להשתמש יותר, ויותר אנשים

הבחנות שקל לבלבל

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

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

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

סיכום הקורס

איפה אנחנו

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

השרשור

מתחילים בשאלה, לא ברעיון

הקורס נפתח בשאלה "האם שווה להשקיע ולעשות את המוצר הזה?" — ולא ב"איזה מוצר לבנות".

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

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

ולא כל מוצר הוא מוצר מצליח

מוצר מצליח עושה ערך ללקוח ואימפקט לחברה.

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

ולכן מתחילים מהבעיה

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

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

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

מה בכלל הופך מוצר למוצר

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

והמעבר למוצר כשירות הוא מה שמשנה הכל:

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

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

מי עושה מה

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

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

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

ואיך יודעים שזה עובד

חוזרים למדידה. מדד תפוקה אומר אם משתמשים במוצר; מדד תוצאה אומר אם הוא הועיל.

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

מה עוד לא נלמד

הוזכרו כמה שיגיע: RICE לתעדוף, AARRR, OKR, User Story, A/B Testing, Voice of the Customer, מחזור חיי המוצר לעומק, פרסונות, ומחקר שוק ומתחרים.

איך ללמוד מזה

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

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

לחזרה מהירה — גיליון התמצית בחומרי העזר.