Краткая история большинства стартапов

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

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

Проблема в том, что эта механика одинаково хорошо работает вообще для любых проектов, включая те, у которых есть фатальные проблемы в виде отсутствия масштабируемой модели дистрибуции и так называемого product/market fit. При этом отсутствие product/market fit еще не означает, что у проекта не может быть прогресса и роста. Если основатели очень сильно этого хотят, то рост будет. Но, условно, на 1% в месяц. Поэтому мы и видим массу зомбообразных проектов, которые, вроде как, существуют уже давно, но находятся примерно в том же состоянии, что 3-4 года назад.

Для примера, представим себе команду, делающую сервис для ведения заметок. Обычно с ними происходит следующее:

1) Команда смотрит на Evernote и понимает, что сделать намного лучше не просто можно, а «давно пора»

2) Команда делает прототип и показывает его ранним пользователям (Early Adopters)

3) Получив фидбек, команда вдохновляется, корректирует ранее составленный роадмап и начинает "колбасить фичи", которых, естественно, должно быть много с учетом того, что фидбек получался от матерых power-юзеров, коими и являются Early Adopters

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

5) Разработка - это длительные процесс, поэтому незаметно пробегает месяцев 12-15. Все это время продажи инкрементально растут, а пара сотен баксов в месяц превращается в пару тысяч баксов в месяц

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

7) Первые эксперименты по платному привлечению показывают, что экономика не сходится, то есть затраты на привлечение одного пользователя превышают количество денег, которые он впоследствии платит за продукт. Значит, нужно экспериментировать с финансовой моделью (подписка, все дела) и повышать ретеншн.

8) Спустя несколько месяцев упорной работы над оптимизацией workflow, A/B-тестированием онбоардингов и прочей работы над продуктом, удается повысить ретеншн и ARPU. Платное привлечение теперь выходит в ноль или даже в небольшой плюс. Вот только оказывается, что трафика этого мало, а экономика сходится далеко не во всех каналах.

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

Именно поэтому и существует тот самый статистический факт: «В среднем, каждый проект, который вообще выживает, тратит не менее 7 лет на то, чтобы стать устойчивым бизнесом».

В чем проблема такого проекта? В том, что команда слишком долго пребывает в заблуждении, что улучшение качества продукта приведет к росту продаж. Это фатальная ошибка, поскольку улучшение качества продукта приведет к продажам, а не к росту продаж. Почувствуйте разницу, она важна. Сущности «продажи» и «рост продаж» - это как «скорость» и «ускорение». Разные физические свойства объекта в пространстве.

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

Поэтому «модель дистрибуции» - это такая же важная сущность, как и «продукт», облик которой должен быть сформирован на начальной стадии вместе с обликом продукта. В случае с заметочным сервисом (и вообще любым сервисом тематики Productivity) команда могла бы поступить, например так:

1) Выбираем чёткую целевую аудиторию: например, разработчики программного обеспечения

2) Исходя из этого реализуем продукт с фокусом на потребности этой аудитории (тёмная тема, подсветка кода, соответствующие функции категоризации и так далее)

3) Ключевой особенностью продукта делаем то, что он заточен на коллаборацию разработчиков с другими участниками команд разработки (другие разработчики, дизайнеры, менеджеры, системные архитекторы и т.д.)

4) В качестве финансовой модели выбираем классический подход тарифных планов и подписку

Обратите внимание, что в таком сценарии есть два позитивных момента:

1) Четкая целевая аудитория. Чем чётче ЦА, тем более заточенные конкретно на неё функции мы реализуем. Это по определению повышает общее «качество» продукта

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

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

Два простых заключительных вывода:

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

2) Без понимания и апробирования работоспособности модели дистрибуции лучше даже не начинать процесс полноценного создания продукта. Убедиться, что модель дистрибуции работает, стоит еще на ранних версиях MVP. "Качество продукта" почти не влияет на количество продаж.

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

P.S. Я завел Telegram-канал, в котором пишу про различные аспекты создания ИТ-продуктов (да и любых продуктов, в общем-то) и как организовывать созидательный процесс. Присоединяйтесь.

#продукты #стартапы