מעורר השראה – Inspired

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

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

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

מרטי קייגן, מהמובילים בעולם בתחום ניהול מוצרים טכנולוגיים, הוא מייסד חברת SVPG שנותנת שירותי הדרכה וייעוץ לחברות מוצר. בעבר היה בתפקידי ניהול בכירים בחברות HP, Netscape ו-eBay.

שלושה שלבים של חברות היי-טק

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

סטארט אפ

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

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

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

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

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

חברות שהיו מוכשרות ובעלות מזל (בדרך כלל שתי התכונות נחוצות) להשיג התאמת מוצר/שוק מוכנות להתמודד עם אתגר קשה לא פחות: כיצד לצמוח ביעילות. צמיחה היא אתגר קשה מאוד, אך על אף זאת, קייגן מכנה את בעיה זו כ-"a good problem to have".

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

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

תאגידים

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

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

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

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

עשר הסיבות לכישלון מוצרים

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

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

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

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

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

1. מקור הרעיונות: מרבית הרעיונות מגיעים מצוותי המכירות ובעלי העניין. זה לא המקור הטוב ביותר להשגת רעיונות. בנוסף, זה מוביל להחלשת צוותי המוצר, תפקידם הוא רק לבצע ולממש את מה שהוחלט כבר.
2. הפגם ב-business cases: לבחון את הערך, העלות והסיכון הפוטנציאליים של רעיון זה צעד חשוב. במיוחד בשביל רעיונות שדורשים השקעה גדולה. אבל יש פגם במודל הנוכחי, חברות משתמשות בשיטת ה-business cases על מנת לתעדף היכן הרעיון יכנס במפת הדרכים. הם עושים זאת על ידי 2 נתונים עיקריים: כמה יעלה לייצר את זה, וכמה אפשר להרוויח מזה. אבל הבעיה היא, שבשלב זה, אין שום דרך להעריך את הנתונים האלו.
3. הבעיה של מפות הדרכים: חברות מאוד מתרגשות ממפות הדרכים שלהן, הן מתעדפות בצורה מדוקדקת רשימות של רעיונות ופרויקטים. אך לשיטה זו יש 2 בעיות: הראשונה היא שלפחות חצי מהרעיונות במפת הדרכים לא הולכים להצליח, והשניה היא שגם הרעיונות שיראו פוטנציאל כלשהו, ידרשו כמה מחזורים של שיפורים על מנת להביא ערך אמיתי לחברה. עוד על בעיה זו בהמשך.
4. תפקיד מנהל המוצר: אי אפשר לקרוא לתפקיד זה ״מנהל מוצר״ – המונח הנכון הוא ״מנהל פרויקט״. במודל הנוכחי, הוא בסך הכל מאגד דרישות ואפיונים למעצב ולמהנדסים. זה הפוך לגמרי מתפקידו האמיתי של מנהל המוצר המודרני.
5. תפקיד המעצב: המעצב במודל הנוכחי נכנס בשלב מאוחר מדי לתהליך. כתוצאה מכך לא ניתן להפיק מהמעצב את מירב הערך שהוא יכול לתת. הנזק כבר נגרם, עכשיו המעצב רק צריך להעביר מכחול על הבלאגן. המעצב יודע שהרעיון לא מיטבי, אבל הוא מנסה לגרום לו להיראות נחמד ועקבי.
6. המהנדסים נכנסים מאוחר מדי: כשהמהנדסים עושים רק עבודת תכנות – הם מפיקים רק חצי מהערך שלהם. המהנדסים הם מקור החדשנות הטוב ביותר בחברה, והם בכלל לא מוזמנים למסיבה.
7. ה-Agile נכנס מאוחר מדי: הצוותים שמשתמשים ב-Agile, מנצלים רק 20% ממנו. במודל הנוכחי משתמשים ב- Agile רק בחלק של מסירת המוצר. שאר הארגון הוא הכל חוץ מ-Agile.
8. החברה הופכת להיות ממוקדת-פרויקטים: פרויקטים הופכים לחיווי להצלחה. הבעיה בפרויקטים, היא שהעניין בהם הוא הפלט (ולא התוצאות העסקיות). תהליך זה מוביל לפרויקטים מיותמים, ולצוותי מוצר שמצופה מהם רק לייצר מוצרים מבלי לדאוג לערך שהם מספקים לחברה.
9. הסיכון הוא בסוף: הבעיה הגדולה ביותר בשיטת ה-Waterfall היא שהסיכון הוא בסוף התהליך – תיקוף הרעיון, כלומר המשוב שאנחנו מקבלים מהלקוחות, מתבצע מאוחר מדי. העקרון הבסיסי בשיטות הפיתוח הרזות הוא צמצום הבזבוז. במודל הנוכחי ישנו בזבוז רב של משאבי עיצוב, פיתוח ובקרת איכות.
10. עלות ההזדמנות: בזמן שמודל זה מעסיק את החברה ומבזבז זמן וכסף, ההפסד הגדול ביותר הוא ככל הנראה ״עלות ההזדמנות״. בזמן שהחברה בזבזה את משאביה בניסיון לממש רעיונות כושלים, היא יכלה לפתח דברים אחרים שיכלו להניב רווחים רבים יותר.

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

