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

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

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

Проблема в том, что эта механика одинаково хорошо работает вообще для любых проектов, включая те, у которых есть фатальные проблемы в виде отсутствия масштабируемой модели дистрибуции и так называемого 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-канал, в котором пишу про различные аспекты создания ИТ-продуктов (да и любых продуктов, в общем-то) и как организовывать созидательный процесс. Присоединяйтесь.

0
20 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Денис Еськин

нет повести печальнее на свете...

Ответить
Развернуть ветку
Anton Barinov

хорошая статья, интересная

Ответить
Развернуть ветку
Максим В

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

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

Может напишете пару советов как стимулировать пользователей приводить новых?

Ответить
Развернуть ветку
Dmitriy Tarasov
Автор

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

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

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

Но есть пара других способов стимуляции сетевого эффекта:

1) Сарафанное радио в случае историй успеха. Например, когда люди знакомятся друг с другом в Tinder, то уходят из сервиса, но в разговорах со знакомыми рассказывают, что познакомились со своей парой там. В результате тем, кто слышит эти истории интересно попробовать самим.

2) Истории с доступом по приглашениям. В этом случае заинтересованные пользователи пишут в социальных сетях, спрашивая инвайт. Тоже сарафанное радио.

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

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

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

Ответить
Развернуть ветку
Алеоп

2/3 поста прям про нас, интересно)

Ответить
Развернуть ветку
Наташа Кондакова

Мне понравилась аналогия со «скоростью» и «ускорением») вообще приятно читать, спасибо за статью!

Ответить
Развернуть ветку
R.A.

Отлично. Подписка

Ответить
Развернуть ветку
Darya Khay

Лайк. Очень полезно.

Ответить
Развернуть ветку
Роман Величкин

А доказательства есть? Пока что выглядит как гипотетические рассуждения без каких-либо фактов.

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

Ответить
Развернуть ветку
Dmitriy Tarasov
Автор

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

Пара примеров:
Dropbox: появился как инструмент для хранения персональных данных, переориентировался на коллаборацию

Notion: появился как инструмент для персональных заметок (замена Evernote), переориентировался на коллаборацию

Todoist: появился как инструмент для персонального планирования, добавил коллаборацию и активно развивает это направление

Craft: появился как персональный заметочник, переориентировался на коллаборацию.

Последние, кстати - победители Apple Design Awards, а основатель - выходец из InVision с огромным нетворком. Что-то в этом деле понимает.

Что касается вашего сравнения MMO vs Single Player, то и в SaaS ведь коллаборативные сервисы никого не убивают. Просто зарабатывают на два порядка больше и растут быстрее.

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

Ответить
Развернуть ветку
Роман Величкин
то и в SaaS ведь коллаборативные сервисы никого не убивают. Просто зарабатывают на два порядка больше и растут быстрее

Это тоже не показатель. Успешный коллаборативный сервис может и зарабатывает больше, но рядом с ним куча погибающих конкурентов. А рынок обычных сервисов может быть свободнее и легче для захвата.
Ну это я просто рассуждаю, не претендую на истину. Ну как и вы :) Или нет?

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

победители Apple Design Awards

Странно, что у Apple в то же время лучшие игры победители - сингловые, а не мультиплеерные сервисы. Это я к тому, что такие награды - это не показатель.

Ответить
Развернуть ветку
Dmitriy Tarasov
Автор

Единственный показатель - это рынок.

Ответить
Развернуть ветку
Роман Величкин

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

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

Ответить
Развернуть ветку
Dmitriy Tarasov
Автор

Ну извините, не угодил 😅

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

В Стиме постоянно в топе по одновременному количеству игроков сингловые игры.

Ответить
Развернуть ветку
Dmitriy Tarasov
Автор

Только если на релизе. Очень странный довод

Ответить
Развернуть ветку
Роман Величкин

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

Ответить
Развернуть ветку
Pavel One

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

Ответить
Развернуть ветку
17 комментариев
Раскрывать всегда