Проснулись, потянулись, и вперед читать полезный контент➡️
Почему не бывает универсального шаблона для A/B-тестов
Недавно наш маркетолог спросила: «А почему нет единого шаблона для A/B-тестов, чтобы всё делать правильно всегда?» И если вас тоже волновал этот вопрос, то ответ на него такой: по кочану.
Каждый продукт — это уникальная снежинка
То, что работает для одной компании, может угробить другую. У каждого продукта свои паттерны, целевые метрики, пользователи и контексты. Нет смысла брать чужие подходы, если ты не понимаешь, как их адаптировать.
Возьмём, например, интернет-магазины. Если вы меняете внутрянку, например рекомендационную систему, эффекта новизны не будет — метрики могут меняться сразу. Но если мы тестируем что-то, что может вызвать вау-эффект, этот эффект надо учитывать и оценивать отдельно.
Долгосрочные риски вместо краткосрочного счастья
Приведу пример из дейтинга. Представим: запускается A/B-тест, в котором одной группе пользователей (допустим, мужчинам) показывают только популярных женщин: моделей, инфлюенсеров, с раскрученными соцсетями. Мужчины начинают закидывать им суперлайки, и revenue у платформы взлетает.
Классно? Нет.
В краткосрочной перспективе всё выглядит как успех, но что будет дальше?
🤎 Обычные женщины начинают чувствовать себя невидимыми — им никто не пишет.
🤎 Модели-инфлюенсеры чувствуют себя заваленными спамом, от которого быстро становится тошно.
🤎 В итоге все уходят с платформы: кто-то из-за отсутствия внимания, кто-то из-за его избытка.
Результат: в A/B-тесте рост выручки, но в долгосроке — полный провал.
Медленно, но верно
Некоторые фичи нужно раскатывать медленно и аккуратно. Например:
🤎 Алгоритмы для трейдинга. Ошибка тут может стоить мгновенных и катастрофических убытков.
🤎 Скоринговая модель для банка. Только через месяцы ты увидишь, оправдалась ли гипотеза.
Принимать решения на основе слишком короткого теста = записываться на Ironman, пробежав без остановки свой первый километр.
Главное правило
A/B-тесты — это не только метрики, но и понимание бизнеса. Перед тем как что-то выкатывать, важно задать себе вопросы:
🤎 Какие метрики важны вот в этой конкретной истории?
🤎 Что может случиться в долгосрочной перспективе?
🤎 И самое главное: ты уверен, что понимаешь, что делаешь? Ты можешь объяснить это CEO? А маркетологам? А пятилетке? А пятилетке в четыре года?
Потому что если ты не понимаешь, то применять не надо.
Почему не бывает универсального шаблона для A/B-тестов
Недавно наш маркетолог спросила: «А почему нет единого шаблона для A/B-тестов, чтобы всё делать правильно всегда?» И если вас тоже волновал этот вопрос, то ответ на него такой: по кочану.
Каждый продукт — это уникальная снежинка
То, что работает для одной компании, может угробить другую. У каждого продукта свои паттерны, целевые метрики, пользователи и контексты. Нет смысла брать чужие подходы, если ты не понимаешь, как их адаптировать.
Возьмём, например, интернет-магазины. Если вы меняете внутрянку, например рекомендационную систему, эффекта новизны не будет — метрики могут меняться сразу. Но если мы тестируем что-то, что может вызвать вау-эффект, этот эффект надо учитывать и оценивать отдельно.
Долгосрочные риски вместо краткосрочного счастья
Приведу пример из дейтинга. Представим: запускается A/B-тест, в котором одной группе пользователей (допустим, мужчинам) показывают только популярных женщин: моделей, инфлюенсеров, с раскрученными соцсетями. Мужчины начинают закидывать им суперлайки, и revenue у платформы взлетает.
Классно? Нет.
В краткосрочной перспективе всё выглядит как успех, но что будет дальше?
Результат: в A/B-тесте рост выручки, но в долгосроке — полный провал.
Медленно, но верно
Некоторые фичи нужно раскатывать медленно и аккуратно. Например:
Принимать решения на основе слишком короткого теста = записываться на Ironman, пробежав без остановки свой первый километр.
Главное правило
A/B-тесты — это не только метрики, но и понимание бизнеса. Перед тем как что-то выкатывать, важно задать себе вопросы:
Потому что если ты не понимаешь, то применять не надо.
Please open Telegram to view this post
VIEW IN TELEGRAM
✍6🔥5💯4
Как не сойти с ума от метрик
Метрики — это один из главных инструментов управления бизнесом. Поэтому их надо холить и лелеять, а не превращать дашборд в хаос и свалку. Вот несколько универсальных правил:
1. Уровни важности
В компании должны быть все уровни метрик. Допустим:
💚 Глобальные (например, выручка, MAU) — для стратегического управления.
💚 Продуктовые (конверсия, retention) — для оценки успеха конкретных фич.
💚 Финансовые — чтобы CFO не звонил вам среди ночи.
И так далее.
Но важно понимать: не все метрики нужны всем и не надо пихать их в один дашборд. Если гендир смотрит на надои Бурёнки №14, а доярка изучает проекцию прибыли — что-то пошло не так.
2. Убираем шум
Каждая метрика должна быть полезной. Прежде чем добавить метрику в дашборд, нужно задать себе вопрос:
💚 Что означает для моего продукта/команды рост этой метрики? А падение?
💚 Что я сделаю, если метрика упадёт? А если возрастет?
Если ответ на все вопросы «ничего» или «ничего конкретного» — эта метрика вам не нужна. По крайней мере, не в текущем дашборде. Выбрасывайте ненужные цифры и оставляйте только те, на которые вы реально будете смотреть.
3. Одинаковые правила для всех
Каждый отдел, каждый сотрудник должен считать одни и те же метрики одним и тем же способом. Почему это важно? Потому что без этого менеджеры будут видеть одни цифры, маркетологи — другие, а дата-саентисты вообще в своём мире. Подробнее об этом я уже писал вот тут.
4. Прозрачность
Во-первых, каждая метрика должна основываться на здравом смысле и логике.
Прежде, чем принять решение отслеживать ту или иную метрику или влиять на нее, спросите себя:
💚 Какие бизнес-сценарии ждут продукт?
💚 На что может повлиять та или иная часть продукта?
💚 И уже на основе этого стройте метрики. А не наоборот — не надо подгонять свои желания и хотелки под какие-то метрики.
Во-вторых, у каждого отдела самыми важными будут разные метрики. Продакт-менеджеры смотрят на одно, маркетологи на другое. Главное, чтобы доступ к цифрам был у всех, кому они нужны. От этого зависит, как быстро и точно принимаются решения.
Итог
Метрики должны уменьшать количество хаоса, а не наоборот. Не превращайте дашборд в кладбище ненужных цифр. Помните: меньше, но лучше.
Метрики — это один из главных инструментов управления бизнесом. Поэтому их надо холить и лелеять, а не превращать дашборд в хаос и свалку. Вот несколько универсальных правил:
1. Уровни важности
В компании должны быть все уровни метрик. Допустим:
И так далее.
Но важно понимать: не все метрики нужны всем и не надо пихать их в один дашборд. Если гендир смотрит на надои Бурёнки №14, а доярка изучает проекцию прибыли — что-то пошло не так.
2. Убираем шум
Каждая метрика должна быть полезной. Прежде чем добавить метрику в дашборд, нужно задать себе вопрос:
Если ответ на все вопросы «ничего» или «ничего конкретного» — эта метрика вам не нужна. По крайней мере, не в текущем дашборде. Выбрасывайте ненужные цифры и оставляйте только те, на которые вы реально будете смотреть.
3. Одинаковые правила для всех
Каждый отдел, каждый сотрудник должен считать одни и те же метрики одним и тем же способом. Почему это важно? Потому что без этого менеджеры будут видеть одни цифры, маркетологи — другие, а дата-саентисты вообще в своём мире. Подробнее об этом я уже писал вот тут.
4. Прозрачность
Во-первых, каждая метрика должна основываться на здравом смысле и логике.
Прежде, чем принять решение отслеживать ту или иную метрику или влиять на нее, спросите себя:
Во-вторых, у каждого отдела самыми важными будут разные метрики. Продакт-менеджеры смотрят на одно, маркетологи на другое. Главное, чтобы доступ к цифрам был у всех, кому они нужны. От этого зависит, как быстро и точно принимаются решения.
Итог
Метрики должны уменьшать количество хаоса, а не наоборот. Не превращайте дашборд в кладбище ненужных цифр. Помните: меньше, но лучше.
Please open Telegram to view this post
VIEW IN TELEGRAM
💯6✍3🔥2
«Не трогай то, что работает»
Недавно спрашивал про странные и тупые бизнес-советы. Один из комментариев:
Фраза логичная только если вы — маленькая итальянская пиццерия где-то в деревне, которая никогда не планирует расти. Для всех остальных это миф.
Если у вас вдруг возникнет желание сказать это своему полному энтузиазма junior product manager, сначала задайте себе несколько вопросов:
1. Оно действительно работает?
То, что модель выдаёт какие-то цифры, не значит, что она правильная. Баги, костыли, неверные результаты — это всё ещё «работает», но делает это ужасно. Как и ребенок, который учится есть, обмазывает кашей себя, стол и кота. Формально, он ест.
2. Оно эффективно?
Если процесс тянет на себе половину бюджета компании, но формально выполняет задачу, это не повод оставлять его в покое. Сплошь и рядом я вижу пайплайны из говна и палок, которые в целом работают верно. Только цена этого — седые волосы CFO, который видит счет за Google Cloud в конце месяца и «ой у нас нет бюджета оплатить кондиционер».
3. Оно масштабируемо?
Работает сейчас — это не значит, что будет работать при росте. Сможет ли текущая система справиться, если нагрузка вырастет в два раза? А в пять? А в сто?
4. Оно актуально?
Даже если что-то работает, это не значит, что оно нужно.
Например, модель предсказывает churn через неделю — но бизнесу теперь важны предсказания на месяц вперёд.
То, что работало год назад, может быть бесполезным сегодня.
Итог:
Любую систему важно регулярно пересматривать, обновлять и адаптировать. Бизнес растёт, цели меняются, и только те, кто вовремя трогает то, что «работает», остаются на плаву.
Трогайте всё!Но не как Харви Вайнштейн.
Теперь рассказывайте, какие «работающие» процессы или системы вы меняли, чтобы всё заработало лучше?
Недавно спрашивал про странные и тупые бизнес-советы. Один из комментариев:
«Не трогай то, что работает», — говорили мне разные люди несколько раз. Я всё равно трогал, и оказывалось, что работает плохо, неправильно, бизнес теряет деньги, а клиенты недовольны. Этот совет не ужасный, но он настолько размытый и невнятный, что без контекста в нём нет никакого смысла.
Фраза логичная только если вы — маленькая итальянская пиццерия где-то в деревне, которая никогда не планирует расти. Для всех остальных это миф.
Если у вас вдруг возникнет желание сказать это своему полному энтузиазма junior product manager, сначала задайте себе несколько вопросов:
1. Оно действительно работает?
То, что модель выдаёт какие-то цифры, не значит, что она правильная. Баги, костыли, неверные результаты — это всё ещё «работает», но делает это ужасно. Как и ребенок, который учится есть, обмазывает кашей себя, стол и кота. Формально, он ест.
2. Оно эффективно?
Если процесс тянет на себе половину бюджета компании, но формально выполняет задачу, это не повод оставлять его в покое. Сплошь и рядом я вижу пайплайны из говна и палок, которые в целом работают верно. Только цена этого — седые волосы CFO, который видит счет за Google Cloud в конце месяца и «ой у нас нет бюджета оплатить кондиционер».
3. Оно масштабируемо?
Работает сейчас — это не значит, что будет работать при росте. Сможет ли текущая система справиться, если нагрузка вырастет в два раза? А в пять? А в сто?
4. Оно актуально?
Даже если что-то работает, это не значит, что оно нужно.
Например, модель предсказывает churn через неделю — но бизнесу теперь важны предсказания на месяц вперёд.
То, что работало год назад, может быть бесполезным сегодня.
Итог:
Любую систему важно регулярно пересматривать, обновлять и адаптировать. Бизнес растёт, цели меняются, и только те, кто вовремя трогает то, что «работает», остаются на плаву.
Трогайте всё!
Теперь рассказывайте, какие «работающие» процессы или системы вы меняли, чтобы всё заработало лучше?
🔥10💯6✍3
Мини-консалтинг за пользовательские взаимодействия
Многие из вас в опросе отметили, что хотите больше конкретных кейсов и разборов. И это отличная идея, я и сам такое люблю. Но есть одна проблема: не все готовы публично рассказать о своих проблемах, а о проблемах своих клиентов я тоже, знаете, не могу рассказывать на 100% прозрачно.
Решение найдено! Я прикрутил анонимного бота для вопросов. Теперь вы можете анонимно спрашивать меня про всё, что вас волнует: про бизнес, продукты, метрики, A/B-тесты, что угодно. Я возьму ваши вопросы, разберу их и сделаю посты с ответами, которые, возможно, помогут не только вам, но и ещё кому-нибудь.
Как это работает?
1. Заходите к боту.
2. Пишете ваш вопрос, кейс, проблему, доебку.
3. Я читаю и делаю пост со своими мыслями и рекомендациями.
Почему это круто?
🌟 Анонимность. NDA не нарушается, лишнее не рассказывается.
🌟 Больше пользы. Вы получаете ответ на свой кейс, я — контент, другие подписчики — инсайты.
🌟 Никаких продаж и реклам — чистый консалтинг за ваше время и интерес.
Первый вопрос может быть как раз от вас
Что у вас болит? Где застряли? Расскажите, разберём вместе.
P.S. Не забудьте остановить бота после того, как зададите вопрос, а то получите тыщу спам-сообщений от него. К сожалению, мы живем в обществе💛
Многие из вас в опросе отметили, что хотите больше конкретных кейсов и разборов. И это отличная идея, я и сам такое люблю. Но есть одна проблема: не все готовы публично рассказать о своих проблемах, а о проблемах своих клиентов я тоже, знаете, не могу рассказывать на 100% прозрачно.
Решение найдено! Я прикрутил анонимного бота для вопросов. Теперь вы можете анонимно спрашивать меня про всё, что вас волнует: про бизнес, продукты, метрики, A/B-тесты, что угодно. Я возьму ваши вопросы, разберу их и сделаю посты с ответами, которые, возможно, помогут не только вам, но и ещё кому-нибудь.
Как это работает?
1. Заходите к боту.
2. Пишете ваш вопрос, кейс, проблему, доебку.
3. Я читаю и делаю пост со своими мыслями и рекомендациями.
Почему это круто?
Первый вопрос может быть как раз от вас
Что у вас болит? Где застряли? Расскажите, разберём вместе.
P.S. Не забудьте остановить бота после того, как зададите вопрос, а то получите тыщу спам-сообщений от него. К сожалению, мы живем в обществе
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7✍4💅1
Я просто подарок (буквально).
Один мой знакомый очень давно хотел дать мне денег, но как-то все повода не было. И тут на Новый год он придумал подарить своей сотруднице менторинг от меня.
Во-первых, желаю всем таких друзей, которых хлебом не корми — дай вам заплатить.
Во-вторых, сегодня Старый Новый год, и это хороший повод подарить своим сотрудникам, начальникам, коллегам консультацию от ASAO DS или менторинг от меня. А если назовете промокод ДАНЮША, я даже бантик прилеплю себе на голову.
Один мой знакомый очень давно хотел дать мне денег, но как-то все повода не было. И тут на Новый год он придумал подарить своей сотруднице менторинг от меня.
Во-первых, желаю всем таких друзей, которых хлебом не корми — дай вам заплатить.
Во-вторых, сегодня Старый Новый год, и это хороший повод подарить своим сотрудникам, начальникам, коллегам консультацию от ASAO DS или менторинг от меня. А если назовете промокод ДАНЮША, я даже бантик прилеплю себе на голову.
😁20✍3💅3
Надо ли сразу делать продукт, который скейлится?
После одного из предыдущих постов мне предъявили, что необязательно вообще-то сразу делать продукт, который можно будет масштабировать.
Это зависит от того, что именно вы делаете.
Чтобы разобраться, важно понять разницу между PoC, MVP и полноценным продуктом.
1. PoC — Proof of Concept
Это проверка гипотезы.
PoC — это не продукт. Никогда. Это штука из говна и палок, которая должна ответить на один вопрос: «Стоит ли вообще двигаться дальше?»
🔶 Пример:
Хочется сделать retention prediction model. Берётся куча данных, делается линейная регрессия в прости господи Excel и смотрится: что-то там она предсказывает и делает это даже чуть лучше подброшенной монетки. Окей, гипотеза подтвердилась — можно продолжать.
На этом этапе планировать ничего не надо, это просто быстрый «тяп-ляп», только без продакшена. Нигде, кроме внутреннего теста или презентации для инвестора, этой штуке не место.
2. MVP — Minimum Viable Product
Это уже продукт, которым можно пользоваться.
MVP — это минимум value, который можно протестировать на реальных юзерах. Его задача — проверить, работает ли гипотеза в реальной среде.
🔶 Пример:
Social app решил ввести новую фичу: дикпик и супердикпик. Разработали базовый функционал, который работает, но совсем не оптимизирован, разве что по мелочи. Больше и не надо, ведь его задача — потусить на A/B-тестах, получить данные и решить, стоит ли развивать эту идею дальше.
Но! MVP уже нужно делать с учётом будущего роста. То есть это не должен быть набор костылей, который придётся переписывать с нуля, если гипотеза подтвердится.
3. Полноценный продукт
Это то, что вы делаете после успешного тестирования на этапе MVP.
На этом этапе все костыли убираются, добавляются нужные фичи, оптимизируются параметры, настраивается полноценная аналитика, завязывается бантик — продукт готов к масштабированию.
Ошибки, которые убивают стартапы
1. PoC отправляют в прод
Быстро слепили что-то, отдали юзерам, метрики выросли. И вот эта костыльная штука уже полгода работает на проде, потому что её боятся трогать, чтоб не поломать конверсию.
2. MVP превращают в продукт
Вместо того чтобы доработать MVP после тестов, его просто запускают как полноценный продукт. Скейлить его невозможно, баги копятся, грустно.
3. Пропускают PoC и делают сразу полноценный продукт
Самая дорогая ошибка. Полгода половина компании делает и тестирует новую фичу, потом другая половина запускает маркетинговую кампанию, а в итоге ей пользуется сотня человек из сотен тысяч MAU.
Итог
Успех продукта — это три этапа, и каждый из них нужен:
🔶 PoC проверяет гипотезу.
🔶 MVP даёт реальную обратную связь от юзеров.
🔶 Полноценный масштабируемый продукт приносит деньги.
[Классный панч в конце и CTA оставлять комментарии]
После одного из предыдущих постов мне предъявили, что необязательно вообще-то сразу делать продукт, который можно будет масштабировать.
Это зависит от того, что именно вы делаете.
Чтобы разобраться, важно понять разницу между PoC, MVP и полноценным продуктом.
1. PoC — Proof of Concept
Это проверка гипотезы.
PoC — это не продукт. Никогда. Это штука из говна и палок, которая должна ответить на один вопрос: «Стоит ли вообще двигаться дальше?»
Хочется сделать retention prediction model. Берётся куча данных, делается линейная регрессия в прости господи Excel и смотрится: что-то там она предсказывает и делает это даже чуть лучше подброшенной монетки. Окей, гипотеза подтвердилась — можно продолжать.
На этом этапе планировать ничего не надо, это просто быстрый «тяп-ляп», только без продакшена. Нигде, кроме внутреннего теста или презентации для инвестора, этой штуке не место.
2. MVP — Minimum Viable Product
Это уже продукт, которым можно пользоваться.
MVP — это минимум value, который можно протестировать на реальных юзерах. Его задача — проверить, работает ли гипотеза в реальной среде.
Social app решил ввести новую фичу: дикпик и супердикпик. Разработали базовый функционал, который работает, но совсем не оптимизирован, разве что по мелочи. Больше и не надо, ведь его задача — потусить на A/B-тестах, получить данные и решить, стоит ли развивать эту идею дальше.
Но! MVP уже нужно делать с учётом будущего роста. То есть это не должен быть набор костылей, который придётся переписывать с нуля, если гипотеза подтвердится.
3. Полноценный продукт
Это то, что вы делаете после успешного тестирования на этапе MVP.
На этом этапе все костыли убираются, добавляются нужные фичи, оптимизируются параметры, настраивается полноценная аналитика, завязывается бантик — продукт готов к масштабированию.
Ошибки, которые убивают стартапы
1. PoC отправляют в прод
Быстро слепили что-то, отдали юзерам, метрики выросли. И вот эта костыльная штука уже полгода работает на проде, потому что её боятся трогать, чтоб не поломать конверсию.
2. MVP превращают в продукт
Вместо того чтобы доработать MVP после тестов, его просто запускают как полноценный продукт. Скейлить его невозможно, баги копятся, грустно.
3. Пропускают PoC и делают сразу полноценный продукт
Самая дорогая ошибка. Полгода половина компании делает и тестирует новую фичу, потом другая половина запускает маркетинговую кампанию, а в итоге ей пользуется сотня человек из сотен тысяч MAU.
Итог
Успех продукта — это три этапа, и каждый из них нужен:
[Классный панч в конце и CTA оставлять комментарии]
Please open Telegram to view this post
VIEW IN TELEGRAM
✍5💯3🔥2
Ура, пошли вопросы от подписчиков.
Какую самую идиотскую проблему ты решал?
А я вам сейчас расскажу.
Работал я как-то с компанией, связанной с видео. У них была стандартная, на первый взгляд, задача: модерация контента. Ну, знаете, чтобы рафинированная и целомудренная аудитория не дай бог не лицезрела человеческий пэнис.
Модерационный алгоритм работал хорошо. Слишком хорошо. В один момент он начал блокировать видео, где два лысых человека сидели рядом, потому что он думал, что это жопа. Нет, правда. Алгоритм был уверен: два круглых, кожаных, отражающих свет предмета в кадре — всё, это 18+. Если бы я был стримером и пригласил гостем Брюса Уиллиса или облокотился на зеркало, нас бы забанили за похабщину.
Модерация видео — это, казалось бы, задача, идеально подходящая для AI. Но только человеческий мозг умеет распознавать паттерны на таком уровне, чтобы отличить две сочные лысины взрослых приличных людей от ягодиц.
Я хотел бы сказать, что решил эту проблему быстро. Но нет. Мы даже хакатон устраивали, чтобы обучить алгоритм думать не как подросток с плохим чувством юмора. Пришлось настроить кучу дополнительных правил, уточнить датасеты, вот это все. В итоге справились, но сколько нервов это стоило… Отдельным удовольствием была уточняющая разметка данных на «жопа — не жопа».
Всем хороших выходных!
🍑 С любовью, Ягодица из ASAO.
Какую самую идиотскую проблему ты решал?
А я вам сейчас расскажу.
Работал я как-то с компанией, связанной с видео. У них была стандартная, на первый взгляд, задача: модерация контента. Ну, знаете, чтобы рафинированная и целомудренная аудитория не дай бог не лицезрела человеческий пэнис.
Модерационный алгоритм работал хорошо. Слишком хорошо. В один момент он начал блокировать видео, где два лысых человека сидели рядом, потому что он думал, что это жопа. Нет, правда. Алгоритм был уверен: два круглых, кожаных, отражающих свет предмета в кадре — всё, это 18+. Если бы я был стримером и пригласил гостем Брюса Уиллиса или облокотился на зеркало, нас бы забанили за похабщину.
Модерация видео — это, казалось бы, задача, идеально подходящая для AI. Но только человеческий мозг умеет распознавать паттерны на таком уровне, чтобы отличить две сочные лысины взрослых приличных людей от ягодиц.
Я хотел бы сказать, что решил эту проблему быстро. Но нет. Мы даже хакатон устраивали, чтобы обучить алгоритм думать не как подросток с плохим чувством юмора. Пришлось настроить кучу дополнительных правил, уточнить датасеты, вот это все. В итоге справились, но сколько нервов это стоило… Отдельным удовольствием была уточняющая разметка данных на «жопа — не жопа».
Всем хороших выходных!
Please open Telegram to view this post
VIEW IN TELEGRAM
😁15🔥12💅1
Куда уходят пользователи?
Я пришел решать проблему компании с ретеншном. Люди скачивали приложение, пользовались какое-то время — и всё, прощай, goodbye, hasta la vista. Никто не мог понять, в чём дело. Метрики смотрели, данные ковыряли, гипотезы строили — безрезультатно.
Что бросилось мне в глаза: у пушей был подозрительно низкий open rate. Вроде, формально всё ок, отправляются в правильное время, даже доходят. Но обнаружилась одна деталь…
Они отправляли все пуши по таймзоне UTC.
И всё бы ничего, если бы это был локальный сервис для жителей Рейкьявика, но в США люди живут не по UTC. У кого-то пуши приходили в три часа ночи, у кого-то — в 6 утра. Короче, в моменты, когда если и смотришь в экран телефона, то только чтобы выключить будильник.
Естественно, пуши никто не читал. —> Напоминания о функционале никто не видел. —> Пользователи теряли интерес и просто уходили.
Как исправили? Настроили отправку пушей по локальному времени юзеров. С вас миллион долларов и диетическая кола за услугу консалтинга (стандартная ставка).
Мораль:
Пуши — это не просто уведомления и не стоит их недооценивать. Это способ напомнить пользователю, зачем он здесь и почему ему это приложение нравится. Но если вы отправляете их, игнорируя реальную жизнь пользователей, если они не персонализированы, то лучше вообще не отправляйте.
Я пришел решать проблему компании с ретеншном. Люди скачивали приложение, пользовались какое-то время — и всё, прощай, goodbye, hasta la vista. Никто не мог понять, в чём дело. Метрики смотрели, данные ковыряли, гипотезы строили — безрезультатно.
Что бросилось мне в глаза: у пушей был подозрительно низкий open rate. Вроде, формально всё ок, отправляются в правильное время, даже доходят. Но обнаружилась одна деталь…
Они отправляли все пуши по таймзоне UTC.
И всё бы ничего, если бы это был локальный сервис для жителей Рейкьявика, но в США люди живут не по UTC. У кого-то пуши приходили в три часа ночи, у кого-то — в 6 утра. Короче, в моменты, когда если и смотришь в экран телефона, то только чтобы выключить будильник.
Естественно, пуши никто не читал. —> Напоминания о функционале никто не видел. —> Пользователи теряли интерес и просто уходили.
Как исправили? Настроили отправку пушей по локальному времени юзеров. С вас миллион долларов и диетическая кола за услугу консалтинга (стандартная ставка).
Мораль:
Пуши — это не просто уведомления и не стоит их недооценивать. Это способ напомнить пользователю, зачем он здесь и почему ему это приложение нравится. Но если вы отправляете их, игнорируя реальную жизнь пользователей, если они не персонализированы, то лучше вообще не отправляйте.
🔥4💯4✍3😁2💅1
Бизнес строится на данных. Но что, если данные врут?
Однажды я работал с компанией, которая по всем отчетам и аналитике имела львиную долю юзеров в США. Этот факт очень тешил им эго и радовал их инвесторов, ведь выйти на американский рынок — мечта любого стартапа.
Но поскреби юзера-американца и получишь VPN.
Большинство VPN американские, так что юзеры из Middle East или ЮВА, где куча сервисов и приложений заблокированы, заходят через них. По отчётам кажется, что большая часть выручки идёт из Штатов, а если копнуть глубже — например, посмотреть на язык или таймзону устройства — оказывается, что распределение юзеров совсем другое.
Проблемы у компании как раз начались тогда, когда они строили гипотезы и принимали стратегические решения на этой ложной картине. Компания думала, что знает своего пользователя, и проектировала продукт для мифического среднего американца, а реальных юзеров из Индии или Саудовской Аравии просто игнорировала.
Итог:
♦️ Деньги тратятся на маркетинг, который не работает, потому что нацелен не на ЦА
♦️ Продукт не решает проблемы пользователей, потому что портрет пользователя не сходится с реальностью
♦️ Бизнес оказывается в свободном падении.
Я не знаю, искажали ли они данные сознательно в попытке показать инвесторам несуществующую картину или для них это тоже стало удивительным открытием, но на всякий случай морали две:
1. Проверяйте данные. Смотрите глубже, если что-то не сходится непонятно почему.
2. Не врите сами себе. И инвесторам не врите. Старайтесь врать по минимуму, когда дело касается данных, потому что такую ложь очень легко проверить и навсегда потерять репутацию прикольного стартапа.
Однажды я работал с компанией, которая по всем отчетам и аналитике имела львиную долю юзеров в США. Этот факт очень тешил им эго и радовал их инвесторов, ведь выйти на американский рынок — мечта любого стартапа.
Но поскреби юзера-американца и получишь VPN.
Большинство VPN американские, так что юзеры из Middle East или ЮВА, где куча сервисов и приложений заблокированы, заходят через них. По отчётам кажется, что большая часть выручки идёт из Штатов, а если копнуть глубже — например, посмотреть на язык или таймзону устройства — оказывается, что распределение юзеров совсем другое.
Проблемы у компании как раз начались тогда, когда они строили гипотезы и принимали стратегические решения на этой ложной картине. Компания думала, что знает своего пользователя, и проектировала продукт для мифического среднего американца, а реальных юзеров из Индии или Саудовской Аравии просто игнорировала.
Итог:
Я не знаю, искажали ли они данные сознательно в попытке показать инвесторам несуществующую картину или для них это тоже стало удивительным открытием, но на всякий случай морали две:
1. Проверяйте данные. Смотрите глубже, если что-то не сходится непонятно почему.
2. Не врите сами себе. И инвесторам не врите. Старайтесь врать по минимуму, когда дело касается данных, потому что такую ложь очень легко проверить и навсегда потерять репутацию прикольного стартапа.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7✍2💅2😁1
Pre mortem: искусство предсказания факапов
Что такое post mortem, я думаю, вы все и так знаете. Но я в своей работе больше люблю проводить pre mortem, прежде чем что-то запускать, делать, одобрять, и так далее.
Это значит: сразу представить, что всё пошло по самому худшему сценарию, и заранее понять, где и почему оно могло развалиться.
Зачем это нужно?
Чтобы убрать грабли до того, как на них наступят, и подстелить соломку.
И это не какое-то мыслительное упражнение, чисто посидеть поразмышлять, а полезная практика для бизнеса. Ты становишься адвокатом дьявола, начинаешь фокусироваться не на желаемом результате, а на потенциальных фейлах. Это очень помогает избавиться от предвзятых мыслей и ожиданий, которые мозг даже не фиксирует, когда думает только о цели.
Выглядит это так:
— Зовёшь коллег.
— Вместе брейнштормите, где и что может пойти не так.
— Сразу ищете решения, чтобы прикрыть слабые места.
Так факапы, которые могли случиться, не случаются. Эксперименты становятся точнее, результаты — чище, а команда начинает думать критически и смотреть на риски прежде, чем с энтузиазмом браться за задачку.
Запомните: чем лучше проведён pre mortem, тем меньше шансов, что потом придётся проводить post mortem.
P.S. Эта практика противопоказана беременным женщинам, ипохондрикам и любителям аффирмаций.
Что такое post mortem, я думаю, вы все и так знаете. Но я в своей работе больше люблю проводить pre mortem, прежде чем что-то запускать, делать, одобрять, и так далее.
Это значит: сразу представить, что всё пошло по самому худшему сценарию, и заранее понять, где и почему оно могло развалиться.
Зачем это нужно?
Чтобы убрать грабли до того, как на них наступят, и подстелить соломку.
И это не какое-то мыслительное упражнение, чисто посидеть поразмышлять, а полезная практика для бизнеса. Ты становишься адвокатом дьявола, начинаешь фокусироваться не на желаемом результате, а на потенциальных фейлах. Это очень помогает избавиться от предвзятых мыслей и ожиданий, которые мозг даже не фиксирует, когда думает только о цели.
Выглядит это так:
— Зовёшь коллег.
— Вместе брейнштормите, где и что может пойти не так.
— Сразу ищете решения, чтобы прикрыть слабые места.
Так факапы, которые могли случиться, не случаются. Эксперименты становятся точнее, результаты — чище, а команда начинает думать критически и смотреть на риски прежде, чем с энтузиазмом браться за задачку.
Запомните: чем лучше проведён pre mortem, тем меньше шансов, что потом придётся проводить post mortem.
P.S. Эта практика противопоказана беременным женщинам, ипохондрикам и любителям аффирмаций.
😁9💯4✍2🔥1
Недавно нам в бот пришёл вопрос:
"Как часто приходилось работать с B2B? Может, какие-то ошибки часто допускаются в B2B или есть особенности подхода в анализе данных B2B-компаний, которые кажутся тебе интересными?"
Если коротко: в B2B сложно найти стандартные пути и шаблоны для аналитики. Почему? Потому что каждый бизнес тут действительно уникален.
В B2C почти всегда есть юзеры, retention, inventory, и основные метрики можно перенести из одного продукта в другой. Плюс, обычно гораздо больше данных, на основании которых можно принимать решения. И связь между рекламой и ростом пользователей тоже почти всегда легко видно. Все эти закономерности одинаково применимы к интернет-магазину, онлайн банку или очередному клону Тиндера.
А в B2B? Там всё куда сложнее. У SecOps платформы для корпоративных клиентов, legal compliance трекера для финтеха и тулзы для предсказания цен на бирже энергоресурсов из общего только непонимание людьми со стороны, что эти компании вообще делают.
Но есть и хорошие новости. Независимо от размера, трекать вот эти вещи можно и нужно:
✔️ Выручку от клиента.
✔️ Churn / retention rate — не везде актуально, но если актуально хоть в каком-то виде, надо трекать.
✔️ Как клиенты пользуются продуктом: количество запросов, частота основных действий.
✔️ Рекламную аналитику: лиды, success rate — всё то же, что в B2C. Это, конечно, если у вас есть реклама.
Если у компании много клиентов (типа Slack или Zoom), там уже можно развернуться. Такие B2B всё больше похожи на B2C: вместо юзеров — другие компании, но механики схожи, и можно трекать все стандартные штуки типа retention, churn, LTV, и так далее.
А если клиентов три? Вот тут уже начинаются нюансы. Когда каждый клиент — это маленькое чудо (как у нас в ASAO DS сейчас), никаких больших выводов на их основе не сделаешь. Просто данных недостаточно. Здесь поможет только здравый смысл, наблюдательность и понимание, как бизнес устроен в целом.
Какие ошибки встречаются в B2B?
1️⃣ Неправильная оценка масштаба.
У маленьких компаний это выглядит так: "У нас было три лида, один упал, второй пропал, значит, наш conversion rate — 33%." Ну да, конечно.
А у больших — наоборот: игнорирование возможностей. Например, крупная компания вроде Zoom, но с аналитикой на уровне маленького стартапа, где считают каждого клиента уникальным и не смотрят на общую картину.
2️⃣ Недостаток здравого смысла.
Но в целом, эта ошибка встречается всегда и везде.
Итак:
Аналитика данных в B2B — это сложно, но можно. Главное понять, где ты находишься: маленький стартап, крупная компания или что-то между. И не копировать готовые решения, а думать головой.
P.S. Наш дорогой аноним, задавший этот вопрос: если дашь боту чуть больше конкретики, хотя бы индустрию и размер компании, с удовольствием дам советы с ценностью чуть больше, чем у фразы «нормально делай — нормально будет».
Напоминаю про нашу консалтинг-пятиминутку, записаться можно тут💅
"Как часто приходилось работать с B2B? Может, какие-то ошибки часто допускаются в B2B или есть особенности подхода в анализе данных B2B-компаний, которые кажутся тебе интересными?"
Если коротко: в B2B сложно найти стандартные пути и шаблоны для аналитики. Почему? Потому что каждый бизнес тут действительно уникален.
В B2C почти всегда есть юзеры, retention, inventory, и основные метрики можно перенести из одного продукта в другой. Плюс, обычно гораздо больше данных, на основании которых можно принимать решения. И связь между рекламой и ростом пользователей тоже почти всегда легко видно. Все эти закономерности одинаково применимы к интернет-магазину, онлайн банку или очередному клону Тиндера.
А в B2B? Там всё куда сложнее. У SecOps платформы для корпоративных клиентов, legal compliance трекера для финтеха и тулзы для предсказания цен на бирже энергоресурсов из общего только непонимание людьми со стороны, что эти компании вообще делают.
Но есть и хорошие новости. Независимо от размера, трекать вот эти вещи можно и нужно:
Если у компании много клиентов (типа Slack или Zoom), там уже можно развернуться. Такие B2B всё больше похожи на B2C: вместо юзеров — другие компании, но механики схожи, и можно трекать все стандартные штуки типа retention, churn, LTV, и так далее.
А если клиентов три? Вот тут уже начинаются нюансы. Когда каждый клиент — это маленькое чудо (как у нас в ASAO DS сейчас), никаких больших выводов на их основе не сделаешь. Просто данных недостаточно. Здесь поможет только здравый смысл, наблюдательность и понимание, как бизнес устроен в целом.
Какие ошибки встречаются в B2B?
1️⃣ Неправильная оценка масштаба.
У маленьких компаний это выглядит так: "У нас было три лида, один упал, второй пропал, значит, наш conversion rate — 33%." Ну да, конечно.
А у больших — наоборот: игнорирование возможностей. Например, крупная компания вроде Zoom, но с аналитикой на уровне маленького стартапа, где считают каждого клиента уникальным и не смотрят на общую картину.
2️⃣ Недостаток здравого смысла.
Но в целом, эта ошибка встречается всегда и везде.
Итак:
Аналитика данных в B2B — это сложно, но можно. Главное понять, где ты находишься: маленький стартап, крупная компания или что-то между. И не копировать готовые решения, а думать головой.
P.S. Наш дорогой аноним, задавший этот вопрос: если дашь боту чуть больше конкретики, хотя бы индустрию и размер компании, с удовольствием дам советы с ценностью чуть больше, чем у фразы «нормально делай — нормально будет».
Напоминаю про нашу консалтинг-пятиминутку, записаться можно тут
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8✍3💅2
Если вы когда-нибудь смотрели на свой технологический стек и думали: «Почему тут всё горит и стоит столько денег?», вот подсказка: дело не в инструментах, а во внутренних процессах и приоритетах.
Когда продукт, разработка и руководство думают каждый о своем, это превращается в басню Крылова либо в дорогую, сложную и неэффективную систему. Вот как это происходит:
1️⃣ Руководство хочет чего-то эдакого
Кто-то из фаундеров или C-level видит вирусный пост в LinkedIn и решает: «Нам срочно надо внедрить AI» или «Переводим нашу пекарню на блокчейн!». А разработчики потом скотчем прилепляют что-то, что юзеры не просили, но «штука крутая + в питчдеке будет смотреться мощно».
2️⃣ Разработка зацикливается на элегантности
Тем временем разработчики любят так сильно увлечься оптимизацией незначительных элементов или 1000х масштабированием, что забывают про главное: продукт должен работать. Прямо сейчас.
3️⃣ Продакт-менеджер хочет всё вчера
Под давлением руководства продуктовые менеджеры требуют быстрых решений. А такие патчи добавляют ещё больше трещин в фундамент.
Итог? Бюджет куда-то делся, система раздута, а проблемы так и не решены.
Вот жёсткая правда:
Ваш технологический стек — это зеркало ваших приоритетов.
Если руководство, разработка и продукт не согласны друг с другом в том, что важно (спойлер: важна ценность для пользователя), всё разлетается в стороны. Каждый инструмент, каждая строчка кода, каждая фича должны быть привязаны к ясной цели, которую знают все-все приниматели решений или как это po-russki.
Как исправить, если все уже разлетелось:
✅ Начинать с проблемы пользователя. Решает ли нынешний стек эту проблему?
✅ Упрощать. Беспощадно удалять всё, что не добавляет ценности.
✅ Разговаривать словами через рот. Все должны вместе и согласованностроить коммунизм идти к одной цели.
Короче, технолгический стек — это ваши приоритеты в действии. А методология «Лебедь, Рак и Щука» работает еще хуже, чем «Жаба и Гадюка».
Ну и в чем я не прав?
Когда продукт, разработка и руководство думают каждый о своем, это превращается в басню Крылова либо в дорогую, сложную и неэффективную систему. Вот как это происходит:
1️⃣ Руководство хочет чего-то эдакого
Кто-то из фаундеров или C-level видит вирусный пост в LinkedIn и решает: «Нам срочно надо внедрить AI» или «Переводим нашу пекарню на блокчейн!». А разработчики потом скотчем прилепляют что-то, что юзеры не просили, но «штука крутая + в питчдеке будет смотреться мощно».
2️⃣ Разработка зацикливается на элегантности
Тем временем разработчики любят так сильно увлечься оптимизацией незначительных элементов или 1000х масштабированием, что забывают про главное: продукт должен работать. Прямо сейчас.
3️⃣ Продакт-менеджер хочет всё вчера
Под давлением руководства продуктовые менеджеры требуют быстрых решений. А такие патчи добавляют ещё больше трещин в фундамент.
Итог? Бюджет куда-то делся, система раздута, а проблемы так и не решены.
Вот жёсткая правда:
Ваш технологический стек — это зеркало ваших приоритетов.
Если руководство, разработка и продукт не согласны друг с другом в том, что важно (спойлер: важна ценность для пользователя), всё разлетается в стороны. Каждый инструмент, каждая строчка кода, каждая фича должны быть привязаны к ясной цели, которую знают все-все приниматели решений или как это po-russki.
Как исправить, если все уже разлетелось:
✅ Начинать с проблемы пользователя. Решает ли нынешний стек эту проблему?
✅ Упрощать. Беспощадно удалять всё, что не добавляет ценности.
✅ Разговаривать словами через рот. Все должны вместе и согласованно
Короче, технолгический стек — это ваши приоритеты в действии. А методология «Лебедь, Рак и Щука» работает еще хуже, чем «Жаба и Гадюка».
Ну и в чем я не прав?
💯5✍4😁1
Я когда писал про лысины и жопы, вспомнил еще одну историю⬇️⬇️⬇️
В мире стриминг-платформ логика проста:
Микрофон — значит блогер или певец, пушим в рекомендации.
Дилдак — значит контент для взрослых, блокируем немедленно.
Звучит разумно, но на практике…
Предположение, что микрофон — это серебристая/черная штука у рта, а дилдак — что-то цветное совсем в других местах, с реальностью не бьётся. Причём в обе стороны.
Учитывая разнообразие форм и цветов микрофонов, даже опытный модератор иногда путался, что уж говорить об алгоритмах. Поэтому, как и с лысыми головами и ягодицами, этой проблеме пришлось выделить отдельный проект. Интересно, сколько из участвовавших в нём саентистов гордо добавили это в своё CV.
Так что если вас в следующий раз позовут на запись подкаста, подумайте: а микрофон ли это перед вами? 😉
В мире стриминг-платформ логика проста:
Микрофон — значит блогер или певец, пушим в рекомендации.
Дилдак — значит контент для взрослых, блокируем немедленно.
Звучит разумно, но на практике…
Предположение, что микрофон — это серебристая/черная штука у рта, а дилдак — что-то цветное совсем в других местах, с реальностью не бьётся. Причём в обе стороны.
Учитывая разнообразие форм и цветов микрофонов, даже опытный модератор иногда путался, что уж говорить об алгоритмах. Поэтому, как и с лысыми головами и ягодицами, этой проблеме пришлось выделить отдельный проект. Интересно, сколько из участвовавших в нём саентистов гордо добавили это в своё CV.
Так что если вас в следующий раз позовут на запись подкаста, подумайте: а микрофон ли это перед вами? 😉
😁12✍3🔥2💅2
Друзья, сегодня без вайба достигаторства, легкий хи-хи контент
10 заповедей стартапера
1. Не называй себя «Uber для [чего угодно]».
2. Не пивоть каждый раз, когда выходит новый хайповый тренд.
3. Не говори «Мы маленький стартап», если нанимаешь людей как Amazon.
4. Не делай редизайн офиса с блекджеком и шлюхами как только инвесторы дали денег.
5. Не говори, что ты лучше ChatGPT, если это не так (а это не так).
6. Не заменяй нормальную стратегию скоростью.
7. Не упахивай команду под лозунгом «стартап-атмосферы».
8. Не называй свой питчдек емким, когда там тупо не хватает данных.
9. Не называй сверхурочный неоплачиваемый проект хакатоном.
10. Почитай отца, мать, а также свой питчдек несколько раз перед отправкой инвестору.
Аминь 🙏
Что я забыл?
10 заповедей стартапера
1. Не называй себя «Uber для [чего угодно]».
2. Не пивоть каждый раз, когда выходит новый хайповый тренд.
3. Не говори «Мы маленький стартап», если нанимаешь людей как Amazon.
4. Не делай редизайн офиса с блекджеком и шлюхами как только инвесторы дали денег.
5. Не говори, что ты лучше ChatGPT, если это не так (а это не так).
6. Не заменяй нормальную стратегию скоростью.
7. Не упахивай команду под лозунгом «стартап-атмосферы».
8. Не называй свой питчдек емким, когда там тупо не хватает данных.
9. Не называй сверхурочный неоплачиваемый проект хакатоном.
10. Почитай отца, мать, а также свой питчдек несколько раз перед отправкой инвестору.
Аминь 🙏
Что я забыл?
🔥8😁8💯6✍2
Коллеги! Я ничего не знаю про LinkedIn. Но, к сожалению, если у тебя есть маленький бизнес и большие амбиции, рано или поздно приходится разбираться.
Так что пару месяцев назад я решил наконец привести свой профиль в порядок, чтобы люди заходили, читали мои посты и думали: «Как бы так постараться дать ему денег?»
Мне в этом помогли Community Sprints — две недели интенсивного LinkedIn-дрочева, после которых я:
✅ Смог писать посты осмысленнее, чем «На меня упала наковальня, вот как этот опыт помог мне в B2B-продажах»
✅ Удалил сертификат «Русского медвежонка» из профиля (ребята заставили)
✅ Больше не говорю «делюсь инсайтом»
✅ Перестал переписываться с людьми как бот (успешно выдаю себя за человека)
Теперь я получаю свои заслуженные пять лайков, но с гораздо большим пониманием, как это всё работает. И если вам тоже пора приводить лидов и свой профиль в порядок, вот ссылка на их новый поток.
Так что пару месяцев назад я решил наконец привести свой профиль в порядок, чтобы люди заходили, читали мои посты и думали: «Как бы так постараться дать ему денег?»
Мне в этом помогли Community Sprints — две недели интенсивного LinkedIn-дрочева, после которых я:
Теперь я получаю свои заслуженные пять лайков, но с гораздо большим пониманием, как это всё работает. И если вам тоже пора приводить лидов и свой профиль в порядок, вот ссылка на их новый поток.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7✍6💅2😡1
Сложно поверить, но даже на Дане бывают пятна.
Одну из первых моих hiring ошибок я вспоминаю до сих пор. Это была PhD из Гарварда по дата саенсу. Гарвард! PhD! Эффект ореола застелил мне глаза.
Тогда я ещё не умел толком проводить интервью, спросил какие-то базовые штуки — а сам уже мысленно оформлял оффер.
Что пошло не так?
Красные флаги, которые я проигнорировал:
➡️ На собеседовании она ничего не спросила про бизнес. Всё свелось к обсуждению моделей и технических деталей. Слово "value" для неё существовало только в уравнениях.
➡️ Тестовое задание. Вместо того чтобы решить его простой моделью, был выбран какой-то безумный путь с нейросетями. Правильно? Да. Эффективно? Абсолютно нет.
➡️ Уже в первые дни работы появились проблемы со здравым смыслом. Например, ее не смущало, что в результате расчетов вероятность определенных событий оказывалась отрицательной.
➡️ Невероятно медленно. То, что нормальный мидл делает за день, она растягивала на недели, оборачивая всё в ненужные сложности.
Я тогда взял двоих в команду, и 50% этой команды оказались провалом. Попытки обучить и донести что-то про бизнес-контекст и что один юзер не может приносить ежедневно несколько тысяч долларов выручки оказались бесполезными.
Как раз примерно тогда я четко понял, что есть два дата саенса — академический и бизнесовый. И если кто-то их путает, это может стоить не только времени. Я об этом уже писал вот тут, если интересно.
И если вы на интервью впечатлились чужим титулом, дипломом или именитым работодателем, помните: ваши ожидания — это только ваши ожидания.
Одну из первых моих hiring ошибок я вспоминаю до сих пор. Это была PhD из Гарварда по дата саенсу. Гарвард! PhD! Эффект ореола застелил мне глаза.
Тогда я ещё не умел толком проводить интервью, спросил какие-то базовые штуки — а сам уже мысленно оформлял оффер.
Что пошло не так?
Красные флаги, которые я проигнорировал:
Я тогда взял двоих в команду, и 50% этой команды оказались провалом. Попытки обучить и донести что-то про бизнес-контекст и что один юзер не может приносить ежедневно несколько тысяч долларов выручки оказались бесполезными.
Как раз примерно тогда я четко понял, что есть два дата саенса — академический и бизнесовый. И если кто-то их путает, это может стоить не только времени. Я об этом уже писал вот тут, если интересно.
И если вы на интервью впечатлились чужим титулом, дипломом или именитым работодателем, помните: ваши ожидания — это только ваши ожидания.
Please open Telegram to view this post
VIEW IN TELEGRAM
💯8✍3🔥3
Почему я стараюсь держаться подальше от корпораций
Когда-то давно я работал в большом европейском корпорате и руководил проектом по трансформации и автоматизации аналитики.
Это звучит красиво, но на деле выглядело так:
✅ Куча отделов, куча инструкций. И одна тупее другой. Например: «Собери метрики, засунь в Excel вот в эти вот столбики, добавь вот эту формулу сюда, покрутись три раза вокруг своей оси, найди адрес почты в утке, а утку в зайце, и потом отправь циферки на имейл».
✅ Никакой единой системы. Просто живые люди руками пересылают файлы, двигают данные из колонки A в колонку J и надеются, что ничего не сломается.
✅ Ошибки на каждом этапе. Потому что где люди — там косяки.
И вот я трачу месяцы, чтобы автоматизировать этот цирк и убрать человеческий фактор. Всё сделал, конечно, но аллергия и нервный тик остались.
Потому что когда корпорация огромная, клиенты важные, деньги бешеные, а внутри — вот это вот всё, возникает вопрос: Как? Зачем? Почему?!
Мой личный топ момент: документация, в которой требовалась обратная совместимость с перфокартами. В 21 веке.
Ну ладно, может, это была аномалия? Может, в других корпорациях всё нормально… Расскажите, я не знаю, я к ним больше на пушечный выстрел не подойду. Но если вы корпорация с кучей денег, которые вам некуда девать, то подумаю. 😉
Когда-то давно я работал в большом европейском корпорате и руководил проектом по трансформации и автоматизации аналитики.
Это звучит красиво, но на деле выглядело так:
И вот я трачу месяцы, чтобы автоматизировать этот цирк и убрать человеческий фактор. Всё сделал, конечно, но аллергия и нервный тик остались.
Потому что когда корпорация огромная, клиенты важные, деньги бешеные, а внутри — вот это вот всё, возникает вопрос: Как? Зачем? Почему?!
Мой личный топ момент: документация, в которой требовалась обратная совместимость с перфокартами. В 21 веке.
Ну ладно, может, это была аномалия? Может, в других корпорациях всё нормально… Расскажите, я не знаю, я к ним больше на пушечный выстрел не подойду. Но если вы корпорация с кучей денег, которые вам некуда девать, то подумаю. 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
😁9💯6🔥2
Я много чем недоволен и постоянно пишу про свои и чужие ошибки и про то, как все кругом неправы и все делают неправильно.
Но мой психотерапевт говорит, что надо обращать внимание на светлые стороны, так что вот вам позитивный пост с зелеными флагами дата-саентистов.
Вот несколько вещей, которые сразу показывают, что перед вами не просто человек, знающий Python, а реально толковый специалист:
1. Думает про проблему, а не про инструменты
Если человек сразу кидается обсуждать модели и техстак, не вникая в бизнес-контекст, — это тревожный звоночек. Хороший дата-саентист в первую очередь спрашивает:
📌 Какую проблему мы решаем?
📌 Где это встроится в бизнес?
📌 Что эта модель должна делать и как её результаты повлияют на компанию?
2. Выбирает самое простое решение
Если задаёшь тестовое, а человек сразу начинает строить LLM на коленке, вместо того чтобы решить задачу в три строки, — это плохой знак. Настоящие профессионалы не пытаются забивать гвоздь микроскопом. Они находят минимально сложный и при этом рабочий вариант.
3. Задаёт вопросы и не боится сказать «я не знаю»
Хороший специалист не боится уточнять, если что-то не понимает. Он не будет давать любое решение лишь бы что-то сказать. Вместо этого он спросит:
💡 Какие допущения мы можем сделать?
💡 Я бы начал с того и этого, но для более детального ответа мне надо больше данных.
💡 Я не вижу очевидного решения, не хватает контекста.
Это признак зрелости, а не слабости.
4. Быстро адаптируется, если условия задачи меняются
Классический прием, который я очень люблю применять на техсобесах: берём ту же задачу, но добавляем новые ограничения или меняем условия (например, цель задачи). Как меняется решение? Если кандидат тут же соображает, какие части модели или данных надо пересмотреть, — отлично. Если он начинает паниковать и пытаться натянуть старое решение на новую ситуацию — это уже не очень. Подход к таким задачам как раз поможет понять, как кандидат понимает бизнес.
(Есть такое, что я под видом зеленых флагов опать напихал кучу красных? Я старался как мог, но я хейтер по натуре).
Но мой психотерапевт говорит, что надо обращать внимание на светлые стороны, так что вот вам позитивный пост с зелеными флагами дата-саентистов.
Вот несколько вещей, которые сразу показывают, что перед вами не просто человек, знающий Python, а реально толковый специалист:
1. Думает про проблему, а не про инструменты
Если человек сразу кидается обсуждать модели и техстак, не вникая в бизнес-контекст, — это тревожный звоночек. Хороший дата-саентист в первую очередь спрашивает:
📌 Какую проблему мы решаем?
📌 Где это встроится в бизнес?
📌 Что эта модель должна делать и как её результаты повлияют на компанию?
2. Выбирает самое простое решение
Если задаёшь тестовое, а человек сразу начинает строить LLM на коленке, вместо того чтобы решить задачу в три строки, — это плохой знак. Настоящие профессионалы не пытаются забивать гвоздь микроскопом. Они находят минимально сложный и при этом рабочий вариант.
3. Задаёт вопросы и не боится сказать «я не знаю»
Хороший специалист не боится уточнять, если что-то не понимает. Он не будет давать любое решение лишь бы что-то сказать. Вместо этого он спросит:
💡 Какие допущения мы можем сделать?
💡 Я бы начал с того и этого, но для более детального ответа мне надо больше данных.
💡 Я не вижу очевидного решения, не хватает контекста.
Это признак зрелости, а не слабости.
4. Быстро адаптируется, если условия задачи меняются
Классический прием, который я очень люблю применять на техсобесах: берём ту же задачу, но добавляем новые ограничения или меняем условия (например, цель задачи). Как меняется решение? Если кандидат тут же соображает, какие части модели или данных надо пересмотреть, — отлично. Если он начинает паниковать и пытаться натянуть старое решение на новую ситуацию — это уже не очень. Подход к таким задачам как раз поможет понять, как кандидат понимает бизнес.
(Есть такое, что я под видом зеленых флагов опать напихал кучу красных? Я старался как мог, но я хейтер по натуре).
💯7✍2🔥2
Раньше бизнесам в целом и дата-саентистам в частности приходилось с нуля делать почти все — от инфраструктуры до ML-моделей. Сегодня ландшафт изменился:
📌 Готовые решения теперь есть почти для всего
Когда-то, чтобы встроить ML в продукт, приходилось писать кастомные пайплайны, решать инфраструктурные задачи и тонко настраивать модели. Теперь для большинства задач есть готовые библиотеки, third-party сервисы и огромное количество best practices. Если e-commerce стартапу захотелось сделать чат-бот, больше не надо создавать под это отдельную команду и решать кучу инженерных проблем. Сейчас ты просто берешь готовый API и интегрируешь.
📌 Изобретать новые модели нужно только deep-tech компаниям
Если бизнес не строит свою R&D-лабораторию, то нет никакого смысла изобретать велосипед. Всё, что реально работает, уже давно описано, запротоколировано и доступно в виде фреймворков и сервисов. Ключевой навык теперь — не писать модели с нуля, а понимать, когда и как их применять.
📌 Data Science становится про продукт, а не про код
Технические задачи не исчезли, но теперь они гораздо более стандартизированы. В итоге ценность создают не те, кто может собрать модель с нуля на ассемблере, а те, кто понимает, зачем она нужна и какую проблему решает.
Время метафоры: раньше каждый столяр сначала должен был сначала сам придумать и сделать себе набор инструментов, а потом только начать строгать. Сегодня все можно изучить онлайн и купить на маркетплейсе — кроме понимания, какую мебель делать лучше, каким именно способом и кому она вообще нужна. И именно из-за того, что инструменты доступны практически каждому, технический порог входа ниже, а значит и конкуренция уходит в область продукта и бизнеса.
И такие навыки, конечно, будут цениться всегда.
📌 Готовые решения теперь есть почти для всего
Когда-то, чтобы встроить ML в продукт, приходилось писать кастомные пайплайны, решать инфраструктурные задачи и тонко настраивать модели. Теперь для большинства задач есть готовые библиотеки, third-party сервисы и огромное количество best practices. Если e-commerce стартапу захотелось сделать чат-бот, больше не надо создавать под это отдельную команду и решать кучу инженерных проблем. Сейчас ты просто берешь готовый API и интегрируешь.
📌 Изобретать новые модели нужно только deep-tech компаниям
Если бизнес не строит свою R&D-лабораторию, то нет никакого смысла изобретать велосипед. Всё, что реально работает, уже давно описано, запротоколировано и доступно в виде фреймворков и сервисов. Ключевой навык теперь — не писать модели с нуля, а понимать, когда и как их применять.
📌 Data Science становится про продукт, а не про код
Технические задачи не исчезли, но теперь они гораздо более стандартизированы. В итоге ценность создают не те, кто может собрать модель с нуля на ассемблере, а те, кто понимает, зачем она нужна и какую проблему решает.
Время метафоры: раньше каждый столяр сначала должен был сначала сам придумать и сделать себе набор инструментов, а потом только начать строгать. Сегодня все можно изучить онлайн и купить на маркетплейсе — кроме понимания, какую мебель делать лучше, каким именно способом и кому она вообще нужна. И именно из-за того, что инструменты доступны практически каждому, технический порог входа ниже, а значит и конкуренция уходит в область продукта и бизнеса.
И такие навыки, конечно, будут цениться всегда.
💯6✍4🔥3