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

החזרה מחופשת הלידה סימנה עבורי התחלה חדשה. חזרתי עם ראש נקי, הרבה מוטיבציה, ורצון אמיתי לשנות. ואז הגיעה גם ההזדמנות - אתגר משמעותי שהנחיתו על שולחני:  לשפר את תהליך יצירת המשחקים החדשים ב-Zynga. באופן מאוד אופייני ל-mavens הוענק לי חופש פעולה מלא, אז החלטתי לגשת לזה אחרת הפעם. התוצאות היו חזקות במיוחד: עברתי מ discovery ל-proof of concept בתוך פחות מחודש, למרות משאבים מוגבלים.

אז איך בעצם זה קרה? 

ראשית, התעקשתי להבין באופן אישי, ״דרך השטח״, מי המשתמשים הפוטנציאליים ומהם הקשיים שלהם. מיפיתי כל אדם שמעורב בתהליך פיתוח משחק חדש בחברה - ממעצבי משחקים, דרך מנהלי מוצר,אנשי user acquisition, שיווק, מנהלים, Consumer Insights ואפילו ASO. 

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

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

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

הבנת הצורך ויצירת הפיתרון 

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

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

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

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

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

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

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