Моё простое УТП для разработки сайтов: делай быстрее, но нормально

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

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

Клиент покупает не наши созвоны и согласования

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

А потом попадает в процесс: созвон, ещё созвон, правки, ожидание текста, обсуждение картинки. Мы вроде заняты, работа идёт, но у человека пока нет инструмента.

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

Если можно убрать лишнее ожидание без потери результата, почему не убрать? Клиенту вряд ли станет хуже от того, что мы организовали процесс понятнее.

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

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

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

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

Но это была гипотеза для определённого продукта. Я не обещаю сделать за пару дней любой магазин со всеми интеграциями. Под такое предложение нужно выбрать соответствующий объём и процесс.

Быстрее — не значит кое-как

Вот здесь главная граница. Если ради срока убрали проверку, оставили кривую мобильную версию и забыли настроить форму, никакого преимущества нет. Ты просто быстрее сдал проблему.

Я хочу ускорять повторяющуюся работу и согласования. Использовать подходящие решения, заранее получать материалы, понимать, кто подтверждает результат. А не требовать от команды не спать.

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

Не путай запуск сайта и гарантированные заявки

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

Поэтому обещание должно быть точным: что мы делаем и к какому моменту. Дальше у бизнеса есть реклама, предложение, работа с обращениями. Если берёшь на себя и это, обсуждай отдельно.

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

Проверь, можешь ли ты сократить путь до результата

Возьми несколько своих последних проектов. Где ждали? Где переделывали без ясной причины? Что можно было согласовать раньше? Какие задачи повторялись?

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

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