На что мы с Адой смотрим? Только неправильные ответы ⤵️

Who's your папка?🍆

Я тут продвигаю свой канал и вписался в папку со всякими полезностями про и для стартаперов. Комьюнити классное, делятся своим опытом, кейсами и мыслями о том, как развивать бизнес. Каналы про все: от создания и запуска до роста и закрытия. Так что подписывайтесь на всех сразу и набирайтесь бизнес-знаний.🤦‍♂️

ХУК: МИФЫ про DATA SCIENCE, КОТОРЫЕ ВРЕДНЫ ДЛЯ БИЗНЕСА И ПРОСТО ТУПЫЕ

❎ Миф 1: Data Science нужен только дата-компаниям (у которых основной продукт — что-то из ML или data-платформ) 🧑‍💻
Это неправда. Почти каждая продуктовая компания нуждается в Data Science. Примеры? Пожалуйста:
🔴Рекомендательные системы на маркетплейсах и в контент-приложениях: если бы рекомендательные системы в Tinder не были хорошими, у вас бы не было удачных мэтчей. А если бы они не были отличными, то мэтчи были бы слишком удачными, вы бы уже давно нашли любовь всей своей жизни и перестали бы платить за подписку.
🔴Пуш-уведомления, которые смотрят вам в душу: если в основе пушей, которые конкретно вы получаете в конкретное время, нет хорошей Data Science, вы их мьютите. Если есть — вы на них кликаете.
🔴Churn prediction (прогнозирование оттока юзеров, извините, я билингв): не добраться вам до уровня 4385712 в Candy Crush без помощи дата-отдела.

❎ Миф 2: Data Science — это сложные модели 🧬
Нейросети и Generative AI сейчас у всех на слуху, но для большинства бизнес-задач они не нужны. Забивать гвозди микроскопом — интересное, но бесполезное и дорогое занятие.

❎ Миф 3: Нужен PhD 🧑‍🎓
Если ваша цель — оффер от DeepMind или OpenAI — да, возможно. Но в большинстве компаний опыт и продуктовый подход должны бы цениться ценятся больше, чем диплом. Сегодня важны не академические знания, а умение решать задачи бизнеса.

❎ Миф 4: Проекты долгие 👨‍🦳
В Data Science как науке — да, можно ждать месяцами, а то и годами. Но в бизнесе Data Science работает быстро: разработать решение с нуля до прода иногда можно и за несколько недель, а если у вас железные яйца достаточно кофе — то за несколько дней.

❎ Миф 5: Это дорого 🤑
Построить внутренний дата-отдел — и правда задача, которая ударит по ресурсам компании и особенно по сердцу вашего CFO. Но есть много разных облачных решений и других способов сэкономить — о них мы поговорим как-нибудь потом, когда я решу заняться саморекламой.

Ну и в чем я не прав?

Недавно был на подкасте, рассказывал очевидные вещи, про которые все любят забывать 😡

ХУК: Как завалить стартап?

Очень просто — нанять не тех людей на ключевые позиции. Вот мои красные флаги, сшитые из потерянных денег, времени и желания жить:

🚩 На просьбу рассказать о себе, они перечисляют только свои технические навыки.
Вы нанимаете человека, а не библиотеку Python. И уж точно не 10-страничное резюме с красивыми словами. Вайбы, конечно, не самое важное в сотруднике, но этот вопрос —проверка на софт-скиллы и общее умение складывать слова в предложения.

🚩 Они никогда не упоминают бизнес-контекст или его влияние.
Напоминаю, что плохие дата-саентисты просто пишут код. Хорошие — пишут код, который решает задачи вашего бизнеса.

🚩 Разговаривают модными словами, не релевантными вопросу.
Спорим, что дата-решение для вашего бизнеса не требует создания ИИ-NFT-квантового-фиджет-спиннера?

🚩 Предлагают слишком сложные решения для простых проблем.
Обучать кастомную LLM для поиска неправильного форматирования в тексте — это как греть сэндвич ядерным реактором. Алло!

🚩🚩 Запутались, но вместо того чтобы спросить, пытаются дать неправильный ответ.
И это самый красный из всех флагов. Почему?
Потому что интервью — это миниатюрная версия того, как человек будет работать в реальности. И самое плохое, что может сделать сотрудник, когда не знает решения проблемы, — это не спросить совета, а втихую накосячить. Это бомба замедленного действия для компании. 💣

Есть, конечно, и другие красные флаги, такие как «он не знает ничего про Data Science» или «пытается поджечь офис», но оставлю их на усмотрение HR-менеджера.

Ну и в чем я не прав?

Отойдите от монитора, опустите плечи, разожмите челюсть и всем хороших выходных 🙏

Sunday Saddies Meme 💔

Перевод: «Имейте, пожалуйста, в виду, что я владелец малого бизнеса. Если увидите, как я разговариваю сам с собой, не мешайте — у меня рабочее совещание».

ХУК: что такое ССУТ и почему вам он нужен прям ща?

🤔 Сначала важный момент: я не знаю, как Single Source of Truth называется по-русски. Есть ли вообще устоявшееся понятие? Как будто нет, так что предлагаю аббревиатуру ССУТ. Звучит? Звучит.

