פיתוח מוצר B2C נראה לעיתים פשוט יותר מ-B2B, אבל יש היבטים ייחודיים לעבודה ב-B2C אשר דורשים תשומת לב וגישה שונה. בגדול, צריכים להיות מאוד data-driven ולחשוב על איך התוכנה פותרת דברים באופן סקלבילי. אי אפשר לבנות על מכירות שיובילו להכנסות - זה תפקיד המוצר. אי אפשר להשאיר פערים ולסמוך על שיחות עם משתמשים כדי לגלות מה צריך לתקן.
אני ישי, עבדתי עם יותר מ-10 חברות על יותר מ-20 מוצרים כ-Fractional Chief Product Officer או כעובד חברה בתפקידי Chief Product Officer, Senior Director Portfolio Business Performance, Lead Product Manager. עבדתי על מוצרים משלב קונספט ועד לשלב מוצר באוויר במשך שנים בתחומי משחקי מובייל, פייסבוק, ווב, מרקטפלייס, אפליקציות עיבוד תמונה, פינטק, Subscription, Free to Play וכמובן AI. מבחינת סקייל המוצרים הגדולים הגיעו ל-10 מיליון משתמשים ביום ו-150-250 מיליון דולר בשנה.
הנה עשר טעויות שראיתי על פני חברות גדולות וסטרטאפים בשלבים מוקדמים ומתקדמים:
1. לא מכוונים לשוק גדול מספיק
עשינו מחקר מקומי ומצאנו בעיה אמיתית בשוק שלנו. קדימה לעבודה?
טעות נפוצה היא להניח שזה תקף בכל העולם. או לפחות בעולם המערבי. או בארה"ב.
ב-B2C קהל היעד שונה מאוד בין מדינה למדינה. העדפות תרבותיות. מבנה שוק שונה. העדפה למודל עסקי כזה או אחר ומוכנות לשלם על דברים מסוימים. בתעשיות כמו פינטק או מדטק גם רגולציה יכולה להשפיע על מבנה המוצר ואופן השיווק. מבנה הורטיקל ורמת הסגמנטציה או ריכוזיות בשוק גם לא אחידים.
סטארטאפ בתחום ניהול תקציב אשראי שיכול לעבוד בישראל ודורש בנקאות פתוחה לא יצליח בארה"ב היכן שאין בנקאות פתוחה. באירופה יש בנקאות פתוחה - אך אופן לקיחת האשראי על ידי לקוחות ברוב מדינות אירופה שונה מהשיטה בישראל ובארה"ב.
גרמנים לא אוהבים לשלם על מנוי. סינים אוהבים מנוי לא מתחדש ולבקש החזר. במזרח אירופה מותחים את גבולות השימוש החינמי.
שחקנים במזרח הרחוק מצפים לסגנון עיצובי מסוים ויש להם סובלנות גבוהה לסיבוכיות עקב מוכנות להשקיע בלימוד מערכות מורכבות. הציפיות של שחקנים במערב שונות ודורשות מבנה שונה ודרך לימוד יותר מודרכת.
כל זה מוביל לכך שאפילו אם מצאנו בעיה תקפה במספר מדינות המוצר שיוכל לפתור אותה יהיה שונה. זה יכול להיות שוני עמוק בפונקציונליות או הבדלים תרבותיים שדורשים מסע משתמש אחר, מתן פיצ'רים שונים בחינם או בתשלום או אפילו מודל עסקי אחר.
כשחושבים על סקייל של סטארטאפ B2C צריך לוודא שהתכנית היא באמת גלובלית או מכוונת למדינות גדולות בהן מוצר אחד מסוגל להשיג סקייל והכנסות גבוהים.
לכן מומלץ לחקור את הבעיה והפתרון בשוק הכי גדול קודם ולוודא שמה שמצאנו בשוק קטן תקף לגבי קהל יעד גדול מספיק.
2. מכוונים לשוק הגלובלי אבל משקיעים הרבה זמן בשוק קטן
אחרי שאפיינו מוצר התחלתי שאמור להתאים לשוק הגלובלי צריך להגיע הכי מהר ל PMF. זה אומר שמה שאפיינו בהתחלה הולך להשתנות מאוד, הרבה פעמים, עד שנגיע ל-PMF. מה פותרים, איך פותרים, מה לא פותרים, איך מציגים את הפיצ'רים ואיך הם עובדים, מה בחינם ועל מה לוקחים כסף, מהם דפוסי השימוש ואיך מנתבים את המשתמשים בתוך המוצר כדי לייצר הרגלים. כל אלו יהיו מאוד שונים אם נשווה בין המוצר הראשוני עליו חשבנו למוצר שיעבוד בפועל.
השלב הזה לוקח יותר זמן ממחקר ופיתוח ראשוניים. אם עושים את זה בשוק קטן בו נגיד ונוח לנו ואנחנו מרגישים בבית, אנחנו עשויים לשנות את המוצר עבור אותו שוק קטן באופן שאיננו מועיל להשגת PMF בשוק הגלובלי או בשוק האמריקאי. הסקייל של המוצר רק בשוק קטן לרוב לא מספיק כדי להעמיד את הסטרטאפ על הרגליים ולאפשר לו להתרחב גלובלית ללא גיוס כסף נוסף.
הזמן שדרוש לנו להבנת המשתמשים בשוק האמריקאי והתאמת המוצר אליהם לא מתקצר בגלל שהצלחנו בשוק אחר. בצוותים רבים הוא אפילו מתארך כי אנחנו חושבים שאנחנו יודעים דברים שלא בהכרח נכונים לשוק אליו אנו בונים עכשיו ואנחנו כצוות למעשה פיתחנו התנגדות ראשונית לתהליך הכי חשוב שאנחנו צריכים לבצע כעת – למידה. הסבלנות הארגונית וזו של המשקיעים גם כן מועמדים למבחן כי אחרי שבילינו חודשים ארוכים ואולי אפילו שנים בהשגת PMF בשוק הקטן, אנחנו שוב בשלב ה-PMF במקום להתקדם לשלב ה-Growth.
רבים חושבים שמספיק לתרגם כדי להיכנס למדינה חדשה. אבל אפילו אם השפה היא באמת החסם היחיד צריך לעשות culturalization, שזה לתרגם תוך לקיחת ההקשר המוצרי והתרבותי בחשבון. זה כולל לעיתים גם שינוי במודל העסקי. התימחור דורש התאמות. במדינות רבות תרגום לשפה המקומית אפילו לא שיפר את התוצאות לעומת הגרסה האנגלית!
מה עושים?
אם אנחנו בונים מוצר גלובלי שאיננו מרקטפלייס, אפשר להתחיל במספר מדינות מפתח או להתחיל גלובלי. רוב הסיכויים שנראה פערים בהתנהגות משתמשים וב-KPIs בין מדינות שונות, וזה בסדר: קובעים מדינה או קבוצת מדינות שהן מדינות היעד (ארה"ב, מדינות דוברות אנגלית, מערב אירופה) ומתייחסים לנתונים שלהן כדי לקבל החלטות.
אם אנחנו בונים מרקטפלייס בו המיקום משנה אז להתחיל גלובלית לא מומלץ כי מילוי שני צידי הביקוש וההיצע במיקומים רבים יהיה מאתגר. במצב זה צריך להתחיל באזור גאוגרפי שדומה לעוד הרבה אזורים גאוגרפיים מבחינת המאפיינים הרלוונטיים למוצר. אז ברור שברירת המחדל צריכה להיות שוק היעד הכי גדול, שזה ארה"ב, כדי שלאחר כיבוש עיר אחת אפשר יהיה לעבור להבאה בתור בשינויים מוצריים מינימליים.
מתי חורגים מברירת המחדל? כשארה"ב איננה שוק יעד בכלל או המקום בו ההזדמנות היא הכי קטנה בהשוואה למדינות אחרות. ואז צריך להתחיל במדינה בה ההזדמנות היא הכי גדולה.
מרגישים בנוח לפתח ולהתאים לשוק הישראלי כי אנחנו במילא פה ומכירים ומבינים? זה מקרה בו צריך להתחיל בבעיה הכי קשה וחשובה לפיצוח - תתחילו עם השוק שאתם לא מבינים כשיש לכם כסף ואנרגיה.
חוששים מעלויות המרקטינג בארה"ב? הבעיה הזו לא תיעלם והיכולת שלכם להתמודד איתה לא תשתפר בלי שתתחילו להתמודד איתה.
חוששים לשרוף את השוק לפני שהמוצר בשל? אל דאגה, מוצר טוב לא שורף שוק ומוצר גרוע לא מגיע למספיק אנשים כדי לשרוף את השוק. Word of Mouth עובד על מוצרים נהדרים, לא על גרועים.
3. נותנים לנתונים במספרים קטנים לבלבל אותנו
ה-KPIs שאנחנו רואים בשלבים מוקדמים הם משהו שיש לקחת with a grain of salt. במשחקים למשל, חלק מהמספרים שרואים בשלבים מוקדמים יכולים להיות פי 2 או 3 גדולים או קטנים כשמגיעים לסקייל גלובלי. מוצר אחד שעבדתי עליו התחיל 70% מתחת ליעדים שהצבתי וכשיצאנו גלובלית הנתונים השתפרו פי 3 כלפי מעלה. יש מוצרים שהיו חלשים וכשעלו בסקייל נעשו גרועים יותר.
למה זה קורה? כי כל עוד עובדים במספרים קטנים, אפילו אלפים בודדים, מדובר בדגימה מוטית של קהל היעד. האנשים שהבאנו או הגיעו למוצר שלנו יכולים להיות מאוד מעוניינים או בכלל לא. אנשים גם מבינים באיזה שלב המוצר נמצא ומתנהגים בהתאם. איכות מוצר נמוכה, נוכחות שיווקית לא מקצועית, שירות לקוחות ירוד - משתמשים קולטים הכל ורמת המחוייבות שלהם למוצר היא בהתאם בשילוב עם רמת הצורך. אם מדובר במוצר שפותר צורך גדול וכואב בשוק ללא פתרונות חלופיים - משתמשים סלחנים יותר לפשרות ונרתמים להצלחת המוצר.
אז מה עושים?
מוודאים איזה משתמשים הבאנו מבחינת השתייכות לקהל היעד ורמת מחוייבות, בייחוד כשמסתמכים על מקורות לא אורגניים למשתמשים. בשלב הראשוני נתמקד ביצירת ערך למשתמשים שרוצים את המוצר וננסה להגיע לכאלה באחוזים גבוהים. לאחר שהוכחנו ערך ומדדנו KPIs טובים עבורם ב-retention, Key action performance וגם conversion ומונטיזציה ככל האפשר - אז נעבור להתמודד עם משתמשים פחות מחוייבים כדי לאפשר סקייל גדול יותר.
נשאף להגיע למוצר שמאפשר סקייל ולהגיע לסקייל מהר ככל האפשר. ההיתכנות שאנחנו מאפטמים לקהל יעד מצומצם מדי או שונה מדי תמיד קיימת כל עוד לא התרחבנו. עד שנגיע לשלב הזה נתייחס למספרים בעירבון מוגבל ונקבל החלטות על בסיס מה יוצר תוצאות טובות יותר. נשמור פיצ'רים שמעלים retention גם אם המספר לא בדיוק מה שרצינו, כי יכול מאוד להיות שממילא הוא יהיה גדול או קטן יותר כשנגיע לסקייל רציני. ויש סיכוי שהחלטות נכונות בשלבים מוקדמים יצטרכו להיבחן מחדש כשנגיע לסקייל וזה בסדר.
4. משקיעים יותר מדי בקוסמטיקה לפני שהעיקר שם
עקרונות ה-MVP או MLP עומדים בעינם. גם ובייחוד עכשיו שנעשה קל ומהיר יותר לפתח, עדיף לנצל את הפרודקטיביות הזאת על מה שחשוב. ומה שחשוב זה לייצר ערך למשתמשים ולכן נתמקד בהבאת המשתמשים האלה ל-aha moment, וכל דבר אחר לא חשוב וברוב המקרים מיותר.
עיצוב גרסה שלישית של סט הצבעים של ה-UI? מיותר אלא אם לא ניתן לקרוא או להבין את האייקונים והטקסט.
פרופיל משתמש? מיותר במוצרים בהם הוא לא לב המוצר. בדייטינג - כנראה חשוב. במוצר בו אפשר להסתפק בתפריט הגדרות בסיסי - מיותר.
Infrastructure לעבודה מושלמת בכל סוגי הדפדפנים לפני שהוכחנו שמשתמשי כרום מתים על המוצר? מיותר.
יכולת שמירת נתונים על פני מכשירים רבים? מיותר כאשר ניתן להוכיח את מתן הערך העיקרי למשתמש בלי התשתית הזאת. חיוני כאשר מפתחים מתחרה לדרופבוקס.
אנליטיקס שמראים לנו איך המשתמשים השתמשו ב-UX ובאיזה פיצ'רים הם השתמשו? ממש לא מיותר! במקרה קיצוני אחד מוצר עלה לאוויר וייצר הכנסות גבוהות מאוד. חודש לאחר מכן הייתה ירידה בביצועים וכשנשאלו מה הסיבה לכך האנליסטים נאלצו להגיד שהם לא יודעים כלום, כי בפיתוח הורידו בתיעדוף את הכנסת ה-analytics hooks למוצר. עד שהכניסו אותם כמובן שהיה מאוחר מדי כי רמת ההכנסות ירדה וחלק גדול מאוד מהמשתמשים עזב את המוצר.
5. משקיעים בברנדינג מוקדם מדי
אין הרבה מה להרחיב כאן. לפני שהמוצר בסקייל, לא בטוח בכלל שהברנד שאתם חושבים עליו תואם למוצר אליו תגיעו. השקעה כספית גדולה בברנדינג גם לרוב מתקשה להדגים ROI כך שזה באמת לעשירים.
6. משקיעים יותר מדי זמן בפיתוח לפני שההיפותיזה נבחנת מול משתמשים אמיתיים
המטרה היא לספק ערך למשתמשים. אין ערך בלי משתמשים. עשינו מחקר. אפיינו מוצר. אין דרך מסביב לזה – הכל היפותיזה עד שזה פוגש משתמשים אמיתיים. וזה רגע מאיים קצת, כי אז מתחילים להגיע מספרים. והמספרים לא בהכרח יהיו טובים. לרוב הם די גרועים. המספרים נותנים ודאות מזוייפת כפי שהסברתי, יש להתייחס אליהם בחשדנות, אבל בכל זאת צריך להסתכל עליהם. וזה נעשה גרוע יותר כי יש משקיעים שיימנעו מלהשקיע בגלל המספרים אבל בלי מספרים אולי הם היו משקיעים.
ב-B2C המטרה היא להגיע ל-PMF. יש שמגדירים PMF כ-retention ויש שמגדירים כ-ROAS חיובי ברמה כלשהי. אין הגדרת PMF שלא כוללת מוצר באוויר עם משתמשים מקהל היעד. ולכן בהתאם לכללי התיעדוף של ערך למשתמשים קודם – ברגע שניתן לספק להם ערך – צריך להעלות את המוצר ולהתחיל לבדוק את ההיפותיזה שלנו. עדיף להתמודד עם קשיים, טעויות ומאות איטרציות כשיש כסף ואנרגיה מאשר כשמנסים לגייס את הסיבוב הבא ולחוצים בזמן.
כלל אצבע? בייחוד היום עם יכולות הפיתוח המואצות בזכות AI, שישה חודשים זה המקסימום של המקסימום שהייתי מפתח בלי להעלות מוצר לאוויר או לפחות לבדוק גרסאות מוקדמות מול משתמשים. מתי חורגים מכך? כשמדובר במוצר שדורש פיתוח ממושך כדי ליישר קו עם מתחרים בשוק בוגר. גם במקרה זה - אמור להיות לנו Unique Value Proposition והייתי שואף לבחון אותו מול משתמשים בהקדם.
7. מבלבלים פידבק איכותני מילולי עם נתונים
ב-B2C, בדומה ל-B2B, צריך לדבר עם משתמשים. סקרים, קבוצות מיקוד, שיחות ישירות. צריך לוודא את הבעיה אותה אנו פותרים, להבין איך משתמשים חושבים על הבעיה ואיזה פתרונות אלטרנטיבים עומדים לרשותם. לראות איך הם משתמשים במוצר שלנו ומה עובד או לא עובד להם.
לשאול שאלות היפותטיות לגבי מה הם היו עושים או אם הם היו מוכנים לשלם או כמה זה פחות אפקטיבי. בהקשר זה כדאי לקרוא את הספר The Mom Test של Rob Fitzpatrick.
ב-B2C התוצר משיחות כאלה עם משתמשים הוא היפותיזות חדשות לנסות, לא החלטות. כי ב-B2C מה שקובע הוא מה מאות אלפי ומיליוני משתמשים עושים בפועל עם המוצר שלנו.
מה עושים? משתמשים במידע ממשתמשים כדי למצוא דברים חדשים לנסות, ממדלים איך הדברים האלה עשויים להשפיע על המוצר, מתעדפים ואז מפתחים ומודדים איך הדברים האלה משפיעים על ה-KPIs בפועל.
מעלים Scale באמצעות User Acquisition מוקדם מדי
טעות נפוצה היא להסתכל על ROAS ולנסות להגדיל את ה-UA Spend לפני שהגענו לביצועים טובים מבחינת שימוש במוצר ו-retention.
הסיכון הגדול הוא שנעלה סקייל לפני שהמוצר באמת ברמת ביצועים הולמת, דבר שעשוי לקרות כשאנחנו מבססים את ההחלטה על מידע חלקי. אם העלינו סקייל באופן משמעותי לפני שהמוצר מספק ערך באופן עקבי לאורך זמן למשתמשים אנו עלולים לגלות שהמשתמשים ששילמנו להביא למוצר לא נשארים לאורך זמן, שה-ROAS לא חיובי כבר ושבעצם יש עוד הרבה עבודת מוצר לפנינו כדי לשמר משתמשים לאורך זמן.
בנוסף, כשמגיעים לסקייל גדול של המוצר הרבה דברים משתנים. האופרציה מתחילה לכלול כמות משמעותית של support. ביקורות משתמשים מתרבות. התשתית צריכה להיות יציבה ומהירה. כל באג עולה כסף ותהליך הפיתוח צריך לעלות ברמה בהתאם. כל פיצ'ר חדש עשוי לפגוע בביצועים של המוצר ובביצועי קמפיין שמוציאים עליו הרבה כסף וכך כל הארגון מתחיל להיות חששן ואיטי יותר כי כל נגיעה יכולה לעלות הרבה כסף.
ראיתם ROAS חיובי על בסיס prediction? מומלץ לוודא שה-retention ומדדי השימוש במוצר תומכים בתחזית ה-LTV הזאת. כדאי לחכות עד שלפחות קצת נתוני אמת ייאספו כדי לחזק את הביטחון ב-prediction.
בינתיים אפשר לקצר את חלון ה-payback כדי להשתמש בנתוני אמת וכך להקטין את הסיכון שהכסף לא יוחזר.
9. מתמכרים ל-A/B testing
A/B testing הוא כלי מאוד שימושי וחשוב ב-B2C. הוא מאפשר להגיע למסקנות חד משמעיות לגבי מה השינוי שעשינו למוצר השיג מבחינת התנהגות משתמשים וביצועי המוצר.
מדובר באנליזה סטנדרטית ועקבית, עם פחות מקום לשיקול דעת כך שהביטחון בתוצאות מ-a/b test גבוה יותר.
מדובר בהשוואה לגבי תוכן הניסוי בלבד, כך ששינויים אחרים וחיצוניים מנוטרלים או מפוזרים בשווה בין קבוצות הניסוי. זה תקף לרוב הדברים שנרצה לבדוק למעט סוגי מוצרים ומקרים בהם a/b test לא ישים, כגון פיצ'רים ויראליים ופיצ'רים מערכתיים במרקטפלייס או באינטראקציות משתמשים אחד מול אחד או PvP.
לא תמיד a/b test הוא הפתרון העדיף:
a/b test לוקח זמן ולצורך הרצת כל הניסויים שהיינו רוצים צריך הרבה מאוד משתמשים והרבה מאוד זמן וגם יש סיבוכיות פיתוחית וב-QA ככל שמספר הניסויים גדל. אז צריך לתעדף את מה שחשוב, שינויים גדולים שמשפיעים על הערך שהמשתמש מקבל, פיצ'רים חדשים, נקודת המעבר ממוצר חינמי לבתשלום, תימחור.
לעומת זאת יש קטגוריה שלמה של דברים שבשלבים מוקדמים ולעיתים גם מאוחרים, לא שווה להשקיע a/b test עליהם: שינויי UI קטנים או שינויי UI בניסויים נפרדים, שינויים שאין דרך להימנע מהם כמו שינוי UI שמאפשר הוספת components חדשים ונחוצים או שינויים עקב רגולציה.
שינויים שלא מסוגלים להשפיע משמעותית על ה-KPIs גם אין טעם לבדוק ב-a/b test. הדבר החשוב להבין בשלבים מוקדמים הוא שאם משהו לא יכול להשפיע על התוצאות ולכן אין טעם להריץ אותו כניסוי, ברוב המקרים - גם לא כדאי להתעסק בלפתח אותו בכלל. המיקוד שלנו צריך להיות במה שכן יזיז את הנתונים.
באופן כללי, כשמספר המשתמשים קטן לעשות a/b test לוקח יותר זמן מאשר להוציא את השינוי לאוויר ולמדוד את ההשפעה. מומלץ לשחרר לאוויר רק דבר אחד עיקרי כל פעם כדי שנוכל לבסס את הקשר בין השינוי בנתונים לבין מה שעשינו.
והנה הקאצ'. תנודתיות הנתונים שנראה במוצר בשלבים מוקדמים תהיה גבוהה, מה שמקשה על מדידה של שינוי שקטן מהתנודתיות ללא שימוש ב-a/b test. אז גם אם יקח פחות זמן לראות את האפקט, במקרים רבים לא נצליח לראות אותו בכלל ולא נקבל תשובה לשאלה האם מה שאנחנו עושים עוזר למוצר. הגישה שאני ממליץ עליה בשלבים כאלה היא לקבל שתי החלטות:
נתעדף לנסות רק מה שיכול להשפיע באופן משמעותי על התוצאות. אם התנודתיות היא פלוס-מינוס 4%, אנחנו צריכים להתמקד בלהוציא דברים למוצר שיש להם פוטנציאל של לפחות 30% שיפור. כל דבר קטן יותר פשוט לא צריך לקבל תשומת לב בשלב בו אנחנו קטנים.
אם לא ראינו שיפור ברור - נתנהג כאילו מה שעשינו לא הצליח ונשאיר במוצר רק שינויים שהצליחו להראות שיפור ברור.
גישה זו מתמרצת את הצוות לחשוב בגדול, לחשוב על המשתמשים ולהיות כנים עם עצמנו. תהליך הלמידה מניסוי לניסוי יוביל להצלחה.
10. נותנים למלכוד 22 לעצור אותנו
ב-B2C טרקשן נמדד ב-KPIs, מה שמוביל למלכוד בשלבים מוקדמים: מצד אחד אנחנו אולי יכולים לגייס הון לפני שיש מוצר ו-KPIs להסתכל עליהם. מצד שני התקדמות אמיתית לא יכולה לקרות ללא עלייה לאוויר, מדידת תוצאות ותחילת התהליך לשיפורן. לפעמים עדיף לגייס הון על בסיס החזון ולא להגיע לנתונים כדי לא להישפט על פיהם במידה והם לא מזהירים מההתחלה.
המלכוד מתחיל כשאנחנו מעכבים את התקדמות המוצר ומדידת תוצאות כדי לא לגייס על בסיס נתונים. תמיד אפשר למצוא סיפור משכנע שמסביר למה עוד לא עלינו לאוויר, אבל האמת היא שמשקיעי B2C במקרים רבים ממילא ירצו לראות נתונים ובמקרה הטוב הם גם יגידו את זה בבירור. משקיעי B2C טובים ידעו להתייחס לנתונים מוקדמים בעירבון מוגבל.
מה עושים? קובעים תכנית עבודה עם יעדים ולו"ז. קובעים זמן מקסימלי שגיוס פוטנציאלי יכול להוות סיבה לעיכוב ביישום התכנית וכשהזמן הזה חולף - מפסיקים לחכות לגיוס וממשיכים בעבודה.
קריאת הבלוג 
האזנה לפרק 
צפייה בוידאו 
תשאלו אותנו הכל
