חוברת הקורס

הרצאה 1 — שכבות המוצר ותעדוף מפת הדרכים

מפת ההרצאה

פתיחה: מהיעדים למפת הדרכים

ההרצאה ממשיכה את מה שכבר נעשה בקורס: הצגות האמצע (שוק, תחרות, צורכי הלקוח וחזון), תרגול על OKR, יוזמות שעלו ב-Value Proposition Canvas, וחידוד של המדדים ושל ה-North Star Metric.

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

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

North Star Metric

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

שלושה סוגי מדדים

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

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

שכבות המוצר

התחלת ההסבר לא נקלטה כולה (ראו בסוף העמוד). מה שנשמע: תהליך הבנייה מתחיל בחיבור ל-mission statement, והשלב השני הוא מפת שכבות המוצר.

היתרון של המפה הזו: היא ממקדת ב-core benefit, התועלת המרכזית שהמוצר רוצה להביא ללקוח שלו.

דוגמת המלון

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

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

למה הסדר חשוב: שוקולד על סדין מלוכלך

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

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

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

מהחזון ועד המשימה

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

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

איך אוספים את מה שייכנס למפה: התהליך נקרא top-down, bottom-up, ואז mix & match. מצד אחד, רעיונות שנגזרים מה-OKR. מצד שני, מה שמגיע מהשטח. ובסוף מחברים את שניהם לרשימה אחת.

Bottom-up: מה מגיע מהשטח

קודם כל להקשיב

הדחף הוא לקפוץ לתעדוף, אבל הצעד הראשון הוא להקשיב ולהבין את הבעיה, את המהות שלה ואת הכאב.

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

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

יעד משותף, מדדים שונים

באסטרטגיה טובה יש לכולם objective משותף, אבל key results שונים. גם בתוך העולם הטכנולוגי:

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

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

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

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

כל בקשה מחוברת ליעד

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

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

מה רושמים על כל בקשה: - היעד: ה-objective הכללי, או ה-key result הספציפי. שניהם מקובלים, אבל עדיף ה-key result, כי כך יודעים על איזה מדד זה יעבוד - Summary: תיאור קצר - מי ביקש: יש הבדל אם הבקשה הגיעה מהתמיכה או מהמנכ״ל

Top-down: מיוזמה לפיצ'רים

כאן מתחילים מה-OKR שכבר מכירים: אילו רעיונות לפעילות יזיזו את ה-key results קדימה, או אילו KPI ראיתי ואני רוצה לשפר נקודתית.

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

טבלה אחת, ו-backlog מוצרי

זה ה-mix & match: הפיצ'רים מה-top-down והבקשות מה-bottom-up מתכנסים לטבלה אחת.

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

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

מי עושה מה

בשלב מאוחר יותר מפרקים את הפריטים לדרישות ול-user stories.

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

RICE ו-ICE

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

ICE: במוצר חדש אין עדיין R, כי אין כמות משתמשים. לכן מדברים רק על Impact, Confidence ו-Effort. לפי ההרצאה זה התעדוף המקובל יותר בתחום.

Confidence: מנתונים, לא מתחושה

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

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

דוגמה: כמה אנשים זה משפיע

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

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

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

דוגמה: החלפת תורים

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

• שני objectives: חיבור מיידי בין מי שצריך תור לתור שהתפנה וחיסכון בזמן החיפוש, וניהול משותף לכל המשפחה
• הפיצ'רים: התראות בזמן אמת, סנכרון, והזמנת בן משפחה לחשבון
• התוצאה: קודם התראות, אחר כך סנכרון, ואחר כך הזמנת בן משפחה

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

Build versus buy

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

• בונים לבד את מה שנמצא ב-core של המשימה, או מה שיוצר בידול בשוק (market differentiation): משהו ייחודי למוצר
• יכולות כלליות שאינן הליבה: לא שווה להתעמק בהן. לוקחים פרטנר, קונים ומחברים משהו חיצוני, או עושים את המינימום הנדרש, למשל כשזו רגולציה
• זה תעדוף אסטרטגי: מה בכלל נכנס לעבודה של צוות הפיתוח. כשמשקיעים משאבים במשהו לא חשוב, מפסידים זמן וכסף
• RICE הוא תעדוף אחר: הוא מסדר את הפיצ'רים שכבר הוחלט להכניס לצוות

מה חסר בעמוד הזה

• 0:00 עד 0:09: אין קול בהקלטה
• 0:18 עד 0:19: ההקלטה עוברת מהתרגול בקבוצות ישר לאמצע ההסבר על שכבות המוצר. ההתחלה שלו, כולל משהו על Product Market Fit, לא נקלטה
• מה שהוצג רק במצגת: הנוסחה של RICE, הסולם של Impact ושל Confidence, התבנית של טבלת הבקשות, והטבלאות של שתי הדוגמאות

בדיקה עצמית