עקרונות לחברות מוצר

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

מונחי יסוד

כעת נעשה יישור קו ונגדיר מספר מונחים בסיסיים שמוזכרים פעמים רבות בספר (ובסיכום).

מוצר שלם 

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

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

תהליך מציאת ומסירת מוצר רציף

ישנם שתי פעילויות שקיימות בכל צוותי מוצר: מציאת מוצר (Product Discovery) – עלינו למצוא מוצר לבנות ולתכנן אותו, ומסירת מוצר (Product Delivery) – עלינו למסור את המוצר הזה ללקוחות.

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

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

מציאת מוצר

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

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

1. מי יקנה או ישתמש בזה? (בדיקת הערך)
2. האם המשתמש יבין איך להשתמש בזה? (בדיקת השימושיות)
3. המהנדסים יצליחו לבנות את זה? (בדיקת המעשיות)
4. בעלי העניין בחברה יתמכו בזה? (בדיקת החיוניות העסקית)

אב טיפוס

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

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

מסירת מוצר

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

התאמת מוצר/שוק

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

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

חזון מוצר

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

צוותי מוצר חזקים

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

עקרונות של צוותי מוצרים חזקים

1. צוות של שליחים: ישנו ציטוט בעמק הסיליקון שאומר ״אנחנו צריכים צוותים של שליחים, לא צוותים של שכירי חרב״. שכירי חרב עושים את מה שאומרים להם, ואילו שליחים באמת מאמינים בחזון והם מחויבים לפתור בעיות ללקוחותיהם.
2. הרכב הצוות: צוות טיפוסי מורכב ממנהל מוצר, מעצב, ובין 2 ל-12 מהנדסים. (יתכנו גם חברי צוות נוספים כמו מנהל שיווק, מהנדסי אוטומציה, חוקר משתמשים ועוד)
3. העצמת צוותים ולקיחת אחריות: צוותי מוצר מקבלים יעדים עסקיים ברורים וזו אחריותם להגיע ליעדים אלו. צריך להעצים ולדרבן צוותים למצוא בעצמם דרכים להגיע ליעדים. והם צריכים להיות אחראיים לתוצאות.
4. גודל הצוות: הגבול העליון לצוות הוא כ-8 עד 12 מהנדסים. אך דווקא גיוון הכישורים של חברי הצוות הוא חשוב יותר מגודל הצוות.
5. מבנה הדיווח בצוות: צוות מוצר הוא ארגון שטוח בהגדרה. בדרך כלל, אין מנהלים בצוות, וכל חבר בצוות עושה את התרומה האישית שלו. החברים בצוות ממשיכים לדווח למנהל הפונקציונלי שלהם, לדוגמא, המהנדסים מדווחים למנהל ההנדסה.
6. שיתוף פעולה צוותי: מערכת היחסים בצוותי מוצר מבוססת על שיתוף פעולה אמיתי. מנהל המוצר, המעצב, והמהנדסים צריכים לייצר מוצרים ביחד.
7. מיקום הצוות: צוותי מוצר צריכים פיזית לשבת יחד, אחד ליד השני, מספיק קרובים כדי שיוכלו לראות את המסך אחד של השני. זה נשמע קצת מיושן, עם כל הקדמה והמעבר לעבודה מרוחקת, אבל החברות הטובות ביותר הבינו ויישמו את הערך הרב במיקום חברי צוות אחד ליד השני.
8. תחום עבודת הצוות: צוות מוצר צריך להיות אחראי על תחום ספציפי בחברה. לדוגמא, בפייפאל תוכלו לעבוד בצוות שאחראי על איתור ומניעה של הונאות, ובפייסבוק תוכל לעבוד בצוות שעוסק בניוזפיד. צוות שאחראי על תחום מסוים, אמור להיות אחראי על כל המטלות בתחום זה – פיצ׳רים, תיקוני באגים, שיפורי ביצועים, שינויי תוכן וכו׳.
9. עמידות הצוות: צוותי מוצר צריכים להיות עמידים ויציבים. עמידות הצוות חשובה כי לאנשים לוקח זמן להיפתח ולהיקשר לחברי הצוות שלהם, וגם כי לוקח זמן ללמוד ולשלוט בתחום עבודת הצוות. אם חברי הצוות ישתנו כל הזמן, יהיה להם קשה להרגיש תחושת בעלות על המוצרים שלהם ולא תהיה להם תשוקה של שליחים.
10. אוטונומיית הצוות: כדי שצוותים יהיו מועצמים ובעלי תשוקה של שליחים – אנחנו צריכים לתת להם חופש פעולה רחב. לצוות צריכה להיות היכולת להחליט איך לפתור את הבעיות שמשויכות אליהם. אוטונומיה פירושה גם להפחית ככל הניתן את התלות בין הצוותים.

