Продуктовый подход: почему агентству так трудно его освоить

Две разные логики работы

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

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

Отсюда разные вопросы на планёрке. В проекте спрашивают «успеваем ли к сроку». В продукте — «что мы узнали за неделю и что это меняет».

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

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

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

Из чего состоит работа над продуктом

Основу заложили несколько известных методологий. Стив Бланк описал Customer Development — проверку того, что у клиента действительно есть проблема, до того как строить решение. Эрик Рис в книге «Бережливый стартап» 2011 года предложил цикл «создать — измерить — научиться» и понятие MVP. Клейтон Кристенсен популяризировал идею Jobs to be Done: человек «нанимает» продукт, чтобы сделать определённую работу.

Цель всех этих инструментов одна — найти соответствие продукта рынку, product-market fit. Пока его нет, всё остальное вторично: масштабировать продажи продукта, который не нужен, бессмысленно.

Гипотезы вместо требований

• Сформулировать, какая проблема есть у какого сегмента.
• Поговорить с потенциальными клиентами до того, как писать код.
• Сделать самую дешёвую проверку: лендинг, прототип, ручную услугу.
• Заранее решить, какая цифра будет считаться успехом.
• Отказаться от гипотезы, если цифра не достигнута, а не подгонять объяснения.

Пивот как нормальная часть пути

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

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

Какие метрики смотреть при продуктовом подходе

В проекте главная цифра — процент выполнения плана. В продукте смотрят на поведение пользователей. Активация показывает, сколько новых пользователей дошли до первой пользы. Удержание, или retention, — сколько вернулись через неделю и через месяц. Экономику описывают LTV, доход с клиента за всё время, и CAC, стоимость его привлечения.

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

Объяснять ценность самому

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

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

Продуктовый взгляд на матрицу услуг

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

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

Мой опыт и ошибки

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

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

Что бы я сделал иначе

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

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

Как агентству начать работать по-продуктовому

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

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