Продакт оптимизирует то, что уже работает. Он может заниматься воронками, полировать фичи и так далее, но всё его обучение вообще никак не предполагает создания продукта. Только улучшение чего-то, что уже работает.

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

Продакт — это тот, кто 20 лет назад был проджектом. Это люди, которых вы нанимаете, чтобы они сделали вам проект. Основная функция продакта — оптимизировать продукт. Упрощая, они кастдевят, придумывают гипотезы, быстро ставят эксперименты, оптимизируют воронки и собирают совещания.

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

Вы, возможно, будете смеяться, но разработчик заменяет продакта на старте продукта и показывает большую эффективность. Я проверил это численно.

Чуть подробнее — про то, что происходит на запуске проектов

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

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

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

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

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

И вот в этом месте я попробовал назначать разработчиков руководителями параллельно основному процессу. У меня была гипотеза, что разработчик будет хуже понимать маркетинговую часть, но он не будет терять времени на совещания, коммуникации внутри команды и так далее. Он может просто быстро взять и запилить, а мы можем быстро закинуть туда трафик и посмотреть. Даже разговаривать особо не надо.

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

Тогда одновременно я попробовал ещё один подход и начал нанимать продактов со сдельной оплатой за эксперимент. Оффер был из серии «даём 7к USD на эксперимент». Дедлайн проверки — 45 дней. 3к USD — компенсация за проверку в карман. 4к USD — на организацию: создать сайт, сделать РК, купить трафик.

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

И так было на каждом этапе. Люди, которые в штате, воспринимают всё как работу. Кажется, что штатному продакту даже комфортно разводить какую-то бурную деятельность. Внешние же делают так: «Да не буду делать отчёт на 50 страниц и презентацию на команду. Вот вам отчёт на три страницы: здесь всё нужное для эксперимента, и я готов мириться с неопределённостью вот тут и тут».

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

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

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

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

Получаются простые штуки, на которых можно тестировать, если качественно и быстро наливать трафик.

Всё, что нам в нашей модели остаётся делать, — это сверить по метрикам, интересно нам в эту сторону копаться или нет.

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

Напомню, что у нас каждый разработчик — это человек, который когда-то что-то ещё делал на рынке, стал успешным, захотел иметь свой проект и пришёл к нам пилить своё за зарплату. Мы берём 60–80 % доли сразу, но зато даём всю инфраструктуру. Вот тут — подробно, почему это рационально, когда у вас есть семья и дети.

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

Грубо говоря, когда вы сначала ограничены ресурсами, а потом — инвесторами и их поиском, то за год не получится протестировать пять идей, потому что нет денег на трафик. С нами можно протестировать 5–10 разных продуктов. Это означает большее матожидание крупного выигрыша. Дальше вопрос заключается в том, кто и как считает и насколько кто понимает, что можно заработать в реальном «свободном» венчурном проекте. Тут я ещё раз отправлю вас к рассказу в прошлом посте про «котлету» денег и про то, как её забрать.

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

Один из наших самых успешных разработчиков-ИТ-предпринимателей, кстати, это человек, который имел оборотку в два миллиона долларов в месяц на своём проекте у нас в студии. Мы решили, что можно вкладываться и расти до 20 миллионов в месяц, наняв ему CEO для американского рынка. В итоге выяснилось, что он там просто не нужен, потому что без него всё равно получается быстрее даже с поправкой на косяки по незнанию. Второй раньше руководил большим проектом на 150 человек: он шёл снизу вверх с нуля и учился делать каждую ступеньку руками. Его уже нигде не объехать на кривой кобыле. Он тестирует быстрее всего, потому что ничего ни у кого не спрашивает.