У вайбкодера нет покупателя

Вайбкодер сегодня может за вечер собрать то, на что раньше маленькой команде нужна была неделя.

Экран. Авторизация. База. Оплата. Красивый лендинг. Почти готовый продукт.

И где-то здесь возникает странная пауза: а покупатель у него есть?

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

Покупатель. У которого есть проблема, привычный способ её решать, цена этой проблемы и готовность что-то поменять.

Создатель быстро собирает продукт, но место покупателя остаётся пустым

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

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

Сейчас часть этого пути сжалась до дней, а иногда до часов.

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

Если мы ускорили delivery, но не ускорили понимание клиента, получаем больше готовых вещей, которые никому особенно не нужны.

Не трагедия. Просто дорогой способ учиться.

Программное обеспечение — только часть продукта. Важная, но недостаточная.

Для себя я бы записал формулу так:

Продукт = потребность + клиенты + ПО.

Уберём потребность — останется технология в поиске применения.

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

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

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

Кажется, что LLM лучше всего умеют писать код. Это самая заметная часть.

Но если дать модели только задачу «сделай приложение», она ускорит ровно то место, где у нас и так уже всё относительно хорошо.

Гораздо интереснее использовать её до кода.

Например, чтобы:

Это не отменяет разговор с клиентом.

LLM может помочь заметить паттерн. Но не почувствует, где собеседник говорит вежливо, а где у него действительно болит. И уж точно не заплатит за нас.

Разговор с потенциальным клиентом начинается раньше, чем открывается ноутбук

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

Первое — не «кому может пригодиться наш продукт?». На этот вопрос почти всегда хочется ответить: всем.

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

Второе — спрашивать не про будущее, а про прошлое.

Не «Купили бы вы такую функцию?». Вежливый человек обычно ответит так, чтобы не обидеть.

Лучше:

Третье — искать не согласие, а обязательство.

Согласие звучит так: «Интересно, покажите, когда будет готово».

Обязательство выглядит иначе: человек даёт доступ к процессу, зовёт следующего участника, готов тестировать, оставляет предоплату, подписывает пилот. Не обязательно сразу деньги. Но что-то, за что ему уже нужно отвечать.

И ещё одна фраза, которую я слышал слишком часто: «Мы точно купим, если добавить ещё вот это».

Иногда за ней действительно спрятано важное требование. Но чаще это безопасный способ не принимать решение сейчас. Вместо «нет» человек предлагает автору продукта ещё немного поработать.

Я бы не спорил и не считал такую фразу обещанием. Лучше уточнить спокойно: если эта функция появится, кто будет принимать решение, какой бюджет уже есть и готовы ли мы зафиксировать пилот или дату оплаты? Ответ на эти вопросы обычно показывает, что именно перед нами: реальная потребность или вежливая отсрочка.

Это не повод давить на человека. Это способ отличить любопытство от реальной ценности.

На Track To мне понравилась простая рамка: ставить цель не «запустить продукт», а «получить первые оплаты» — и разложить путь на 30–90 дней.

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

Это важное смещение фокуса.

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

На том же Track To есть вполне практичный первый шаг: выбрать одного клиента, сформулировать оффер, собрать около двадцати контактов и начать ручные разговоры. Не потому, что двадцать — магическое число. А потому, что «найти клиентов» в такой формулировке перестаёт быть большой тревожной задачей и превращается в следующий измеримый шаг.

Вайбкодинг делает ещё одну вещь опасной: слишком легко влюбиться в результат.

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

Мне кажется, в этот момент нужно делать наоборот — показывать раньше.

Не обязательно отдавать доступ всем. Можно руками закрыть часть процесса. Можно предложить сервис вместо продукта. Можно взять один сценарий и провести человека по нему вместе.

Команда проверяет прототип вместе с клиентом, а не после долгой разработки

Смысл не в том, чтобы скорее получить похвалу. Смысл — быстрее выяснить, где гипотеза ломается.

Что именно непонятно? Какая часть не нужна? Кто принимает решение? Почему привычный процесс кажется безопаснее? Что человек готов поменять прямо сейчас?

Ответы на эти вопросы часто важнее, чем следующая версия модели или ещё один фреймворк.

Я не призываю разработчиков бросить разработку и всем уйти в интервью.

Хороший продукт всё ещё должен работать. Скорость delivery даёт большое преимущество: меньше времени между гипотезой и проверкой, меньше денег на ошибку, больше попыток.

Но это преимущество работает только в связке с discovery.

Если discovery идёт раз в квартал в отдельной презентации, а delivery каждый день быстро строит новые фичи, команда просто быстрее удаляется от клиента.

Нормальный цикл, как мне кажется, выглядит так:

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

Но направление задаёт не модель. Его задаёт человек, который достаточно близко подошёл к клиенту, чтобы заметить проблему до того, как начал её красиво программировать.

Практическая рамка для первых продаж: Track To.

#ИИ #Вайбкодинг #Продукт #Discovery #Delivery #Стартап #Клиенты