1. במלון, איפה עובר הגבול בין generic ל-expected? תנו דוגמה מהמיטה.
2. למה שוקולד על הכרית לא עוזר כשהסדין מלוכלך?
3. לקוח מבקש "כפתור בעמוד הראשי". מה עושים לפני שמתעדפים?
4. ממה מורכבת הטבלה המאוחדת, ולמה היא עדיין לא מפת דרכים?
5. בדוגמת הבריאות, למה המוקד קיבל עדיפות על מינהל הסיעוד?

תשובות.

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

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

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

4: פיצ'רים מה-top-down ובקשות מה-bottom-up, עם תיאור, יעד ו-key result, מי ביקש, אימפקט וזמן. זה backlog מוצרי. מפת דרכים נוצרת רק אחרי התעדוף.

5: ה-reach: כ-100,000 אזרחים מול כ-6,000 אנשי סיעוד. האימפקט היה דומה, וההבדל בזמן הפיתוח לא היה מהותי.

שכבות המוצר

חמש השכבות

עוד דוגמאות ל-core benefit: שואב רובוטי: בית נקי. Wix: אתר לעסק, וכלים לנהל אותו. Google: מידע מסודר, רלוונטי ויעיל.

הכלל: מלמטה למעלה

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

איפה זה תופס אתכם

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

בדיקה עצמית

1. מוצר חדש משיק פיצ'ר AI מרשים, אבל המערכת נופלת לעיתים קרובות. מה הבעיה, במונחי השכבות?
2. ספא במלון: באיזו שכבה?
3. מה ההבדל בין generic ל-expected?

תשובות.

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

2: Augmented: מעבר למה שמצפים בחדר עצמו.

3: Generic הוא מה שחייב להיות כדי לענות על התועלת (מיטה וסדינים). Expected הוא מה שהלקוח מצפה לו (שהסדינים נקיים).

יעדים ומדדים

מהחזון ועד המשימה

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

North Star Metric

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

סוגי מדדים

יעד משותף, מדדים שונים

איפה זה תופס אתכם

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

בדיקה עצמית

1. מה ההבדל בין objective ל-key result?
2. למה כדאי להגיע ל-North Star Metric לפני ששוקלים פיצ'רים?
3. איך QA ומנהל מוצר יכולים לשאוף לאותו דבר ולהימדד אחרת?

תשובות.

1: ה-objective אומר לאן רוצים להגיע. ה-key results הם המדדים שמראים שבאמת מתקדמים לשם.

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

3: ה-objective משותף: שהמוצר יצליח. ה-key results שונים: QA נמדד על באגים, מנהל המוצר על ערך ואימפקט.

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

התהליך

1. Bottom-up: אוספים מה שמגיע מהשטח: מנכ״ל, לקוחות ומשתמשים, פיתוח, שיווק, מכירות, BI ודוחות תמיכה. קודם מקשיבים ומבינים את הבעיה
2. Top-down: מה-OKR גוזרים רעיונות, ומפרקים כל initiative לרמת פיצ'רים
3. Mix & match: הכול נכנס לטבלה אחת: פיצ'ר, תיאור, objective ו-key result, מי ביקש, impact וזמן
4. Backlog מוצרי: זו הרשימה. עדיין לא מפת דרכים
5. תעדוף: לפי אימפקט וזמן, או לפי RICE. רק עכשיו זו מפת דרכים

אימפקט וזמן

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

RICE ו-ICE

ICE הוא אותו דבר בלי Reach, למוצר חדש שאין לו עדיין משתמשים.

Build versus buy

זה תעדוף אסטרטגי: מה בכלל נכנס לצוות. RICE מסדר את מה שכבר נכנס.

איפה זה תופס אתכם

• מי שצועק הכי חזק לא מקבל ראשון. בדוגמה מההרצאה, מוקד עם כ-100,000 פניות קדם לגוף שזעק הכי חזק, ועם כ-6,000 אנשים
• לבדוק מה מאחורי ה-Reach. פניות רבות שמתפזרות על נושאים רבים עשויות להוריד את הציון כשעובדים לפי נושא
• 50% הוא לא Confidence. ביטחון גבוה מגיע מנתוני שימוש אמיתיים
• גם כשהסדר נראה מובן מאליו, כדאי לבסס אותו במדדים, כדי לתקשר אותו
• Backlog הוא לא מפת דרכים. בלי תעדוף זו רק רשימה

בדיקה עצמית

1. מה ההבדל בין backlog למפת דרכים?
2. שני פיצ'רים: אחד עם impact 5 ו-XL, השני impact 4 ו-S. מה כנראה קודם, ולמה?
3. למה במוצר חדש משתמשים ב-ICE?
4. מה ההבדל בין build versus buy ל-RICE?

תשובות.

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

2: השני. האימפקט שלו כמעט זהה, והמאמץ קטן בהרבה. כך מביאים ערך מהר, ורואים אם הוא משפיע.

3: אין עדיין משתמשים, ולכן אין Reach למדוד.

4: Build versus buy מחליט מה בכלל ייכנס לעבודת הצוות. RICE מסדר את הפיצ'רים שכבר הוחלט להכניס.