➡️ Слова не сходятся, и метрики тоже
Представьте: у вас есть несколько команд. Одна работает над новой фичей, другая отвечает за монетизацию, а третья занимается маркетингом. Все эти команды смотрят на ретеншн. Только для одних это 20 дней, для других — 5, а третьи считают ретеншеном только тех, кто потратил больше X денег. И каждая из этих команд уверена, что их метрика — самая правильная.
Что происходит дальше?
♦️Каждая команда делает свой дашборд и следит за «своим» ретеншном.
♦️Основываясь на нем, ставят задачи дата-отделу, например, сделать ML-тулзу для предсказания ретеншна.
♦️На основании этих данных принимают решения.
А потом менеджмент получает отчёты. В одном — метрика растёт, в другом — падает, в третьем уходит в параллельную реальность. И что с этим всем делать?

➡️ Хаос метрик
Примеры того, к чему это может привести:
♦️Кто-то переходит из команды монетизации в команду новой фичи и продолжает работать со «своим» ретеншеном, потому что не знает, что есть еще какой-то.
♦️Принятые на основе таких данных решения просто не сработают, потому что данные изначально неверны.
♦️И ладно ретеншен, но так же могут считать выручку, ROI или LTV. И это уже пиздец страшно.

➡️ Как сделать нормально?
Нужен Single Source of Truth. Это база знаний, где:
♦️Чётко прописаны основные метрики. И указано, как именно их считать. Нет двух определений для одной и той же метрики.
♦️Кто-то отвечает за порядок. У этой базы должен быть владелец: человек или команда, которые добавляют новые метрики, удаляют устаревшие и следят за актуальностью базы.
♦️Метрики фиксируются. Если вы решите изменить определение ретеншена — это должно быть согласовано и зафиксировано. А потом смениться во всей компании.

➡️ Почему это важно?
Да, это скучно. Но зато все будут работать с одними и теми же данными, а менеджмент сможет принимать решения, основываясь на реальной картине.
Если для того, чтоб принимались критические для бизнеса решения, нужно жестко фиксировать и поддерживать базу, лучше потратить время на это, чем потом разгребать последствия.

А как с ССУТ в вашей компании?

ХУК: МЕНЬШЕ СЛУШАЙТЕ, БОЛЬШЕ СЧИТАЙТЕ

1. Слова пользователей не всегда совпадают (всегда не совпадают) с их действиями
Netflix давно понял, что люди говорят одно, а делают другое. Они просят «интеллектуальный контент», а потом залипают в сериал а-ля Power Rangers. Tinder тоже в курсе, что несмотря на то, что в био вы ищете «девушку для совместных занятий в церковном хоре», больше вам зайдет подойдет доминатрикс в латексном костюме на трехметровых каблуках.

Эти компании знают, что слова юзеров — это мечты, а поведение — реальность. Метрики показывают, что на самом деле важно. Они не врут. Смотрите на данные, а не только на фантазии — свои или ваших пользователей. Если декларируемые предпочтения не бьются с эмпирическими цифрами, доверяйте последним.

2. Изменения без измерений (и наоборот) — это пустая трата ресурсов
Перед тем как пивотнуть продукт или запустить новую функцию, ответьте на три вопроса:
♦️Какие метрики мы будем отслеживать?
♦️Сколько времени и как будем тестировать?
♦️Что будет считаться успехом?
Если у вас нет ответов на эти вопросы, остановитесь. Иначе вы семь раз отмерите, ничего в результате не отрезав.

3. Делайте выводы
Каждое изменение — это эксперимент. Через 2–3 недели (условно, зависит от вашего бизнеса) вы должны увидеть результаты A/B-теста. Если ничего не прояснилось, проблема либо в гипотезе, либо в метриках.
Думайте, анализируйте, переделывайте. Это нормально.

4. Метрики — это мешки, которые надо ворочать
Быть визионером прикольно: придумываешь всякое, вдохновляешь команду и заказываешь в офис пиццу по пятницам. Но иногда надо и поработать: запустить тесты, покопаться в таблицах.
Да, это муторно. Но именно из таких процессов рождаются успешные продукты. Метрики могут не вдохновлять, но они точно тащат ваш бизнес.

Итог: Метрики — это зеркало в примерочной вашего бизнеса. Скорее всего, вы увидите пузо, которое вам не понравится, но зато сможете выбрать что-то, что будет нормально на вас сидеть.
А с пользователями надо выстраивать отношения типа «доверяй, но проверяй» — мы внимательно прислушиваемся к тому, что говорят люди, но не верим им на слово.

Сколько на этом посте будет реакций, столько дебильных метафор я добавлю в следующий пост.

Пока я пытаюсь впихнуть 24 метафоры в один пост, держите мем 🙂

ХУК: МНЕ НАДОЕЛИ ИЗБАЛОВАННЫЕ ДЕТИ И НЕВНИМАТЕЛЬНЫЕ РОДИТЕЛИ

