💥 Разберу ваш питч-дек за ЛЮБУЮ сумму

Месяц назад я впервые провёл разборы питч-деков в формате «плати сколько хочешь».

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

Решил — надо повторить!

Почему вообще я?

⁃ Выиграл все питч-конкурсы в России и парочку зарубежных
⁃ Привлёк $5M+ на pre-seed и seed раундах

Зачем мне это?

⁃ Реально кайфую, когда могу быть полезен
⁃ Насмотренность
⁃ Ну и немного плюсов в карму ✨

В чём подвох?

Да ни в чём. Просто люблю помогать другим — вот и всё.

Хочешь записаться?

Вот ссылочка: https://forms.gle/XQaxKCqj4jC5fUYr9

Записаться можно до 27 июня.

П.С. Если ты уже фандрейзишь — приходи.
Если только готовишься — тем более приходи.
Будет честно, по делу и с шутками за 200!

Почему европейский венчур такой скучный

Каждый раз, когда сравниваю фандрайзинг в США и в Европе, хочется обнять европейского фаундера.

В Америке вполне возможно прийти к инвестору с сильной командой и авантюрной идеей, и получить несколько миллионов. Есть капитал, есть культура риска, и есть понимание, что рано — это ок.

В Европе же всё иначе.
У фаундера уже готов продукт, стабильный рост, выручка месяц к месяцу, команда. И он такой: «Пожалуйста, можно 450 тысяч фунтов?»
А в ответ: «А можно ещё разок перепроверить все дашборды? А почему у вас NRR 145%, а не 152%? Могу предложить 50K и подарочную карту Amazon».

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

Я не говорю, что в Штатах всё идеально. Но если у фаундера сильный профиль, нормальный продукт и реальный опыт — шанс получить деньги там выше. Просто потому что люди готовы рисковать, по крайней мере пока что.

А в Европе можно быть отличным фаундером, с крутым треком и внятной моделью — и всё равно сражаться за каждый цент.

Так что когда в следующий раз увидите, как стартап в Америке поднимает seed на 10 миллионов за презентацию — помните: это не обязательно потому, что он лучше.

Кто-то родился с серебряной ложкой во рту, а кто-то с шилом в попе (пост-самотерапия, не про бизнес).

Есть люди, которые умеют отдыхать. У них получается просто не работать и при этом не чувствовать себя виноватыми. Завидую.

У меня так не выходит. Каждая попытка устроить отпуск начинается одинаково: «Вот сейчас отключусь, наберусь сил, буду просто отдыхать». Через пару часов дней становится скучно, а еще через день я уже незаметно открываю ноутбук и начинаю что-то тыкать по кнопочкам. Не из тревоги, а от скуки.

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

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

Необязательно быть гедонистами и лежать на пляже с коктейлем. Но необходимо отдыхать подходящим способом. Для меня это «Что? Где? Когда?» и (уже больше 20 лет) Warcraft 3.

В комментариях можно обозвать меня трудоголиком и рассказать про свои планы на летние каникулы.

Почему стартапу без технического фаундера больно

Представьте, что вы решили открыть частную клинику. Сняли классное здание, сделали стильный брендинг, наняли медсестёр и даже интернов. Пациенты записываются, деньги пошли — вроде всё супер. Но (ожидаемо) есть нюанс: никто из вас не врач. Ни медицинского образования, ни понимания, как лечить людей и что для этого нужно.

Примерно такая же история часто происходит со стартапами.

Два фаундера придумали продукт, отлично понимают рынок, умеют продавать, даже находят деньги. Всё вроде классно, кроме одного — оба гуманитарии по призванию и недоразумению никто из них не разбирается в технике и разработке.

Что обычно делают такие фаундеры?
Нанимают разработчиков (в штат или на аутсорс) и начинают ставить им задачи напрямую. И вот тут начинаются проблемы.

Фаундеры ставят задачи, как понимают их сами. Разработчики же воспринимают эти задачи буквально — потому что продуктовая логика это не их работа. В итоге бизнес говорит на одном языке, разработчики пишут код на другом. Между ними нет никого, кто мог бы нормально переводить.

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

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

