Опыт создания Legal Tech продукта

В конце мая настоящего года закрылась сделка по продаже Телеграм-сервиса @infocourt_bot, сооснователем и идейным вдохновителем которого я являюсь.

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

В этой статье я постарался сформулировать ключевые элементы опыта, полученного в результате реализации проекта.

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

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

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

Итак, ключевые выводы:

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

Сервис был запущен 06 декабря 2018 года. Изначально мы создавали сервис, который бы сообщал только о задержке в начале судебных заседаний, и при этом аудитория была предельно понятной: все люди физически находились в здании Арбитражного суда г. Москвы в ожидании своих заседаний.

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

К моменту запуска сервиса в боте насчитывалось более 1000 человек. Это давало надежду на то, что проект «полетит», но было совершенно непонятно, будет ли это, в принципе, работать, и не закидают ли меня помидорами за такую реализацию, за возможные косяки в работе и прочее.

В тот момент я понял, что значит «выйти из зоны комфорта».

Пожалуй, день запуска сервиса оставил самые мощные впечатления, – выхода не было, дата старта была объявлена, и мы запустились.

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

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

Себе я эту мысль иллюстрирую собственным потребительским поведением. Есть, скажем, wi-fi в Московском метро. Им можно пользоваться, не платя денег. Для этого надо сначала просмотреть несколько роликов рекламы. Если ехать одну-две станции, то можно посмотреть рекламу, и не выйдя в интернет выйти из вагона. Это неудобно. Но это бесплатно!

До тех пор, пока я не подписался на тариф без рекламы – я не мог оценить, что Оно того стоит. Я ездил и думал: «Я не буду платить деньги за то, чем могу воспользоваться бесплатно, пускай даже с неудобствами». Мне тогда и в голову не приходило, что я оплачиваю доступ к интернету фактом просмотра рекламы.

Сколько пользователю нужно времени чтобы распробовать продукт? Наверное, столько же, сколько потребовалось мне, чтобы начать платить за услугу wi-fi в метро, подписаться на Netflix, YouTube Premium и иные подобные сервисы.

Совсем коротко эту мысль передает расхожая английская поговорка: «No pain, no gain».

Это, пожалуй, самая сложная составляющая деятельности. Очень динамическая субстанция. Я бы выделил несколько уровней.

· Уровень проекта. В идеале, проект должен быть один. Причем это касается каждого из сооснователей.

· Уровень текущей задачи. Например, ключевым показателем для улучшения функционирования сервиса является конверсия пользователей. Что мы делаем в этом случае? Фокусируемся на увеличении конверсии.

· Уровень текущего ключевого решения. Например, мы знаем, что конверсию увеличит видеомануал по работе с сервисом, – делаем мануал.

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

· В каждый момент времени на каждом из описанных уровней есть Х в степени Y дополнительных вводных: · у каждого сооснователя свои жизненные обстоятельства, свои дополнительные проекты (семья, работа по найму, квартирный вопрос, и далее по списку),

· компетенции членов команды востребованы неравномерно по времени развития проекта. В периоды, когда компетенция не востребована, возникающий вакуум заполняется другими проектами или задачами,

· чтобы определить ключевую задачу или метрику надо каждый раз проверять ряд гипотез. Каждая проверка гипотезы – проект в проекте,

· обратная связь от пользователей может в корне противоречить уже намеченному и согласованному плану действий команды,

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

В качестве соуса к этому салату обстоятельств, я бы добавил эмоциональную составляющую в виде маниакально-депрессивной синусоиды. Нижний пик – все плохо. Верхний пик – мы короли!

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

Как в покере: хорошие игроки чаще скидывают, чем рейзят.

Для начала нового вида деятельности должны существовать очень веские причины.

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

Таков мой опыт, полученный в ходе создания продукта. Уверен, что с полученными знаниями будет легче реализовывать следующие проекты.

Уверен также, что после реализации следующих, будет новый опыт, и новый опыт будет другим.