שיעור 4

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

2:15 שעות. שיעור שלם, בלי פיצול.

מפת השיעור

לפתח או לקנות

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

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

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

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

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

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

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

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

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

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

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

בידול

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

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

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

Deep Domain Expertise

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

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

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

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

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

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

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

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

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

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

חמשת הלמה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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