Именно поэтому технический фаундер так важен. Ему не обязательно писать код самому или разбираться в каждой детали. Я, например, никогда не был фронтендером. Но я могу понять, правильно ли ребята решили задачу и не развалится ли вся архитектура через месяц.

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

О чём ещё стоит договориться с кофаундером на берегу

Недавно был пост про то, о чём фаундерам лучше договориться заранее. Вот ещё одна штука, о которой многие почему-то забывают.

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

Допустим, фаундеры решили: у них двоих по 30%, ещё 30% идёт инвесторам, и 10% — в пул для сотрудников. Если нужно привлечь ещё инвестиции или нанять очень крутого человека, то все доли уменьшаются пропорционально. Не должно быть такого, что «ну, это твоя зона ответственности, так что ты от своей доли и отдавай».

Зачем это нужно?

Потому что кофаундеры всегда должны быть на одной стороне. Иначе возникает конфликт интересов, когда кому-то выгоднее одно решение, а кому-то другое. Это как с родителями маленького ребёнка: нельзя, чтобы ребёнок бегал от мамы к папе и проверял, кто из них добрее.

Стартап — это тот же ребёнок (регулярно кричит и обделывается). И если у фаундеров изначально не совпадают интересы, все решения будут приниматься исходя не из того, что лучше для компании, а из того, что выгоднее кому-то одному.

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

Понятно, что в жизни случается разное — например, кто-то уходит, кто-то теряет интерес. На такие случаи есть отдельные механики вроде вестинга. Но базовая логика простая: пока кофаундеры работают вместе, они должны быть заодно. Потому что в стартапе и так проблем будет хватать — нет смысла пытаться отхватить больший кусок пирога, пока это просто липкое тесто на пути в духовку.

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

1. «Наконец-то я уйду из корпората и перестану отчитываться за каждый чих».
На самом деле, в стартапе отчетности, бюрократии и согласований будет не меньше, просто тут ещё нет никаких процессов, и всё это придется мучительно строить самим. С нуля.

2. «Главное — это бизнес и маркетинг, а технология — вторично».
Если кто-то из кофаундеров однажды переустановил винду, это ещё не делает его CTO. Если стартап не закрывает техническую компетенцию, в какой-то момент у него развалится не только код, но и вся бизнес-модель.

3. «Сейчас сделаем продукт, и люди сами придут».
Просто хорошего продукта недостаточно. Сам по себе он никому не нужен. Без грамотного продвижения он так и останется красивым никому неизвестным кодом.
На практике часто выигрывают не идеальные, а средние продукты с сильным маркетингом и отлаженным дистрибуцией.

4. «Move fast and break things».
Классный слоган, но на практике полная ерунда. Да, первые прототипы можно делать из говна и палок. Но в продакшен это попадать не должно. Если заранее не думать про масштабирование и качество, рано или поздно настанет техническая жопа.

5. «Мы подняли денег на год — значит, целый год можем просто пилить продукт».
На самом деле, даже если вы очень хорошо всё просчитали, денег всегда нужно больше. Привлечённые деньги заканчиваются быстрее, чем кажется, и искать следующие раунды придётся раньше, чем хотелось бы — иначе придётся бегать по рынку с горящей жопой горящими глазами и паникой.

Есть тут у меня first- или second- time фаундеры? Что я забыл?

Как запустить классный продукт, который никому не нужен

Есть писатели, которые пишут только для себя, в стол — потому что писательство для них хобби, или они боятся критики, или еще по какой-то причине. И некоторые стартаперы берут с них пример — делают продукт, которым никто не воспользуется.

Почему? Потому что фаундеры часто настолько концентрируются на самом продукте, что совсем не думают о дистрибуции — то есть о том, как клиенты узнают о продукте и почему решат дать ему шанс.

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

Выделили какой-то бюджет на рекламу, думая: «Продукт же крутой, люди подтянутся, дальше пойдёт органика». В итоге весь бюджет сгорает на неоптимизированных Google и Facebook ads, а среди пользователей — только сами фаундеры, пара друзей и их мамы.

В B2B — аналогичная история. Стартап приходит в большую компанию и говорит: «Мы очень умные, дайте нам доступ к вашей чувствительной дате, положитесь на нас полностью. Да, мы познакомились вчера, но мы правда классные». Компания резонно спрашивает: «А почему мы вообще должны вам доверять и рисковать?» И стартап остаётся с гениальной технологией и нулём клиентов.