מנהל המוצר

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

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

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

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

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

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

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

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

מעצב המוצר

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

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

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

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

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

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

1. תעשה כל מה שצריך כדי שהמעצב ישב לידך.
2. תשתף אותו בכל פעם שעולה רעיון חדש.
3. תשתף אותו בכל אינטראקציה עם הלקוחות. תלמדו על הלקוחות יחד.
4. תילחם ברצון שלך לתת לו רעיונות עיצוביים. תן לו את החופש לפתור קשיים עיצוביים בעצמו.
5. תעודד אותו להיכנס בתחילת התהליך ובתדירות גבוהה. המעצב צריך להרגיש חופשי לחקור ולהציע פתרונות שונים (שלא רק בתחום העיצוב).

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

המהנדסים

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

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

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

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

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

מפות דרכים: הבעיות, הסיבות והחלופות

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

הבעיות

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

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

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

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

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

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

הסיבות

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

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

החלופות

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

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

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

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

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

שיטות מציאת מוצר

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

מסגור (Framing)

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

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

ניתן למסגר רעיון בעזרת 2 שיטות אלו:

1. הערכת הזדמנויות (Opportunity assessment): בשיטה זו אנו צריכים לענות על 4 שאלות חשובות: מה היעד העסקי שעלינו להגיע אליו? איך נדע שהגענו עלינו? איזו בעיה זה יפתור עבור לקוחותינו? באיזה סוג לקוח אנחנו מתמקדים כרגע? תשובות לשאלות אלו יעזרו למסגר בעיות.
2. מכתב מלקוח (Customer letter): הרעיון הוא שמנהל המוצר יכתוב מכתב מדומיין מלקוח שמרוצה ומסופק מאוד מהמוצר שלכם. במכתב, הלקוח מסביר ממה הוא מרוצה וכיצד מוצר זה שיפר את חייו. שיטה זו עוזרת לשים אותנו בנעליים של הלקוח ולחוות את הבעיות מהצד שלו.

תכנון (Planning)

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

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

יצירת רעיון (Ideation)

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

1. ראיונות עם לקוחות (Customer interviews): לראיין את הלקוחות זו השיטה הבסיסית ביותר אך מהחשובות והחזקות ביותר. בראיון עם הלקוח עלינו לקבל תשובות למספר שאלות חשובות, האם הלקוחות שלנו הם מי שאנחנו חושבים שהם? האם הבעיות שלהם הן הבעיות שאנחנו חושבים עליהן? איך הם פותרים את בעיות אלו כיום?
   חשוב לעשות ראיונות עם לקוחות לפחות כשעתיים בכל שבוע, עם עדיפות שזה יתבצע במשרד שלהם, במקום הטבעי שלהם, זה יכול לעזור לכם ללמוד את סביבת העבודה שלהם. בראיון צריכים לנכוח מנהל המוצר, המעצב ואחד המהנדסים.
