Компании Treasure Data потребовалось десять лет, чтобы пройти путь от технологического стартапа до бизнеса с облачной выручкой более 100 миллионов долларов ARR. Однако этот успех не был линейным: на отметке в 10 миллионов долларов команда столкнулась с жесткой конкуренцией со стороны технологических гигантов, что вынудило её совершить радикальный и болезненный пивот. Генеральный директор компании Казуки Ота (Kazuki Ohta) подробно рассказал, как трансформация из сложной платформы больших данных в прикладное маркетинговое решение спасла компанию от гибели и вывела её в лидеры нового рынка.
🚀 От академических суперкомпьютеров к облачному Hadoop 0:05
Казуки Ота начинал свою карьеру как специалист по высокопроизводительным вычислениям (HPC). Будучи приглашенным исследователем в Аргоннской национальной лаборатории в Чикаго, он работал с суперкомпьютером Blue Gene, объединявшим около полумиллиона вычислительных узлов. Этот комплекс использовался для сложных симуляций — от аэродинамических до ядерных, генерируя колоссальные объемы информации. Именно тогда Ота осознал силу больших данных и задумался о необходимости демократизации подобных технологий, которые в то время были доступны лишь правительственным структурам.
Вторым источником вдохновения для будущего предпринимателя стала технология open-source Hadoop, изначально созданная Yahoo по образу внутренних архитектур Google. Ота активно включился в разработку патчей для проекта и начал развивать Hadoop-сообщество в родной Японии. Проект, начавшийся как встреча трех инженеров-энтузиастов, за два года разросся до комьюнити в 3 000 человек.
Общаясь с участниками сообщества, Казуки Ота выделил три главные проблемы, с которыми сталкивался бизнес при попытке внедрить аналитику больших данных:
- Фактор времени: развертывание инфраструктуры занимало до 18 месяцев, при этом показатель успеха проектов составлял всего 30%.
- Кадровый голод: для обслуживания систем требовались ученые и специалисты с докторскими степенями (PhD). Если ИТ-гиганты уровня Facebook или Twitter могли нанимать таких сотрудников, то традиционный бизнес был не в состоянии их удержать.
- Огромные капитальные затраты: покупка специализированных серверов, сетевого оборудования и систем хранения требовала колоссальных авансовых инвестиций.
В 2011 году у Оты родилась простая идея: развернуть Hadoop в облаке, чтобы клиенты могли мгновенно анализировать данные по модели ежемесячной подписки без капитальных затрат и найма штата ученых. В возрасте 25 лет он отправился в Кремниевую долину, где вместе с сооснователями Хиро и Садой начал привлекать ангельские инвестиции. По воспоминаниям спикера, инвесторы тогда реагировали с недоумением, задавая вопрос: «Кто вообще станет отправлять свои данные в облако?». В то время облачные технологии еще не стали мейнстримом, и это был огромный риск.
📈 Ложный успех: 10 миллионов долларов ARR и «долина смерти» 6:36
Стартап официально выпустил продукт на рынок в четвертом квартале 2011 года. За первые два года Treasure Data номинально выросла с нуля до 5 миллионов долларов ARR. Однако за красивым фасадом скрывалась опасная реальность: 96% этой выручки обеспечивали всего две гигантские сделки (на 3,6 млн и 1,2 млн долларов), которые основатели закрыли лично благодаря своим связям. Тем не менее, этот показатель позволил привлечь раунд серии A и масштабировать процессы.
На тот момент продукт компании состоял из трех ключевых компонентов:
- Сбор данных: с помощью разработанного стартапом open-source инструмента Fluentd, который собирал более 80 миллиардов записей в месяц.
- Хранение: масштабируемое колоночное хранилище на базе Hadoop MapReduce, обрабатывавшее в общей сложности 360 миллиардов записей.
- Анализ: интеграция с популярными BI-инструментами и дашбордами.
Команда позиционировала себя как универсальная облачная платформа больших данных (Big Data PaaS). К концу 2014 года (период серии B) компания вышла на показатель в 2,5 миллиона долларов выручки за квартал и преодолела планку в 10 миллионов долларов ARR. В штате работало около 50 сотрудников, распределенных между Калифорнией (Маунтин-Вью) и Токио, а база насчитывала более 120 клиентов. Продукт имел отличную валовую маржинальность в 72%, а аналитики Gartner включили компанию в список «Cool Vendor».
Несмотря на внешнее благополучие, Казуки Ота признается, что на отметке в 10 миллионов долларов ARR руководство компании ощущало, будто они медленно движутся на «кладбище стартапов». Причиной было полное отсутствие реального соответствия продукта рынку (Product-Market Fit). Компания нанимала успешных вице-президентов по продажам и маркетингу из крупных ИТ-структур, но они не могли стабильно обеспечивать пайплайн и выполнять квоты. Из всех нанятых сейлз-менеджеров (AE) лишь один стабильно закрывал планы, да и то только при непосредственном участии основателей стартапа. Процесс продаж оставался ручным и немасштабируемым.
🌪️ Угроза со стороны гигантов и разрушение метрик 13:29
Главная опасность для молодой компании пришла со стороны облачных гигантов. На второй-третий год существования Treasure Data корпорация AWS представила свое облачное хранилище Amazon Redshift, а Google выпустила движок BigQuery. Стартап оказался в ситуации, когда ему пришлось напрямую конкурировать с инфраструктурными продуктами платформ, обладавших безграничными ресурсами.
Как следствие, ключевые показатели эффективности (KPI) Treasure Data начали стремительно ухудшаться:
- Падение среднего чека (ASP): переговоры с потенциальными клиентами неизменно начинались с вопроса, почему они должны платить Treasure Data, если Amazon и Google предлагают бесплатную регистрацию и дешевые триалы.
- Рост оттока (Churn): небольшие компании массово уходили к конкурентам из-за более низких цен и силы брендов Google и AWS.
- Стагнация чистой удерживаемой выручки (NRR): крупные клиенты, использовавшие платформу для аналитики игр или телематики, постепенно запускали процессы внутренней оценки альтернатив от гигантов.
- Замедление цикла продаж: сделки стали длинными, а процент их закрытия резко упал из-за необходимости постоянно доказывать преимущества в сравнении с Redshift или BigQuery.
Процесс продаж оставался невероятно сложным. Поскольку Treasure Data продавала горизонтальную платформу, менеджерам приходилось каждый раз кастомизировать решение под конкретного заказчика: выявлять его боли, подключать консалтинг, собирать дашборды и внедрять софт. Сложность и стоимость пресейла оставались на уровне семизначных сделок, в то время как реальная цена, которую готов был платить рынок, стремительно падала.
🧭 Развилка Джерри Янга: два пути борьбы с гигантами 17:15
Понимая критичность ситуации, основатели обратились за помощью к пулу своих инвесторов и советников, среди которых были Билл Тай и сооснователь Yahoo Джерри Янг. Во время короткой 30-минутной встречи Джерри Янг сформулировал для стартапа две возможные стратегии развития:
- Начать строить технологические надстройки над собственной платформой, уйти на уровень выше — в слой бизнес-приложений — и решать конкретную конечную проблему клиента (End-to-End).
- Привлечь огромный объем капитала (более миллиарда долларов) и вступить в прямую ценовую войну с Amazon и Google, соревнуясь в производительности инфраструктуры на доллар затрат.
По второму пути пошла компания Snowflake, сумевшая привлечь огромные раунды. Однако, как прагматично отмечает Казуки Ота, основатели Treasure Data не имели в Долине статуса «звездных» предпринимателей с громкими именами, поэтому они понятия не имели, как собрать миллиард долларов под масштабное видение. Единственным жизнеспособным вариантом действий остался первый путь — переход к бизнес-приложениям.
Команда провела детальный сравнительный анализ двух моделей:
| Критерий | Горизонтальная платформа | Конечное бизнес-приложение (App) |
|---|---|---|
| Фокус продукта | Широкий спектр инженерных задач | Узкая, но завершенная бизнес-проблема |
| Маркетинг и продажи | Сложное позиционирование, разное для каждого клиента | Понятная ценность, предсказуемый и повторяемый шаг продаж |
| Зависимость от партнеров | Высокая (нужны системные интеграторы) | Низкая (процесс контролируется внутри компании) |
| Маржинальность бизнеса | Падает до 20–30% под давлением гигантов | Держится на уровне 70% и выше |
| Удерживание клиента | Высокое (платформа становится фундаментом ИТ-систем) | Ниже (приложение проще заменить аналогом) |
По мнению Оты, хотя инвесторы традиционно любят масштабные истории про «универсальные платформы», для стартапа ранней стадии модель конечных приложений является куда более эффективным способом выхода на рынок благодаря предсказуемости продаж.
🛠️ Рождение CDP и внутренняя «война» 22:17
Чтобы понять, какое именно приложение нужно рынку, команда провела масштабный аудит текущей клиентской базы. Выяснилось, что 90% заказчиков использовали платформу Treasure Data для анализа поведения пользователей: данных с сайтов, мобильных приложений, CRM и социальных сетей. Более того, хотя формальным покупателем софта выступал ИТ-департамент, реальным заказчиком и спонсором аналитики в 90% случаев являлся отдел маркетинга, которому данные требовались для удержания клиентов, кросс-продаж и привлечения трафика.
Основываясь на этих выводах, команда разработала надстройку над своей платформой, которая выполняла три базовые задачи: идентификацию пользователей из разных источников, их сегментацию и активацию маркетинговых кампаний.
Историческая справка: В 2017 году Казуки Ота наткнулся на формирующуюся карту рынка MarTech, где зарождалась небольшая категория из 20–30 игроков под названием Customer Data Platform (CDP). Спикер отмечает, что этот рынок сразу ему понравился: на нем полностью отсутствовали Amazon, Google или Microsoft. После изнурительной борьбы с гигантами конкуренция с небольшими MarTech-стартапами казалась руководству Treasure Data легкой прогулкой.
Период перехода, занявший от 18 до 24 месяцев, Казуки Ота называет «военным временем». Внутри компании, где работало около 100 человек, вспыхнуло сопротивление. Лишь единицы верили в идею смены фокуса. Доходило до серьезных организационных драм: один из вице-президентов, категорически несогласный с решением, пытался через совет директоров добиться увольнения самого Оты с поста руководителя продуктового направления.
Чтобы преодолеть кризис, Ота отказался от попыток переубедить всех сотрудников. Вместо этого он создал изолированную мини-команду «размером в одну пиццу»: он сам, второй сооснователь, фронтенд-разработчик, бэкендер и ML-инженер. Они нашли 2–3 лояльных клиента, создали для них рабочий прототип и получили первые контракты с реальной ежемесячной выручкой (MRR). Как только на доске появились логотипы известных брендов с понятными денежными суммами, сопротивление внутри компании сошло на нет.
Для подстраховки отдел разработки параллельно запустил коммерческую Enterprise-версию инструмента Fluentd. Это направление за два года выросло с нуля до 1 миллиона долларов ARR, но через три года руководство приняло решение закрыть его, чтобы сфокусировать 100% ресурсов на более быстрорастущем направлении CDP.
🚀 Прыжок к $100M ARR и новая модель продаж 26:49
Пивот потребовал жестких и непопулярных решений. Стартап осознанно заморозил инновации для своей старой базы клиентов, сидевших на платформе больших данных, что спровоцировал прогнозируемый отток. Компанию покинули многие старые сотрудники-инженеры, которые приходили создавать сложную инфраструктуру Big Data, а не маркетинговый софт.
Команда полностью переписала маркетинговые материалы, убрав из лексикона весь сложный технический жаргон, поскольку теперь продажи велись не техническим директорам, а директорам по маркетингу (CMO). Изменился и профиль торговых представителей (AE): вместо технических специалистов компания начала нанимать выходцев из Adobe, Salesforce и Oracle, умеющих общаться с бизнесом.
Результаты превзошли ожидания:
- Ускорение роста: за три года компания взлетела с 25 до 100+ миллионов долларов ARR. Скорость роста бизнеса увеличилась с вялых 20–30% до 70% и более в год.
- Увеличение маржинальности: валовая маржа выросла до уровня конца 70-х годов.
- Рост среднего чека (ASP): вопреки опасениям, средняя стоимость контракта выросла до 350–400 тысяч долларов в год.
- Масштабируемость: цикл продаж сократился, так как процесс теперь полностью контролировался командой Treasure Data без оглядки на инфраструктурных партнеров. Сроки выхода новых сейлз-менеджеров на плановые показатели эффективности существенно сократились.
Сегодня в категории CDP насчитывается более 150 игроков. Однако парадокс заключается в том, что старая технологическая платформа больших данных, которая чуть не погубила стартап в борьбе с AWS, теперь стала его главным конкурентным преимуществом. Она позволяет Treasure Data легко справляться с тяжелыми инфраструктурными требованиями крупных корпоративных клиентов, чего не могут сделать «легкие» MarTech-конкуренты.
🏛️ Стратегия платформы плюс убийственное приложение 31:08
На основе пройденного пути Казуки Ота сформулировал важный тезис для ИТ-индустрии: чтобы построить бизнес масштабом более 100 миллионов долларов ARR, компании жизненно необходима синергия собственной платформы и сильного прикладного приложения.
Он приводит исторические аналогии:
- iPhone бесполезен без базовых встроенных приложений (почта, браузер, сообщения) — никто не купил бы просто операционную систему iOS с предложением написать софт самому.
- Windows завоевала мир благодаря тому, что Microsoft владела главным прикладным офисным пакетом (Excel, Word, PowerPoint).
- Salesforce построила огромную экосистему force.com, но начинала с понятного killer-app в виде CRM-системы (Sales Cloud).
- ServiceNow развивает глобальную платформу автоматизации, начав с конкретного приложения для ИТ-менеджмента (ITSM).
Сейчас Treasure Data использует эту стратегию для дальнейшей экспансии, опираясь на трехмерную матрицу роста Salesforce: продукт (What), регион (Where) и индустрия/сегмент (Who). Поскольку базовый рынок CDP растет в среднем на 30% в год, а компания стремится удерживать планку роста в 50–60% для сохранения высокой оценки инвесторами, стартап запустил стратегию «Beyond Marketing» (За пределами маркетинга). Мощности платформы данных теперь упаковываются в новые специализированные приложения для отделов продаж и контакт-центров.
В завершение Казуки Ота дает совет основателям бизнеса: в моменты кризиса важно доверять интуиции и иметь авторитетных советников, которые могут выступить в роли «врачей» для заболевшего стартапа. Главное — не бояться принимать сложные, порой одиночные решения и доказывать правоту не спорами, а быстрыми результатами малых команд.