В обоих случаях проблема не в продукте. Продукт может быть отличным. Но чтобы он стал востребованным, нужно чётко понимать, как его продавать, доносить до аудитории и мотивировать первых пользователей попробовать.

Иначе есть классный продукт, про который никто не узнает — и синдром Кассандры в комплекте.

Когда перестать улучшать продукт и заняться делом

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

С улучшением продукта работает примерно так же.

В начале улушать легко и приятно: вложили месяц работы, получили +20% к метрикам. Ещё месяц — и прирост уже +3%. Ещё месяц — и уже едва 0,5%.

Это называется diminishing returns. Чем больше сил вложено, тем меньше эффект от каждого следующего шага.

Проблема в том, что команды часто не умеют вовремя остановиться. Иногда это выглядит как бесконечное улучшение одной и той же модели, фичи или метрики. Например, весь data science в банке занимается только скорингом. Да, это самая важная модель, и улучшать её всегда приятно. Но если вся команда месяцами до блеска натирает праздничное столовое серебро (уже и так неплохо работающий скоринг), то никто не моет посуду, из которой едят каждый день. То есть никто не делает, например, банальную модель churn prediction, которой вообще сейчас не существует, хотя даже простейшая её версия сразу дала бы заметный эффект.

Тут нет универсального рецепта, как вовремя остановиться. Нужно просто понимать: если долго улучшать что-то одно, и результат уже почти не меняется — самое время отвлечься и посмотреть вокруг. Возможно, прямо сейчас рядом лежит что-то простое и недоделанное, от чего толку будет в разы больше.

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

AI заменит людей? Нет, он сделает их ещё важнее

Меня недавно спросили, заменит ли искусственный интеллект программистов и продуктологов.

Это, конечно, гадание на кофейной гуще, но мой короткий ответ: нет, не заменит. AI не уберёт людей из процесса создания продуктов, он просто резко поднимет уровень абстракции.

Было время, когда программисты должны были писать low-level код на ассемблере. Потом появились Python и прочие языки с кучей библиотек и модулей. Программисты перестали заниматься низкоуровневыми проблемами и стали продуктивнее. Хотя олдскульные ребята это уже не считают «настоящим программированием», на деле это позволило профессионалам сильно ускориться.

Дата-саентистам сегодня не нужно кодить модель с нуля — взял готовое решение, собрал из кубиков продукт. Представьте, если бы сейчас все пришлось писать руками — продукты появлялись бы в десять раз медленнее.

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

Теперь человек оперирует абстракциями более высокого уровня. Понятно, что low-level скиллы частично атрофируются, а если вдруг случится «Дюна», то и топовые ребята действительно уже ничего не сделают руками.

Зато прямо сейчас продукты станут появляться быстрее и будут гораздо глубже. Например, игры станут интереснее и больше по масштабу. Маленькая студия недавно выпустила игру «Clair Obscur: Expedition 33», которая взорвала всем мозг. Ребята точечно использовали AI и автоматизацию, чтобы сосредоточиться на сюжете и персонажах, а не тратить время на рутину. Потом, когда появилось время, заменили AI-текстуры на проработанные вручную. Так же поступили авторы игры Bellwright — пока игра в раннем доступе и постоянном улучшении, они сделали AI-озвучку, чтоб не терять деньги и время на поиск актеров.

Но когда AI станет ещё глубже встроен в рабочие процессы, роль человека изменится ещё сильнее. И здесь возникает интересный вопрос: сможем ли мы через несколько лет вообще называть человека, который уже сам не пишет код, программистом? Возможно, эволюция отойдёт настолько далеко от изначального понимания программирования, что придётся придумывать новые термины и роли.

Хоть кое-что понятно уже сейчас: если кто-то продолжит делать вид, что ничего не происходит, и будет программировать так же, как в 2020-м, вот его AI заменит практически стопроцентно.

Что случится, когда контент станет Персональным?

Кастомизация контента уже стала привычной: персональные рекомендации, индивидуальные ленты соцсетей и новостей, ультра-мега-таргетированная реклама.

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

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