2. מבחן השוער (Concierge test): במבחן השוער אתם ניגשים אל הלקוחות ומבקשים מהם להראות לכם כיצד הם עושים את עבודתם. מבחן זה יעזור לכם להבין את שיטות העבודה שלהם ובכך תוכלו למצוא בעיות חדשות לפתור להם. כמו בשיטת הראיונות, גם כאן צריכים לנכוח מנהל המוצר, המעצב ואחד המהנדסים.
3. האקתון (Hack days): ישנם שני סוגים של האקתונים: מודרך ולא מודרך. בהאקתון מודרך, הצוות מקבל בעיה של לקוח או יעד עסקי ומתבקש להתחלק לקבוצות ולעבוד על פתרונות מתאימים. בין היתר הצוותים אמורים ליצור אב טיפוס. בהאקתון לא מודרך, חברי הצוות יכולים לחקור כל רעיון למוצר ששייך למשימה הכללית של החברה. שיטה זו מפתחת תשוקה של שליחים ונותנת לחברי הצוות את החופשיות והעוצמה שהם צריכים על מנת למצוא פתרונות איכותיים. 

בניית אב טיפוס (Prototyping)

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

ישנם 5 עקרונות בסיסיים לבניית אבות טיפוס:

1. מטרת אב הטיפוס היא ללמוד משהו במחיר נמוך יותר (במונחים של זמן ומאמץ) מאשר בניית מוצר אמיתי.
2. יצירת אב טיפוס מכריחה את הצוות לחשוב על בעיות בצורה עמוקה יותר מאשר לכתוב אותן על מסמך.
3. יצירת אב טיפוס היא פעילות הכרוכה בשיתוף פעולה צוותי. חברי צוות המוצר והשותפים העסקיים יכולים לחוות את אב הטיפוס על מנת לייצר למידה משותפת.
4. ישנם רמות שונות של דיוק לאבות טיפוס. דיוק גבוה משמעותו אב טיפוס שנראה כמו מוצר אמיתי ולהיפך. רמות דיוק שונות משרתות פתרונות שונים. לעיתים אב טיפוס לא נדרש להיראות כמו מוצר אמיתי ומספיק שרק יכיל את המינימום האפשרי.
5. המטרה העיקרית של אבות טיפוס היא לבחון סיכון מוצרי אחד או יותר (ערך, שימושיות, מעשיות או חיוניות עסקית).

בדיקת ערך (Value testing)

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

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

1. בדיקת ביקוש: לא תמיד ברור אם יש ביקוש למוצר מסוים. יתכן שנשיק מוצר מדהים שפותר בעיה כלשהי, אבל הבעיה הזו לא מטרידה את הלקוחות והם לא מוכנים לשלם כדי לפתור אותה. בדיקת ביקוש אמורה לזהות מוקדם אם יש ביקוש למוצר שלנו, כדי שנמנע מלבזבז את משאבינו על מוצר שאין לו ביקוש.
   דוגמא לשיטת בדיקת ביקוש היא ״מבחן דף הנחיתה״: הרעיון הוא לפרסם דף נחיתה של המוצר שאנחנו רוצים לבדוק, וכשהלקוחות ינסו לרכוש את המוצר או להתחבר אליו, נסביר להם שאנחנו בשלבי הכנה של המוצר ושנחזור אליהם כשהמוצר יהיה מוכן. בעזרת מבחן זה אנחנו יכולים ללמוד אם לקוחות מעוניינים במוצר שלנו ואפילו נוכל לשוחח ולראיין אותם.
2. בדיקת ערך איכותנית: בדיקה זו מתמקדת בעיקר בתגובות של הלקוחות. הם אוהבים את המוצר? הם ישלמו עליו? ואם לא, למה לא? בדיקה זו יכולה להתבצע על ידי מבחן שימושיות (יוסבר בהמשך), ראיונות עם לקוחות ושיפור קבוע של אב הטיפוס.
3. בדיקת ערך כמותנית: בדיקה זו מתמקדת ביעילות – עד כמה הפתרון שלנו באמת פותר את הבעיה של הלקוחות. בדיקה זו יכולה להתבצע בעיקר על ידי A/B Testing ושיטות נוספות לחשיפת מוצרים ופיצ׳רים בצורה הדרגתית.

בדיקת שימושיות (Usability testing)

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

מבחן זה מתבצע בארבעה שלבים:

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

בדיקת מעשיות (Feasibility testing)

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

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

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

בדיקת חיוניות עסקית (Business viability testing)

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

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

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

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

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

צוות מוצר טוב/צוות מוצר גרוע

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

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

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

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

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