קשה ליצור מוצרים חדשים שאנשים אוהבים, בעיקר משום שזהו תהליך מורכב שלוקח זמן רב. הוא מבקש מאיתנו ללמוד מהטעויות שלנו, בהקשר שבו חזרה לתיקון שגיאות לעולם אינה מתקבלת בברכה. תהליך של יצירת משהו גדול דורש יצירתיות ומשמעת. מוצרים רבים נכשלים כי שני החלקים האלה אינם תומכים זה בזה. במקום זאת, הם מגבילים זה את זה.
הגבלת יצירתיות עם תהליך קפדני שמונע על ידי מנהלים תניב מוצר משעמם וחסר תועלת. ההסתמכות על היצירתיות של היוצר לבדה תביא אותך ל-80% במהירות, אבל לעולם לא תצליח לעשות את הליטוש האחרון לפרטים החשובים.
במשך שנים רבות, ראיתי מוצרים נכשלים בגלל אגו, סירוס יצירתי וחוסר משמעת. הצורך במוצרים איכותיים היום גדול מכדי לבזבז זמן וכישרון.
על ידי יצירת מוצרים ב-Translated וב-Memopal ועל ידי התבוננות בכל כך הרבה סטארט-אפים מעולים, המצאתי שיטה שמטרתה לספק את האיזון הנדרש של יצירתיות ומשמעת, דרך מהירה ומאושרת מראש לחזור אחורה ולתקן שגיאות שגם משלבת שני אלמנטים נפוצים של מוצרים מוצלחים: חזון ופסיכולוגיה.
הצוות המינימלי מורכב כך:
- מנהל מוצר, שמשימתו להוביל
- המשתמש/ים, שמשימתם להביע את נקודות הכאב ואת חשיבותן. המשתמש הוא מאמץ מוקדם שהביע עניין בקנייה או בשימוש במוצר שלך
- המפתח/ים, שמשימתם היא למצוא פתרונות לנקודות הכאב של המשתמש ולהעריך את העלויות שלהן
אם אתה מייסד יחיד, אני מציע לך למלא את תפקיד מנהל המוצר, ואם אפשר, לגייס מפתח. מייסדים יחידים יכולים למלא תפקיד כפול של מנהל מוצר ומפתח, אך זה לא מצב אידיאלי כי זה גורם דחף טבעי להישאר באזור הנוחות, משהו ששיטה זו נועדה למנוע.
רוב האנשים יוצרים מוצרים מבלי שיש להם משתמש בלולאה הראשונית. אני חושב שזה רעיון רע. כדי להצליח בלי המשתמש, תצטרך הרבה מזל, ומשתמשים נמצאים בשפע, הרבה יותר ממזל.
זהה כאבים
פגישות מרובות בנות שעה. המשתמש יבטא את הכאב הנתפס שלו. מנהל המוצר ישאל שאלות כדי להבהיר ולצלול עמוק יותר עד שייחשף השורש האמיתי של נקודת הכאב. המפתחים יהיו משקיפים שקטים. כאן מתבהרת איכותו של מנהל המוצר: עד כמה הוא יכול להתעמק בשורשי נקודת הכאב מבלי להיחשב לאידיוט? המשתמש בדרך כלל ינסה לרצות את מנהל המוצר, ויאמר שהוא ישמח שבעיה מסויימת תיפתר. עם זאת, מנהל המוצר לא צריך להקשיב לדברי המשתמשים: מנהל המוצר צריך להסתכל על מה שהם עושים. לשם כך, לעתים קרובות אני מציע לדמות את הרעיון שכבר קיים מוצר שפותר את הבעיה שנקרא X ועולה Y. ואז אני אומר “אתה רוצה שאני אשיג לך אחד עכשיו?”. אם המשתמש אומר “כן”, זיהית כאב נתפס ששווה לפעול על פיו. אם המשתמש אומר “לא” או מתחיל להוסיף דרישות נוספות וסיבוכים, אתה צריך להתחיל את התהליך שוב. מנהל מוצר ימיר כל נקודת כאב למשימה.
הוסף חזון
מספר פגישות של שעה אחת כדי לדון על מראהו האידיאלי של המוצר בעתיד. המשתתפים לא צריכים להרגיש שזה מה שהם מתבקשים לבנות עכשיו, אלא מה לדעתם יהיה אפשרי ביום מן הימים. מנהל המוצר ישאל את המפתחים איך לדעתם אפשר יהיה להתעלות מעל הציפיות של המשתמש, תוך התחשבות בכאב הנתפס שלו. הם ידברו על מה שהטכנולוגיה יכולה לעשות. מנהל מוצר צריך להפנות את אותה שאלה למשתמש ולהציג את דעתו בסוף. בדרך כלל, למנהל המוצר יש חזון, אך כשהוא מציג אותו אחרי כולם, הוא יכול למנף את היצירתיות של המשתתפים. הדיון צריך להימשך עד שמנהל המוצר מסכים שהמוצר העתידי יהיה אפשרי מבחינה טכנית ואהוב על ידי המשתמש. מנהל המוצר ימיר את הרעיונות למשימות.
הוסף פתוס
רוב המוצרים המוצלחים נותנים למשתמשים משהו נוסף מעבר לפתרון לבעיה נתפסת.
התייחסות ליהירות, לעצלנות ולכמיהה למשהו שאיננו יכולים להשיג, הם אחדים מהאלמנטים המשותפים של מוצרים מעולים. פגישות אלה מצליחות הכי טוב אם הן כוללות רק את מנהל המוצר והמשתמש בשיחה אינטימית. מנהל המוצר צריך לאפשר למשתמש לדון בעבודתו או בחייו ולשכוח לרגע את ייצור המוצר. מנהל המוצר צריך לשאול את המשתמש מה גורם לו להיראות טוב יותר מעמיתיו, מה משעמם אותו ומה הוא רוצה שאינו יכול להשיג. זה יתורגם למשימות.
הגדר עדיפויות וגרסאות
כל המשימות שנגזרו מנקודות הכאב, החזון והפסיכולוגיה ייכללו בטבלה דומה לטבלה הבאה:
| משימה | $ עלות | $ השפעה | עדיפות |
|---|---|---|---|
| בקש מהמשתמשים ללחוץ לחיצה ימנית על התמונה כדי לשתף אותה | 2,000 | 10,000 | 5.0 |
| גרסה 1 | |||
| הגדל תמונות | 1,500 | 5,000 | 3.3 |
| תמיכה ב-Android | 10,000 | 10,000 | 1.0 |
| גרסה 2 | |||
| ארגון אוטומטי של תמונות | 50,000 | 25,000 | 0.5 |
| סימון אוטומטי של התמונות הטובות ביותר | 20,000 | 5,000 | 0.2 |
| גרסה 3 | |||
עלות היא הערכה של העלות הכוללת של המשימה. נתון זה ימולא רק על ידי המהנדסים. השפעה היא ציון או ערך כלכלי הקשור למשימה. שדה זה ימולא רק על ידי המשתמשים, אולי מבלי לראות את העלות. ההיבט החשוב הוא לא המספר עצמו אלא היחס בין המשימות. אם ערכה של משימה אחת כפול מערכה של משימה אחרת, השפעתה צריכה להיות גדולה פי שניים. מנהל המוצר צריך לאתגר את המהנדסים ואת המשתמש כדי לוודא שהאומדנים נכונים. מנהל המוצר יחשב את העדיפות כהשפעה/עלות וידרג את המשימות בסדר עדיפות יורד. מנהל המוצר, בעזרת המשתמש והמהנדסים, ימתח קווים אופקיים לתכנון גרסאות.
קיבוץ משימות לתוך גרסאות לפי עדיפויות מבטיח אספקה של ערך מקסימלי בגרסה הראשונה. זה קריטי להתאמה בין המוצר לשוק. אם הצעת הערך הרצויה אינה ברורה בגרסה הראשונה, מנהל המוצר צריך לערער על המספרים הקודמים ו/או לשקול מחדש את הצעת הערך עצמה. אתה עלול לגלות שבעצם לא שווה לעבוד על נקודת הכאב שהעסיקה אותך.
ביקורת
צור גרסת מוצר 1 ובקש מהמשתמש להשתמש בו. בקש הזמנות מראש בהנחה הוגנת, שכן אתה מתמודד עם מוצר אלפא. אם המשתמש מזמין מראש, עבור אל גרסה 2 ונסה שוב.
אם המשתמש לא הזמין מראש כי אינו סבור שהמוצר מטפל בנקודת הכאב, חזור אחורה וזהה שוב את נקודות הכאב. אם, אחרי כמה מחזורים, המשתמש עדיין לא מסר הזמנה מראש, יש להחליף את הגורם החלש ביותר מבין המשתמש, היזם ומנהל המוצר ולהתחיל את המחזור מחדש.
מעבר ליצירתיות ומשמעת, אם אתה רוצה לייצר מוצרים טובים אתה צריך להיות מוכן גם להקריב קורבנות גדולים או לקוות להרבה מזל. אם אתה רוצה לייצר מוצר נהדר, תזדקק לשניהם.