Вместо общей сказки для всех детей или одной игры для всех AI создаст уникальную историю или игровой мир конкретно под запросы и интересы каждого. Игра подстроится под любимый сюжет и механики, книга — под любимый жанр и персонажей.

С одной стороны, круто: вместо того чтобы скучать над стандартной школьной программой, ребёнок получает сказку, где он сам — главный герой. Взрослый получает игру или фильм, который идеально отражает его настроение и интересы прямо сейчас.

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

Это не хорошо и не плохо, просто интересно, куда всё это может привести. Не знаю, как у вас, а у меня от этой мысли лёгкий экзистенциальный дискомфорт.

Почему вайб-кодинг не заменит реальное программирование (пока что)

Я пользуюсь Cursor почти каждый день, но недавно решил ради интереса поработать с ним так, как это делают вайб-кодеры: просто писал промпты и просил нейросеть фиксить баги. Специально не использовал свои технические знания, чтобы посмотреть, насколько далеко я смогу зайти.

И вот, шаг за шагом, простая изначально штука стала превращаться в монстра. Cursor фиксит одно, забывает другое, создаёт кучу внутренних противоречий и с каждым «fix it» только усложняет код. В итоге моя штука стала делать то, что от нее требуется, но как огромный, некрасивый и нестабильный прототип, который 100% сломается на любом edge-кейсе.

Пугает то, что сейчас большое количество «AI-фаундеров» кодит именно так.

Проблема всех вайб-кодинг инструментов (Cursor, Copilot и т.д.) не в том, что они не работают — они работают отлично, но только когда человек точно знает, чего хочет.

Для опытного разработчика, который понимает код и просто не хочет тратить время на рутину, Cursor — лучшее, что придумали за последнее время. Он действительно в разы повышает продуктивность.

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

Короче, вайб-кодинг сейчас хорош для простейших задач или ранних прототипов. Но если хочется контролировать, что происходит с продуктом, лучше понимать, как устроен код.

Иначе получится машина, которая едет, но в любой момент может резко свернуть в стену.

Чем опасны black box решения в стартапах

Врачи много лет изучают, как работает человеческое тело во всех его деталях и сложностях. Хотя потом многие из них становятся участковыми терапевтами, и в основном просто выписывают парацетамол.

Космонавтов перед полётом на МКС учат вручную чинить отсеки станции — нельзя отправить человека в космос, если он не понимает, как устроен корабль, хоть в реальности «жесть» происходит редко и существует большая система проверок и контроля.

В разработке продуктов должна быть та же логика. Кто-то в команде обязан понимать, как именно работает все, чем вы пользуетесь.

Причём здесь вайб-кодинг?

В разработке продуктов есть понятие «black box» — когда неизвестно, как именно работает используемое решение. Использовать black box удобно и просто. Но часто очень опасно.

Допустим, есть продукт, написанный с помощью вайб-кодинга. Вначале всё идеально. Быстро, дёшево, рабочий сервис, деньги капают.

Проблемы начинаются позже, когда что-то идёт не так.

Например, 29 февраля всё ломается, потому что модель «не подумала» про високосный год. Или начинает накапливаться незаметная ошибка, которая месяцами остаётся незамеченной, а потом резко роняет весь сервис.

Или — реальный случай — сервис вдруг решает «съесть» $100 тысяч за ночь из-за неоптимального запроса в BigQuery. Никто не заметил вовремя, потому что никто не понимал, что происходит внутри.

Важно не путать: использовать готовые и известные third-party решения — абсолютно нормально, это осознанный выбор + всегда есть кто-то, кто знает, как это решение устроено. Но вот использовать и покупать продукт, написанный на коленке только через вайб-кодинг — это как лечь на операцию к человеку, у которого очень красивый халат, много подписчиков в инстаграме, который говорит много умных слов, но не имеет соответствующего образования, и который, до кучи, и отвечать ни за что не будет.

В стартапах следует придерживаться той же логики, что и в медицине и космической авиации. Использовать готовые решения — удобно и часто правильно. Но кто-то в компании обязательно должен знать, как всё работает под капотом, даже если кажется, что парацетамола хватит на все случаи жизни.

