יומנו של סטארט-אפיסטחוצפה חיובית: כך בודקים אם יש צורך במוצר לפני שרצים לפתח אותו
יומנו של סטארט-אפיסט
חוצפה חיובית: כך בודקים אם יש צורך במוצר לפני שרצים לפתח אותו
עדיף להציע ללקוח הפוטנציאלי מוצר שעדיין לא הגיע לרמת פיתוח מספקת ואפילו מוצר לא קיים מאשר לבזבז המון זמן, מחשבה, עבודה וכסף על מוצר שלא יתפוס. נכון, זה עשוי לעצבן כמה אנשים, אבל עדיין, האופצייה השנייה הרבה יותר גרועה
תהליכי פיתוח של מוצר טכנולוגי הם ארוכים ומורכבים. יחסית למה? יחסית למה שהאדם הסביר מצפה. לפעמים אני מציע שינוי כלשהו במוצר שלנו ומתבשר על ידי צוות הפיתוח שהשינוי שנראה לי כל כך קטן ומינורי ייקח שבוע שלם של פיתוח. או חודש. או יותר. זה נראה על פניו פשוט, אבל תמיד מתגלה שהפשטות הזו כרוכה במחקר, בעיצוב, בכתיבת קוד, באינטגרציה, בבדיקות, בתיקונים - בקיצור, זה הכול חוץ מטריוויאלי.
כמובן שיש גם דברים שמפותחים במהירות ובקלות יחסית, אבל ככל שהמוצר מתקדם יותר, כך בדרך כלל מסתבך גם התהליך. בעשורים האחרונים התפתחו מתודולוגיות פיתוח מודרניות, המאפשרות פיתוח מהיר יותר בסביבות פיתוח מוצר גמישות ומודולריות, אבל גם בסביבות הללו כמעט כל פיתוח חדש צריך להשתלב במערכת מורכבת וצריך לוודא שאין התנגשויות, ומשימות שנראות פשוטות יחסית אורכות זמן רב ודורשות משאבים רבים. המציאות הזאת מקשה על ארגון שחרט על דגלו את החדשנות, כיוון שהיכולת להיות ספונטניים, להגיב במהירות לשינויים ולצרכי שוק, ולייצר משהו עובד בספרינטים קצרים, הולכת ופוחתת ככל שהארגון גדל והמוצר מתפתח.
כאן נכנסת לפעולה המתודולוגיה שאימצנו מעולם השיווק: נסה לפני שתתחייב. בדיוק כמו מכון כושר המאפשר לך לבוא לאימון ניסיון לפני שתרכוש מנוי שנתי, חנות בגדים המאפשרת לך למדוד את הבגד ולוודא שהוא מתאים לפני שתקנה, או משחק וידאו שאפשר לשחק בו את השלב או השניים הראשונים שלו בטרם נידרש לרכוש אותו, גם בעולם הפיתוח נמצאה הדרך לוודא שהמוצר עונה על צורך שוק אמיתי לפני שנפנה משאבים יקרים לתהליך של פיתוח והטמעה.
תארו לכם שהייתם משתמשים באפליקציה מסוימת, כמו וולט למשל, ולאחר שבחרתם מנות להזמנה ממסעדה כלשהי הייתה מופיעה לכם האופציה להפוך את ההזמנה שלכם מהזמנה חד פעמית להזמנה שחוזרת על עצמה אוטומטית על בסיס שבועי ביום ושעה קבועים בשבוע. ונניח שהרעיון הזה מצא חן בעיניכם ולחצתם על הכפתור המתאים כדי להפוך את ההזמנה לקבועה ואז הייתה מופיעה לכם הודעה בנוסח: ״השירות עדיין אינו זמין, בדקו שוב בקרוב״. קצת מתסכל. אבל אם וולט באמת היו שוקלים לפתח אפשרות כזו, הפיתוח היה מורכב וכולל המון מרכיבים שיש לתמוך בהם: אפשרות לערוך ולבטל את ההזמנה הקבועה, אפשרות לדלג על משלוח או שניים, התאמת המערכת לקליטת הזמנות עתידיות, הכשרת צוותי השירות לתת מענה לשאלות הקשורות בהזמנה חוזרת ועוד.
זמן הפיתוח של שירות מהסוג הזה עשוי לקחת בין חודש לחצי שנה, לערב הרבה מאוד גורמים (יועץ משפטי, מעצב, מפתחים, בודקי תוכנה ועוד), להביא לדחייה בפיתוח ובהטמעה של תכונות אחרות במוצר ועוד. לכן, לפני שמתחייבים על פרויקט בכזה סדר גודל עדיף לוודא שהמשתמשים באמת רוצים אותו. במקרה כזה, הייתי ממליץ לוולט להטמיע את ההצעה כחלק מחווית המשתמש - כלומר, לגרום למשתמש לעבור את כל התהליך שבו הוא מאשר את ההזמנה, את המחיר ואת פרטי התשלום, ורק ברגע האחרון, כשהוא כבר משוכנע שהנה, הוא מקבל את השירות החדש הזה- להודיע לו בנימוס שכרגע השירות עדיין לא זמין.
למה בכלל לתסכל את המשתמשים שלנו? כי אחרי שנתסכל כמות קטנה יחסית של משתמשים (ותמיד אפשר לפצות אותם באיזו הנחה קטנה על ההזמנה שלהם או משהו כזה), נקבל אינדיקציה מאוד אמינה מהשוק שהמוצר שלנו באמת נדרש. אם ראינו שהמשתמשים כבר קיבלו את החלטת הקנייה, עברו את כל השלבים ולקחו התחייבות לשירות המוצע, אנחנו מבינים שהם באמת רוצים אותו ושווה לנו כארגון (במקרה הזה לוולט) להתחייב לפיתוח שלו.
בזמנו, כשניהלתי את תחום המסחר המכוון בחברת ניקלאודיון בארצות הברית, עשיתי משהו כזה באתר החנות הדיגיטלית שלנו כשהצעתי לרוכשים להוסיף הקדשה אישית מאחת הדמויות של תוכניות ניקלאודיון למתנה שהם רוכשים תמורת עשרה דולר נוספים. התוצאות היו חד משמעיות: כמעט 30% מהרוכשים הוסיפו את השירות הזה. הם אמנם התאכזבו לגלות בהמשך שהשירות עדיין לא קיים, אבל נתנו לי ביטחון רב בכך שמשתלם לפתח את התשתית הנדרשת כדי להציע את השירות הזה, שאכן הושק בערך חצי שנה מאוחר יותר וזכה להצלחה.
במוצר של חברת פיגי - אפליקציית מובייל המאפשרת יצירת והפצה של בלוגים בפורמט ויזואלי דמוי ״סטורי״ - רצינו לבדוק האם מידת ההיענות ליצירה באפליקציה תעלה כשתהליך היצירה מתקצר משמעותית. לשם כך פיתחנו גרסה מאוד ראשונית (ובמידה לא מבוטלת מבוססת על עבודה ידנית מאחורי הקלעים) של ״בוט״ שלוקח שרשורים מטוויטר והופך אותם באופן אוטומטי לפיגיז - כלומר, לסיפורים מרובי עמודים שמותאמים לצריכה במובייל ומעוצבים כמו סטורי ויזואלי יפה, ולא רק כמו צ׳אנקים עוקבים של 280 תווים.
פרסמנו את דבר קיומו של הבוט ופנינו למשתמשי טוויטר רבים בהצעה לתייג את הבוט כדי שהמערכת (וגם כמה עובדים חרוצים שנשארו ערים מסביב לשעון) תייצר עבורם פיגי יפה על בסיס תוכן השרשור שלהם מטוויטר. הרבה אנשים נענו לאתגר ובימים הבאים המערכת יצרה להם פיגי באופן חצי אוטומטי. מה ההיגיון בלהוציא החוצה מוצר שעדיין עאובד בצורה מאוד חלקית, כרוך בתפעול ידני ומגיע לתוצאות בינוניות? ההגיון הוא שההתנסות הזאת הראתה לנו שאנשים אכן מגלים עניין בפיתוח הזה, לקבל שאלות ומשובים שעוזרים לנו לדייק את המוצר העתידי לפני שאנחנו משקיעים בפיתוח שלו וגם לנסות כל מיני אפשרויות, כללי פיתוח, עיצובים וכדומה.
למדנו, למשל, שאנשים היו שמחים שהפיגי המיוצר להם אוטומטית יופיע בחשבון שלהם באפליקציה, כדי שהם יוכלו להוסיף לו ליטושים, עיצובים ואלמנטים נוספים (תמונות, וידאו, אנימציות, ועוד) משלהם. למדנו גם מה מידת הרגישות של משתמשים לחירות האומנותית שהבוט לוקח לעצמו בטיפול בטקסטים שלהם, למדנו שהוספת לינק לשרשור המקורי בטוויטר בעמוד השער של הפיגי שנוצר מגבירה במאות אחוזים את הסיכוי שהצייצן שחיבר את השרשור יחלוק את הפיגי בחשבון הטוויטר שלו ועוד. כל אלה לקחים חשובים שחסכו לנו המון זמן פיתוח ועיכובים מיותרים בהמשך.
המתודולוגיה של Try Before You Build היא מהיתרונות היחסיים של סטארט-אפ. כשעשיתי את זה בזמן עבודתי בניקלאודיון זה אמנם הצליח אבל זכיתי ללא מעט ביקורת על ״הטעיית צרכנים״ בשלב הניסוי, כי בתאגידים גדולים מידת הגמישות לניסויים נמוכה יותר. בסטראט-אפים, המוגבלים במשאבים, אין ברירה אלא להיעזר בקצת חוצפה, יצירתיות, ניסוי וטעייה כדי לחדד מה שווה השקעה ומה רעיון שנשמע טוב אבל עדיין לא בשל להשקיע בו. והיופי כאן הוא שקהילת המשתמשים אינה רק אסופת צרכנים פסיביים, אלא חלק מתהליך גיבוש המוצר והתאמתו לשוק.
שאול אולמרט הוא יזם, מייסד ומנכ"ל פלייבאז לשעבר וממקימי הסטארט-אפ Piggy