Вам очень надо, чтоб ребёнок вас любил всегда. А ребёнок любит сладкое. Если сегодня вы дадите ему конфету, он обрадуется. Завтра дадите половинку — устроит истерику и насрет в углу. Если дадите две, он успокоится, но только до следующего раза. И так будет продолжаться, пока вы не психанете и не скажете: «Хватит конфет, мы ведем тебя к инсулинорезистентности и инсульту в 30 лет, давай есть брокколи». Но поздно: ребёнок любит вас только потому, что вы даете ему конфеты, так что он пойдет к бабушке, которая накормит его сладким, и забудет про вас.

К чему это я?
Инвесторы со стартапами — это те же дети и сладости. Чтобы привлечь деньги, приходится показывать гиперрост. Метрики — те самые конфеты. А вот брокколи — это работа, приносящая в моменте меньше наслаждения, но позволяющая в дальнейшем иметь здоровый и масштабируемый бизнес:
🔧 рефакторинг кода,
🔄 улучшение процессов,
📈 создание прочного фундамента.

Но брокколи никто не хочет, особенно когда вокруг все предлагают только десерты всех форм и размеров.

Поэтому стартапы фигачат на гиперрост, чтобы выглядеть красиво для инвесторов. А тем временем:
🚽 Технический долг растёт, код становится франкенштейном из костылей.
🚽 Команды тонут в бесконечных алертах.
🚽 В компании куча людей, сжирающих ресурсы, но не нужных бизнесу на данном этапе.

Прогресс превращается в театр, где вместо реальных улучшений — красивые графики.

Фундамент ломается. Давление растёт. Всё летит в тартарары.

Такой ты умный. А как надо?
Фаундерам и инвесторам надо перестать жить одним днём:
🔴Фаундерам — ставить долгосрочные цели выше быстрых побед.
🔴Инвесторам — понимать, что x100 за пять лет лучше, чем x10 за год с последующим медленным нервным затуханием.

Масштабирование — это не взорвать все, чтоб красиво горело. Это устойчивый рост, где клетчатка важна, но конфеты никто не отменяет.

А где обещанные 24 метафоры?
Я устал.
Это я про следующий пост говорил 🤷‍♀️

Мне больно смотреть на A/B-тесты

🔴Работал я с одной компанией, которая тестировала новую фичу и словила багу, из-за которой фича не работала у половины пользователей. И продакты решили, что это очень удобное разделение юзеров для A/B-теста: контрольная группа с багой, тестовая — без.

Почему это плохая идея? Баги никогда не случайны. Они могут зависеть от платформы, региона или ещё десятка факторов. С таким же успехом можно делать тест нового десерта на группах, в одной из которых — дети, а в другой — аллергики.

🔴Другой пример.

Допустим, мобильная игра запустила новый виртуальный item и сразу увидела взлет продаж в тестовой группе. В отчёте радостно написали: «Item классный! Продажи выросли, выручка выросла, все растет, счастье-то какое!»

Только она не выросла, а скакнула, а потом откатилась обратно и осталась на плато. Это один из вариантов «эффекта новизны» — временного всплеска интереса, который потом угасает. Но умные продакты, берегущие свою карьеру, остановили А/Б-тест до того, как он стал этот эффект отражать.

🔴Еще мое любимое, это А/Б-тест, где результат показал стопроцентный рост. Круто! Но есть нюанс: в одной группе сконвертировался один человек, а в другой — два.

🔴Или вот такая история.

E-commerce платформа тестирует новый пользовательский флоу. Результаты теста: большинство метрик упали, но! Среднее время на сайте и количество действий на пользователя выросли.

Продакты посмотрели на графики и решили: успех! Пользователи стали больше времени проводить на платформе, значит, им очень нравится. Графики показали инвесторам, флоу запустили.

А теперь правда: флоу оказался настолько сложным, что люди не могли понять, куда нажимать. Они просто метались по сайту, как кот по комнате с пылесосом.

Почему это случилось? Потому что изначально у теста не было плана. Никто не подумал, на какие метрики вообще надо смотреть, чтоб оценить успех или неудачу запуска.

И это только самые безобидные косяки.

🧠 Что идёт не так?

Все эти примеры — результат одних и тех же ошибок:
1. Нет чёткого плана.
2. Нет рандомизации.
3. Игнорирование эффекта новизны.
4. Полное отсутствие статистики.

🧠 Как это исправить?

1. Начинать с цели
Что именно вы хотите узнать? Какие метрики покажут успех? Что будет считаться победой?
2. Группы должны быть случайными
Рандомизация — это не пожелание, а правило. Если группы формируются по принципу бага или удобства, это не тест, а картина, нарисованная пальцем в воздухе.
3. Учитывать эффект новизны
Смотреть на первые дни фичи — это как оценивать свой марафон после первой сотни метров. Настоящая картина видна не сразу.
4. Не подыгрывать себе
Как бы ни хотелось, чтобы фича залетела, не надо подгонять результаты или выбирать для отчета те метрики, по которым есть рост.

Итог:
A/B-тесты должны быть адвокатом дьявола и бесить, потому что показывают контринтуитивные вещи, а не быть инструментом продвижения собственной карьеры, поглаживания своего эго и прочего самоуспокоения — для этого есть социальные сети.