Как проверить идею SaaS, прежде чем написать хоть одну строку кода

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

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

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

Почему строить сразу кажется продуктивным — и обычно таковым не является

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

Беда в том, что рабочий экран почти ничего не говорит о том, верна ли идея. Можно построить красивый, безупречный продукт для проблемы, которой ни у кого нет, и он будет так же мёртв, как и уродливый. Код — это ответ на вопрос «как мы это доставим?», а не «нужно ли это кому-нибудь?» Тратить месяцы на первый вопрос, не ответив на второй, — это и есть то, как хорошие инженеры строят элегантные решения вымышленных проблем.

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

Найдите единственное допущение, способное похоронить всё

Каждая идея SaaS опирается на стопку убеждений, и они не одинаково опасны. Некоторые безопасны — «люди пользуются почтой», «малый бизнес не любит бумажную волокиту». Другие — это ставки, от которых зависит всё предприятие, и если они ошибочны, остальное уже не имеет значения. Задача валидации — не проверить всё. Её задача — найти самое рискованное допущение и атаковать именно его первым.

Чтобы его найти, запишите свою идею одним предложением: «[эти люди] испытывают [эту проблему] достаточно остро, чтобы платить за [это решение] вместо [того, что делают сейчас]». Затем безжалостно спросите себя: какое слово в этом предложении, окажись оно ложным, потопит идею? Обычно это не решение. Это вопрос, достаточно ли проблема болезненна, чтобы за неё платить, или сможете ли вы вообще достучаться до этих людей по приемлемой цене.

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

Говорите с людьми — но делайте это правильно

Самое полезное, что вы можете сделать, — это поговорить с людьми, у которых, как вам кажется, есть эта проблема. Не с друзьями, не с другими основателями — с реальными людьми, которые этим бы пользовались. И вот ловушка, что губит большинство попыток: люди вежливы. Спросите «вы бы пользовались инструментом, который делает X?» — и почти каждый скажет да, ведь сказать да бесплатно и любезно. Это «да» бесполезно. Оно потопило больше стартапов, чем любой технический сбой.

Решение — перестать спрашивать о будущем и начать спрашивать о прошлом. Будущее — там, где люди лгут из вежливости; прошлое — там, где живёт правда. Вместо «вы бы этим пользовались?» спросите «расскажите о последнем разе, когда вы столкнулись с этой проблемой». Что они сделали? Сколько это заняло времени? Во что им обошлось? Искали ли они решение? Платили ли за него? Реальное поведение всякий раз бьёт гипотетический энтузиазм.

Вопросы, на которые отвечают честно

• «Проведите меня по последнему разу, когда это случилось». — вскрывает реальный рабочий процесс, а не идеализированный.
• «Что вы с этим сделали?» — показывает, действительно ли им не всё равно или они просто отмахиваются.
• «Сколько времени или денег это вам стоило?» — превращает расплывчатую боль в число.
• «Пытались ли вы это исправить раньше? Что вышло?» — говорит, есть ли бюджет и намерение.
• «Что сейчас раздражает вас сильнее этого?» — проверяет, входит ли ваша проблема хотя бы в их первую пятёрку.

Сколько разговоров? Меньше, чем вы думаете. К тому моменту, как вы проведёте десять честных, грамотно построенных интервью с нужными людьми, закономерность обычно очевидна. Либо трое-четверо из них загораются и начинают живо описывать боль, либо все они вежливо прохладны, и никакая хитрая разработка этого не исправит. Двенадцати-пятнадцати вполне достаточно, чтобы принять решение, которому можно доверять.

Дешёвые способы проверить реальный спрос

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

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

1. 1
   Выложите одностраничный питч

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

   Не о «лайке». Попросите людей оставить почту в листе ожидания, оформить предзаказ или записаться на звонок. Чем дороже им сказать да, тем больше это да значит.
3. 3
   Направьте немного честного трафика

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

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

Самый сильный тест спроса из всех — попросить денег вперёд. Предпродажа, платный пилот, предоплата за ранний доступ — всё, при чём открывается кошелёк. Это кажется напористым, и это самое честное, что вы можете сделать для самого себя. Человек, отдающий даже небольшую сумму за продукт, которого ещё не существует, говорит вам то, чего не скажет ни один опрос. Если вы найдёте троих-четверых таких людей, у вас больше нет идеи. У вас есть бизнес, ждущий, когда его построят.

Продайте это, прежде чем построить

Между «людям интересно» и «люди будут платить каждый месяц» есть шаг, заслуживающий отдельного внимания: доставлять ценность вручную, прежде чем её автоматизировать. Если ваша идея — инструмент, который, скажем, превращает беспорядочные письма от поставщиков в аккуратный еженедельный отчёт, сделайте это сначала вручную для трёх-четырёх клиентов. Вы становитесь программой. Это медленно и не масштабируется — и в этом весь смысл: так вы узнаёте, что продукт на самом деле должен делать, прежде чем закрепите это в коде.

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

Честное чтение сигналов

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

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

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

Когда вы действительно готовы строить

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

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

Частые вопросы