Founder School S3E4

Сегодня мы поговорим о претотипировании (pretotyping) — наборе техник, позволяющих быстрее тестировать идеи. Этот подход помогает сократить временные затраты и получить достоверную информацию о востребованности той или иной идеи или функции.

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

Когда я рассказываю о претотипировании, всегда начинаю с реальных примеров. Один из них — кейс Telegram. Несколько месяцев назад в разделе управления каналом появилась кнопка Buy Ads и баланс звёздочек. Механика проста: за качественный контент получаешь звёздочки, тратишь их на рекламу, привлекаешь новых подписчиков и снова зарабатываешь звёздочки — получается самоподдерживающийся цикл.

Я кликнул на новую кнопку, но увидел лишь сообщение: «Функция появится в ближайшие недели». Это предупреждение оставалось там несколько месяцев. В итоге функция действительно заработала, но меня заинтересовал сам подход.

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

Мы тоже применяем этот приём в своих продуктах — он помогает запускать только действительно нужные функции, экономя время и ресурсы команды.

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

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

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

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

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

Третий кейс - мой личный опыт с первой версией продукта Onsa, которую я создал на одном из хакатонов. Это был простой Telegram-бот, который по ссылке из LinkedIn генерировал подробную анкету с рекомендациями, как подготовиться к сейлз-звонку с конкретной компанией. После звонка бот анализировал транскрипт, помогая улучшить результаты.

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

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

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