Я днями познайомився з дуже цікавою підприємицею.

В 2007 вона переїхала в Азію, жити життя діджитал-номада. Знайшла роботу в діджитал маркетингу на джоб борді для експатів.

Компанія, до якої вона долучилась, мала одного співробітника і робила 120к обороту на місяць при 60к чистого профіту.

З однии нюансом - це був ecommerce, який продавав модафініл американцям (рецептурний препарат, що покращує фокус).

Схема працювала, як дропшипінг:

1. Вони мали асистента в Індії, який купував модафініл в аптеці
2. Приймали платежі в крипті
3. Асистент слав препарат в Штати

В якийсь момент її босу почали погрожувати якісь чуваки, які робили схожий бізнес з росії.

Тоді вони вперше взяли консультацію юриста і зрозуміли, що те, що вони роблять, не зовсім легально.

Тому вони вирішили просто переїхати у В‘єтнам, бо звідти не екстрадують.

Тільки тоді вона вирішила звільнитися, зрозумівши, що ризик того точно не вартий.

Намагаюсь вмовити її на подкаст :)

Якщо ви будуєте маркетплейс в 2024, то подумайте, чи можете не тільки зробити дистрибуцію, але й “закрити” на собі supply частину.

Насправді, зовсім небагато маркетплейсів роблять це кльово і елегантно, і не в будь-якій ніші це можливо. Але ось два хороших приклади, де маркетплейс робить і дистрибуцію (лідген) для саплаю, і софт для них же, значно збільшуючи цінність платформи.

- Lottie - це AirBnB для будинків для стареньких, що не можуть жити самі. Вони зробили лідген бізнес для цих установ, але також роблять CRM-ку, яку supply частина може використовувати, таким чином закриваючи їх на собі. Чого йти на іншу платформу, якщо тут і ліди, і робота з лідами?

- Booksy - зробили сервіс для бронювання послуг краси, а з іншого боку - маркетплейс для букінгу подібних послуг. Таким чином supply користується не тільки сервісами для букінгу, але й отримує бізнес з маркетплейсу.

Мабуть є ще приклади, але з того, що я розумію зараз, єдиний варіант рейзити під маркетплейс в 2024 - це мати розуміння проблеми supply до рівня, коли ви можете їм давати не тільки лідів, але й додаткову цінність.

Діма Расновський з Glovo - мій улюблений співрозмовник по всьому, що стосується маркетплейсів. Діма запускав Glovo в Україні, а зараз скейлить їх бізнес у Африці.

В новому випуску Product&Growth Show Діма розказав купу цікавих речей.

- Маркетплейси додають рекламу на свої платформи, щоб зробит сервіс дешевшим для користувачів. В Instacart 15% від GMV генериться бренд рекламою, в Glovo це 2-3%.

- В рамках доставки їжі, наразі користувачі готові чекати довше у випадку, якщо це дешевше. У людей стало менше грошей, тому вони пріоритезують їх збереження.

- В розвинених економіках ми маємо до 5 поколінь людей, що живуть одночасно. Кожне з цих поколінь має свої потреби і це можливість для нішування. Це одна з причин, чому будувати суперепи стало складніше - все важче і важче створювати рішення, які підходять кожному користувачу.

Слухати, як завжди, можна тут:
- Apple Podcasts
- Soundcloud
- YouTube
- Spotify

P.S. Не забудьте написати рев’ю, якщо вам сподобалось! 🙂

Кому цікава тема, послухайте ще оцей подкаст - не тільки про Swift, але багато про те, як за допомогою цієї мережі північнокорейські хакери майже вкрали 1 мільярд доларів у уряду Бангладешу.

Слухати на Spotify.

Коротке інтро у світ Swift і що спільного між банками та соціальними мережами

Цікаво, що пости про Swift у мене в каналі набирають найбільше залучення, хоча, як на мене, це доволі суха технічна тема для людей, що працюють з пейаутами.

В двох словах, Swift - це такий дуже секьюрний імейл для банків, що має шаблони повідомлень (інструкції) з певним переліком полів. Є один тип в якому взагалі шлеться plain text і очікується, що банк, який отримує повідомлення, щось на основі цієї інструкції зробить.

З цікавого, Swift може використовуватись замість API для інтеграцій між декількома установами - якщо ти можеш інструктувати банк повідомленням, то чим це гірше, ніж через API?

У світі Swift стосунки між банками - це граф. Як у фільмі «Соціальна мережа» де вперше показали концепт графу за‘язків між друзями, де одна людина мала стосунки з багатьма.

Так і в Swift: банк А може виплатити гроші в банк С використовуючи банки B1, B2 та B3. Бувають також випадки, коли банк С має рахунок в банку А і навпаки, тоді виникає так званий book transfer, коли гроші рухаються миттєво, але це не означає, що виплата теж відбувається миттєво.

Найпростіше думати про Swift платежі, як про перельоти між країнами. Наприклад, коли летиш з Таліну в Будапешт, то треба зробити пересадку в Варшаві. Кожен платіж має свій itinerary аеропортів через які він пройде.

Кожен з цих банків може мати різні фічі - процесинг відкритий на вихідних, більш автоматизований fin crime процес, дешевші комісії. Але найскладніше це те, що всі ці банки можуть бути в різних таймзонах.

Фінансова установа, що відправляє Swift пейаут повинна заповнити itinerary- банки-кореспонденти, через які платіж має пройти.

Розуміючи фічі кожного банку ти можеш сам вирішити, що для тебе важливіше - виплатити швидше, виплатити дешевше, чи можливо щось третє.