Конец эпохи cookies: что будет с рекламой?

Долгие годы в мире рекламы всё решалось просто: у рекламщиков было море данных о каждом человеке.

Cookies фиксировали, какие сайты посещал, что смотрел и что собирался купить. А технические данные устройства (модель телефона, версия ОС, браузер) помогали дорисовать портрет: условный старенький iPhone 8 — один сегмент аудитории, новый iPhone Pro — совсем другой.

Вместе это давало почти магическую точность. Зашёл один раз на сайт за робот-пылесосом — и ещё месяц реклама этого пылесоса гоняется за тобой по всему интернету.

Но времена меняются. Браузеры и устройства начали прятать эту информацию. Например, iPhone с 14-й модели маскирует все телефоны под один шаблон. А cookie-free режимы больше не экзотика для параноиков и любителей режима инкогнито — многие браузеры включают их по умолчанию. Плюс всё жёстче работают privacy-регуляции вроде GDPR.

Для AdTech-компаний, которые строили свой бизнес на cookies и данных устройств, это удар. Вместо точного профиля остаётся набор косвенных сигналов, из которых можно лишь предполагать, кто перед тобой.

Что это значит на практике?

Теперь игра идёт по закону больших чисел. Например, человек заходит в Candy Crush. Рекламная биржа видит только первые цифры IP, примерную модель телефона и браузер. Этого недостаточно, чтобы понять, хочет он новые кроссовки или нет. Но если собрать миллионы таких пользователей и научиться выжимать максимум даже из крошечных намёков, можно повысить точность таргета на 0,01% — и это уже принесёт большие деньги.

Проблема в том, что анализировать такие слабые сигналы в реальном времени — это не «если человек искал пылесос — показать пылесос». Это дорогие алгоритмы, сложные модели и большие данные.

Реклама будет работать, но она уже не будет такой прямолинейной, как при cookies. А войти на этот рынок без серьёзной инфраструктуры и дата-команды станет почти невозможно — мелкие агентства просто не выживут.

Как убить аналитику ещё до старта

Однажды к нам пришел разработчик мобильных игр с миллионами скачиваний: «Сделайте нам динамическую персонализированную настройку сложности, чтобы игроки дольше оставались».

Чтобы оценить проект, мы пропросили их прислать нам снэпшот данных — дали конкретный список того, какие данные нужны.
Они пропали на пару недель собирать данные, потом вернулись с Excel-табличкой. В файле — одна колонка и несколько десятков строк: конверсия с уровня 1 на уровень 2, с уровня 2 на уровень 3…
Мы спрашиваем: «А где сырые события? Что конкретно делал игрок? Где клики, ретраи, покупки?»
Ответ: «Мы это не собирали. Только конверсию считали».

Такие данные хороши для отчёта, но из них невозможно восстановить поведение конкретного игрока. Модель учить просто не на чем.

И теперь, чтобы дойти до персонализации, им, учитывая нынешнее состояние их бэкенда, сначала надо год пилить систему сбора данных с нуля. И потратить на это плюс-минус сотни тысяч долларов.

Хранить сырые данные с запасом — дёшево. Не хранить их — дорого. Очень дорого. Особенно когда они понадобятся для задач, которые ещё вчера казались «лишними»: рекомендации, персонализация и, конечно, мой любимый churn prediction.

Данные нужны не «для галочки». Это задел на будущее. А если их нет, будущее может не наступить.

Data-driven на заборе написано

Сейчас каждая вторая компания гордо пишет в презентациях, питчах и сайтах, что она data-driven.

На деле это часто значит, что где-то лежит Excel с цифрами, в который никто толком не заглядывает.

Что такое настоящий data-driven:
1. Данные реально влияют на решения. Не раз в полгода, а постоянно, вшиты в процессы. Например, просела конверсия. В одной компании это решали бы совещанием и перекрашиванием баннера, «надо попробовать». А в другой открыли дашборд, нашли, что проблема только в одном сегменте, и быстро переделали оффер под него.
2. Выстроена аналитика. Метрики считаются одинаково во всех отделах, данные унифицированы и валидируются. А не так, что в одном отделе retention rate считается на один день, в другом — на неделю, а в третьем — на NULL.
3. Есть автоматизация. Рекомендательные системы, модели прогнозирования, другие продукты, которые работают без ручного управления.
4. Есть культура оунершипа. У каждого отчёта, модели и процесса есть человек, который знает, как оно устроено, и несёт за это ответственность. Чтобы все эти вещи не воспринимались как статуи с Острова Пасхи — вроде не падают, но кто, как и зачем сделал — никто не знает.
5. Данными пользуются все. Не только дата-саентисты, но и продажи, маркетинг, операционка. И не в формате «мне ассистент прислал распечатку скриншота дэшборда».

