עזבו אתכם MVP, בואו נדבר על דחלילים
זה נכון, עד שהגיעה מתודולוגיית ה Agile לעולמינו בתחילת שנות 2000, מנהלי המוצר של עידן הדינוזאורים היו נוהגים לכתוב דרישות ו FSDים עצומים שדרשו שנות אדם של איפיון ורק לאחר סיום סבב האישורים, החתימות ואישור התקציב היה ניתן להתחיל לפתח, עד שהגיע ה Time to market למוצר או לפיצ'רים כבר לא היה שימוש.
מרגע שהעולם התוכנה הבין שאין ברירה אלא להיות יעילים ומהירים יותר מרבית הארגונים הטמיעו Agile כסטנדרט, בעיקר ביכולת לחסוך בזמן, ולצמצום עלויות האפיון ופיתוח של פיצ'רים קצרי תוקף.
בערך באותו הזמן גם נולד המונח האהוב MVP, או בשמו הארוך Minimum viable product -
אותה השיטה שמזמינה אותנו לפתח גרסה ראשונית למוצר שלנו שיש בה "מספיק" פיצ'רים שמישים כדי שלקוחות ראשוניים שלנו יוכלו להתחיל להתעניין ולרכוש את המערכת שלנו.
זה בהחלט אמור לעבוד עבור ארגוני בתחילת דרכם כשהמוצר מרובה פיצ'רים.
אז אנחנו לעבוד: סוקרים את כל הדרישות שלנו, מתעדפים, מתמחרים, מתעדפים שוב, מקבלים החלטה מה זה "מספיק פיצ'רים לגרסה הראשונה", בודקים אם יספקו את צרכי הלקוחות שלנו, מפתחים, מתקנים, מתקנים שוב,
מבינים שבגלל שפיתחנו רק 10 מתוך 100 הדרישות המקוריות יש לנו "חור" באיפיון, ואז מוציאים עוד גרסת תיקונים קטנה אחת ודי, ולבסוף אפשר להציג גרסה ראשונה ללקוח הפוטנציאלי שבמקרה הטוב יסכים לחתום איתנו אבל ממש מחכה לגרסה הבאה עם הפיצ'רים שהכי חסרים לו ובמקרה הרע, הלקוח הפוטנציאלי שלנו חתם עסקה עם חברה אחרת.
כך שלעיתים נראה שגם ה MVP המדוייק והקטנקטן ביותר פשוט לא מספיק מהיר כדי להתחרות בשוק המשתנה שלנו.
אז תשאלו - יש הצעה אחרת? טוב ששאלתם - דחלילים!
דחליל הוא לא עוד MVP, הוא לא פיתוח חלקי או קטן מאוד, דחליל הוא פיתוח שנראה עובד אבל לא עושה כלום.
איך זה עובד?
בשיחות המכירה עולה צורך בפיצ'ר מסויים, יתכן ויש לקוח שמתנה את העסקה בקיומו של הפיצ'ר הזה,
אתם מכירים את הצורך ואולי הפיצ'ר הזה ב Road Map להמשך הדרך כי לטעמכם השוק עדיין לא נזקק לו כרגע.
את המוצר שלנו אנחנו מציגים באין סוף מפגשים, מיט-אפים, כנסים (לפני הקורונה), במקום לפתח את הפיצ'ר הזה כ MVP, בואו ננסה לבחון אותו כדחליל.
איך עושים את זה?
דחליל טוב הוא פלואו מספק בסביבת ה DEMO או PROD שמראה באופן מופלא איך הפיצ'ר עובד, אבל למעשה אין מאחריו שום קוד לוגי שמבצע פעולה בקאנדית.
למשל הלקוח שואל אם האפליקציה שלנו יודעת לתמוך בתשלום על ידי זיהוי רשתית העין.
התשובה שלנו תהיה - "כמובן", הינה אתה מקרב את העין למצלמה ומוצר שלנו מציג הודעת אישור על ביצוע תשלום - מופלא. מי ידע שאין שום לוגיקה מאחרי?
דחליל טוב בעיני הוא שינוי FRONT שלא דורש יותר מיומיים-שלושה של מפתח.
דחליל טוב דורש ממחקר והאיפיון מוצרי מסויים, נדרש מאמץ UX / UI כדי שהדחליל יראה טוב.
לפני ההחלטה על פיתוח הדחליל עלנו לקבל הערכה כמה זמן/כסף יקח לפתח את הגרסה המלאה של הפיצ'ר כדי שלא נתחייב לתחילת עבודה עם לקוח כשאנחנו לא מוכנים.
מה הרווחנו בתהליך הזה?
אם הפיצ'ר הזה זכה להצלחה והביא לקוחות לשולחן המכירה, מצויין, נקדם את הפיצ'ר הזה בתעדוף ונדאג שיהיה מוכן בזמן כשהלקוח הראש יתחיל להשתמש במוצר שלנו בפועל (הטמעה היא דבר שלוקח זמן)
אם הפיצ'ר עשה וואוו בדמואים אבל אף לקוח לא רכש את המוצר או הפיצ'ר הזה - חסכנו זמן, כסף ומשאבי פיתוח יקרים משמעותיים.
אם הפיצ'ר הזה בכלל לא עשה וואוו - אז הרווחנו הבנה שאין צורך בפיתוח פיצ'ר כזה כרגע או בכלל וחסכנו עוד יותר. כי לעיתים רק כשלקוחות רואים פלואו עובד הם מבינים שאין להם צורך בו.
בכמה חברות שייעצתי להם יש פיצ'רים שמוצגים כנתמכים ב ROAD MAP וברשימת הפיצ'רים. הם מוצגים בכנסים למשקיעים ולקוחות, אבל בפועל אף אחד לא השתמש בהם מעולם.
טרנדים וצרכי לקוחות הם דבר משתנה ודינאמי באופן מטריף, אל תפלו בפח, לפני MVP תבדקו אופציה לשימוש בדחליל.
לקוח שרואה DEMO והדחליל עונה לו על הצורך יחתום אתכם על הסכם פעילות מבלי לדעת שעדיין לא נתמך (עדיין).
אבל אם הדחליל לא ריגש אותו - חסכתם המון.
מכירה מהנה