Навчіться розказувати про ваш скоуп однією картинкою і одним словомЯ помітив, що побудова бренду ваших внутрішніх розробок мабуть не менш важлива, ніж бренд для зовнішніх продуктів. Особливо, якщо вас вже більше однієї команди. І чим більша компанія, тим це важливіша.

Останній скоуп, з яким я працював в Wise був Swift - по суті, доларові пейаути на рахунки поза Штатами. Звучить просто, але під капотом там купа різних інтеграцій (наприклад, якщо ви платите долари з Wise в Україну фіз особі з рахунком в приватбанку, то виплата прилетить за секунди, а якщо платите фіз особі з рахунком в монобанку, то це може зайняти від 12 годин до днів), декілька machine learning моделей, один граф і таке інше.

Сформувати бачення для такого скоупу було складно, але воно крутилось навколо швидкості пейауту, ціни пейауту та ефективності маршруту пейауту.

Майже рік я намагався знайти форму, в якій я міг би просто пояснити всім іншим, в чому особливість скоупу і яка кінцева мета. Документи, роадмеп і тд не особливо працювали без додаткового пояснення.

Тоді я зрозумів, що бачення команди має бути скомуніковане однією картинкою і одним словом.

Залишилось це якось зробити.

Я намалював дуже просто блоксхему нашої системи і показав, як те, що ми будуємо зараз доповнить те, що ми вже побудували, показавши цільові метрики кожного блоку системи.

Після цього, я зібрав команду інженерів і ми придумали назву Pathfinder, яка інтуітивно вказує всім на те, що наша система робить - шукає найбільш оптимальний маршрут для пейауту, враховуючи інфру, обмеження та данні по попередніи платежам.

Після цього я поїхав у відпустку. Повернувшись, я був вражений фідбеком - всі зрозуміли наші плани, Pathfinder став брендом і за декілька тижнів нас запросили розказати про проект всій компанії.

Ми не змінили нічого в скоупі, метриках чи роадмапі. Все, що ми зробили - навчились пояснювати наш складний технічний скоуп однією картинкою і одним словом.

У будь-якій незрозумілій ситуації - пиши все, що в тебе в голові
У кожного продакта/підприємця в житті буває ситуація, коли потрібно зрозуміти, над чим працювати далі, але в голові немає чіткості.

Замість того, щоб шукати черговий фреймворк - ось вам мій інструмент:
1. Відкрийте новий документ
2. Напишіть все, що ви знаєте про свій продукт.
3. Поки ви будете писати, ви зрозумієте, де в вашій історії є сліпі зони, неточності або просто нестаток впевненості.
4. Оформіть цей документ таким чином, щоб його могли читати і інші люди
5. З цього моменту - це ваша біблія. Відправляйте цей документ людям перед зустріччю і просіть прочитати, щоб бути на одній хвилі.

Скоріше за все, на це піде багато часу. Одного разу в Wise мені довелося написати документ на 29 сторінок, щоб в себе в голові структурувати проблему.

Зате потім у мене завжди було місце, куди відправити людину, якщо є "одне маленьке технічне питання".

Три кар'єрні поради, про які ви мене не просили:

1. Якщо ви хочете працювати у великих продуктових компаніях на розвинутих ринках, уникайте позицій, де ви "оптимізовуєте воронку" заради оптимізації воронки чи "підвищуєте залучення" заради залучення. Такий досвід складно продавати - він не показує як ви знаходите проблеми, пріоритезуєте та вирішуєте їх, а це є одним з ключових навиків, за який вас наймають.

2. Намагайтеся не працювати над проблемами, які ви не розумієте, як продати наступному роботодавцю. Коли ви починаєте вирішення нової проблеми ви маєте уявити, як ви опишете результати її вирішення у себе в резюме. Ви маєте бути готовими пояснити з чого ви вибирали і яким чином.

3. Коли проходите інтерв'ю на продуктову позицію в компанію, яка вирішує реальну проблему, то фокусуйтесь на проблемі, яку ви вирішували і на тому, як ви будували conviction, що цю проблему треба вирішити, а не на тактичних кроках. Тактика мало цікава, conviction - дуже.

Не так давно я мав нагоду проінтерв'ювати достатньо досвідченого продакта з move-to-earn ніші (StepN, Sweatcoin etc). На папері в кандидата був чудовий досвід, в реальності - він не міг пояснити, яку проблему вирішував їх продукт. Звісно, скоріше за все він був би чудовим кандидатом для своєї ніші, але компаній в цій ніші не так багато. А тих, в яких хочеться працювати, ще менше.

Це не означає, що його досвід менш цінний. Він просто цінний в іншому контекст, в компанії іншого типу.

Нещодавно допомагав одному стартапу найняти свого першого продакта.

Зробив для них шпаргалку з запитаннями, які треба задати перед наймом. Ці питання дозволять кристалізувати хто конкретно потрібен.

Можливо, вам теж допоможе.

- Яка основна метрика бізнесу?
- Яка основна проблема бізнесу зараз?
- Що ви робите в продукті зараз, щоб вирішити цю проблему? Як це працює?
- Як працює розробка продукту зараз?
- Які з цим проблеми?
- Як ми будемо знати, що проблема вирішена?
- Які конкретні задачі буде виконувати співробітник?
- Яку інформацію ви хочете отримати в резюме кандидата?
- Які результати роботи кандидата відповідають вакансії?
- Які навики мають бути в цільового кандидата?
- Які характеристики мають бути в цільового кандадата?
- Сформуйте цілі для кандидата на перші три місяця його роботи.