Если этого нет, то решения в компании по-прежнему принимаются на глаз.

Почему стартапу мало просто сделать продукт

Когда фаундеры думают о запуске стартапа, они обычно представляют себе что-то вроде: «Вот мы придумали классную идею, написали код, и оно сразу заработало». Особо прошаренные понимают, что надо будет найти клиентов, готовых платить за этот продукт. Но об одном аспекте обычно забывают почти все first-time фаундеры.

Помимо очевидных задач вроде разработки, дизайна и продуктовой логики, есть ещё огромный пласт скучной бюрократии и compliance-требований, которые люди склонны недооценивать или просто не видеть.

Допустим, фаундер делает какой-нибудь финтех-продукт. И прежде чем написать хоть одну строчку полезного кода, придётся пройти через мучительный квест по интеграции десятка сторонних продуктов и стандартов. Тут и ISO 27001, и SOC2, и GDPR, и куча других красивых сокращений, смысл которых сводится к тому, чтобы данные пользователей не утекли, а компания не развалилась ещё до запуска.

На практике это означает, что с самого старта в стартапе должен появиться человек, который вместо кода будет месяцами выстраивать процессы: системы мониторинга, системы контроля доступа, системы логирования каждого чиха и вздоха. Каждый сотрудник должен пройти секьюрити-тренинг, на каждом ноутбуке будет стоять отдельный софт для мониторинга и защиты, а любое действие с кодом будет требовать нескольких уровней согласований.

Это ещё не всё: бесконечные документы, процессы, тесты, внутренние проверки и аудит. И это до того, как компания выпустила хоть что-то живое.

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

Поэтому важно сразу понимать: стартап — это не просто продукт, но и огромный пласт бюрократии, compliance, аудита и согласований на каждый (второй) чих. Всё как у больших корпораций, только с одним отличием: в корпорациях эти процессы хотя бы уже выстроены, а в стартапах их приходится сквозь пот, кровь и слезы собирать прямо на ходу.

Знаете эти наклейки в супермаркете на овощах: «органическое», «экологически чистое». Которые на деле ничего не значат, просто морковки с такими наклейками зачастую меньше, грязнее и дороже?

Так вот, с лейблом data-driven на компании всё то же самое. Красивый ярлык, который любят клеить, даже если внутри никакой data culture нет.

А вот где она реально есть — это сразу видно:

1. Доступность и прозрачность.
Если маркетологу нужен отчёт, а его держит у себя аналитик из соседнего отдела и присылает раз в месяц — это не data culture. В нормальной среде есть дашборд, он сам обновляется, и каждый смотрит туда, когда нужно.

2. Единая система.
Когда одна и та же метрика считается разными отделами по-разному — в одном месте с одними фильтрами, в другом без, в третьем с какой-то ещё логикой — на выходе всегда будут три разных числа. В нормальной системе метрики считаются единообразно, и все понимают, что именно за ними стоит.

3. Валидность.
Регулярные проверки, что данные актуальны и корректны. Если в воронке продаж где-то по ошибке поменяли одно поле, и это аукнулось на всех отчётах, проблема должна быть найдена сразу, а не через квартал.

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

5. Использование в работе.
Данные должны быть не для отчётности, а для действий. Если продукт-менеджер видит, что конверсия просела в одном сегменте, он не идёт «поменять баннер, потому что так кажется», а запускает гипотезу, проверяет её и смотрит результат в тех же данных.

Когда в компании есть все эти процессы, то есть и data culture. Без нее есть только данные, но пользы от них столько же, сколько от диплома «Русского медвежонка» на собеседовании — вроде бы очень полезная вещь, но почему-то не помогает.