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

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

Готовность платить — это не эмоция. Это поведение. И основатель, который хочет построить дорогой актив, должен научиться отличать одно от другого.

2.4. Что является гипотезой, а что уже можно считать фактом

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

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

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

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

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

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

Полезно делить свои утверждения на четыре уровня.

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

Второй уровень — наблюдение. «Я видел это в нескольких компаниях или разговорах». Уже лучше, но пока слишком слабо.

Третий уровень — подтверждённая гипотеза. «Мы поговорили с нужным сегментом, увидели повторяемость, получили одинаковые сигналы, поняли последствия и начали видеть признаки спроса». Это уже рабочая почва.

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

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

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

2.5. Как не влюбиться в решение раньше, чем вы поняли проблему

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

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

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

Есть несколько простых правил, которые здесь очень помогают.

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

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

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

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

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

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

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

2.6. Как описать проблему так, чтобы её понял и клиент, и инвестор

Одно из самых ценных умений основателя — уметь ясно описывать проблему. Не туманно, не длинно, не с интеллектуальными украшениями, не с модными словами ради солидности. А ясно.

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

Хорошее описание проблемы должно отвечать на несколько вопросов.

Кто именно с ней сталкивается.

В какой ситуации она возникает.

Почему она действительно мешает.

Во что она обходится.

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

Когда вы отвечаете на эти вопросы, проблема перестаёт быть абстракцией. Она становится деловой реальностью.

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

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

Клиенту важно услышать в вашем описании узнаваемость. Он должен подумать: «Да, это про нас». Инвестору важно услышать в нём экономику и масштабируемость. Он должен подумать: «Да, проблема реальна, повторяема и за её решение действительно могут платить».

Поэтому одно и то же ядро проблемы нужно уметь выражать и по-человечески, и по-деловому. Но суть должна оставаться одной.

Есть простая рабочая формула: