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

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

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

Часть II. Продукт и рынок: как появляется реальная ценность

Глава 6. От идеи к продукту: первая полезная версия

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

Почему? Потому что слово «сделать» звучит слишком просто. На практике между идеей и продуктом лежит не только разработка, дизайн, интерфейс и техническая сборка. Между ними лежит вопрос куда более серьёзный: что именно должно появиться в первой версии, чтобы клиент действительно получил пользу, а вы — доказательство того, что движетесь не в сторону красивой игрушки, а в сторону компании.

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

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

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

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

6.1. Что такое минимально жизнеспособный продукт

Термин «минимально жизнеспособный продукт» часто понимают неправильно. Одни думают, что это почти готовый продукт, просто чуть короче. Другие — что это можно сделать кое-как, лишь бы показать хоть что-нибудь. Обе трактовки опасны.

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

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

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

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

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

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

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

В этом и состоит зрелый подход к продукту. Не спрашивать: «Насколько это уже похоже на большую компанию?» Спрашивать: «Насколько это уже решает важную задачу клиента?»

6.2. Что должно войти в первую версию, а что пока не нужно

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

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

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

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

В первую версию обычно должны входить пять вещей.

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

Второе — основная полезная логика. То есть тот механизм, ради которого продукт вообще создаётся.

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

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

Пятое — возможность увидеть результат. Продукт не должен просто «работать внутри». Он должен выводить клиента к ощутимому эффекту.

А что пока не нужно? Почти всё, что не влияет напрямую на проверку главной ценности.

Не нужны сложные настройки для редких случаев.

Не нужны широкие роли и права доступа «на будущее».

Не нужны интеграции, без которых можно обойтись на первом этапе.

Не нужна избыточная аналитика, если вы ещё не доказали базовый сценарий.

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

Не нужен функционал «на всякий случай».

И особенно не нужно всё, что рождается из страха показаться слишком маленькими.

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

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

6.3. Почему переусложнение убивает скорость и ясность

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