Год назад мне показали продукт. Красивый, продуманный, с потрясающим дизайном и безупречной архитектурой. Команда из восьми человек работала над ним одиннадцать месяцев. И он ни разу не видел живого пользователя.
“Мы почти готовы. Ещё месяц-два.”
Я слышал это четыре раза. В марте, в мае, в августе и в октябре. Каждый раз — “ещё месяц-два”. Каждый раз — новые причины: тут подправим дизайн, тут добавим фичу, тут перепишем этот модуль, потому что появилось более элегантное решение.
Продукт так и не вышел.
Анатомия перфекционизма
Со стороны это выглядит как ответственность. Команда хочет сделать хорошо. Не хочет позориться перед пользователями. Заботится о качестве. Звучит правильно, да?
Нет. Это не ответственность. Это страх.
Перфекционизм — это защитный механизм. Защита от чего? От реальной обратной связи. От момента, когда живые люди скажут, что ваш продукт не нужен. Или нужен, но не такой. Или нужен, но не им.
Пока продукт “в разработке” — он идеален в вашей голове. Все сценарии продуманы, все edge cases обработаны, каждый пиксель на месте. Но в тот момент, когда вы показываете его реальному пользователю — иллюзия рассыпается. Пользователю плевать на вашу архитектуру. Ему важно, решает ли ваш продукт его проблему. И часто ответ — нет.
Это больно. И перфекционизм — способ эту боль отложить. “Ещё месяц-два” — и продукт станет настолько хорош, что критики не будет. Спойлер: критика будет всегда. Вопрос в том, получите вы её через три месяца или через три года.
Цена ожидания
Давайте посчитаем. Команда из восьми человек. Средняя зарплата — двести пятьдесят тысяч рублей. Плюс налоги, офис, оборудование — умножаем на полтора. Итого: три миллиона в месяц. За одиннадцать месяцев — тридцать три миллиона рублей.
Тридцать три миллиона, потраченных на продукт, который ни разу не проверили на реальных пользователях.
А теперь представьте альтернативу. Через два месяца — минимально работающая версия. Показали десяти пользователям. Получили обратную связь. Оказалось, что три из пяти запланированных фич никому не нужны, зато нужна одна, о которой вы не думали.
Через четыре месяца — вторая версия. Уже с учётом реальных потребностей. Двадцать пользователей. Первые платящие клиенты. Реальные данные вместо гипотез.
Разница — двадцать пять миллионов рублей и, что важнее, семь месяцев жизни.
Признаки перфекционизма в команде
Я научился замечать их рано.
“Давайте сначала доведём до ума, потом покажем.” Классика. Нет такого состояния “до ума”. Есть состояние “достаточно хорошо, чтобы получить обратную связь”. Это два разных стандарта.
“Нам стыдно показывать это в таком виде.” Если вам не стыдно за первую версию — вы запустились слишком поздно. Не я придумал, но подписываюсь.
“Конкуренты сделали лучше, нам нужно догнать.” Конкуренты делают продукт три года. Вы не догоните за месяц. И не нужно. Ваше преимущество — в скорости обучения, а не в количестве фич.
“Пользователи не поймут, что мы хотели сказать.” Так поговорите с ними и узнайте, что ОНИ хотят. А не додумывайте за них.
Решение: жёсткий дедлайн запуска
Единственное лекарство от перфекционизма — жёсткий, немовабельный дедлайн запуска.
Не “примерно в марте”. Не “когда будет готово”. А конкретная дата. Пятнадцатое число. И к этой дате продукт выходит. Не идеальный — работающий.
Критерий запуска должен быть не “идеально ли это?”, а “достаточно ли это хорошо, чтобы дать ценность?” Это другой вопрос. И он ведёт к другим решениям.
Когда у вас есть жёсткая дата, вы начинаете приоритизировать. Что действительно важно для первой версии, а что может подождать? Какие фичи критичны, а какие — “было бы неплохо”? Вы вынуждены принимать решения. А перфекционизм — это, по сути, отказ принимать решения. “Мы сделаем всё” — это отсутствие приоритетов.
Практический рецепт
Определите минимальный набор ценности. Не минимальный набор фич, а минимальный набор ценности. Что ваш продукт должен сделать, чтобы один конкретный пользователь сказал: “Это полезно”? Вот это и есть ваш MVP.
Установите дату запуска и привяжите к ней что-то необратимое. Анонс клиентам. Договорённость с партнёром. Публичное обещание. Что-то, что нельзя перенести без репутационных потерь.
Разделите команду на “до запуска” и “после запуска”. Одна часть доводит MVP до рабочего состояния. Другая — готовит план развития после обратной связи. Это снимает тревогу: мы не бросаем качество, мы откладываем его на осознанный этап.
И помните: первая версия — это не финальный продукт. Это инструмент обучения. Вы запускаете не для того, чтобы заработать миллионы. Вы запускаете, чтобы узнать, что нужно рынку. Когда вы смотрите на первую версию как на эксперимент, а не как на витрину — перфекционизм отступает.
Напоследок
Тот продукт, о котором я рассказал в начале, в итоге вышел. Через полтора года после начала разработки. К этому моменту рынок изменился, конкурент занял нишу, а у команды кончилась мотивация. Запустились тихо. Без фанфар. Набрали двадцать пользователей за первый месяц.
Двадцать пользователей за полтора года работы. Если бы запустились через три месяца — могли бы получить двадцать пользователей за три месяца. И ещё год — на доработку продукта с учётом их обратной связи.
Перфекционизм не улучшает продукт. Он убивает его. Медленно, красиво и с ощущением, что “мы всё делаем правильно”.