Илья Лисовский – Азбука основателя. Как создать технологический стартап и подготовить его к сделке с инвестором. Практическое руководство (страница 12)

Переусложнение убивает стартап сразу в нескольких местах.

Во-первых, оно убивает скорость. Пока вы строите «полноценную архитектуру», рынок не ждёт вас с цветами. Клиенты не замерли в ожидании вашего совершенства. Чем дольше вы делаете первую версию, тем дольше живёте не в подтверждённой реальности, а в дорогом предположении.

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

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

В-четвёртых, оно убивает разговор с клиентом. Потому что чем сложнее продукт, тем сложнее объяснить, что именно он делает. А если вы не можете коротко объяснить это клиенту, у вас почти наверняка есть проблема не только с маркетингом, но и с продуктовой логикой.

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

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

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

6.4. Как определить первую полезность для клиента

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

Первая полезность — это не весь будущий эффект продукта во всей его стратегической красоте. Это тот первый ощутимый результат, после которого клиент может сказать: «Да, здесь есть смысл. Это уже помогает».

Именно «уже помогает» — ключевая формулировка.

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

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

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

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

Есть несколько хороших признаков правильно найденной первой полезности.

Она понятна клиенту без длинной лекции.

Она связана с реальной болью, а не с теоретическим улучшением.

Её можно увидеть или измерить.

Она проявляется достаточно быстро.

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

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

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

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

6.5. Почему набор функций ещё не равен ценности

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

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

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

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

Функции — это способ доставки ценности, а не сама ценность. И как только основатель забывает об этом, продукт начинает расти как склад технических возможностей, а не как инструмент пользы.

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

Есть хороший проверочный вопрос для любой новой функции: какую конкретную ценность для клиента она усиливает? Если ответ нечёткий, функцию лучше не делать сейчас. А иногда и вообще не делать.

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

Сильный продукт не обязательно беден на возможности. Но он почти всегда строг в устройстве. В нём есть внутренняя логика. Каждая важная часть работает на общую ценность. Клиент чувствует это очень быстро, даже если не может описать словами. Одни продукты кажутся перегруженными и утомительными. Другие — точными и собранными. Разница обычно не в объёме труда, а в качестве отбора.

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

6.6. Как не строить продукт ради собственного восхищения им

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

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

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

Продукт ради собственного восхищения обычно имеет несколько симптомов.

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