BLISSe
“טיקטוק לבילויים”: סרטונים קצרים של ברים, מסעדות ומסיבות, עם המלצות אישיות או לקבוצה. הקמתי, חקרתי, עיצבתי, ועצרתי.
הבעיה
- יותר מדי אפשרויות, ומידע מפוזר בין פלטפורמות ולא מעודכן
- גם כשבוחרים, המקום לא תמיד מתאים לאווירה, למוזיקה או לאוכל
- חוסר אמון בביקורות, שחלקן מזויפות
- FOMO: הפחד לפספס את המקום הנכון
| זיהו ביקורות מזויפות | |
|---|---|
| אומרים שביקורות מזויפות פוגעות באמון |
נתוני רקע מהמחקר, לא מהסקר שלי. מקור: BrightLocal 2022.
מה עשיתי
- משתתפים בסקר
- 150
- מתחרים שמופו
- 14
- אתר ואב-טיפוס ב-Figma
- MVP
- מחקרסקר, ראיונות ומיפוי של 14 מתחרים, בהם Ontopo, Tabit, Eventbrite, Fever ו-Yelp
- אפיון ועיצובוויירפריימים ואפיון מלא, עיצוב ב-Figma ואב-טיפוס שנבדק מול משתמשים
- MVPאתר שנבנה בכלי GenAI. מיקוד בחיי לילה בלבד: מסיבות, ברים ומסעדות
- צוותגיוס יועצים וראיונות עם שותפים טכניים פוטנציאליים
מודל עסקי
עד 50 אלף משתמשים: עמלה של 3% עד 10% על עסקאות, ומערכת הזמנות לעסקים ב-39 או 89 דולר בחודש. מעל 50 אלף: חבילות לעסקים ב-39, 199 ו-399 דולר.
המוצר
| מסך | מה המשתמש רואה | מה הוא בודק |
|---|---|---|
| Onboarding | בחירת מוזיקה, אוכל, קהל, מצב רוח וסגנון בילוי | האם אנשים מוכנים להגדיר העדפות |
| Video-first Feed | סרטון של המקום לפני פרטי הטקסט | האם “להרגיש את האווירה” מקצר החלטה |
| Match Score | התאמה של מקום לאדם או לקבוצה | האם ציון אישי משפר רלוונטיות |
| For Me / For Group | העדפות אישיות לעומת בחירה קבוצתית | האם זה מוריד חיכוך בין חברים |
| Saved / Shared List | שמירת חלופות ושליחתן לחברים | האם ההחלטה הופכת לתוכנית |
| Business View | הצגת המקום לקהל רלוונטי ומדדי עניין | הצעת הערך לצד ההיצע |
| קטגוריה | דוגמאות | ההשערה של BLISSe |
|---|---|---|
| מפות וביקורות | Google Maps, Tripadvisor | דירוג לפי התאמה לערב, לא לפי מספר |
| וידאו והשראה | Instagram, TikTok | Discovery שבנוי ל“לאן לצאת” |
| אירועים וכרטיסים | DICE, Resident Advisor, Fever | החלטה רחבה יותר על מקום וקבוצה |
| קבוצת חברים | WhatsApp, Google Search | החלטה משותפת במוצר אחד |
את אתר המוצר והדמו אפשר לראות כאן: blisse-app.com · app.blisse-app.com. זה דמו של המחקר, לא מוצר מסחרי שהגיע להיקפים מאומתים.
ההחלטה
הבעיה של המשתמשים הייתה אמיתית. אבל בעלי העסקים, הלקוחות המשלמים, לא הראו נכונות לשלם.
במוצר דו-צדדי, מי שסובל מהבעיה הוא לא בהכרח מי שמשלם. זה היה הסיכון המרכזי, ולצידו שירות מילואים ממושך והקושי למצוא שותף טכני. החלטתי לעצור לפני שהשקעתי בפיתוח מלא. הלקח הזה, לבדוק את המשלם ולא רק את המשתמש, הוא היום השאלה הראשונה בכל רעיון שאני בודק.