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

הקלטה של 59 דקות, מתוכן כתשע הדקות הראשונות בלי קול. שכבות המוצר על דוגמת בית מלון, מאיפה מגיעות בקשות, איך מרכזים יוזמות ובקשות בטבלה אחת, תעדוף לפי אימפקט וזמן, RICE ו-ICE, ו-build versus buy.

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

ההרצאה ממשיכה את מה שכבר נעשה בקורס: הצגות האמצע (שוק, תחרות, צורכי הלקוח וחזון), תרגול על 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 אנשי סיעוד. האימפקט היה דומה, וההבדל בזמן הפיתוח לא היה מהותי.